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

[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

[fadk2wf]

Hallo @lvogt,

schade, daß du da nicht helfewn kannst.
Wie ich erfahren habe, hat anscheinend Dirk Tostmann die wmbus Funktion ins culfw eingebaut.
Sein Kürzel ist mir in einem Forum auch schon begegnet. Ich möchte ihn gerne fragen, ob er sich das anschaut. Deswegen wollte ich hier sein Kürzel einfügen, aber er steht nicht in der Liste.
Da muß ich wohl im FHEM Forum nochmal nachsehen und dort einen Post schreiben.

Nach den Recherchen in den Foren (speziell FHEM) gibt es die Aussage dazu, daß die culfw wmbus OMS Daten auf 433 MHz nicht verarbeiten kann. Ein Beitrag sagt sogar, daß die Kombi in den wmbus Specs nicht vorgesehen ist, was meinen vorliegende Dokus widerspricht. Ein Erweiterung der Norm EN 13757-4 in 2013 und 2019 haben das definiert. (Webseite OMS-Group)
Die Hersteller der Wasserzähler führen die Nutzung von 433 MHz in ihren Produktblättern auch auf.

Da der TI-CC1101 alle Frequenzen kann, müßte das technisch realisierbar sein. Der Radiocrafts RC1140 kann das gemäß dem Datenblatt. Den RC wmbus Stick gibt es für 868 und 433 für T und S Modes. Der ist für Privatleute nur nirgends zu bekommen, außerdem recht teuer. Ob der "wireless m-bus Aadapter" den erkennt, ist mir auch unbekannt.

Bevor ich da weitern Aufwand investiere hier die entscheidende Frage:
Gibt es schon irgendwo oder wird es eine passende CUL/nanoCul-FW zum Empfang von OMS Daten über wmbus für 433 MHz geben?
Es wäre ganz toll, wenn das jemand beantworten könnte oder sich ein Freiwilliger fände, der das bauen kann. Ich kann das leider nicht.

Vielen Dank schon mal im voraus für Beiträge zum Thema!
Grüße, Horst

[fadk2wf]

Hallo allerseits,
der Empfang von wmbus Telegrammen mit dem nanoCUL im 433 MHz Band ist erstmal gelöst.
Ob das auch auf anderer HW geht, weiß ich nicht.
Die detaillierte Beschreibung dazu habe ich in einem Thread in FHEM Forum beschrieben:
https://forum.fhem.de/index.php/topic,132763.0.html

viele Grüße
Horst

[smartboart]

@fadk2wf Hallo, kann man deine angepasste Version irgenwo herunter laden?

[fadk2wf]

@smartboart
Hallöli,
hier ist die Hex-File für 434,475 MHz, nur M-Bus, keine anderen Protokolle.
nanoCUL433_nur-mbus-buff-300_König.hex
viele Grüße
Horst

[smartboart]

@fadk2wf Super! Vielen Dank. Gleich mal ausprobieren...

[smartboart]

@fadk2wf Welchen Wasserzähler liest du mit der FW aus?

[fadk2wf]

@smartboart Das ist ein Sensus iPerl.
Wie ich zu der Lösung gekommen bin, habe ich in dem oben verlinkten FHEM Forumsbeitrag beschrieben. Die Weisheit, daß der Zähler im 433er Band funkt hatte ich vom Versorger.
Alle Tests vor dem Einstecken in den iobroker Raspi hatte ich mit HTerm am Windows PC gemacht. Da der Zähler nur alle Stunde einen Satz funkt, habe ich meine 70cm Band Hochantenne an dem nanoCUL angeschlsossen (fa=Funkamateur, DK2WF ist mein Call). Da kamen aus größerer Entfernung öfter M-Bus Telegramme.
Zu Hause mit der Gummischwanz-Antenne ist das ein Geduldsspiel.

[smartboart]

@fadk2wf danke für die Rückmeldung.. habe auch nen sensus iperl...habe es mit dem 800 Band nicht hinbekommen und probiere jetzt mit dem 400er.klappt beides noch net.

[smartboart]

@fadk2wf jedenfalls habe ich bei der hin und her flasherei jetzt beide nano culs gebrickt. Blinken nur noch hektisch als würden sie gerade gflasht. Mal sehen wann ich hier weiter testen kann...

[fadk2wf]

@smartboart Ich habe die mit dem XLoader-10 geflasht. Mit dem 139 hat es nicht geklappt. Später habe ich gesehen, daß in den devices.txt andere Werte waren. Der ATmega329 hat bei mir nur mit 115200 Baud geflashed. Da blinkert er am Anfang mehrmals, aber während der ca. 20 Sekunden Flash Vorgang blinkt nix, Er meldet am Ende die Bytes geflashed, fertig.
Mit Hterm am PC kann man den mit 38400 connecten und dann mit Befehl V schauen ob er reagiert und dann mit X21 (oder27) das Empfangen starten und mit brt den T-Mode setzen. Dann hat er nach ca 2 Stunden einen Datensatz angezeigt:

27  900
TMODE
062E0000543D6104
020000080010B5A9
5C040622F8440700
182EBF4309B5876B
F8B610EF2C171F41
00597F3E81350900
b1E44AE4C74428230680700227AD6001005BB0FBE79F207BE71013E5002D00610709CCF1E6680F9

Die Registerliste zeigt er mit C99 und in der zweiten Reihe die rechten 3 Bytes sind die Frequenz in Reg 0D-0F.
Frag doch mal beim Versorger nach welches Modell bei dir verbaut ist. Außerdem kann man da gleich feststellen, ob die den AES Key rausrücken. Wenn du den nicht bekommst, kannst du dir die Mühe sparen.