NEWS
Test Adapter wireless-mbus v0.9.x
-
@hg6806 sagte in Test Adapter wireless-mbus v0.7.x:
Ja, ich warte immer auf Übertragung und kann auch mal S Mode versuchen.
Nochmal die Frage ob es bei @kiste01 nun läuft?
Update: Hat sich geklärt. Mehrere Neustarts und ein kurzes Entfernen des Sticks haben Wunder bewirkt.
Das letzte Adapterupdate hat irgendwas verändert, so dass ich den Adapter nicht mehr grün bekomme, davor lief es top. Da ich zeitgleich aber auch sonst das System (iob auf 4.0.21 und node.js auf 14.19.1) aktualisiert habe, kann ich das nicht voneinander trennen.
Aktuell steht das im log
wireless-mbus.0 2022-03-28 18:04:19.841 debug connected set to false wireless-mbus.0 2022-03-28 18:04:19.803 debug connected set to false wireless-mbus.0 2022-03-28 18:04:19.800 debug connected set to false wireless-mbus.0 2022-03-28 18:04:19.786 error Serialport error: Port is not open wireless-mbus.0 2022-03-28 18:04:19.784 error Serialport error: Error Resource temporarily unavailable Cannot lock port wireless-mbus.0 2022-03-28 18:04:19.775 debug Created device of type: CUL (untested) wireless-mbus.0 2022-03-28 18:04:19.691 info starting. Version 0.7.7 (non-npm: lvogt/ioBroker.wireless-mbus#32679a612e4f3c02184035bd12d7fcaad4840ff1) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.19.1, js-controller: 4.0.21 wireless-mbus.0 2022-03-28 18:04:19.673 warn This object will not be created in future versions. Please report this to the developer. wireless-mbus.0 2022-03-28 18:04:19.671 warn Object wireless-mbus.0.info.rawdata is invalid: Default value has to be type "string" but received type "boolean"
-
@lvogt bei mir funktioniert nach wie vor der Adapter mit dem neuen Update.
-
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
-
@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?
-
@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!
-
@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.)
-
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 -
@marsmännchen
Wenn du die Firmware verwendet hast, die du verlinkst, dann musst du 38400 als Baudrate verwenden. -
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/180dcb5Datenpunkte werden angelegt, connected is auch:
Hier sind die Settings:
Als "Geräte Adresse" habe ich die ID eingetragen. Ist das überhaupt richtig?
-
@hg6806 verwende mal eine andere baudrate, ich musste die 57600 einstellen.
-
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
-
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. -
@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 )
-
@marsmännchen
Schau doch erst einmal perls -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-xxxxxxxEs 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. -
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? -
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.
-
@hg6806 sagte in Test Adapter wireless-mbus v0.7.x:
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 -
@lvogt 2022-04-10 16:26:07.921 -
Habe den Adapter auf debug gestellt und bekomme das folgende.
[32minfo[39m: wireless-mbus.0 (8517) Got terminate signal TERMINATE_YOURSELF
2022-04-10 16:26:07.925 - [32minfo[39m: wireless-mbus.0 (8517) terminating
2022-04-10 16:26:07.927 - [32minfo[39m: wireless-mbus.0 (8517) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2022-04-10 16:26:08.497 - [32minfo[39m: host.iobrokerserver instance system.adapter.wireless-mbus.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2022-04-10 16:26:11.038 - [32minfo[39m: host.iobrokerserver instance system.adapter.wireless-mbus.0 started with pid 9481
2022-04-10 16:26:12.370 - [34mdebug[39m: wireless-mbus.0 (9481) Redis Objects: Use Redis connection: 127.0.0.1:9001
2022-04-10 16:26:12.442 - [34mdebug[39m: wireless-mbus.0 (9481) Objects client ready ... initialize now
2022-04-10 16:26:12.445 - [34mdebug[39m: wireless-mbus.0 (9481) Objects create System PubSub Client
2022-04-10 16:26:12.446 - [34mdebug[39m: wireless-mbus.0 (9481) Objects create User PubSub Client
2022-04-10 16:26:12.531 - [34mdebug[39m: wireless-mbus.0 (9481) Objects client initialize lua scripts
2022-04-10 16:26:12.538 - [34mdebug[39m: wireless-mbus.0 (9481) Objects connected to redis: 127.0.0.1:9001
2022-04-10 16:26:12.577 - [34mdebug[39m: wireless-mbus.0 (9481) Redis States: Use Redis connection: 127.0.0.1:9000
2022-04-10 16:26:12.595 - [34mdebug[39m: wireless-mbus.0 (9481) States create System PubSub Client
2022-04-10 16:26:12.597 - [34mdebug[39m: wireless-mbus.0 (9481) States create User PubSub Client
2022-04-10 16:26:12.647 - [34mdebug[39m: wireless-mbus.0 (9481) States connected to redis: 127.0.0.1:9000
2022-04-10 16:26:12.973 - [33mwarn[39m: 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 - [33mwarn[39m: 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 - [32minfo[39m: 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 - [34mdebug[39m: wireless-mbus.0 (9481) Created device of type: IMST iM871A
2022-04-10 16:26:13.102 - [34mdebug[39m: wireless-mbus.0 (9481) IMST: Receiver mode set to CA mode
2022-04-10 16:26:13.104 - [34mdebug[39m: wireless-mbus.0 (9481) connected set to true
2022-04-10 16:26:13.105 - [34mdebug[39m: wireless-mbus.0 (9481) connected set to trueWenn 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
-
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 - [32minfo[39m: 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... -
@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?