Test Adapter wireless-mbus v0.9.x

[Meldb]

Hallo kann ich mit diesem Adapter u. dem Cul 868 auch den Wasserzähler Kamstrup flowIQ 2200 Auslesen?

[olixAtiobroker]

Hallo, erstmal vielen lieben Dank für diesen Adapter!
Ich habe eine Diehl Sharky 775, den ich gerne mit dem CUL Stick auslesen würde. Prinzipiell scheinen der Stick und der Adapter die Daten auch zu empfangen, allerdings erhalte ich immer folgende Message:

Parser failed to parse telegram from device HYD-2788042f

Hat schon mal jemand den Sharky Wärmezähler erfolgreich eingebunden?
Bevor ich mich in wireless M-Bus und OMS einarbeite, wollte ich mal fragen ob jemand was mit der Message-Struktur unten anfangen kann und mir sagen, ob es eine gewisse Erfolgsaussicht zur Unterstützung gibt?
Ich kann gerne bei einer Umsetzung unterstützen.
Danke und Grüße,
Oliver
Hier das komplette Log:

2022-10-03 22:18:58.201 - info: wireless-mbus.0 (27585) starting. Version 0.8.5 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.18.1, js-controller: 4.0.19
2022-10-03 22:18:58.312 - debug: wireless-mbus.0 (27585) Created device of type: CUL
2022-10-03 22:18:58.321 - debug: wireless-mbus.0 (27585) CUL: TX: 560d0a
2022-10-03 22:18:58.338 - debug: wireless-mbus.0 (27585) CUL: RX: 000a
2022-10-03 22:18:58.389 - debug: wireless-mbus.0 (27585) connected set to false
2022-10-03 22:19:01.338 - info: wireless-mbus.0 (27585) CUL: Error getting CUL version: Timeout waiting for response
2022-10-03 22:19:01.339 - debug: wireless-mbus.0 (27585) CUL: TX: 5832310d0a6272630d0a
2022-10-03 22:19:01.360 - debug: wireless-mbus.0 (27585) CUL: RX: 434d4f44450d0a
2022-10-03 22:19:01.361 - info: wireless-mbus.0 (27585) CUL: Receiver set to C-MODE and data reporting with RSSI
2022-10-03 22:19:01.422 - debug: wireless-mbus.0 (27585) connected set to true
2022-10-03 22:19:13.355 - debug: wireless-mbus.0 (27585) CUL: RX: 6237333434323432333246303438383237383134314543333437413845303036353730324436353933313941414436383745353241464532373737
2022-10-03 22:19:13.386 - debug: wireless-mbus.0 (27585) CUL: RX: 3143393138384433333831344242304630454532324143413536304335334445353132344639433233463843324338303238414646354442383345313637433441443939314331414234324132414332443939414430323337464138323937423941424339444238413944303041313244304142463339
2022-10-03 22:19:13.417 - debug: wireless-mbus.0 (27585) CUL: RX: 323731313237343641384236413839443531433641323446393543314131333236453930323133454242433835453531374545423738464441394237383339333932374337344237313830354146454331363345364142383133390d0a
2022-10-03 22:19:13.419 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a8e0065702d659319aad687e52afe27771c9188d33814bb0f0ee22aca560c53de5124f9c23f8c2c8028aff5db83e167c4ad991c1ab42a2ac2d99ad0237fa8297b9abc9db8a9d00a12d0abf3927112746a8b6a89d51c6a24f95c1a1326e90213ebbc85e517eeb78fda9b78393927c74b71805afec163e6ab8139
2022-10-03 22:19:13.422 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a8e0065702d659319aad687e52afe27771c9188d33814bb0f0ee22aca560c53de5124f9c23f8c2c8028aff5db83e167c4ad991c1ab42a2ac2d99ad0237fa8297b9abc9db8a9d00a12d0abf3927112746a8b6a89d51c6a24f95c1a1326e90213ebbc85e517eeb78fda9b78393927c74b71805afec163e6ab81
2022-10-03 22:19:13.426 - debug: wireless-mbus.0 (27585) Short header
2022-10-03 22:19:13.427 - error: wireless-mbus.0 (27585) Warning unknown security mode: 16
2022-10-03 22:19:13.428 - error: wireless-mbus.0 (27585) Encryption mode 10 not implemented
2022-10-03 22:19:13.431 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f
2022-10-03 22:19:46.124 - debug: wireless-mbus.0 (27585) CUL: RX: 62373334343234323332463034383832373831343145433334374139303030363535
2022-10-03 22:19:46.156 - debug: wireless-mbus.0 (27585) CUL: RX: 443244374530354346384243424633354435314345433431464242383144443235454139424646423433443432343333373034383842374536413243463741373342323641323334414139384337413242454142393739464331443638373843344544423136424538354538453530353343364330333941364434
2022-10-03 22:19:46.187 - debug: wireless-mbus.0 (27585) CUL: RX: 364541423334333938384239304443314233344233393430464632463934363231423130364135354135304537453945414338363744313632364445333137353435414630433030383244394436393735334631353846423638383736393938373834423330344243303541383033410d0a
2022-10-03 22:19:46.188 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a9000655d2d7e05cf8bcbf35d51cec41fbb81dd25ea9bffb43d4243370488b7e6a2cf7a73b26a234aa98c7a2beab979fc1d6878c4edb16be85e8e5053c6c039a6d46eab343988b90dc1b34b3940ff2f94621b106a55a50e7e9eac867d1626de317545af0c0082d9d69753f158fb68876998784b304bc05a803a
2022-10-03 22:19:46.189 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a9000655d2d7e05cf8bcbf35d51cec41fbb81dd25ea9bffb43d4243370488b7e6a2cf7a73b26a234aa98c7a2beab979fc1d6878c4edb16be85e8e5053c6c039a6d46eab343988b90dc1b34b3940ff2f94621b106a55a50e7e9eac867d1626de317545af0c0082d9d69753f158fb68876998784b304bc05a80
2022-10-03 22:19:46.190 - debug: wireless-mbus.0 (27585) Short header
2022-10-03 22:19:46.190 - error: wireless-mbus.0 (27585) Warning unknown security mode: 29
2022-10-03 22:19:46.190 - error: wireless-mbus.0 (27585) Encryption mode 1d not implemented
2022-10-03 22:19:46.191 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f
2022-10-03 22:20:02.644 - debug: wireless-mbus.0 (27585) CUL: RX: 6237333434323432333246303438383237383134314543333437
2022-10-03 22:20:02.661 - debug: wireless-mbus.0 (27585) CUL: RX: 41393130303635353432443746373733423131373945453630434337463534383332334141453939453837463144333130313536373133454145353245
2022-10-03 22:20:02.692 - debug: wireless-mbus.0 (27585) CUL: RX: 424530323030353732344644433145354636393541353541334141334546334534424344343635333537383533383235343733454342393633414644414531304634463830374346303336443037373439323641424643444546333635424443413838353642353330343744324345334542434435353038
2022-10-03 22:20:02.722 - debug: wireless-mbus.0 (27585) CUL: RX: 31324339333430463242444344353941353636423130313939324230354230383735334244413534433141343030423738394544303436383732383133410d0a
2022-10-03 22:20:02.723 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a910065542d7f773b1179ee60cc7f548323aae99e87f1d310156713eae52ebe02005724fdc1e5f695a55a3aa3ef3e4bcd465357853825473ecb963afdae10f4f807cf036d0774926abfcdef365bdca8856b53047d2ce3ebcd550812c9340f2bdcd59a566b101992b05b08753bda54c1a400b789ed046872813a
2022-10-03 22:20:02.724 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a910065542d7f773b1179ee60cc7f548323aae99e87f1d310156713eae52ebe02005724fdc1e5f695a55a3aa3ef3e4bcd465357853825473ecb963afdae10f4f807cf036d0774926abfcdef365bdca8856b53047d2ce3ebcd550812c9340f2bdcd59a566b101992b05b08753bda54c1a400b789ed04687281
2022-10-03 22:20:02.725 - debug: wireless-mbus.0 (27585) Short header
2022-10-03 22:20:02.725 - error: wireless-mbus.0 (27585) Warning unknown security mode: 20
2022-10-03 22:20:02.725 - error: wireless-mbus.0 (27585) Encryption mode 14 not implemented
2022-10-03 22:20:02.726 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f

[lvogt]

@gizmodlx Ja wenn der Adapter zum selben Gerät unterschiedliche Telegramm bekommt / bekommen hat (bei dir evtl. aufgrund des Bugs den ich in 0.8.5 eingebaut hatte), dann wird das nicht besonders gut gehandhabt. Du wirst du Meldung los, wenn du einmal das Gerät im Objektbaum löschst - zumindest wenn du dir das leisten kannst (in Bezug auf gelöschte History oder was vl. sonst von den Datenpunkten abhängt)

@Meldb Vermutlich dürfte das gehen - aber natürlich alles ohne Garantie
Du brauchst natürlich in jedem Fall den AES Key falls verschlüsselt gesendet wird (was bei dem Gerät der Fall sein dürfte). Der Key kann nur vom Hersteller / Wasserversorger erhalten werden @fzzybllz !

@olixAtiobroker Ich bin etwas über die Ausgaben irritiert. Der Anfang eines der Telegramme den ich mir jetzt angeschaut habe wirkt sehr "spezifikations unkonform". Es fängt schon mit der Zähler ID an: HYD-2788042f <- das f hinten passt schon nicht so richtig. Kannst du irgendwo am Zähler eine ähnliche Nummer finden?
Dann kommt ja die Meldung zum security mode. Zum einem ist es schon merkwürdig dass der security mode ja scheinbar von einem zum nächsten Telegramm sich ändert, zum anderen sind diese Modes (zumindest nach OMS) nicht spezifiziert.
Was aber irgendwie gegen korrupte Daten spricht, ist dass die CRC Prüfsummen alle passen... Ich bin etwas ratlos...

[olixAtiobroker]

Hallo @lvogt,
erstmal vielen Dank für die Antwort. Der Diehl Sharky 775 ist ein "Hydrometer" und meiner hat die Seriennummer 4181-2788 - von daher passt der erste Teil der ID "HYD-2788", die "8042f" die danach kommt, hat keine Entsprechung.

Laut Datenblatt unterstützt der Zähler "Open Metering Standard ... Generation 3 Profil A oder Generation 4 Profil B" - wobei ich mich da noch nicht schlau gemacht habe.

Kannst Du mir einen "Link" auf die Spezifikation schicken (oder ggf. sagen, welche Spec. Du erwartest) bzw. was das Log-Telegramm zeigt? MBUS oder nur OMS (oder was anderes)? Ich würde dann ggf. weiter in den Specs. suchen, mir fehlt aber der Einstiegspunkt und eine Idee was das Log wirklich zeigt.

Besten Dank und Grüße,
Oliver

[olixAtiobroker]

@lvogt, ach ja und unterstützt Deine Implementierung "Generation 3 Profil A/ Generation 4 Profil B"?
Nochmal Danke,
Oliver

[Meldb]

@lvogt Hallo danke für die Antwort. Denn AES Key habe ich den Stick muss ich mir erst besorgen.

[lvogt]

@olixatiobroker
Die Zeile mit Message 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.

[Wolfi]

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?

[lvogt]

@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...

[Wolfi]

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ß

[JuFu]

@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?

[JuFu]

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]

@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???

[lvogt]

@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...)

[JuFu]

@lvogt
Ich habe den Mode umgeschalten und das Debug war noch an ...
Hier das log-file:
iobroker.2023-01-10.log.htm

[lvogt]

@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....

[JuFu]

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

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

Das bringt mich doch schon mal deutlich weiter!

Ganz herzlichen Dank dafür!

[JuFu]

@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.

[jgoller]

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

[lvogt]

@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