Test Adapter wireless-mbus v0.10.x
-
@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 memoryWenn 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 timeoutDas 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
dmesgnach 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/ttyAMA0klingt (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 ttyUSB0wenn ich ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 6. Apr 19:41 /dev/ttyUSB0Aber 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.19Muss 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 wmbusmetersgestoppt. 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_YOURSELFAber 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.19Ohne 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-idwo 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/ttyUSB0Ich 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 -> ../../ttyACM0Welchen 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 -> ../../ttyACM0Interressant, 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
rawdataState 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?
-
@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.
-
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 -
@marsmännchen
Du könntest noch ein paar Infos con wbusmeters posten, vl können wir dann weiter helfen.
Also zb die Konfiguration und mal einen Aufruf auf mit Ausgabe von wbusmeters wenn auch Daten ankommen.
Ob das wirklich hilft weiß ich natürlich nicht... -
Vielen Dank für die Hilfe, ich hab das schon abgebrochen, und wmbusmeters deinstalliert. Ich warte jetzt erst mal auf :
"eQ3 INNOGY RWE SmartHome USB Empfangseinheit Stromzähler Empfangs Einheit iM871A"
Wenn's damit nicht geht bau ich mir einen Durchflussmesser in die Leitung der in die Wago PFC200 geht. Damit geht's dann sicher. Die Konstellation vom Smartmeter Adapter - Landis+Gyr E450 - Hichi USB Lesekopf hat auch nie funktioniert, musste dann auch auf Eigenbau umsteigen.
Aber mal abwarten ob das mit dem iM871A was bringt.
Danke trotzdem:
-
@marsmännchen said in Test Adapter wireless-mbus v0.7.x:
Vielen Dank für die Hilfe, ich hab das schon abgebrochen, und wmbusmeters deinstalliert. Ich warte jetzt erst mal auf :
"eQ3 INNOGY RWE SmartHome USB Empfangseinheit Stromzähler Empfangs Einheit iM871A"Also da hatten wir wohl die gleiche Idee. Leider hat der Stick von RWE eine andere USB PID (87ED) als der originale iMST iM871A. Und damit wird er (zumindest bei mir) leider nicht erkannt. Hab auch die originale Firmware von iMST drüber geflasht - hat aber auch nicht geholfen. Wenn du damit weiterkommst, sag bitte mal Bescheid
Bin drauf und dran mir einen DVB-T Stick in Verbindung mit rtl-wmbus zuzulegen. Da lassen sich sogar alle Modi (C, T und S) gleichzeitig abfragen. @Ivogt: Wäre es möglich den rtl-wmbus auch in deinem Adapter unterstützten?
