Test Adapter wireless-mbus v0.9.x

[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

[jgoller]

@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

[JuFu]

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

[lvogt]

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

[JuFu]

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

[jgoller]

Hallo,
wollte nur kurz Rückmeldung geben. Hab ja 9 Warmwasser-Zähler von der Zählerplattform eingebaut und frag diese mit dem IMST iM871A USB-Stick ab. In den Einstellungen hab ich Mode C Typ A mit 57600 Baud gewählt. Das funktioniert wunderbar. Die AES-Schlüssel hab ich nach kurzer Anfrage bei Zählerplattform nach 1-2 Tagen erhalten.
Einzig die Zählerstände kommen wohl als String an, da zB SourceAnalytix keine Berechnung durchführen kann.

Input value for wireless-mbus.0.DWZ-xxxxxxxx.data.2-0-VIF_VOLUME, type = string but should be a number, cannot handle calculation

Vielleicht hat ja einer nen Tipp, wie ich das gelöst bekomme. Eine Anfrage hab ich schon in diesem Thread gestellt.

[MartyBr]

@jgoller
Ich setze die Version 0.8.6 ein, die macht keine Probleme. Der Zählerstand ist bei mir als mixed gesetzt:

{
  "type": "state",
  "common": {
    "name": "Volume (Instantaneous value)",
    "role": "value.volume",
    "type": "mixed",
    "read": true,
    "write": false,
    "unit": "m³"
  },
  "native": {
    "id": ".data.2-0-VIF_VOLUME",
    "StorageNumber": 0,
    "Tariff": 0
  },
  "_id": "wireless-mbus.0.DWZ-22271898.data.2-0-VIF_VOLUME",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1665748391545
}

[Hc-Yami]

Hallo zusammen,
wegen dem Bericht von heise bin ich überhaupt darauf aufmerksam geworden, dass sich meine Q caloric 5.5 von QUNDIS überhaupt auslesen lassen. Tatsächlich bin ich jetzt erst darauf gestoßen, dass ich das ganze auch in ioBroker durch diesen Adapter bekommen könnte. Natürlich habe ich mir nun schon den empfohlenen USB-Stick von heise gekauft. Hier wurde ein RTL-SDR für meine Heizkostenverteiler genannt. Explizit dieser:

https://www.amazon.de/NooElec-NESDR-Smart-RTL2832U-R820T2-basierte/dp/B01HA642SW

Komme ich damit gar nicht weiter bei ioBroker? Sprich; verkaufen und dann am besten welchen kaufen?

Vielen Dank für eure Antworten!

[lvogt]

@hc-yami
Im Moment kann der Adapter mit rtl-wmbus als Quelle leider nichts anfangen.
Vor einer Weile hatte schon mal jemand danach gefragt... Wenn mich mal die passende Motiviation packen würde, würde ich die Unterstützung dafür vermutlich auch einbauen - aber eine Prognose wann das passiert möchte ich nicht abegeben....

Der SDR als Empfänger hat auch ein paar grundsätzliche Nachteile (zumindest als ich mich mal damit vor einigen Jahren beschäftigt hatte): Sowohl die Hardware als auch die Software muss deutlich mehr arbeiten, da die Hardware nicht explizit auf wmbus ausgelegt ist.

Grundsätzlich wird hier so weit ich das beurteilen kann, gerne der IMST Stick oder ein CUL verwendet - da ich den Adapter aber selbst gar nicht verwende kann ich auch nur begrenzt Empfehlungen zur Hardware geben...