UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

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

[fadk2wf]

Hallo zusammen,

das ist mein erster Post in diesem Forum. Nach längerem Lesen finde ich das Forum Top!!
Ich weiß auch nicht, ob mein Thema hier im richtigen Thread ist, da bitte ich um Nachsicht.
Folgendes:
Ich habe einen iobroker laufen und schon mit Tasmota die eine oder ander Löung mit MQTT laufen.
Nun wollte ich den neuen Sensus iPerl Wasserzähler auslesen und habe einen nanoCul868 besorgt. Der wurde auch im wireless m-bus Adapter erkannt, Version angezeigt, Read-mode und T-mode gesetzt und ging in Listenig in T-Mode. Aber es kamen keine Telegramme.
Nach Telefonat mit Versorger hat mir der freundliche Mensch gesagt, daß der iPerl auf 433 MHz sendet. Gemäß Infos im Datenblatt kann der wirklich mit wmbus OMS-konforme Daten senden.
Die Übermittlung des AES-Keys haben wir vereinbart, wenn ich die Daten empfangen kann.

Habe dann einen nanoCul433 besorgt und festgestellt, daß die culfw433 keinen wmbus unterstützt.
Nun habe ich seit Tagen gesucht, ob es eine Lösung gibt, die das ermöglicht. Wenn man die culfw für wmbus flasht, dann zeigt die Version trotzdem 868 an. Mit der culfw433 ist der befehl brt unbekannt.
Gibt es eine passende FW? Leider bin ich nicht versiert genug, um eine eigene FW herzustellen.
Komme aus dem Mainframe Bereich ind habe lange genung geübt, bis ich mit dem Linux klarkam ;-))
Wenn ich in die Datei Board.h schaue, dann müßte man anscheinend eine Config erstellen können, die das hergibt.
Vielen Dank schon mal für eine Antwort!
Horst

[IOSD]

Hallo,

vielleicht kann mir jemand weiterhelfen. Ich bekomme mit meinem CUL 868 den Adapter nicht zum laufen. LOG siehe unten.
Unter fhem funktioniert alles, kann natürlich auch darüber in Iobroker einbinden.
Ich würde allerdings gerne verstehen wollen, warum das hier nicht geht..

Danke

Wireless-mbus.0
2023-03-16 09:22:04.140 error Timeout waiting for response

wireless-mbus.0
2023-03-16 09:22:04.139 error Error opening serial port /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285XL-if00-port0 with baudrate 38400

wireless-mbus.0
2023-03-16 09:22:04.136 error CUL: Failed to init device: Timeout waiting for response

wireless-mbus.0
2023-03-16 09:22:01.134 debug CUL: TX: 5832310d0a6272740d0a

wireless-mbus.0
2023-03-16 09:22:01.131 info CUL: Error getting CUL version: Timeout waiting for response

wireless-mbus.0
2023-03-16 09:21:58.192 debug connected set to false

wireless-mbus.0
2023-03-16 09:21:58.122 debug CUL: TX: 560d0a

wireless-mbus.0
2023-03-16 09:21:58.115 debug Created device of type: CUL

wireless-mbus.0
2023-03-16 09:21:58.033 info starting. Version 0.8.10 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v16.19.1, js-controller: 4.0.24
host.iobroker
2023-03-16 09:21:55.275 info instance system.adapter.wireless-mbus.0 started with pid 4944

[lvogt]

@fadk2wf
Sorry, mit den Möglichkeiten der culfw kenne ich mich nicht aus.

@IOSD
Klingt nach wahlweise falschem Port oder falscher Baudrate oder sonstigen Problemen auf Systemebene.

[ratte-rizzo]

Moin @iosd

Falls Du alle Konfigurationsfehler ausgeschlossen hast, dann hilft Dir vielleicht folgendes Vorgehen -- so bekomme ich meinen CUL nämlich nach einem Neustart (!) immer wieder ans laufen: Den Adapter im 5min Rhythmus automatisch neu starten lassen. Irgendwann (<6h) berappelt er sich dann und es kommt eine dauerhafte und stabile Kommunikation zu Stande -- bis zum nächsten Neustart des Containers.

Keine Ahnung, warum das bei mir so ist, aber nachdem ich alle Konfig-Einstellungen überprüft und die Erreichbarkeit über die Kommandozeile sichergestellt habe, war das die einzige Möglichkeit bei mir.

Viel Erfolg
Daniel