NEWS
Test Adapter wireless-mbus v0.9.x
-
@lvogt, ach ja und unterstützt Deine Implementierung "Generation 3 Profil A/ Generation 4 Profil B"?
Nochmal Danke,
Oliver -
@lvogt Hallo danke für die Antwort. Denn AES Key habe ich den Stick muss ich mir erst besorgen.
-
@olixatiobroker
Die Zeile mitMessage received
ist das vollständige Telegram als Hexstring. Die OMS Spezifikation gibt's hier: https://oms-group.org/open-metering-system/oms-spezifikation
Zum Großteil (der - bisher - relevante Teil) wird das vom Adapter auch unterstützt. Ich bleibe aber dabei dass irgendwas grundsätzlich schief läuft da das "f" in der Zähler ID eigentlich schon dem absoluten "Minimum" als MBUS bzw. EN 13757-2 widerspricht. -
Habe einen nanoCUL mit Firmware M-Bus (Version nanoCul_r568_mbus_c1t1_bufsize300) gekauft.
Verbindung mit dem Adapter ist "grün" aber bekommen keine Daten im Debug.Gibt es einen Unterschied der M-Bus Firmware ob für FHEM oder iobroker?
Oder was habe ich für ein Probehm?
-
@wolfi gar keine Ausgaben im Debug Log?
Grundsätzlich klingt es für mich aber nach: Messgerät sendet nicht oder auf anderem Modus als erwartet...
-
So wie es aussieht handelt es sich um Empfangs Probleme!
Es kommen jetzt Daten rein! Mehrheitlich von den Nachbarn weniger von meinem eigenen Wasserzähler.Zähler im Keller Empfänger im 1 OG
Ich probiere mal eine größere Antenne.
Und den AES Key brauche ich auch noch.Gruß
-
@fzzybllz Bei uns wurden letztes Jahr ebenfalls die allmess Integral-V UltraLite PRO Wärmemengenzähler installiert und ich beabsichtige mir die EquaScan hMIU RF zu installieren damit die Wärmemengenzähler über Wireless M-Bus fernablesbar sind.
Hast Du es mittlerweile geschafft alle Daten auszulesen? -
Bei uns wurden Allmess Integral-V UltraLite PRO Wärmemengenzähler installiert und ich habe ein Funkmodul EquaScan hMIU RF zum Auslesen des Wärmemengenzählers mittles Wireless-MBus montiert.
Beim Funkmodul EquaScan hMIU RF mit der Atikelnummer 8030C03106 ist die Verschlüsselung werkseiting ausgeschalten, man braucht laut dem technischen Support von Allmess keinen AES-Schlüssel.
Ich verwende den IMST iM871A USB-Stick.
Laut Beschreibung des EquaScan Funkmoduls ist die Betriebsart C2-Mode. Ich vermute mal das entspricht dem wMBus Mode 'C Mode (Frame type B)' in der Instanz des Wireless MBus Adapters?!?
Laut dem Allmess technischen Support sendet das Funkmodul EquaScan hMIU RF nach der Montage für 10 Minuten automatisch. Dann sendet das Modul ab dem Stichtagsmonat (je nachdem wie das Modul programmiert ist) für 56 Tage alle 2 Minuten ein Telegramm, danach nur noch alle 10 Minuten.In den Objekten sehe ich für den WirelessMBus nur den Status der Verbindung (connection) und die rawdata. Bei rawdata kamen nach der Montage für 10 Minuten alle 2 Minuten Daten an, dann war aber Schluß (am 05.01.2023)!
Wie ist es eigentlich gedacht???
Muss ich die rawdata mittels Skript selbst interpretieren und dann für jedes Funkmodul der Wärmemengenzähler die einzelnen Werte herausfiltern oder kann der Adapter in der Richtung etwas tun wenn man ihm sagt um welches Gerät es sich handelt?!
Hier komme ich nicht weiter und wäre für Hilfe dankbar. -
@jufu Wer lesen kann ist klar im Vorteil!
In der Info des Adapters steht: "Wenn der Parser fehlschlägt, werden die Rohdaten des Telegramms im Zustand info.rawdata gespeichert.
Wenn 10 aufeinanderfolgende Telegramme desselben Geräts nicht erfolgreich geparst werden, wird das Gerät bis zum Neustart des Adapters ignoriert (Standard: Ein)"
Das erklärt warum keine Datenmehr kamen!
Nach dem Neustart der Instanz kommen auch wieder aktuelle Daten (rawdata).
Gibt es eine Möglichkeit dem Parser die Datenstruktur mitzuteilen sodass er sie parsen kann??? -
@jufu
Vermutlich ist bereits alles erledigt, wenn du "C Mode (frame type A)" auswählst. Wenn nicht, dann wäre mal ein Log Auszug im Debug Modus, wenn der Adapter ein Telegramm empfangen hat, sinnvoll.Und nein du kannst den Adapter nicht mitteilen wie die Struktur aussieht. (Wobei es dir - wie jemdem anderen auch - natürlich frei steht den Adapter Quellcode zu nehmen und anzupassen...)
-
@lvogt
Ich habe den Mode umgeschalten und das Debug war noch an ...
Hier das log-file:
iobroker.2023-01-10.log.htm -
@jufu
Der Wechsel des Frametypes war jedenfalls schon mal richtig wie ich sehe.
Danach gibt es allerdings noch weitere Probleme. Der Parser hängt sich an einem nicht implementiert LVAR Typ auf.Die Spezifikation ist dazu auch sehr vage... da in deinem Telegramm der VIF dazu aber sowieso als Herstellerspezifisch markiert ist, ist sowieso nicht ganz klar was der Wert enthalten soll...
Ich habe jetzt jedenfalls den Parser angepasst, sodass das Telegramm wenigstens auch bis zum Ende geparst wird. Aktuell sind die Änderungen nur auf GitHub (https://github.com/lvogt/ioBroker.wireless-mbus). Weißt du wie du den Adapter von da installierst? Falls nicht, kann ich die Änderungen auch auf npm publizieren, aber mir wäre es lieber wenn du das ganze erstmal so testen könntest...
Einige Datumsangabe sehen auch etwas fragwürdig aus. Hast du ein Handbuch wo drin steht was genau im Telegramm drin stehen soll? Wenn nicht, wird es vermutlich nicht besser als der aktuelle Stand....
-
@lvogt said in Test Adapter wireless-mbus v0.8.x:
Das bringt mich doch schon mal deutlich weiter!
Ganz herzlichen Dank dafür! -
@lvogt said in Test Adapter wireless-mbus v0.8.x:
Einige Datumsangabe sehen auch etwas fragwürdig aus. Hast du ein Handbuch wo drin steht was genau im Telegramm drin stehen soll? Wenn nicht, wird es vermutlich nicht besser als der aktuelle Stand....
Ich schicke Dir gerne die Telegrammspezifikation des Funkmoduls.
Bitte schau mal in Deinen Chat. -
Hallo,
ich hab nun den ganzen Thread durchgelesen und mir endlich eine wM-Bus-Stick geholt (WiMOD-iM871A). Einen Wasserzähler von der Zählerplattform kam gestern.
Den USB-Stick hat meine Debian iobroker Installation problemlos erkannt, Adapter-Version ist die letzte von github 0.8.7. Anschluß ist /dev/ttyUSB6 und ein Symlink ist erstellt, funktioniert auch. Der Adapter wird grün, allerdings kommen scheinbar keine Daten vom Zähler bzw. können nicht geparst werden. Der Zähler ist zwar nicht eingebaut, aber die Funkschnittstelle ist wohl eingeschalten. Ich hab keinen AES-Key bekommen und nun bei Zählerplattform angefragt, ob ich einen benötige. Der Zähler funkt nach OMS 3.0.1 C1/T1 (vielleicht auch nach 4.0.2 oder neuer).
Hat jemand diese Konstellation schon am Laufen und kann mir da auf die Sprünge helfen?Im Log steht folgendes:
2023-01-13 12:10:00.893 - debug: wireless-mbus.0 (4174326) Redis Objects: Use Redis connection: 0.0.0.0:9001 2023-01-13 12:10:00.969 - debug: wireless-mbus.0 (4174326) Objects client ready ... initialize now 2023-01-13 12:10:01.015 - debug: wireless-mbus.0 (4174326) Objects create System PubSub Client 2023-01-13 12:10:01.016 - debug: wireless-mbus.0 (4174326) Objects create User PubSub Client 2023-01-13 12:10:01.148 - debug: wireless-mbus.0 (4174326) Objects client initialize lua scripts 2023-01-13 12:10:01.174 - debug: wireless-mbus.0 (4174326) Objects connected to redis: 0.0.0.0:9001 2023-01-13 12:10:01.253 - debug: wireless-mbus.0 (4174326) Redis States: Use Redis connection: 0.0.0.0:9000 2023-01-13 12:10:01.402 - debug: wireless-mbus.0 (4174326) States create System PubSub Client 2023-01-13 12:10:01.404 - debug: wireless-mbus.0 (4174326) States create User PubSub Client 2023-01-13 12:10:01.537 - debug: wireless-mbus.0 (4174326) States connected to redis: 0.0.0.0:9000 2023-01-13 12:10:02.546 - info: wireless-mbus.0 (4174326) starting. Version 0.8.7 (non-npm: lvogt/ioBroker.wireless-mbus#43caf409549446307f40255c66e1f58a43a9b1a1) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v16.19.0, js-controller: 4.0.24 2023-01-13 12:10:02.694 - debug: wireless-mbus.0 (4174326) Created device of type: IMST iM871A 2023-01-13 12:10:02.701 - debug: wireless-mbus.0 (4174326) IMST: TX: a581030600030006080005ef 2023-01-13 12:10:02.712 - debug: wireless-mbus.0 (4174326) IMST: RX: a58104009cf7 2023-01-13 12:10:02.715 - info: wireless-mbus.0 (4174326) IMST: Receiver set to CA-MODE 2023-01-13 12:10:02.729 - debug: wireless-mbus.0 (4174326) connected set to true 2023-01-13 12:10:02.775 - debug: wireless-mbus.0 (4174326) connected set to true 2023-01-13 12:10:02.843 - debug: wireless-mbus.0 (4174326) IMST: RX: a582032e44fa125545011900067a3400202595d3503a812e74041b549c1582fcb11c2362d314283194422bd014d0afd1301be802 2023-01-13 12:10:02.844 - debug: wireless-mbus.0 (4174326) IMST: Message received: a582032e44fa125545011900067a3400202595d3503a812e74041b549c1582fcb11c2362d314283194422bd014d0afd1301be802 2023-01-13 12:10:02.846 - debug: wireless-mbus.0 (4174326) 2e44fa125545011900067a3400202595d3503a812e74041b549c1582fcb11c2362d314283194422bd014d0afd1301b 2023-01-13 12:10:02.848 - debug: wireless-mbus.0 (4174326) Short header 2023-01-13 12:10:02.850 - error: wireless-mbus.0 (4174326) encrypted message and no aeskey provided 2023-01-13 12:10:02.851 - debug: wireless-mbus.0 (4174326) Parser failed to parse telegram from device DWZ-19014555
Vielen Dank schon mal im Vorraus
-
@jgoller
Sorry, aber hast du mal versucht das Log zu lesen? Da ist ein Telegramm empfangen worden, aber die vorletzte Zeile sagt ja explizit, dass es verschlüsselt ist und kein Schlüssel konfiguriert wurde...@JuFu danke schön für die Tabellen. Ich hatte bisher nur kurz Zeit reinzugucken. Interessant dass man tatsächlich den Hersteller spezifischen Teil aufschlüsselt, aber ich glaube ich kann das nicht gut mit einbauen. Ich muss mir das aber nochmal in Ruhe angucken
-
@lvogt Habe das Log leider nicht wirklich dahingehend verstanden, das ein AES unbedingt benötigt wird. Hätte ich mal übersetzen lassen sollen.
Bei zählerplattform habe ich nachgefragt, die schicken mir einen AES-Key passend zur Seriennummer des Zählers. Wird wohl erst nächste Woche passieren.
Dann bin ich mal guter Dinge, das die Daten im iobroker über den Adapter korrekt ankommen.
Vielen Dank für den Adapter und die großartige Arbeit. Das hilft meinem Vorhaben deutlich.
Schönes WE -
@lvogt said in Test Adapter wireless-mbus v0.8.x:
@JuFu danke schön für die Tabellen. Ich hatte bisher nur kurz Zeit reinzugucken. Interessant dass man tatsächlich den Hersteller spezifischen Teil aufschlüsselt, aber ich glaube ich kann das nicht gut mit einbauen. Ich muss mir das aber nochmal in Ruhe angucken
Das mit dem Hersteller spezifischen Teil muss nicht unbedingt sein, da wäre lediglich die Restlaufzeit der Batterie und die Betriebszeit interessant.
Aber wenn Du nochmals reinschaust wäre es super wenn das 'wireless-mbus.0.ITW-22210430.data.3-0-VIF_TIME_POINT_DATE_TIME' entsprechend deren Spezifikation dekodiert würde. Zur Zeit stimmt Datum/Uhrzeit nicht. -
@jufu Ja das ist genau der Punkt den ich mehr näher ansehen wollte. Ich habe das jetzt auch eingebaut - und ich hoffe mal die anderen Zeitstempelformate funktionieren alle noch...
Im Moment ist das gerade noch weiterhin nur auf GitHub als 0.8.8 verfügbar. Wenn der Adapter bei dir jetzt sinnvolle Ergebnisse liefert wirds auf npm geschoben.
Die Daten, die dich aus dem Herstellerspeziischen Teil interessieren, könntest du dir ja auch mit einem kurzen eigenen Skript aus dem Datenpunkt rausholen - das sollte ja eigentlich relativ gut gehen.
-
@lvogt said in Test Adapter wireless-mbus v0.8.x:
Ja das ist genau der Punkt den ich mehr näher ansehen wollte. Ich habe das jetzt auch eingebaut - und ich hoffe mal die anderen Zeitstempelformate funktionieren alle noch...
Das schaut doch jetzt richtig gut aus!
Vielen Dank für die Korrektur.