Hallo zusammen,

ich habe soeben Version 0.8.0 auf NPM veröffentlicht. Als funktionale Änderung gibt es nur eine kleine Verbesserung beim Dekoder für PRIOS codierte Telegramme (@marsmännchen )
Im Hintergrund wird jetzt v10 der SerialPort Bibliothek verwendet und das Handling der seriellen Kommunikation mit den unterschiedlichen Sticks wurde komplett neugeschrieben (und funktioniert hoffentlich noch ).

Falls es nicht "läuft" bitte ein "Debug Log" posten und im Zweifelsfall zurück auf 0.7.9. wechseln.

Hallo zusammen,

vor weg eine kleine Bitte. Ich ziertiere mich mal selbst:

@lvogt said in Test Adapter wireless-mbus v0.7.x:

ich habe gerade v0.7.9 auf npm publiziert. Die Version bringt nichts neues für euch - aber für mich
Und zwar werden im Debug Log nun sämtliche "Nachrichten" zw. Adapter und "USB Stick" geloggt. Ich hätte gerne von den 4 unterstützten Empfängsmodulen jeweils von 1 oder 2 Nutzern das Log vom Adapterstart und wenn es geht auch noch von einem empfangenen Telegramm. Gerne als PN (oder Chat wie es hier im Forum heißt) direkt an mich.
Warum das ganze? Wie ich ja schon mal erwähnt habe, besitze ich kein einziges dieser Geräte selber. Ich möchte aber gerne mal den Code der die Kommunikation zw Adapter und USB Gerät handhabt aufräumen. (Teilweise sind da wirklich furchtbare Konstrukte drin...)
Dazu habe ich bereits angefangen Simulatoren für die Geräte zu schreiben. Um sicher zu gehen, dass ich da keine falschen Annahmen einbauen hätte ich gerne noch mal einen abgleich mit der Realität.
Gestern beim Lesen des Codes für den gerade diskutierten IMST Stick zB konnte ich mir bei einigen Teilen gar nicht vorstellen, dass es funktioniert...

Aktueller Zwischenstand:

• IMST iU819A 0/2
• CUL 1/2
• IMST 1/2
• Amber 0/2
• Embit 0/2 (falls die Hardware hier überhaupt jemand verwendet...)

ich habe einen (teilweise) neuen wireless M-Bus Adapter geschrieben. Teilweise bezieht sich darauf, dass ich mich bei diversen anderen Projekten bedient habe (unter anderem beim alten wm-bus und beim mbus Adapter).
Das Paket orientiert sich am ioBroker.mbus Adapter was die Struktur der Datenpunkte angeht - nicht an der merkwürdigen Aufteilung von Wert und Einheit, wie sie der wm-bus Adapter vornimmt.
Generell basiert der Parser für wMBus Telegramme in seinen Wurzeln noch auf der Implementierung aus dem wm-bus Adapter, wurde aber deutlich erweitert und verbessert.

Unterstützt werden Module von Amber Wireless, IMST und Embit - CUL Unterstützung ist vorhanden, aber sucht noch weitere Tester!.

https://github.com/lvogt/ioBroker.wireless-mbus

Der Adapter ist mittlerweile auch bei npm und im latest ioBroker Repository verfügbar.

Die ursprüngliche Version befindet sich hier (funktioniert mit NodeJS v12 nicht mehr)
https://github.com/ISFH/ioBroker.wmbus

@lenny-cb Danke für den Hinweis. Ich habe gerade mal noch einen "mini-fix" dafür eingebaut, der allerdings nur greift für States die neu erstellt werden. Da wird dann der Typ auf 'mixed' gesetzt.

Außerdem bin ich recht überzeugt, dass der CUL Support funktionieren müssste. Es wäre also schön wenn es mal jemand ausprobieren würde.

Ich habe das ganze jetzt auch als v0.6.0 getaggt und im ersten Post verlinkt. Aber Achtung das "original" ISFH git enthält weiterhin die "alte" 0.5.2er Version!

@simps

Hi Simps,

grundsätzlich habe ich beim Entwickeln sehr viel mit dem Amber Stick getestet. Die meiste Zeit im T Mode, da fand ich ihn sehr stabil. Später musste ich dann feststellen, dass er im C Mode gerne mal "abstürzt" (also der Stick selbst), sodass einmal aus dem USB Port ziehen, kurz warten, wieder einstecken nötig war.
Ich selbst verwende den Adapter allerdings schon eine ganze Weile nicht mehr.

Zum HKV kann ich nicht wirklich was sagen. Auf den ersten Blick behaupten die HKV auf der von dir verlinkten Seite sie würde OMS konform senden, das sollte heißen, dass der Adapter damit auch was anfangen kann - garantieren kann ich dir das natürlich nicht. Grundsätzlich möchte ich aber auch nochmal darauf hinweisen, dass du damit ja keine direkten Verbräuche oder Energien messen kannst.

Ja das Installfenster im ioBroker finde ich auch nicht besonders gelungen. Die beiden von dir versuchten Varianten (so weit ich das verstanden habe) erlauben dir nur einen Adapter, der sich bereits in der ioBroker Adapter Liste befindet, wahlweise von GitHub oder npm zu installieren.

So lange dieser Adapter also noch nicht in die Liste aufgenommen wurde, musst du "Benutzerdefiniert" in dem Fenstern auswählen. Als "URL" kannst du entweder nur "iobroker.wireless-mbus" angeben, dann wird der Adapter von npm installiert, oder du gibst den ganzen Pfad zum github Repository an. Sollte am Ende aber aufs gleiche rauskommen.

@ratte-rizzo

Hi,

ja die Einträge müssen wie die Keys vom Typ LSE-25342905 sein. Wenn du die Blockliste speicherst wird der Adapter ja sowieso neugestartet. Danach kannst du dann einfach den LSE-25342905 Knoten im Objektbaum löschen und es sollte nie wieder auftauchen.

Eine Hinweis bzw eine Ausname gibt es noch: Manche Telegramme senden unter der ID eines externen wMBus Sendemoduls die Telegramm und erst im "Application Layer" steht die eigentlich ID des Geräts. Im Objektbaum taucht die "eigentliche ID" auf, aber zum blockieren muss die "erste ID" angegeben werden. (Das gilt übrigens auch für AES Schlüssel.)
Der Haken: Im Moment kann man ohne selbst Hand anzulegen die ID nicht in ioBroker sehen. (Bei AES Schlüsseln ist das einfacher - da wird ja automatisch der "UNKNOWN" Key Eintrang angelegt...)

Die geänderten Loglevel sind wahrscheinlich keine schlechte Idee. Werde mir bei Gelegenheit nochmal insgesamt die Logausgabe vornehmen.

@ratte-rizzo

Hi ja, ich werde das in nächste Zeit mal nach anpassen. Ich glaube ich hatte das schon mal angekündigt, aber dann leider vergessen

@MartyBr

Vor einer Weile hat Diehl mal bei allen Zählern den selben Key verwendet. Wenn man passend sucht findet man dazu auch was. Ich möchte den nicht gerne hier posten, da er zB im FHEM Forum auf "Nachfrage" gelöscht wurde...
Aber mal ganz hypothetisch, wenn man jetzt zb Loxone statt ioBroker verwenden würde und man sich zB fragen würde "HowTo Diehl Hydrus mit loxone" dann hätte man vl. weniger Probleme den Key zu finden...

Ob der Key (immer noch) funktioniert weiß ich natürlich nicht. Ein Versuch wäre es aber wert...

@gizmodlx

Du kannst auch eine Regel für udev anlegen

(Als root bzw. mit sudo) Die Datei /etc/udev/rules.d/99-imst.rules anlegen und das muss rein:

ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="87ed", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id'"

Ohne Garantie dass das so 100% korrekt ist.

EDIT: Ich hatte da ursprünglich auch einen Einzeiler stehen - aber der entfernt wohl die Anführungszeichen - dann ist udev damit glaube ich nicht mehr zufrieden.

EDIT2: Das scheint zu funktionieren:

sudo bash -c "echo \$'ACTION==\"add\", ATTRS{idVendor}==\"10c4\", ATTRS{idProduct}==\"87ed\", RUN+=\"/sbin/modprobe cp210x\" RUN+=\"/bin/sh -c \\'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id\\'\"' > /etc/udev/rules.d/99-imst.rules"

@marsmännchen

sudo modprobe cp210x
sudo bash -c "echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id"

oder so änhlich. Danach bitte dmesg um zu gucken ob ein /dev/ttyUSBn device angelegt wurde.

@ratte-rizzo
Wie ich im Thread ab und zu schon mal erwähne, verwende ich den Adapter und sogar ioBroker einfach gar nicht selbst. Ich habe den Adapter ursprünglich im Rahmen meiner alten Arbeitsstelle geschrieben und ihn nach einer Weile "einfach so" weiter gepflegt.

Empfehlung zur Hardware kann ich daher kaum geben. "Damals" habe ich recht viel beim Testen den Amber Stick verwendet. Der hat ja zB auch diesen praktischen Mode der C und T gleichzeitig kann (hatte damit aber auch ab und zu Hardware(?) Problem). Der tatsächliche produktive Einsatz erfolgte dann mit der Embit Hardware, die aber - soweit ich weiß - nicht als USB Stick sondern nur direkt verbaut in irgendwelchem "Embedded Systemen" zu finden ist.

Der Amber Stick ist mittlerweile glaube ich aber gar nicht mehr so gut zu bekommen. Was recht gut zu bekommen ist, ist der IMST Stick von "alten" RWE SmartHome Angeboten auf eBay oä. Da muss man unter Linux noch ein bisschen was mit udev machen, damit der korrekte Treiber geladen wird (irgendwo hier im Thread zu finden), aber dann sollte es keine Probleme damit geben.

Der von dir gerade etwas in Zweifel gezogene CUL hat auch ein "inoffizielles" Update (auch schon nicht mehr ganz neu) das auch den C Mode bzw. eigentlichen einen C und T Mode implementiert verpasst bekommen. Wenn man also einen kombinierten Mode gebrauchen kann, ist das schon keine schlechte Wahl denke ich.

@cs
Ja das ist offensichtlich eine völlige andere Fehlermeldung...

Du musst den Cache für Kompakt-Telegramme in den Einstellungen einschalten. Ich sollte das mal "automatisieren"...

Ich habe nochmal etwas herum gesucht. Meine aktuelle Vermutung ist, dass es daran liegt, dass der Stick als "ACM CDC" class device erkannt wird (ttyACM0x anstatt ttyUSBx).

U.a. konfiguriert der Kerneltreiber einige defaults die hier vl. Probleme machen (zB siehe hier).

Falls es an "sowas" liegt, müsste vermutlich die tty Konfiguration vor der Verwendung durch den Adapter angepasst werden - im Idealfall würde es reichen die vor der Verwendung durch den Adapter zu setzen (zB durch eine udev Regel).
Aber ich habe damit auch zu wenig Erfahrung um das "blind" zu tun, sondern müsste dazu vermutlich etwas herum probieren - und im Zweifelsfall die wmbusmeters Konfiguration kopieren...

@gammawar said in Test Adapter wireless-mbus v0.10.x:

@lvogt
Hallo,
habe es gerade mit Putty versucht, jetzt kam dies raus:
dialout20:wmbusmeters,iobroker,root

vorher habe ich es über die Proxmoxshell gemacht. Da kommt komischerweise nichts.

Hm, ok. Das sieht eigentlich ok aus. Dann fällt es mir auch langsam schwer aus der Ferne zu helfen.

Es gibt dann wohl am Ende nur zwei Möglichkeiten, entweder ist es immer noch ein "Permission Problem auf Linux" Ebene oder ich habe irgendwas grundlegend falsch gemacht beim Support for den neuen IMST Stick. Aber auch da komme ich dann ohne Hardware ohne weiteres nicht weiter...

@norb-0 said in Test Adapter wireless-mbus v0.10.x:

@lvogt sagte in Test Adapter wireless-mbus v0.10.x:

@norb-0 Läuft 0.10.0 jetzt auch stabil?

ja, 0.10.0 läuft stabil, bis dato keine Fehlermeldungen

Danke. Dann werde ich mal die 0.10.0 als neue "stable" Version setzen.

@gammawar

cat /etc/group | grep dialout

Das kann eigentlich nicht sein. Die Ausgabe des id Befehls sagt ja, dass mindestens root Mitglied der dialout Gruppe ist...

@norb-0 Läuft 0.10.0 jetzt auch stabil?

@gammawar Aber root ist nicht der Account unter dem ioBroker läuft oder?

Was gibt cat /etc/group | grep dialout für eine Ausgabe?

Und läuft ioBroker evtl. im Docker Container?

Hm, dann mache ich evtl. etwas falsch bei öffnen des ttyACM0 Ports falsch.

Ich kann mal versuchen ob ich dazu irgendwas finde - aber evtl. komme ich hier ohne Hardware einfach nicht weiter...

kannst du evl. mal noch die Ausgaben von ls -l /dev/ttyACM0 und id posten?

v0.10.0 mit "ungetestem" Support für den iU819A Stick ist jetzt auf npm.

Ich hatte ja eigentlich gehofft es würde vorher hier noch eine Erfolgsmeldung geben, aber ich bin leider recht sicher, dass die bisher geposteten Probleme schon "vor ioBroker" anfangen.

Da für jemanden mit "altem" Receiver sollte die Version 0.10.0 aber sowieso keine Schwierigkeiten machen sollte, habe ich mich jetzt entschlossen die Version auch korrekt zu veröffentlichen.

@chief42

Die Fehler die da im Log auftauchen kommen direkt von der serialport Library. Da stimmt definitiv irgendwas nicht mit deinem Setup. Im Zweifelsfall könnte es auch irgendein Bug sein.

Im Github Repository gibt es jemand er evtl. mit diesem Bug hier zu kämpfen hat: https://github.com/serialport/node-serialport/issues/2735 - bei dir sieht es danach aber eher nicht aus...

@chief42

Das sind Probleme die definitiv "vor dem Adapter" anfangen. Da kann ich dir nicht helfen.

@wutschkooo

Es gibt jetzt auf GitHub (nicht auf npm!) eine Version mit Unterstützung für den iU891A-XL. Das ist aktuell aber eine Version die ich ausschließlich anhand der Dokumentation geschrieben habe - das muss also unbedingt von jemanden auch mal mit echter Hardware getestet werden.

Außerdem hätte ich gerne ein DEBUG(!) Log vom Start des Adapters und idealerweise auch mit Telegramm Empfang.