NEWS
Test Adapter wireless-mbus v0.9.x
-
Und dann mal die Frage ob es einen Unterschied zum Wireless Adapter 0.1.12 ?
Wobei sich Dieser auch nicht Installieren lässt.Mein System ist soweit auch auf den neusten Stand
-
Hallo zusammen,
ich versuche mich gerade daran meinen Wasserzähler (Qualcosonic W1) via wm-bus in iobroker zu implementieren. Dabei bin ich hier über den iobroker.wmbus Adapter "gestolpert". Kann mir vielleicht jemand helfen wie ich den Adapter unter meinem Raspi installieren kann?
Danke und Grüsse
Jochen -
@hartwigm sagte in Test Adapter wmbus v0.5.x:
... allerdings bekomme ich diesen nicht mehr installiert.
System ist auf dem neusten Stand.
der wm-bus Adapter 0.5.2 läuft unter node-js v12 nicht mehr...
Ich betreibe ihn unter node-js v10 und konnte ihn nur über die URL installieren.
-
Hallo.
Habe auch mittlerweile einen Multical 21 mit Wireless M-Bus eingebaut bekommen und würde diesen gerne auslesen.
Den AES-Key bekomme ich demnächst vom Wasserversorger.
Wird es für den wmbus-Adapter noch ein Update geben, so dass er unter der neuen Version läuft?
Denke das Thema wird in Zukunft immer mehr Leute interessieren, da viele Wasserversorger ihre Zähler umrüsten und auf Wireless Ablesung setzen.
Gibt es eine günstigere Alternativ-Hardware zum iM871A-USB-Stick? Der ist mit ca. 50€ schon relativ teuer.
Danke! -
@lvogt kannst Du deinen Adapter vielleicht mal anpassen, sodass er auch wieder mit Node-JS V12 installierbar ist und läuft?
-
@atifan Hallo, Installationsanleitung steht hier
https://forum.iobroker.net/topic/11087/adapter-wm-bus-kampstrup-multical-21/81
Viel Spass -
@matze-dev darum geht es nicht.
Wenn man node-js von V10 auf V12 updatet, wirft der Adapter "wm-bus" Fehler oder lässt sich bei Neuinstallation gar nicht erst installieren. -
Hi Danke, ich habe mir jetzt mittlerweile nen ESP zum Auslesen gebaut, warte aber immer noch auf den AES-Key vom Wasserversorger
Hab das hier nachgebaut, Materialkosten sind ca. 10 Euro: https://github.com/chester4444/esp-multical21
Der sendet die Daten dann per MQTT.
Mit dem WM-Bus Adapter und nem fertigen Stick wäre das ganze aber bisschen einfacher zu realisieren. -
@lenny-cb Ist auch mein Problem, es lässt sich deswegen gleich gar nicht erst installieren. Weil das schon sehr lange so ist, habe ich meine Heizungsplanung jetzt auch ohne WM-Bus-Wärmemengenzähler abgeschlossen.
-
@jochen-0 sagte in Test Adapter wmbus v0.5.x:
Hallo zusammen,
ich versuche mich gerade daran meinen Wasserzähler (Qualcosonic W1) via wm-bus in iobroker zu implementieren. Dabei bin ich hier über den iobroker.wmbus Adapter "gestolpert". Kann mir vielleicht jemand helfen wie ich den Adapter unter meinem Raspi installieren kann?
Danke und Grüsse
JochenHallo Jochen,
ich stehe gerade auch vor dem Problem den Qualcosonic W1 irgenwie auszulesen. Das Display ist so schlecht/Kontrastarm das es mit der Wasserzählerlösung per Kamera nicht mehr funktioniert.Bist du irgendwie weiter gekommen?
-
Ich habe mal einen minimal Versuch unternommen:
https://github.com/lvogt/ioBroker.wmbus
Da ist einfach nur die Version des serialport Pakets auf einen aktuellen Stand geändert worden. Installieren kann ich das ganze (kurz im ioBroker Docker Container getestet) aber mehr kann ich im Grunde z. Z. nicht unternehmen.
Ich bin nicht mehr beim ISFH angestellt, dass den Adapter für Messtechnik verwendet. Ich selbst besitze keinerlei (sinnvolle) Hardware zum Empfang von wMBus Nachrichten und (vermutlich) auch keine wMBus Geräte in der Nähe... -
@lvogt sagte in Test Adapter wmbus v0.5.x:
Ich habe mal einen minimal Versuch unternommen:
https://github.com/lvogt/ioBroker.wmbus
Da ist einfach nur die Version des serialport Pakets auf einen aktuellen Stand geändert worden. Installieren kann ich das ganze (kurz im ioBroker Docker Container getestet) aber mehr kann ich im Grunde z. Z. nicht unternehmen.
Ich bin nicht mehr beim ISFH angestellt, dass den Adapter für Messtechnik verwendet. Ich selbst besitze keinerlei (sinnvolle) Hardware zum Empfang von wMBus Nachrichten und (vermutlich) auch keine wMBus Geräte in der Nähe...vorab, vielen Dank, dass du dich darum kümmerst.
leider ist es wohl mit der Aktualisierung nicht getan.wmbus.0 2021-08-09 11:18:07.489 warn Terminated (UNCAUGHT_EXCEPTION): Without reason wmbus.0 2021-08-09 11:18:07.473 error SerialPort.list no longer takes a callback and only returns a promise wmbus.0 2021-08-09 11:18:07.471 error TypeError: SerialPort.list no longer takes a callback and only returns a promise at Function.SerialPort.list (/opt/iobroker/node_modules/@serialport/stream/lib/index.js:651:11) at Adapter.processMessage (/opt/iobroker/node_modules/iobroker.wmbus/main.js:438:36) at Adapter.emit (events.js:314:20) at change (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5634:34) at Immediate.<anonymous> (/opt/iobroker/node_modules/@iobroker/db-states-redis/lib/states/statesInRedisClient.js:232:37) at processImmediate (internal/timers.js:461:21) wmbus.0 2021-08-09 11:18:07.459 error unhandled promise rejection: SerialPort.list no longer takes a callback and only returns a promise wmbus.0 2021-08-09 11:18:07.456 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). wmbus.0 2021-08-09 11:18:06.966 error Serialport errror: Port is not open wmbus.0 2021-08-09 11:18:06.959 error Serialport errror: Error: No such file or directory, cannot open /dev/ttyWMBUS
ich denke, hier wurden ursprünglich bei den symlinks was "umgebogen". Daher lässt sich auch der Port nicht öffnen. ABER, alles nur vermutung.
"dependencies": { "@iobroker/adapter-core": "^1.0.3", "node-aes-cmac": "^0.1.1", "serialport": "https://github.com/lvogt/node-serialport/tarball/v6.2.2-symlinks" },
-
Ja ich hatte "damals" auch an der serialport Bibliothek was geändert, damit die Symlinks mit angezeigt werden, um "stabil" den korrekten Port auswählen zu können. Grundsätzlich hatte "damals" aber auch die unveränderte Serialport Bibliothek funktioniert.
Mit dem "einfachen" Upgrade jetzt geht das dann evtl. nicht mehr - ich habe keine Ahnung wie sich serialport seitdem verändert hat.Deinem Logauszug nach, scheint sie sich jedenfalls deutlich geändert zu haben. Und so ist das ganze wohl nicht lauffähig - unabhängig von den Symlinks.
Ich werde mir das vl. in den nächsten Tagen mal anschauen - aber ich verspreche nichts.
-
So ich habe mal noch ein paar Kleinigkeiten angepasst. Es wird im Moment weiterhin die "normale" serialport Bibliothek verwendet. Falls die weiterhin keine Symlinks unterstützt, dann funktioniert das hier gerade auch nicht.
Falls der Adapter jetzt tatsächlich doch schon wieder läuft, dann könnte ich evtl. auch noch versuchen die Symlinks wieder einzubauen, falls gewünscht.
Falls es immer noch nicht funktioniert, müsste ich mal gucken was man so machen könnte...
EDIT: Ich habe auch mal noch versucht ein paar Fehler im "cul-test" Branch zu fixen. Vielleicht funktioniert das jetzt (wenn der Rest denn wieder funktioniert...)
-
@lvogt sagte in Test Adapter wmbus v0.5.x:
So ich habe mal noch ein paar Kleinigkeiten angepasst. Es wird im Moment weiterhin die "normale" serialport Bibliothek verwendet. Falls die weiterhin keine Symlinks unterstützt, dann funktioniert das hier gerade auch nicht.
Falls der Adapter jetzt tatsächlich doch schon wieder läuft, dann könnte ich evtl. auch noch versuchen die Symlinks wieder einzubauen, falls gewünscht.
Falls es immer noch nicht funktioniert, müsste ich mal gucken was man so machen könnte...
EDIT: Ich habe auch mal noch versucht ein paar Fehler im "cul-test" Branch zu fixen. Vielleicht funktioniert das jetzt (wenn der Rest denn wieder funktioniert...)
grad die letzte Version installiert. Klappt wieder. Installation OK, Daten kommen wieder an!
Erst einmal vielen Dank. Wenn ich noch etwas testen soll, sag bescheid. -
@lvogt vielleicht ist das noch interessant:
wmbus.0 2021-08-11 21:38:54.575 warn Object of state "wmbus.0.ESY-61015893.data.8-0-VIF_ELECTRIC_POWER" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.545 warn Object of state "wmbus.0.ESY-61015893.data.7-0-VIF_ELECTRIC_POWER" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.543 warn Object of state "wmbus.0.ESY-61015893.data.6-0-VIF_ELECTRIC_POWER" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.541 warn Object of state "wmbus.0.ESY-61015893.data.5-0-VIF_ELECTRIC_POWER" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.539 warn Object of state "wmbus.0.ESY-61015893.data.4-0-VIF_ENERGY_WATT" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.537 warn Object of state "wmbus.0.ESY-61015893.data.3-0-VIF_ENERGY_WATT" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.535 warn Object of state "wmbus.0.ESY-61015893.data.2-0-VIF_ENERGY_WATT" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.533 warn Object of state "wmbus.0.ESY-61015893.data.1-0-VIF_ENERGY_WATT" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.531 warn Object of state "wmbus.0.ESY-61015893.info.Updated" is missing the required property "common.type" wmbus.0 2021-08-11 21:38:54.528 warn Object of state "wmbus.0.ESY-61015893.info.AccessNumber" is missing the required property "common.type"
-
@lenny-cb Danke für den Hinweis. Ich habe gerade mal noch einen "mini-fix" dafür eingebaut, der allerdings nur greift für States die neu erstellt werden. Da wird dann der Typ auf 'mixed' gesetzt.
Außerdem bin ich recht überzeugt, dass der CUL Support funktionieren müssste. Es wäre also schön wenn es mal jemand ausprobieren würde.
Ich habe das ganze jetzt auch als v0.6.0 getaggt und im ersten Post verlinkt. Aber Achtung das "original" ISFH git enthält weiterhin die "alte" 0.5.2er Version!
-
@lvogt sagte in Test Adapter wmbus v0.5.x:
@lenny-cb Danke für den Hinweis. Ich habe gerade mal noch einen "mini-fix" dafür eingebaut, der allerdings nur greift für States die neu erstellt werden. Da wird dann der Typ auf 'mixed' gesetzt.
Außerdem bin ich recht überzeugt, dass der CUL Support funktionieren müssste. Es wäre also schön wenn es mal jemand ausprobieren würde.
Ich habe das ganze jetzt auch als v0.6.0 getaggt und im ersten Post verlinkt. Aber Achtung das "original" ISFH git enthält weiterhin die "alte" 0.5.2er Version!
Grad mal den Adapter neu installiert. Klappt wunderbar. Vielen Dank, die Warnungen sind weg.
CUL-kann ich leider nicht testen. Habe da, glaube ich, nicht die richtigen Gerätschaften da. -
Aktuelle Version ist nun 0.7.0. Dabei handelt es sich hauptsächlich nur um interne Anpassungen.
Das Ziel sollte eigentlich sein, die Version auch bei npm zu veröffentlichen, allerdings musste ich feststellen, dass es "so" nicht geht. Das Paket wird abgewiesen, da es einen zu ähnlichen Namen zu anderen Paketen hat.
Antwort von NPM:
403 Forbidden - PUT https://registry.npmjs.org/iobroker.wmbus - Package name too similar to existing packages; try renaming your package to '@lvogt/iobroker.wmbus' and publishing with 'npm publish --access=public' instead
Hat damit jemand Erfahrung? Oder was wäre generell jetzt das "ioBroker empfohlene Vorgehen"? Umbennenung in ioBroker.wireless-mbus vl.?
P.S. Ich würde mich immer noch sehr über Rückmeldungen zur CUL Unterstützung freuen.
-
Hi lvogt,
Ja das ist blöd von npm. Ich hatte schonmal so einen "Name ist sehr nah" Thema ... Du kannst versuchen npm anzuschreiben ob Sie den Namen freigeben. Ich hatte damals kein Glück.
Von daher ist es wohl eher die "npm empfohlene Vorgehensweise" so eine blöde umbenennung vorzunehmen Du kannst ggf den originalen Dev anschreiben wegen npm rechten oder halt wieder npm das Du den Namen übernehmen kannst. Das dauert dann paar Wochen hat aber schon mehrfach geklappt - habe aber gelesen das aktuell die Regeln wieder schärfer sind.
Generell hatte ich auch schon überlegt das zu tun was Du getan hast fand es aber wegen der LGPL v2 schwierig ... also bitte sei vorsichtig bezüglich der Verpflichtungen. Ich denke es "sollte" gecovered sein da der Quellcode weiter offen ist aber DU darfst keine Originalen Copyright Infos oder so entfernen und so weiter ...