Test Adapter wireless-mbus v0.9.x

[Simps]

Servus @lvogt

Du suchst ja Tester für CUL, ich hab einen Mini-Cul, die Firmware ist upgedatet auf WMBUs-fähig.

Über Github installiere ich Deinen Adapter, aber er taucht nicht unter den Adaptern auf, er legt aber zwei Objekt-Verzeichnisse an (wmbus/admin, aber keine Ziffer). Beim Installieren kommt (Debug-Fenster). Die Script Depency WARN ist sicher die Lösung, finde durch googlen nichts, was mir hilft, ist es die NPM Version?

url https://github.com/lvogt/ioBroker.wireless-mbus --host pii --debug
install lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a
NPM version: 6.14.16Installing lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a... (System call)
iobroker npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/fsevents):
iobroker npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"})

+ iobroker.wireless-mbus@0.7.8added 2 packages from 2 contributors in 11.038s

46 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
iobroker upload [1] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/wireless-mbus.png wireless-mbus.png image/png
iobroker upload [0] wireless-mbus.admin /opt/iobroker/node_modules/iobroker.wireless-mbus/admin/words.js words.js application/javascript
iobroker exit 0

npm fund hat kein nennenswertes Ergebnis.
Javascript version ist 5.2.21
NPM ist 6.14.16
Alla Adapter sind upgedated (via stable repository).

ABER: Wenn ich nicht den Link aus Github installiere, sondern den WMBUS Adapter 0.7.8 aus dem beta Repository (ist das denn deiner?) bekomme ich im System einen funktionierenden Adapter, ausserdem auch irgendwelche Daten (siehe Screenshot), aber keine Objekte ausm funk. Es müssten aber ein paar funken.

Danke fürs Helfen

Stefan

[lvogt]

@simps
Vorweg: Der wireless-mbus Adapter ist natürlich genau der selbe.

Die Warnung kommt glaube ich von serialport und ist kein Problem sofern ich das gerade richtig im Kopf habe.

Ich vermute mal du hast nur den Adapter installiert aber keine Instanz erzeugt. Du musst jetzt halt im Adapter "Tab" noch eine Instanz anlegen...

Edit: Das was du zeigst sind ja die technischen "Interna" wie sie für jeden Adapter existieren.

Wenn ich irgendwie helfen können soll brauche ich min. ein Debug Log. Und "es m üssten aber ein paar funken" klingt schon nach der Ursache. Wie sicher bist du dir dass was funkt und in welchem Intervall? Und vl auch verschlüsselt?

[Simps]

@lvogt vielen Dank!

Anbei ein Debug-Log, ist das ausreichend? Derzeit hängt er in folgender Schleife fest

wireless-mbus.0
10401	2022-04-04 08:36:08.180	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.22.11, js-controller: 4.0.21
host.pii
2022-04-04 08:36:06.752	info	instance system.adapter.wireless-mbus.0 started with pid 10401
host.pii
2022-04-04 08:35:36.646	info	Restart adapter system.adapter.wireless-mbus.0 because enabled
host.pii
2022-04-04 08:35:36.645	info	instance system.adapter.wireless-mbus.0 terminated with code NaN ()
host.pii
2022-04-04 08:35:36.645	warn	instance system.adapter.wireless-mbus.0 terminated due to SIGABRT
host.pii
2022-04-04 08:35:36.641	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

wireless-mbus.0
10027	2022-04-04 08:24:50.165	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.22.11, js-controller: 4.0.21
host.pii
2022-04-04 08:24:48.732	info	instance system.adapter.wireless-mbus.0 started with pid 10027
host.pii
2022-04-04 08:24:18.631	info	Restart adapter system.adapter.wireless-mbus.0 because enabled
host.pii
2022-04-04 08:24:18.631	info	instance system.adapter.wireless-mbus.0 terminated with code NaN ()
host.pii
2022-04-04 08:24:18.630	warn	instance system.adapter.wireless-mbus.0 terminated due to SIGABRT
host.pii
2022-04-04 08:24:18.630	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

"Adapter aus der Beta installiert" führt natürlich dann zu einer Instanz. Nur der Github-Link nicht. Die technischen Interna hatte ich gescreenshottet, weil ich mir nicht sicher war, ob das helfen könnte.

Derzeit läuft er auf /dev/ttyAMA0 wenn ich den Port wechsle auf /dev/ttyUSB0 kommt:

wireless-mbus.0
10849	2022-04-04 08:47:42.147	error	CUL: Error setting wMBus mode: Timeout waiting for response

wireless-mbus.0
10849	2022-04-04 08:47:42.144	error	CUL: Message response timeout

Das bedeutet, das er auf dem ttyUSB0 nicht ansprechbar ist oder?

Und es "funkt" auf jeden Fall Ich habe hier Test-Heizkostenverteiler verschiedener Marken als Testgeräte, auf der richtigen Frequenz und im richtigen OMS WMBUS Format, einige sind AES verschlüsselt, andere nicht, aber keiner kommt an in den Objekten.

Was denkst Du? Und Danke nochmal!

[lvogt]

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

Anbei ein Debug-Log, ist das ausreichend?

Eigentlich nicht. Da ist ja nicht mal drin dass der Adapter ein korrekte Antwort vom CUL nach dem Setzen des T- oder S-Modes bekommen hat. Aber: (s.u.)

Derzeit hängt er in folgender Schleife fest

wireless-mbus.0
10401	2022-04-04 08:36:08.180	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.22.11, js-controller: 4.0.21
host.pii
2022-04-04 08:36:06.752	info	instance system.adapter.wireless-mbus.0 started with pid 10401
host.pii
2022-04-04 08:35:36.646	info	Restart adapter system.adapter.wireless-mbus.0 because enabled
host.pii
2022-04-04 08:35:36.645	info	instance system.adapter.wireless-mbus.0 terminated with code NaN ()
host.pii
2022-04-04 08:35:36.645	warn	instance system.adapter.wireless-mbus.0 terminated due to SIGABRT
host.pii
2022-04-04 08:35:36.641	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

wireless-mbus.0
10027	2022-04-04 08:24:50.165	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.22.11, js-controller: 4.0.21
host.pii
2022-04-04 08:24:48.732	info	instance system.adapter.wireless-mbus.0 started with pid 10027
host.pii
2022-04-04 08:24:18.631	info	Restart adapter system.adapter.wireless-mbus.0 because enabled
host.pii
2022-04-04 08:24:18.631	info	instance system.adapter.wireless-mbus.0 terminated with code NaN ()
host.pii
2022-04-04 08:24:18.630	warn	instance system.adapter.wireless-mbus.0 terminated due to SIGABRT
host.pii
2022-04-04 08:24:18.630	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Wenn das wirklich eine Schleife ist, sollte es dich nicht wundern wenn der Adapter nichts empfängt, da er offensichtlich ununterbrochen neu gestartet wird. Die Fehlermeldung deutet auf ein Memoryleak hin, aber ich weiß nicht wirklich woher das kommen soll. Insbesondere da ja offensichtlich die meisten keine Probleme mit überfülltem Speicher haben. (Und es ja scheinbar quasi direkt nach dem Adapter Start bereits auftritt.) Weiter oben im Thread hatte jemand anderes schon dasselbe oder wenigstens ein ähnliches Problem was bisher nicht gelöst ist.

Wenn du etwas experimentieren willst kannst du mal versuchen andere Adapter / Skripte zu stoppen und gucken ob es hilft.

"Adapter aus der Beta installiert" führt natürlich dann zu einer Instanz. Nur der Github-Link nicht.

Wie ich geschrieben habe, ist der Unterschied dass ioBroker nicht automatisch eine Instanz anlegt wenn du den Adapter aus dem Git Repository installierst, das müsstest du halt "manuell" machen. Ist aber ja auch egal, der du am Ende sowieso mit dem selben Stand wie aus dem "beta Repository" raus kommst.

Derzeit läuft er auf /dev/ttyAMA0 wenn ich den Port wechsle auf /dev/ttyUSB0 kommt:

wireless-mbus.0
10849	2022-04-04 08:47:42.147	error	CUL: Error setting wMBus mode: Timeout waiting for response

wireless-mbus.0
10849	2022-04-04 08:47:42.144	error	CUL: Message response timeout

Das bedeutet, das er auf dem ttyUSB0 nicht ansprechbar ist oder?

Im Grunde ja. Welches der richtige Port musst du schon selber wissen / rausfinden. (Zb. in dmesg nach dem Verbinden des CULs gucken...) Auf Dauer würde ich dir aber empfehlen, einen Symlink durch udev anlegen zu lassen, damit du nicht auf die ttyUSB Nummerierung vertrauen musst. Wenn du mehr als ein Serialdevice hast, kann die sich (am RPi) nämlich je nach Neustart ändern. (Dazu gibt's keine Anleitung von mir - aber mehr als genug quer durchs Internet verteilt...)

Mal geraten: /dev/ttyAMA0 klingt (in meiner Erinnerung) für den Raspi eher unplausibel - ist je nach Config glaube ich ein Debug Port. Evtl. kommen da Berge von anderen Daten/Müll an. Der Adapter sammelt alles auf (weil er darauf wartet ein vollständiges Telegramm oder eine Antwort auf einen Befehl zu bekommen und schreibt ruckzuck den RAM voll. Vor dem Hintergrund sollte ich mal noch ein Limit für den Puffer einbauen, das ist bisher nämlich noch nicht der Fall...
Wenn ich da richtig gereaten hätte, dann gäbe es kein Problem außer dass du den korrekten Port auswählen musst...

Und es "funkt" auf jeden Fall Ich habe hier Test-Heizkostenverteiler verschiedener Marken als Testgeräte, auf der richtigen Frequenz und im richtigen OMS WMBUS Format, einige sind AES verschlüsselt, andere nicht, aber keiner kommt an in den Objekten.

Das ist schon mal gut - aber natürlich musst du trotzdem darauf warten dass die Geräte auch tatsächlich was versenden. Gerade Heizkostenverteiler sind nicht gerade die Geräte die am häufigsten Senden... (kenne aber natürlich deine konkreten Geräte und deren Konfiguration aber nicht.)

[marsmännchen]

Ich habe scheinbar das gleiche Problem.
Ich versuchte schon lange mit dem Git-Projekt https://github.com/weetmuts/wmbusmeters
eine Verbindung mit MQTT zum IoBroker zu bekommen.
Ich hatte es schon geschafft wunderschöne Werte per Shell von Diehl zu bekommen. Jedoch habe ich es nie geschafft es per MQTT zu versenden.
Jetzt versuche ich es wieder mal mit dem wireless-mbus Adapter.
Meine Hardware:
Ein selbst gebauter CUL mit ArduinoNano mit einem TI-CC1101. Die Firmware ist die von wmbusmeters: https://weetmuts.github.io/wmbusmeterswiki/nanoCUL.html
Wenn ich dmesg:

[    6.798812] usb 1-1.3: ch341-uart converter now attached to ttyUSB0

wenn ich ls -l /dev/ttyUSB*

crw-rw---- 1 root dialout 188, 0  6. Apr 19:41 /dev/ttyUSB0

Aber leider habe ich mit der Konfiguration:

Die Fehlermeldung:

wireless-mbus.0
2022-04-06 20:09:23.651	error	CUL: Error setting wMBus mode: Timeout waiting for response

wireless-mbus.0
2022-04-06 20:09:23.650	error	CUL: Message response timeout

wireless-mbus.0
2022-04-06 20:09:20.732	debug	connected set to true

wireless-mbus.0
2022-04-06 20:09:20.690	debug	connected set to true

wireless-mbus.0
2022-04-06 20:09:20.640	debug	Created device of type: CUL (untested)

wireless-mbus.0
2022-04-06 20:09:20.561	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.0, js-controller: 4.0.19

Muss man etwas in Raspi-Config für den Adapter ändern?

Oder ist das ein Problem der Firmware?
Vielleicht hat jemand einen Tipp wie ich da weitermachen kann.
Gruß
Patrick

[lvogt]

@marsmännchen
Wenn du die Firmware verwendet hast, die du verlinkst, dann musst du 38400 als Baudrate verwenden.

[hg6806]

Leider bekomme ich noch immer keine Daten.
NanoCUL iPerl Wasserzähler.

Ich habe parallel wmbusmeters erfolgreich laufen und dies vorher per

 sudo systemctl stop wmbusmeters.service

 sudo systemctl stop wmbusmeters

gestoppt. Müsste doch ausreichen, oder?

Nach dem Starten sieht es auch gut aus:

wireless-mbus.0
2022-04-07 11:33:27.659	debug	connected set to true

wireless-mbus.0
2022-04-07 11:33:27.656	debug	connected set to true

wireless-mbus.0
2022-04-07 11:33:27.580	debug	CUL: Receiver set to T-MODE and data reporting with RSSI

wireless-mbus.0
2022-04-07 11:33:27.555	debug	Created device of type: CUL (untested)

wireless-mbus.0
2022-04-07 11:33:27.402	info	starting. Version 0.7.8 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.1, js-controller: 4.0.21

wireless-mbus.0
2022-04-07 11:33:26.164	debug	States connected to redis: 127.0.0.1:9000

wireless-mbus.0
2022-04-07 11:33:26.028	debug	States create User PubSub Client

wireless-mbus.0
2022-04-07 11:33:26.026	debug	States create System PubSub Client

wireless-mbus.0
2022-04-07 11:33:25.948	debug	Redis States: Use Redis connection: 127.0.0.1:9000

wireless-mbus.0
2022-04-07 11:33:25.796	debug	Objects connected to redis: 127.0.0.1:9001

wireless-mbus.0
2022-04-07 11:33:25.778	debug	Objects client initialize lua scripts

wireless-mbus.0
2022-04-07 11:33:25.392	debug	Objects create User PubSub Client

wireless-mbus.0
2022-04-07 11:33:25.389	debug	Objects create System PubSub Client

wireless-mbus.0
2022-04-07 11:33:25.327	debug	Objects client ready ... initialize now

wireless-mbus.0
2022-04-07 11:33:25.161	debug	Redis Objects: Use Redis connection: 127.0.0.1:9001

wireless-mbus.0
2022-04-07 11:33:17.472	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

wireless-mbus.0
2022-04-07 11:33:17.470	info	terminating

wireless-mbus.0
2022-04-07 11:33:17.467	info	Got terminate signal TERMINATE_YOURSELF

Aber es kommen einfach keine Daten. Da müssten alle 1-3h Daten kommen.

Ich habe folgende Firmware geflashed:
https://github.com/smarthomeagentur/culfw1/releases/tag/180dcb5

Datenpunkte werden angelegt, connected is auch:

Hier sind die Settings:

Als "Geräte Adresse" habe ich die ID eingetragen. Ist das überhaupt richtig?

[Michi_Pi]

@hg6806 verwende mal eine andere baudrate, ich musste die 57600 einstellen.

[hg6806]

Es läuft jetzt.
Nach einiger Zeit kam dann vom Wasserzähler eine Übermittlung.
Im Adapter wurde dann angezeigt, dass von SEN-xxxxx des AES Key fehlt.
Somit hatte ich dann auch den Gerätenamen, denn ich eins drüber dann korrigiert habe.

@Michi_Pi und zwar bei mir auf 9600

[marsmännchen]

Bei mir leider immer noch der selbe Error.
Hab versucht 9600,38400,57600 bei allem der gleiche Fehler.
Einzig wenn ich den Port auf /dev/ttyAMA0 stelle dann kommt nur:

wireless-mbus.0
2022-04-07 18:49:03.180	debug	connected set to true

wireless-mbus.0
2022-04-07 18:49:03.178	debug	connected set to true

wireless-mbus.0
2022-04-07 18:49:03.163	debug	Created device of type: CUL (untested)

wireless-mbus.0
2022-04-07 18:49:03.098	info	starting. Version 0.7.8 (non-npm: lvogt/ioBroker.wireless-mbus#ece83640b64ef90971e96e03b229f236dd2d2b0a) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.0, js-controller: 4.0.19

Ohne dem Error, aber auch ohne Werte. Mein ArduinoNano hängt aber am USB Port.
Und außerdem, wenn ich im Adapter die Baudrate ändere und dann Speichern&Schliessen klicke, reicht das aus, oder sollte ich dann noch etwas neu starten?
Muss ich die Geräteadresse eintragen? Bei wmbusmaster hatte ich keine in Verwendung, und AES Schlüssel brauch ich scheinbar auch nicht.
Sorry die dummen Fragen, ich will mir nur nicht irgendeinen Fehler einbauen.

[lvogt]

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

Es läuft jetzt.

Hattest du jetzt noch was geändert oder einfach nur gewartet? Aber schön das es funktioniert.

@marsmännchen said in Test Adapter wireless-mbus v0.7.x:

Bei mir leider immer noch der selbe Error.
Hab versucht 9600,38400,57600 bei allem der gleiche Fehler.
Einzig wenn ich den Port auf /dev/ttyAMA0 stelle dann kommt nur:

Da kommt zwar der Fehler nicht - aber auc keine Erfolgsmeldung die eigentlich kommen müsste... Kombiniert damit dass der Port eigentlich keinen Sinn ergibt dürfte das wohl nicht der richtige Weg sein...

Und außerdem, wenn ich im Adapter die Baudrate ändere und dann Speichern&Schliessen klicke, reicht das aus, oder sollte ich dann noch etwas neu starten?

Nein, wenn man die Einstellungen ändert, startet ioBroker einen Adapter sowieso immer neu.

Muss ich die Geräteadresse eintragen? Bei wmbusmaster hatte ich keine in Verwendung, und AES Schlüssel brauch ich scheinbar auch nicht.

Nein die sind nur nötig wenn man AES Schlüssel braucht - und auch dann ist es einfacher da erst was einzutragen wenn man mal ein verschlüsseltes Telegramm empfangen hat (das taucht dann im (Debug) Log auf)

In meinem Augen ist das Problem immer noch wahlweise falscher Port / falsche Baudrate oder eine "merkwürdige" Firmware (aber ich denke wenn wmbusmeters funktioniert dann sollte die Firmware ok sein - aber ka )

[hg6806]

@marsmännchen
Schau doch erst einmal per

 ls -la /dev/serial/by-id

wo der Stick hängt.

Hast du auch einen nanoCUL und iPerl? Und hat es mit wmbusmeters funktioniert?
Dann sollte es jetzt auch funktionieren.
Geräteadresse ist immer xxx-ID, Bei meinem iPerl ist es SEN-xxxxxxx

Es dauert auch manchmal Stunden bis der Wasserzähler überhaupt was sendet.
Ich weiß jetzt gar nicht wie die Stadtwerke das machen. Ob die einen Impuls aussenden können, der den Wasserzähler anregt was auszusenden.
Ich finde es sowieso spannend dass die überhaupt was empfangen können.
Der Wasserzähler ist im Betonkeller verbaut, auf dem Lichtschacht ist ein feinmaschiges Edelstahlgitter gelegt. Das Haus ist bis zur Strasse bzw. Wendehammer nochmal 15m entfernt.

[marsmännchen]

@hg6806

 ls -l /dev/ttyUSB*

Habe ich immer wieder mal gemacht, da findet er auch den cul:

crw-rw---- 1 root dialout 188, 0  6. Apr 19:41 /dev/ttyUSB0

Ich hab keinen bestimmten stick. Meine Hardware besteht aus einem ArduinoNano und dem TI-CC1101.
Auf einem anderen Raspberry habe ich wmbusmeters installiert, dort hat der Wasserzähler alle 15sec seinen Wert gesendet.(Oder wmbusmeters hat ihn alle 15sec. abgefragt,keine Ahnung) Zumindest habe ich alle 15 sec in der Console den aktuellen Zählerstand gesehen.
Muss man auf dem Raspberry noch irgendetwas extra installieren damit der Adapter funktioniert? Mosquitto oder sowas?

[hg6806]

@marsmännchen

Der Stick findet sich bei mir aber wie folgt:

lrwxrwxrwx 1 root root  13  3. Apr 09:42 usb-SHA_CUL868-if00 -> ../../ttyACM0

Welchen Wasserzähler hast du?

Bei 15 Sk. sollte das Try/error Spiel ja recht einfach sein.

Und nein, sonst muss nichts anderes installiert sein. Auch kein Mosquitto.

[marsmännchen]

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

@marsmännchen

Der Stick findet sich bei mir aber wie folgt:

lrwxrwxrwx 1 root root  13  3. Apr 09:42 usb-SHA_CUL868-if00 -> ../../ttyACM0

Interressant, das wäre mal ein Ansatz dem ich nachgehen sollte.
Was aber im widerspruch zum funktionierenden wmbusmeters am anderen Raspberry steht, wo es genauso angezeigt wird. Liegt vielleicht nur an der Hardware.
Try/Error besteht bei mir darin alle Baudraten einmal ausprobiert zu haben. Mehr Try's sind mir bis jetzt noch nicht eingefallen

[HKF8770]

@lvogt 2022-04-10 16:26:07.921 -

Habe den Adapter auf debug gestellt und bekomme das folgende.

info: wireless-mbus.0 (8517) Got terminate signal TERMINATE_YOURSELF
2022-04-10 16:26:07.925 - info: wireless-mbus.0 (8517) terminating
2022-04-10 16:26:07.927 - info: wireless-mbus.0 (8517) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2022-04-10 16:26:08.497 - info: host.iobrokerserver instance system.adapter.wireless-mbus.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2022-04-10 16:26:11.038 - info: host.iobrokerserver instance system.adapter.wireless-mbus.0 started with pid 9481
2022-04-10 16:26:12.370 - debug: wireless-mbus.0 (9481) Redis Objects: Use Redis connection: 127.0.0.1:9001
2022-04-10 16:26:12.442 - debug: wireless-mbus.0 (9481) Objects client ready ... initialize now
2022-04-10 16:26:12.445 - debug: wireless-mbus.0 (9481) Objects create System PubSub Client
2022-04-10 16:26:12.446 - debug: wireless-mbus.0 (9481) Objects create User PubSub Client
2022-04-10 16:26:12.531 - debug: wireless-mbus.0 (9481) Objects client initialize lua scripts
2022-04-10 16:26:12.538 - debug: wireless-mbus.0 (9481) Objects connected to redis: 127.0.0.1:9001
2022-04-10 16:26:12.577 - debug: wireless-mbus.0 (9481) Redis States: Use Redis connection: 127.0.0.1:9000
2022-04-10 16:26:12.595 - debug: wireless-mbus.0 (9481) States create System PubSub Client
2022-04-10 16:26:12.597 - debug: wireless-mbus.0 (9481) States create User PubSub Client
2022-04-10 16:26:12.647 - debug: wireless-mbus.0 (9481) States connected to redis: 127.0.0.1:9000
2022-04-10 16:26:12.973 - warn: wireless-mbus.0 (9481) Object wireless-mbus.0.info.rawdata is invalid: Default value has to be type "string" but received type "boolean"
2022-04-10 16:26:12.975 - warn: wireless-mbus.0 (9481) This object will not be created in future versions. Please report this to the developer.
2022-04-10 16:26:12.989 - info: wireless-mbus.0 (9481) starting. Version 0.7.6 (non-npm: Apollon77/ioBroker.wireless-mbus#9054a4b6bf7ce4bf92f0804e60323dbece905460) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.0, js-controller: 4.0.21
2022-04-10 16:26:13.079 - debug: wireless-mbus.0 (9481) Created device of type: IMST iM871A
2022-04-10 16:26:13.102 - debug: wireless-mbus.0 (9481) IMST: Receiver mode set to CA mode
2022-04-10 16:26:13.104 - debug: wireless-mbus.0 (9481) connected set to true
2022-04-10 16:26:13.105 - debug: wireless-mbus.0 (9481) connected set to true

Wenn ich in das Feld "wireless-mbus.0.info.rawdata" gehe sieht das so aus

Ist also der Wert true / false.

Das Gerät ist eine Zenner Wasseruhr

https://www.energie-zaehler.com/epages/61422236.sf/de_DE/?ObjectPath=/Shops/61422236/Products/ETW-MM-DN20130-wMBUS

[lvogt]

@hkf8770

Damit ich es nicht falsch einsortiere: Bei dir ging es nur um den "VIFExt 0x13" Fehler, ja?

Falls ja, dann wäre natürlich auch Logauszug bei dem der Fehler auftaucht nötig...
Das Handbuch des verlinkten Zählers gibt natürlich keine exakte Telegrammcodierung an, behauptet aber dem OMS 4.0.2 Standard zu folgen. Die VIF Extension ist aber definitiv nicht Teil des Standards - evtl. aber nur eine "Zenner interne" Zusatzinformation. Dem Handbuch nach scheint es aber sowieso nur mit Vormonatswerten zusammen zu hängen und ist damit für dich vermutlich sowieso uninteressant...

2022-04-10 16:26:12.989 - info: wireless-mbus.0 (9481) starting. Version 0.7.6 (non-npm: Apollon77/ioBroker.wireless-mbus#9054a4b6bf7ce4bf92f0804e60323dbece905460) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.0, js-controller: 4.0.21

Kurzer Hinweis: Wie auch immer du dazu kommst: Du hast den Adapter weder aus dem "unstable / beta" Repository installiert, noch aus meinem Github Repository, sondern aus einem (nicht mehr aktuellen) Fork von Apollon. Wenn du die aktuelle Version hättest - wäre zB auch der (unwichtige) Hinweis auf den rawdata State nicht mehr da gewesen...

[HKF8770]

@lvogt ...woher ich den hatte von appollo kann ich nicht mehr sagen, ist aber auf deinen nun upgedatet. Jetzt habe ich die unrealistischen daten auch weg. Das 4-8 ist jetzt 1,828 m², das könnte der Vormonat sein. Da der erst 20 tage eingebaut ist, wird der 5-8 in einem Weilchen kommen

Echt super Adapter.

Blöde Frage. Ich nutze jetzt den C1 Modus bei der Abfrage.
Das muss ich ja im Adapter einstellen.

Wenn ich jetzt weitere Geräte kaufen die auf T1 senden, bedeutet dass das ich einen weitere Instanz installieren muss, also wireless-mbus.1.

Kann der dann auf den gleichen USB Stick zugreifen, oder benötige ich 2 Sticks?

[lvogt]

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

Wenn ich jetzt weitere Geräte kaufen die auf T1 senden, bedeutet dass das ich einen weitere Instanz installieren muss, also wireless-mbus.1.
Kann der dann auf den gleichen USB Stick zugreifen, oder benötige ich 2 Sticks?

Wenn du zwei Instanzen erzeugst braucht auch jede einen echten Stick, den sie anspricht.

Der AMBER Stick hat einen Mode der gleichzeitig C und T empfängt - aber im reinen C-Mode hatte ich auch schon mal öfter das Problem dass der Stick(!) irgendwann crasht und vom Strom bzw. USB getrennt werden muss (ob das Problem auch den gemischten Mode betrifft erinnere ich mich nicht mehr...)

Als Kompromis könnte man überlegen ob man den Tag über mal ne Weile im C Mode und dann wieder ne Weile im T Mode lauscht. Aber das kann der Adapter selber nicht - könnte man aber "von außen" über ein kleines Script einbauen. Man müsste halt nur den Mode in der Config setzen und ioBroker würde den Adapter dann ja sowieso neustarten.

[marsmännchen]

Ok, ich gebe auf mit meiner ArduinoUno TI-CC1101 combo.
Ich kann mir mein Problem nur mit der nicht unterstützten Hardware erklären. Mit wmbusmeter gehts, mit dem Adapter eben nicht.
Ist es erlaubt das mir jemand eine Kaufempfehlung gibt für einen CUL Stick der die Anforderungen erfüllt, und wo er ihn gekauft hat?
MfG
Patrick