UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Rolf_KA]

@Rolf_KA sagte in Test adapter ZWave2 (v0.9.x):

OpenZW und ZWave2 gleichzeitig aktiv sein...

Meinte: OpenZW und ZWave2 "nicht" gleichzeitig aktiv sein...

[JackWolfskind]

Klar, OpenZW hab ich vorher entfernt...

[Markus84]

@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?

[AlCalzone]

@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.

[AlCalzone]

@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.

[JackWolfskind]

@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?

[AlCalzone]

@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...

[Markus84]

@AlCalzone

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.

zwave-31830.log zwave-25223.log e84eb057.json

[AlCalzone]

@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.

[maloross]

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 awake

Eine 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 dead

Bisher erfolglos durchgeführt:

• Adapter Neustart
• Cache leeren
• Netzwerk heilen -> läuft (?? Button rot) aktuell noch

zwave-5263.log

EDIT: Bei Node 4 handelt es sich um einen Wall Plug
Edit2: js-Controller ist aktuell

[AlCalzone]

@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.

[maloross]

@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

[AlCalzone]

@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)?

[maloross]

@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

[JackWolfskind]

@AlCalzone In der Tat, ein RPi reboot half :-)
Hat sich wohl was an der USB Schnittstelle verklemmt ;-)

[Schuko80]

@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 :man-facepalming:

Also Scan completed stand aber definitiv im Log, hab jetzt den Cache gelöscht, alles noch mal durchlaufen lassen

Danach wie folgt vorgegangen:

1. Node 4 manuell aufgeweckt
2. Wert von 4 auf 4,5 hochgedreht
3. Node 4 wieder manuell aufgeweckt
4. Temperatur über rauf Taste von 4 auf 5 geändert
5. Temperatur über runter Taste von 5 auf 4 geändert
6. gewartet, bis Node4 selber aufwacht

Hier das OZW Log File:
OZW_log.txt

[Markus84]

@AlCalzone

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?

[AlCalzone]

@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.

[Markus84]

@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!

[AlCalzone]

@Schuko80 Das Log hilft mir weiter :)
Ich sehe zwei Unterschiede:

1. 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.
2. 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.