Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[AlCalzone]

@cburghardt sagte in [Aufruf] z-wave 1.6.3 testen:

Aber ich habe eine coole Funktion gefunden die den Start bei vielen Batterie Geräten deutlich schneller macht.

Details bitte :innocent:

[cburghardt]

@AlCalzone das ist openzwave spezifisch, es gibt ein Flag "AssumeAwake". Wenn das auf false gesetzt wird, werden beim initialen Scan die Geräte die zuletzt schlafend waren, gar nicht erst angefragt. Sonst werden die Batterie Geräte auch abgefragt und laufen ohnehin in einen timeout wenn sie nicht gerade zufällig wach sind.

[AlCalzone]

@cburghardt Achso... ich handhabe das in meiner Lib so, dass schlafende Geräte zwar gepingt werden - wenn keine Antwort kommt, aber das Gerät als nicht wach markiert wird und eine aktive Kommunikation erst beim nächsten Aufwachen stattfindet. Sensor-Updates und so werden trotzdem verarbeitet.
Ich weiß gerade nicht, was OZW da anders macht, dass es langsamer ist.

[cburghardt]

@AlCalzone da arbeitet openzwave identisch. Aber nachdem der ping mit timeout bei vielen Geräten (wie bei @Stormbringer ) auch dauert, kann man das auch ausschalten.
Warum die 1.6.3 langsamer sein soll als die 1.6.0 bei identischen openzwave library entzieht sich aber meiner Logik.

[AlCalzone]

@cburghardt sagte in [Aufruf] z-wave 1.6.3 testen:

Aber nachdem der ping mit timeout bei vielen Geräten (wie bei @Stormbringer ) auch dauert, kann man das auch ausschalten.

Macht Sinn, ich habe auch schon darüber nachgedacht, beim Start schlafende Geräte deren Status man nicht kennt entsprechend geringer zu priorisieren.

[peppino]

Hallo,

Bei mir stürzt der Adapter nach kurzer Zeit mit folgendem Fehler ab:

Exception: Manager.cpp:1512 - 101 - Invalid ValueID passed to GetValueLabel

OZW_Log3.txt

Mit Adapter Version 1.4.0 normale Funktion.

[cburghardt]

@peppino wir hatten das Problem schon einmal, ich habe ein issue bei openzwave-shared aufgemacht: https://github.com/OpenZWave/node-openzwave-shared/issues/353

Vielleicht hilft es, den Eintrag von node 2 in der openzwave config Datei zu löschen.

[peppino]

@cburghardt wenn ich den besagten Node 2 ausstecke dann startet der Adapter.
Node 2 ist ein "Greenwave Powernode 1"
Node 15 ist auch ein "Greenwave Powernode 1" dieser macht aber keine Probleme,

[cburghardt]

@peppino dann würde ich den besagten node noch einmal excluden und wieder neu einlernen. Vielleicht ging was beim ersten einlernen schief.

[peppino]

@cburghardt Habe Node 2 mit Adapter Version 1.4 excluded
jetzt mit Adapter 1.7.0 included jetzt läuft es. Danke!

Leider haben sich mit dem neuem Adapter teilweise die Namen der Datenpunkte geändert :disappointed:
Das bedeutet jetzt ein wenig Arbeit.

[smudu]

"Das bedeutet jetzt ein wenig Arbeit" kann ich so nicht unterschreiben. Mir hat es bei knapp 30 ZWave Devices mehr oder weniger alles zerlegt (Scripte, Alexa & iqontrol).
Ich vermute mal das mit den neuen Datenpunkt-Bezeichnungen kommt von openzwave. Wenn man nicht ewig auf 1.4.x bleiben will, muss man wohl dadurch.
Ein Hinweis im Changelog wäre trotzdem hilfreich gewesen...

Hier mal ein Erfahrungsbericht und noch Fragen/Bugs(?).
Meine früheren Versuche von 1.4.2 auf 1.6.x umzusteigen waren nicht erfolgreich. Ich wollte die Chance nutzen beim Umstieg von Raspi 3/Node 8 auf Raspi 4/Node 10 gleich auch das Thema anzugehen.
Angeblich reicht ja ein Minimal-Backup einspielen und ioBroker holt sich Adapter, etc. selber. Hat bis auf den Z-Wave Adapter auch erfolgreich funktioniert, hier immer wieder: "cannot find adapter "zwave@1.4.2". Try to install it..."
Lösung: Erst ZWave-Adapter installieren (+ sudo ldconfig) und dann Backup einspielen.

Die Abstürze/Neustarts beim Scannen der Geräte hatte ich auch erst mal. Da ich unfreiwillig unterbrochen wurde, hatte sich der Adapter nach mehreren Anläufen doch noch entschieden das er alles gefunden hat. Brauchte also nichts ex-/includen.

1. Frage, gibt es einen einfachen Weg die alten Datenpunkt-Leichen von 1.4.x zu löschen?

2. Frage, die Parameter für jedes ZWave Device liegen ja unter dem Unterpunkt CONFIGURATION. Bei mir werden die Default-Werte des Herstellers statt den tatsächlich eingestellten Werten angezeigt. Ist das so gewollt?

Letzter Punkt: Ich hatte versucht/vermutet die o.g. Parameter über ZWave Instanz > Geräte > "Info aktualisieren" zu bekommen. Das hat bei mir dazu geführt, dass die Node im Reiter Geräte und auch unter Objekte komplett gelöscht wurde. Nach dem Neustart der Instanz habe ich jetzt unter Objekte nur noch eine Leiche mit den Unterpunkten BASIC und WAKEUP.
Im Log steht:

2019-11-07 23:02:05.715  - info: zwave.0 List of ports: [{"comName":"/dev/ttyACM0"},{"comName":"/dev/ttyAMA0"}]
2019-11-07 23:02:29.005  - info: zwave.0 Execute refreshNodeInfo for 7
2019-11-07 23:02:29.315  - info: zwave.0 node removed: 7

Ich vermute mal, dass die jetzt wirklich gelöscht wurde :anguished:
Falls ich versehentlich mit Maus abgerutscht wäre: sollte da eine Sicherheitsabfrage kommen bevor eine Node gelöscht wird?

[cburghardt]

@smudu
zu 1) es gibt leider keinen einfachen Weg außer manuelles Löschen
zu 2) das kann ich nicht bestätigen, aber vielleicht hängt das vom Gerät ab. Normal werden da die richtigen Werte angezeigt.

Info aktualisieren löscht das Gerät und frägt es neu ab. Also einfach etwas Geduld, vor allem bei Batterie Geräten. Der Controller kennt es noch, also besteht da kein Risiko.

[easybeat]

Hallo

wollte gerade auf von 1.4.2. auf 1.6.3 updaten und das ging ziemlich schief. Nun läuft mein ZWave Adapter nicht mehr:

Hier mein Log:

$ ./iobroker upgrade zwave
Update zwave from @1.3.1 to @1.6.3
NPM version: 6.4.1
npm install iobroker.zwave@1.6.3 --unsafe-perm --production --save --prefix "/opt/iobroker" (System call)
find: ‘/etc/polkit-1/localauthority’: Keine Berechtigungfind: ‘/etc/ssl/private’: Keine Berechtigung

E: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libudev-dev_232-25+deb9u9_armhf.deb 404 Not Found [IP: 93.93.128.193 80]E: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/udev_232-25+deb9u9_armhf.deb 404 Not Found [IP: 93.93.128.193 80]
E: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libudev1_232-25+deb9u9_armhf.deb 404 Not Found [IP: 93.93.128.193 80]
E: Einige Archive konnten nicht heruntergeladen werden; vielleicht »apt-get update« ausführen oder mit »--fix-missing« probieren?

/opt/iobroker/node_modules/iobroker.zwave/lib/preinstall.js:16 if (!suppressException) throw e;
^

Error: Command failed: sudo apt-get install libudev-dev -y
E: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libudev-dev_232-25+deb9u9_armhf.deb 404 Not Found [IP: 93.93.128.193 80]
E: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/udev_232-25+deb9u9_armhf.deb 404 Not Found [IP: 93.93.128.193 80]
E: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libudev1_232-25+deb9u9_armhf.deb 404 Not Found [IP: 93.93.128.193 80]
E: Einige Archive konnten nicht heruntergeladen werden; vielleicht »apt-get update« ausführen oder mit »--fix-missing« probieren?

at checkExecSyncError (child_process.js:607:13)
at Object.execSync (child_process.js:647:13)
at doScript (/opt/iobroker/node_modules/iobroker.zwave/lib/preinstall.js:13:15)
at Object.<anonymous> (/opt/iobroker/node_modules/iobroker.zwave/lib/preinstall.js:26:7)
at Module._compile (module.js:653:30)
at Object.Module._extensions..js (module.js:664:10)
at Module.load (module.js:566:32)
at tryModuleLoad (module.js:506:12)
at Function.Module._load (module.js:498:3)
at Function.Module.runMain (module.js:694:10)

npm
WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.4 (node_modules/osx-temperature-sensor):npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.4: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"})

npm
ERR! code ELIFECYCLEnpm ERR! errno 1

npm ERR! iobroker.zwave@1.6.3 preinstall: node lib/preinstall.jsnpm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the iobroker.zwave@1.6.3 preinstall script.
npm
ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:npm ERR! /home/iobroker/.npm/_logs/2019-11-08T14_38_17_105Z-debug.log

ERROR: Cannot find io-package.json in null
ERROR: process exited with code 10

Irgendeine Idee?

Danke für die Hilfe.

Gruss

Beat

[cburghardt]

@easybeat said in Test Adapter z-wave v1.6.x:

E: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libudev-dev_232-25+deb9u9_armhf.deb 404 Not Found [IP: 93.93.128.193 80]E: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/udev_232-25+deb9u9_armhf.deb 404 Not Found [IP: 93.93.128.193 80]

Spontan würde ich mal sagen:

sudo apt-get update

Da werden veraltete Pakete gesucht.

[AlCalzone]

@easybeat sagte in Test Adapter z-wave v1.6.x:

E: Einige Archive konnten nicht heruntergeladen werden; vielleicht »apt-get update« ausführen oder mit »--fix-missing« probieren?

Aus meiner Sicht steht da was zu tun ist :grimacing:

[Stormbringer]

@AlCalzone Hat jetzt leider etwas gedauert bis ich, wie versprochen deinen Z Wave 2 Adapter probiert hab.... Gerade sind beim Admin Update alle Adapter off gegangen und dann hab ich die Gunst der stunde genutzt. Also Installation und Start des Adapters läuft ohne Fehler.

Nodes kommen auch rein aber irgendwie nur teilweise und nicht komplett. Also von einem Bewegungssensor ist mal Bewegung da und dafür Temperatur nicht... siehe Screenshot. Da alles mit dem anderen Adapter geskriptet ist konnte ich es aber leider nicht lange laufen lassen. Hoffe es hilft dir trotzdem etwas weiter.

[Stormbringer]

@cburghardt sagte in Test Adapter z-wave v1.6.x:

@AlCalzone da arbeitet openzwave identisch. Aber nachdem der ping mit timeout bei vielen Geräten (wie bei @Stormbringer ) auch dauert, kann man das auch ausschalten.
Warum die 1.6.3 langsamer sein soll als die 1.6.0 bei identischen openzwave library entzieht sich aber meiner Logik.

@cburghardt kann ich dich nochmal nerven? :o) Aber es lässt mir einfach keine Ruhe, weil ichs eben selber nicht versteh warum die Probleme nur bei mir auftauchen bei den Versionen nach 1.6.0 und js controller update unausweichlich kommt ;D

Du hast doch gemeint openzwave library ist gleich bei der 1.6.3.? Auf Github steht aber

1.6.3 (cburghardt) Update openzwave version

Kanns nicht doch damit zusammenhängen?

[cburghardt]

@Stormbringer die Version 1.6.3 hat einen Versionscheck von openzwave drin. Als du die installiert hast, wurde somit auch die aktuellste Version installiert. Als du zurückgegangen bist auf die 1.6.0, wurde aber die openzwave nicht verändert.
Nebenbei gesagt habe ich die Version 1.7.0 am laufen bei der ich ein paar Optimierungen eingebaut habe und der Start ist bei mir deutlich flotter.

[Stormbringer]

@cburghardt Danke für die Info 😉 Das erklärt warum die Wallmotes früher auch gingen und jetzt aufgeweckt werden müssen oder neu angelernt. Ähm, das man sich die OZW Version aussuchen kann ist zu viel Arbeit oder geht nicht oder?

Ist bei der 1.7.0 schon das drinnen mit dem neuen Verhalten für batteriebetrieben Geräte, das du ausprobieren wolltest?

[Stormbringer]

@cburghardt 1.7.0 erkennt leider auch keinen einzigen Batteriesensor nach Scan Complete :cry: