Test adapter ZWave2 (v0.9.x)
-
Klar, OpenZW hab ich vorher entfernt...
-
@AlCalzone said in Test adapter ZWave2 (v0.9.x):
Mir die folgenden Dateien schicken:
/opt/iobroker/iobroker-data/zwave2.0/cache/<irgendwas>.json
/opt/iobroker/node_modules/zwave-js/zwave-<irgendwas>.log (bitte die mit dem neuesten Datum).Kann ich das hier ohne Sicherheitsrisiko posten oder wie soll ich dir die Dateien zukommen lassen?
-
@Markus84 Ja kein Problem.
@JackWolfskind "Cannot allocate memory" klingt für mich nach vollem RAM. Wie sieht da die Auslastung aus?
@Schuko80 Danke schon mal für die Logs, aber ... bitte, bitte, bitte schick mir doch noch das angefragte vollständige Log vom originalen Z-Wave Adapter:
@AlCalzone sagte in Test adapter ZWave2 (v0.9.x):Und das bitte nicht vergessen:
@AlCalzone sagte in Test adapter ZWave2 (v0.9.x):
Der OZW_Log hilft mir so leider nicht. Das Interview von Node 4 war noch nicht abgeschlossen, als du die Setpoint-Änderungen durchgeführt hast. Stand denn im ioBroker-Log schon "Scan completed"?
Außerdem bräuchte ich mindestens ein selbstständiges Aufwachen des Nodes nach abgeschlossenem Interview - dazu musst du den Adapter mit Logging einfach noch ca 20 Minuten laufen lassen. -
@Schuko80 Im zweiten Log sieht man jetzt, dass das Thermostat 1x auf die Abfrage des Setpoints antwortet. Der Adapter scannt aber die möglichen Setpoints, und beim nächsten kommt wieder keine Antwort.
Daher ist es für mich wichtig zu sehen, wie OpenZWave damit umgeht. Bitte vor dem Log-Erstellen auch diesen Cache löschen. Das ist eine XML-Datei, die du in der Regel unter
/opt/iobroker/node_modules/openzwave-shared/oder/opt/iobroker/node_modules/iobroker.zwave/node_modules/openzwave-shared/findest. -
@AlCalzone
Am Speicher sollte es eigentlich nicht liegen:
Total RAM usage: 1549 Mb / Free: 72% = 2.839 Mb
Den Debug Level erhöhen bringt nichts, was hat es denn mit dem detailed logging im Adapter auf sich? -
@JackWolfskind sagte in Test adapter ZWave2 (v0.9.x):
Den Debug Level erhöhen bringt nichts, was hat es denn mit dem detailed logging im Adapter auf sich?
Das schreibt den kompletten Datenaustausch inklusive zusätzlicher Infos mit. Ist hier nicht zielführend, weil die Schnittstelle gar nicht erst geöffnet wird.
Vielleicht blöde Frage, aber...
-
Anbei die Dateien
Node 7 ist ein Tür-/Fenstersensor der nicht gefunden wird, obwohl er 2 Meter neben dem Z-Wave Stick ist und mit dem anderen Z-Wave Adapter auch einwandfrei funktioniert
Node 9 ist eine Fernbedienung. Hier wird der Tastendruck nicht erkannt
Node 4,10,11,12 sind Abus Rauchmelder. Die funktionieren einwandfrei, es wird leider kein Name angezeigt.Vielen Dank für deine Mühe!
Ist geplant in der Geräteübersicht auch eigene Namen vergeben zu können? Da ich z.B. mehrere Rauchmelder habe wäre es super, wenn man diese am Namen unterscheiden könnte.
-
@Markus84 Deine Logs schaue ich mir in Ruhe an.
Ist geplant in der Geräteübersicht auch eigene Namen vergeben zu können?
Im Objekte-Tab kannst du die Geräte (Node_xyz) in der Namensspalte schon umbenennen, das bleibt dann auch so.
-
Nach Upgrade auf 9.3 werden 2 von 17 Geräten nicht gefunden.
Upgrade Vorgehensweise:- Installation über Konsole und NPM
- Restart ioB
im ioB-Log steht
zwave2.0 2020-01-28 12:40:33.206 info (5263) Node 4: is now dead zwave2.0 2020-01-28 12:40:18.290 info (5263) Node 4: is now awake zwave2.0 2020-01-28 12:40:17.984 info (5263) Node 4: has returned from the dead zwave2.0 2020-01-28 12:39:42.227 info (5263) Node 4: is now dead zwave2.0 2020-01-28 12:39:27.265 info (5263) Node 4: is now awake zwave2.0 2020-01-28 12:39:26.948 info (5263) Node 4: has returned from the dead zwave2.0 2020-01-28 12:38:33.232 info (5263) Node 4: is now dead zwave2.0 2020-01-28 12:38:18.279 info (5263) Node 4: is now awake zwave2.0 2020-01-28 12:38:18.036 info (5263) Node 4: has returned from the dead zwave2.0 2020-01-28 12:37:53.588 info (5263) Node 20: is now asleep zwave2.0 2020-01-28 12:37:43.586 info (5263) Node 20: is now awake zwave2.0 2020-01-28 12:37:42.702 info (5263) Node 4: is now dead zwave2.0 2020-01-28 12:37:27.749 info (5263) Node 4: is now awake zwave2.0 2020-01-28 12:37:27.445 info (5263) Node 4: has returned from the dead zwave2.0 2020-01-28 12:36:30.772 info (5263) Node 4: is now dead zwave2.0 2020-01-28 12:36:24.680 info (5263) Node 4: is now awakeEine Testschaltung führte zu folgendem Fehler:
zwave2.0 2020-01-28 12:34:01.551 info (5263) Node 17: has returned from the dead zwave2.0 2020-01-28 12:33:55.881 error (5263) The message will not be sent because node 17 is presumed dead zwave2.0 2020-01-28 12:33:52.866 info (5263) Node 17: is now dead zwave2.0 2020-01-28 12:33:52.805 error (5263) Node 17 did not respond to the current transaction after 3 attempts, it is presumed dead zwave2.0 2020-01-28 12:33:52.804 error (5263) Node 17 did not respond to the current transaction after 3 attempts, it is presumed deadBisher erfolglos durchgeführt:
- Adapter Neustart
- Cache leeren
- Netzwerk heilen -> läuft (?? Button rot) aktuell noch
EDIT: Bei Node 4 handelt es sich um einen Wall Plug
Edit2: js-Controller ist aktuell -
@maloross Danke für den Log. Das scheint beides im Endeffekt an einem ähnlichen Problem zu hängen. Beide Nodes weigern sich bei bestimmten Abfragen zu antworten und werden deswegen als tot markiert.
Allerdings bekomme ich auch von beiden zuverlässig eine Bestätigung, dass die Nachricht angekommen ist. Ich werde das Verhalten mal überdenken, so ist das nicht sinnvoll. -
@AlCalzone sagte in Test adapter ZWave2 (v0.9.x):
Allerdings bekomme ich auch von beiden zuverlässig eine Bestätigung, dass die Nachricht angekommen ist.
Ja, hatte den Log überflogen und fand das merkwürdig. Auch dass die Schaltung eines erkannten Nodes zu "Tod und Wiederauferstehung" desselben führte.
Die beiden erkannten Nodes sind dem Stick räumlich am nächsten.Durch diese Dauerschleife werden weitere Nodes wohl auch nicht mehr eingegliedert. Im Adapter schaut das so aus:
so die Ordnerstruktur
und das ist die Karte
-
@maloross Ja, die scheinen fast alle einen nicht existenten Config-Parameter abzufragen. Was ist denn z.B. Node 5 für ein Gerät (Hersteller und Typ bitte)?
-
@AlCalzone
Node 4, 5, 7, 8 und 18 sind Fibaro FGWPE/F Wall Plug Gen5
Node 9 Aeon Labs Multisensor
Node 10 Phileo Flood Multisensor
Node 11 Everspring Motion Sensor
Node 12 FGS222 Double Relay Switch
Node 13 und 21 AEON Labs ZW112 Door Window Sensor 6
Node 16 FGS213 Switch
Node 17 FGRGBWM441 RGBW Controller
Node 19 ZME_WALLC-S Secure Wall Controller
Node 20 FGMS001-ZW5 Motion Sensor -
@AlCalzone In der Tat, ein RPi reboot half
Hat sich wohl was an der USB Schnittstelle verklemmt
-
@Schuko80 Danke schon mal für die Logs, aber ... bitte, bitte, bitte schick mir doch noch das angefragte vollständige Log vom originalen Z-Wave Adapter:
Ja ups, sag doch gleich vom OZW Adapter, hab das voll überlesen
Also Scan completed stand aber definitiv im Log, hab jetzt den Cache gelöscht, alles noch mal durchlaufen lassen
Danach wie folgt vorgegangen:
- Node 4 manuell aufgeweckt
- Wert von 4 auf 4,5 hochgedreht
- Node 4 wieder manuell aufgeweckt
- Temperatur über rauf Taste von 4 auf 5 geändert
- Temperatur über runter Taste von 5 auf 4 geändert
- gewartet, bis Node4 selber aufwacht
Hier das OZW Log File:
OZW_log.txt -
Was mir gerade noch aufgefallen ist: Meine Rauchmelder setzen den Datenpunkt in deinem Adapter beim Auslösen auf 2. Im anderen Adapter wurde der Wert auf 1 gesetzt. Bevor ich mir die Arbeit 2x machen muss: Lässt du den Datenpunkt für den Alarm unter Node_xxx.Notification.smokeAlarm_sensorStatus und setzt auch beim Auslösen eine 2 oder wird das von dir während der Entwicklung nochmal angepasst?
-
@Markus84 Die Werte sind durch die Spezifikation vorgegeben und werden durch mich nicht verändert. 1 und 2 bedeuten beide "Rauch erkannt", wobei bei der 1 eigentlich noch eine Ortsinfo mitgeliefert wird. Diese kann der Adapter aber noch nicht auslesen und abbilden.
Welcher der beiden Werte verwendet wird, hängt vom Gerät ab. Also baue deine Skripts am besten so, dass beide Werte akzeptiert werden.
-
@AlCalzone said in Test adapter ZWave2 (v0.9.x):
Also baue deine Skripts am besten so, dass beide Werte akzeptiert werden.
Besten Dank für die Info, das mache ich!
-
@Schuko80 Das Log hilft mir weiter
Ich sehe zwei Unterschiede:- Beim Interview der Thermostat Setpoint CC macht OZW etwas anders. Meine Implementation folgt nicht exakt den Empfehlungen aus der Spezifikation, was zu den Interview-Problemen führt.
Das Thermostat scheint beim Aufwachen eine spezielle Nachricht zu senden und erwartet dann, dass die Batterie und die Uhrzeit abgefragt werden. Das macht mein Adapter auch nicht.
Ich sehe zu, dass ich das beides behebe - dann sehen wir weiter. Kann aber ein paar Tage dauern.
Edit: 2. sollte eigentlich passieren, aber dazu muss erst mal das Interview abgeschlossen werden. Das hängt am 1. Punkt. Wenn der behoben ist, hoffe ich, dass auch die vom Thermostat erwarteten Abfragen seitens des Controllers kommen.
-
Kleines Update:
Die letzten Bugs hängen alle ein bisschen zusammen. Ich bin dabei, sie nach und nach zu fixen. 1-2 Dinge stehen noch aus und ich muss danach noch final testen, ob mein System noch tut.Danach bin ich auf eure Tests angewiesen. Derzeit rechne ich Mitte nächster Woche mit der 0.9.4
