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

[lvogt]

@hartwigm
Naja wenn die behaupten der sendet und er neu ist sollte man eigentlich nicht von dir den Lesekopf erwarten dürfen.

Evtl. mal näher am Sender testen? Oder mal den Stick mit offizieller Imst Software testen?
Ich kann natürlich nicht 100% ausschließlich dass es am Ende nicht doch am Adapter liegt...

[gizmodlx]

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

@gizmodlx said in Test Adapter wireless-mbus v0.7.x:

@lvogt Was mir noch aufgefallen ist: Die Einstellung zu "blockierten" Zählern scheint nicht zu funktionieren. Ich habe es mit den Werten "Address" und "ID" versucht, aber die Daten anderer Zähler werden weiterhin angezeigt.

Du musst zum Blockieren die Kombination aus Hersteller und ID nach diesem Muster MAN-XXXXXXXX angeben. So wie auch der Übergeordnete Kanal im Objektbaum heißt.

Danke für die Info. Hersteller und ID mit Bindestrich getrennt hat funktioniert.
Statt einer Readme würde da auch ein Einzeiler auf der Konfigurationsseite reichen

[rali2011]

Hallo zusammen,

ich habe es nun endlich hinbekommen Daten von meinem kamstrup multical 21 mit diesem Adapter zu empfangen

Allerdings bekomme ich die Fehlermeldung: "Unknown Kamstrup compact frame format".

Den AES Key hab ich vorher aus einer .kem Datei ausgelesen und im Adapter eingefügt. Mache ich etwas falsch oder muss ich mit einem anderen Programm die Datei weiterverarbeiten?

[lvogt]

@rali2011

In den Adapter Einstellung "Cache für Kompakt-Telegramme" aktivieren. Danach wird die Meldung trotzdem ein paar Mal kommen, weil der Adapter dann erst einmal (pro Adapter Neustart!) ein "nicht-kompakt" Telegramm empfangen muss. Danach werden auch die kompakten korrekt verarbeitet.

[rali2011]

Hallo, ich möchte mit meinem System umziehen und hab mir dazu einen neuen iobroker aufgesetzt. Leider bekomme ich den Adapter dort nicht installiert. Im Expertenmodus habe ich den github link zum installieren eingefügt. Was mache ich falsch?

$ iobroker url https://github.com/lvogt/ioBroker.wireless-mbus.git --host iobroker-kreuser

install lvogt/ioBroker.wireless-mbus#78f62f0c4704420cfebc9d689c721222af66c247

NPM version: 6.14.17

Installing lvogt/ioBroker.wireless-mbus#78f62f0c4704420cfebc9d689c721222af66c247... (System call)

• iobroker.wireless-mbus@0.8.2updated 1 package in 793.631s

48 packages are looking for funding run npm fund for details

upload [2] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/index_m.html index_m.html text/html

upload [1] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/wireless-mbus.png wireless-mbus.png image/png

upload [0] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/words.js words.js application/javascript

Process exited with code 0

Danke für eure Antworten!

[Thomas Braun]

@rali2011 sagte in Test Adapter wireless-mbus v0.7.x:

Process exited with code 0

0 = Adapter wurde installiert.

Und warum bitte die github-Version? Nimm halt das Beta-Repository dafür her und lass den github-Sumpf außen vor.

wireless-mbus
github:	0.8.2
latest:	0.8.2 for 52 days
stable:	-.-.-

[ratte-rizzo]

Moin @lvogt

Ich musste meinen Server mal wieder neu starten und dann habe ich immer Anfangsschwierigkeiten, den CUL zum Leben zu erwecken. Adapter Version 0.8.2

Kann es sein, dass die Timeout Limits etwas knapp gefasst sind? Zwischen dem ersten TX und dem Tm Timeout liegt ja nicht einmal eine Sekunde:

wireless-mbus.0	2022-08-02 06:32:07.237	error	Timeout waiting for response
wireless-mbus.0	2022-08-02 06:32:07.237	error	Error opening serial port /dev/ttyACM0 with baudrate 38400
wireless-mbus.0	2022-08-02 06:32:07.236	error	CUL: Failed to init device: Timeout waiting for response
wireless-mbus.0	2022-08-02 06:32:04.235	debug	CUL: TX: 5832310d0a6272730d0a
wireless-mbus.0	2022-08-02 06:32:04.234	error	CUL: Error getting CUL version: Timeout waiting for response
wireless-mbus.0	2022-08-02 06:32:01.280	debug	connected set to false
wireless-mbus.0	2022-08-02 06:32:01.230	debug	CUL: TX: 560d0a
wireless-mbus.0	2022-08-02 06:32:01.227	debug	Created device of type: CUL
wireless-mbus.0	2022-08-02 06:32:01.174	info	starting. Version 0.8.2 (non-npm: lvogt/ioBroker.wireless-mbus#a5b274111e95f62d28b7179f7d0f29f2ea87b0b7) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.3, js-controller: 4.0.23

Ferner ist es ja nicht so, dass der CUL gar nicht antworten würde. Ich hab auch so etwas im Log:

wireless-mbus.0 2022-08-02 07:13:03.332	error	Timeout waiting for response
wireless-mbus.0	2022-08-02 07:13:03.332	error	Error opening serial port /dev/ttyACM0 with baudrate 38400
wireless-mbus.0	2022-08-02 07:13:03.331	error	CUL: Failed to init device: Timeout waiting for response
wireless-mbus.0	2022-08-02 07:13:01.916	debug	CUL: RX: 38433131334646464644453236343438303030303044463237323739323835353230303030303030303030303030303030303330303746303037443030373430
wireless-mbus.0	2022-08-02 07:13:00.329	debug	CUL: TX: 5832310d0a6272730d0a
wireless-mbus.0	2022-08-02 07:13:00.329	error	CUL: Error getting CUL version: Timeout waiting for response
wireless-mbus.0	2022-08-02 07:12:57.377	debug	connected set to false
wireless-mbus.0	2022-08-02 07:12:57.326	debug	CUL: TX: 560d0a
wireless-mbus.0	2022-08-02 07:12:57.324	debug	Created device of type: CUL
wireless-mbus.0	2022-08-02 07:12:57.291	info	starting. Version 0.8.2 (non-npm: lvogt/ioBroker.wireless-mbus#a5b274111e95f62d28b7179f7d0f29f2ea87b0b7) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.3, js-controller: 4.0.23

Hast Du vielleicht einen Tipp?

Dank & Gruß
Daniel

[ratte-rizzo]

Noch ein Nachtrag (und vielleicht sogar die Lösung):

Ich war jetzt mal faul und hab den ganzen Tag mal eine "Brute Force" Lösung probiert: Adapter-Neustart alle 5 Minuten...

Und tatsächlich hat es nach gut 8 Stunden zum Erfolg geführt! Kommunikation mit dem CUL läuft (und ich vermute auch mal stabil, weil ich bisher immer nur Probleme beim ersten Start nach einem Booten hatte, danach nie wieder).

Daher vermute ich mal als naiver Nutzer: Kann es vielleicht wirklich ein Timing-Problem sein?

Danke fürs nachschauen sagt
Daniel

[lvogt]

@ratte-rizzo
Der Timeout kommt nach 3 Sekunden. Du musst das Log chronologisch - also von unten nach oben - lesen.

Die Antwort, die der Stick in deinem 2. Logauszug schickt, kann ich zu nichts zuordnen.

Ich denke nicht, dass ich da ohne Hardware viel machen kann. Und soweit ich das den Einträgen hier entnehmen kann ist es jetzt auch nicht der Normalfall, dass man 8h lang den Adapter neu starten muss...

Edit: Ich kenne mich mit dem CUL ja wirklich nicht gut aus, aber hast du die Möglichkeit zu beeinflussen in welchem Mode und mit welchen Einstellungen der per default startet, wenn er neu bootet? Evtl. hilft es ja da direkt "bessere" Einstellungen zu setzen?

[ratte-rizzo]

Moin @lvogt

Dass ich das Log von unten her lesen muss, ist klar. Meine Idee war halt, den Timeout von 3s etwas zu vergrößern. Vielleicht 5s oder 10s. Solltest Du den Adapter bei Gelegenheit nochmal anfassen, kannst Du ja mal dran denken. Eilt ja nicht.

Immerhin steht jetzt fest, dass dieser (für mich) nervige Linux Kram mit Rechten, Durchreichen zu VM und so korrekt ist. Die Baustelle ist weiter eingekreist. Vielleicht hilfts ja anderen CUL Nutzern.

Letzte Frage: Was für eine Hardware nutzt / empfiehlst Du denn? Weihnachten kommt ja bald und die CUL HW und SW ist ja auch nicht gerade brandneu.

Dank & Gruß
Daniel

[lvogt]

@ratte-rizzo
Wie ich im Thread ab und zu schon mal erwähne, verwende ich den Adapter und sogar ioBroker einfach gar nicht selbst. Ich habe den Adapter ursprünglich im Rahmen meiner alten Arbeitsstelle geschrieben und ihn nach einer Weile "einfach so" weiter gepflegt.

Empfehlung zur Hardware kann ich daher kaum geben. "Damals" habe ich recht viel beim Testen den Amber Stick verwendet. Der hat ja zB auch diesen praktischen Mode der C und T gleichzeitig kann (hatte damit aber auch ab und zu Hardware(?) Problem). Der tatsächliche produktive Einsatz erfolgte dann mit der Embit Hardware, die aber - soweit ich weiß - nicht als USB Stick sondern nur direkt verbaut in irgendwelchem "Embedded Systemen" zu finden ist.

Der Amber Stick ist mittlerweile glaube ich aber gar nicht mehr so gut zu bekommen. Was recht gut zu bekommen ist, ist der IMST Stick von "alten" RWE SmartHome Angeboten auf eBay oä. Da muss man unter Linux noch ein bisschen was mit udev machen, damit der korrekte Treiber geladen wird (irgendwo hier im Thread zu finden), aber dann sollte es keine Probleme damit geben.

Der von dir gerade etwas in Zweifel gezogene CUL hat auch ein "inoffizielles" Update (auch schon nicht mehr ganz neu) das auch den C Mode bzw. eigentlichen einen C und T Mode implementiert verpasst bekommen. Wenn man also einen kombinierten Mode gebrauchen kann, ist das schon keine schlechte Wahl denke ich.

[gizmodlx]

@lvogt Ich erhalte regelmäßig die folgende Fehlermeldung vom wireless-mbus Adapter:

Ich dachte ja, der Wasserzähler würde sich beim ersten Ablesen irgendwie das richtige Datum ziehen, aber für 2 Parameter wird mir weiterhin der Wert "65535" (entspricht wohl 2128-03-31) ausgelesen. Wäre klasse, wenn man diese Meldung irgendwie unterdrücken könnte. Hast du da eine Idee?

[lvogt]

@gizmodlx

Die neueste "unstable" Version 0.8.5 sollte da jetzt keinen Fehler mehr ausspucken, sondern das nur noch als "INFO" loggen.

Das Problem ist, dass der Zähler da halt einen eigentlich ungültigen Wert zurückgibt - vermutlich weil das entsprechenden Datum nicht gesetzt ist.

[-cs-]

@lvogt

Hallo, habe es auf einem frischen Testsystem probiert, er schreibt immer noch die Error- Meldung.

wireless-mbus.0  2022-09-25 11:21:25.391	error	Unknown Kamstrup compact frame format

System ist heute neu auf einen Raspberry Pi aufgesetzt worden und Adapter ist v0.8.5

Edit:
Ups, da habe ich wohl zu viel quer durch die Beiträge gelesen, das ist ja eine andere Meldung oder?

Zähler ist Kamstrup Multical 21 mit IMST871A - Stick.

[lvogt]

@cs
Ja das ist offensichtlich eine völlige andere Fehlermeldung...

Du musst den Cache für Kompakt-Telegramme in den Einstellungen einschalten. Ich sollte das mal "automatisieren"...

[gizmodlx]

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

@gizmodlx

Die neueste "unstable" Version 0.8.5 sollte da jetzt keinen Fehler mehr ausspucken, sondern das nur noch als "INFO" loggen.

Das Problem ist, dass der Zähler da halt einen eigentlich ungültigen Wert zurückgibt - vermutlich weil das entsprechenden Datum nicht gesetzt ist.

Danke für das Update
Hab die Version 0.8.5 jetzt am Laufen. Der alte Fehler mit ungültigem Datum ist weg, dafür ist ein anderer Fehler neu dazu gekommen:

[fzzybllz]

Hallo zusammen,
da ich mittlerweile nicht mehr weiterkomme, bräuchte ich mal eure Hilfe.
Ich habe den Wireless M-Bus Adapter in v.0.8.2 zusammen mit einem nanoCUL (Arduino Nano + Ti CC1101) (der lag noch rum) am laufen.
Mittlerweile ist der Adapter auch endlich grün und wirft keine Fehler mehr. Geflashed wurde die Firmware von https://weetmuts.github.io/wmbusmeterswiki/nanoCUL.html
Der Adapter ist eingestellt auf Empfänger = CUL / Mode = T Mode / Die richtige Schnittstelle / Baudrate 38400. Nur in dem Setup wird der Adapter auch grün.
Lesen würde ich gerne einen "allmess Integral-V Ultra Lite".
Leider bekomme ich in den Objekten gar nichts ausgeworfen und im Protokoll auch gar nichts angezeigt. Mach ich hier was falsch oder passt noch was an der Hardware/Firmware nicht?
Vg

Edit: Der allmess Integral-V Ultra Lite ist zwar mein Wärmezähler, aber tatsächlich versuche ich mich eigentlich mit einem Itron EquaScan h MIU RF zu verbinden.

[lvogt]

@gizmodlx
Sorry, ich habe da am Wochenende nicht aufgepasst mit 0.8.6 sollte auch der Fehler nicht mehr passieren...

@fzzybllz
Der verlinkte Zähler behauptet im C2 Mode zu senden. Von daher solltest du wohl auch mal den "C/T" Mode des CULs ausprobieren. Ich sehe aber trotzdem zwei potentielle Probleme:
Das Datenblatt sagt C2 - evtl. bedeutet das, dass der Zähler nur antwortet wenn man erst ihm was sendet - da bin ich mir aber recht unsicher. Falls ja, dann ist dieser Adapter damit raus - senden ist bisher nicht drin.
Zum anderen steht im Datenblatt zwar brav wireless m-bus drin - aber nicht OMS - damit könnte es gut sein, dass die Daten nicht so einfach / gar nicht "lesbar" sind.

[fzzybllz]

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

@fzzybllz
Der verlinkte Zähler behauptet im C2 Mode zu senden. Von daher solltest du wohl auch mal den "C/T" Mode des CULs ausprobieren. Ich sehe aber trotzdem zwei potentielle Probleme:
Das Datenblatt sagt C2 - evtl. bedeutet das, dass der Zähler nur antwortet wenn man erst ihm was sendet - da bin ich mir aber recht unsicher. Falls ja, dann ist dieser Adapter damit raus - senden ist bisher nicht drin.
Zum anderen steht im Datenblatt zwar brav wireless m-bus drin - aber nicht OMS - damit könnte es gut sein, dass die Daten nicht so einfach / gar nicht "lesbar" sind.

@lvogt
Danke für die Antwort. Ja wer lesen kann, ist klar im Vorteil. Über den C2 Mode bin ich dann auch gestolpert, hab auf C/T-Mode umgestellt und siehe da. Alles funktioniert einwandfrei.
Mir wurden - wie erwartet - jede Menge Geräte (inkl. meiner 5 Zähler) aufgelistet.
Aktuell scheitert es "nur noch" an den AES Keys. Dazu hab ich gestern noch sehr sehr lange gesucht und bin aber nicht wirklich fündig geworden. Gibts da Tipps wie man die erhalten könnte?

[gizmodlx]

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

@gizmodlx
Sorry, ich habe da am Wochenende nicht aufgepasst mit 0.8.6 sollte auch der Fehler nicht mehr passieren...

Kein Problem Version 0.8.6 wirft jetzt keinen Error mehr aus. Danke!

Der aus meiner Sicht letzte offene Punkt wäre noch die Anlage von bisher nicht vorhandenen Datenpunkten. Hier kommt es immer wieder zu Warnungen, weil der Adapter wohl neue (?) Datenpunkte nicht korrekt anlegt. Kann man zwar auch einfach ignorieren, aber lässt sich sicher auch eleganter lösen.