Test Adapter ZWave 2 v1.9.x

[gelberlemmy]

@alcalzone moin bei mir haben sich Datenpunktnamen beim Update geändert. Konnte in der Beschreibung nicht sehen, das diese geändert wurden.
Es handelt sich hierbei um ein Zipato RF mini Keypad. Dort hat sich in Notification folgendes geändert:

von
zwave2.0.Node_048.Notification.keypadLockOperation_userId
in
zwave2.0.Node_048.Notification.accessControl_keypadLockOperation_userId

von
zwave2.0.Node_048.Notification.keypadUnlockOperation_userId
in
zwave2.0.Node_048.Notification.accessControl_keypadUnlockOperation_userId

Hatte mich schon gewundert, warum ich meine Alarmanlage nach dem Update nicht mehr geschaltet bekomme.

War dies so gewollt ? Oder habe ich dort etwas überlesen ?

Gruß André

[AlCalzone]

@gelberlemmy Ah Mist, das fehlt im Changelog... War notwendig, um mögliche Doppel-Nutzung einer ID zu vermeiden.

[gelberlemmy]

@alcalzone kein Thema....hatte mich nur gewundert.....

[_nico]

@AlCalzone

Mir ist gerade aufgefallen, dass der Devolo BWM und Devolo Tür-/Fensterkontakt nicht mehr die Datenpunkte Binary_Sensor.motion und Binary_Sensor.door_window aktualisiert, sondern jeweils nur Binary_Sensor.any.

Soll das so? Wenn ja und das Gerät es so schickt, ist es natürlich richtig und ich ändere meine Aliases! Wollte es nur vorab klären.

Log + Cache: Archiv.zip

Gruß Nico

--

Nachtrag, hat sich bei der Alarmsirene auch etwas verändert? Die Töne werden nicht mehr abgespielt.

/*

Feuersirene:    notificationType: 0x01, notificationEvent: 0x01
Tuergong:       notificationType: 0x06, notificationEvent: 0x16
Scharfschalten: notificationType: 0x06, notificationEvent: 0x03
Entschärfen:    notificationType: 0x06, notificationEvent: 0x04
Notfall:        notificationType: 0x07, notificationEvent: 0x01
Polizeisirene:  notificationType: 0x0A, notificationEvent: 0x01
Feueralarm:     notificationType: 0x0A, notificationEvent: 0x02
Krankenwagen:   notificationType: 0x0A, notificationEvent: 0x03
Stiller Alarm:  notificationType: 0x0A, notificationEvent: 0xFE
Aus:            notificationType: 0x0A, notificationEvent: 0x00

Rauch / Feuersirene = Feueralarm

*/

sendTo(
    "zwave2.0",
    "sendCommand",
    {
        nodeId: id, 			// The target node
        commandClass: "Notification", 	// Which command class to use
        command: "sendReport", 		// Which command should be sent
        args: [{
            notificationType: notiType,
            notificationEvent: notiEvent
        }],
    },
    ({ error, result }) => {
        if (error) {
            log(error, "error");
        } else {
            // Do something with the result (if there is any)
            // In this case, "undefined" is logged
            log(JSON.stringify(result));
        }
    },
);

[AlCalzone]

@_nico Weder noch sollte geändert sein. Ich schau mir dein Log morgen mal an. Kannst du mir für den Versucht mit der Sirene auch eins machen?

[_nico]

@alcalzone

Log Sirene: zwave-10373.log

2021-03-24T07:02:23.507Z DRIVER   Unexpected error during SerialAPI command: ZWaveError: Notification CC V1 (Ala
                                  rm CC) reports requires the alarm type and level to be set!
2021-03-24T07:02:23.508Z CNTRLR   [Node 046] did not respond after 1/3 attempts. Scheduling next try in 500 ms.
2021-03-24T07:02:24.013Z DRIVER   Unexpected error during SerialAPI command: ZWaveError: Notification CC V1 (Ala
                                  rm CC) reports requires the alarm type and level to be set!
2021-03-24T07:02:24.015Z CNTRLR   [Node 046] did not respond after 2/3 attempts. Scheduling next try in 500 ms.

[AlCalzone]

@_nico Ich weiß nicht, was genau passiert ist, aber alle deine Nodes haben für sämtliche CCs keine Versionsinfo. Als Folge dessen, versucht das Kommando eine V1 Notification zu senden, welche andere Daten braucht als die V2 Notifications.

Probier mal den Cache zu löschen, ob es sich dann wieder einpendelt.

[_nico]

@alcalzone Cache geleert, Interview's laufen noch.

Interview von der Alarmsirene (Node_046) ist durch, bin zwar nicht vor Ort, aber die Meldungen in der zwave.log sind weg und lassen darauf schließen, dass ein Ton abgespielt wurde.

Muss ich nun alle batteriebetriebene Geräte aufwecken (die meisten also von der Wand reißen)? Oder pendelt sich, dass in den nächsten Stunden / Tagen von alleine ein?

Ob die Devolo BWMs und Devolo Tür-/Fensterkontakte nun wieder die Datenpunkte Binary_Sensor.motion und Binary_Sensor.door_window aktualisieren, nicht mehr Binary_Sensor.any, kann ich erst ab 14:30 sagen, wenn zu Hause wieder Bewegung ist.

Stimmt nicht, ich kann das Garagentor öffnen - es wird immer noch Binary_Sensor.any auf true gesetzt, beim Öffnen des Kontakts (Node_009). Hier fehlt sicher noch das Interview, damit beim Öffnen auch wieder Binary_Sensor.door_window auf true gesetzt wird?

Viele Grüße

[AlCalzone]

An sich müsste es sich auch für Batteriebetriebene Geräte mit der Zeit einpendeln, wenn sie mal aufwachen.

Bin mir grade nicht 100% sicher, aber ich glaube für das Garagentor müsste der Adapter nach abgeschlossenem Interview auch wieder wissen, dass es ein Door/Window-Sensor ist. Ist der denn schon ready?

[_nico]

@alcalzone sagte in Test Adapter ZWave 2 v1.9.x:

An sich müsste es sich auch für Batteriebetriebene Geräte mit der Zeit einpendeln, wenn sie mal aufwachen.

Bin mir grade nicht 100% sicher, aber ich glaube für das Garagentor müsste der Adapter nach abgeschlossenem Interview auch wieder wissen, dass es ein Door/Window-Sensor ist. Ist der denn schon ready?

Nein, ready ist false - Interview ist noch nicht gelaufen.

Wenn ich in 4 Stunden nach Hause komme, kann ich das Gerät dann einfach aufwecken und das Interview wird durchgeführt? Oder kommt es irgendwann zum Timeout und ich muss das Interview manuell über die Adapter-Einstellungen triggern?

---

BTW: Wie sieht es eigentlich mit last_seen aus? https://github.com/zwave-js/node-zwave-js/issues/985#issuecomment-764902527

[AlCalzone]

@_nico sagte in Test Adapter ZWave 2 v1.9.x:

kann ich das Gerät dann einfach aufwecken und das Interview wird durchgeführt?

Jup!

@_nico sagte in Test Adapter ZWave 2 v1.9.x:

Wie sieht es eigentlich mit last_seen aus?

Steht noch auf der TODO-Liste

[eumats]

N'abend.

Ich wollte gerade von zwave auf zwave2 umstellen. Das klappt bei nahezu allen Aktoren auch super. Nur leider bei meinen beiden Fibaro FGS223 nicht.
Unter Binary_Switch werden nicht beide Kanäle/„Schalter“ eingezeigt und bei dem Einen der angezeigt wird, passiert beim Schalten in iobroker am Aktor auch nichts…

Beim FGS222 wird alles korrekt angezeigt.

Was habe ich bisher gemacht:

1. Cache leeren
2. erneut interviewen
3. Adapter deinstalliert und neu installiert

Alles leider ohne Erfolg. Bei der Suche hier im Forum habe ich nur die Information gefunden, das der FGS223 bei einigen funktioniert.

Ich wäre für einen Tipp dankbar.

Gruß

[AlCalzone]

@eumats sagte in Test Adapter ZWave 2 v1.9.x:

Ich wäre für einen Tipp dankbar.

Machst du mir mal ein Log vom erneuten Interview des Nodes?

https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md#notwendige-informationen-für-ein-issue

[eumats]

@alcalzone

Klar sehr gerne. Dann hier posten oder lieber einen issue?

[AlCalzone]

@eumats Ruhig hier

[eumats]

@AlCalzone

Hier die Dateien. Es handelt sich im die Nodes 005 und 005. Danke..

zwave-18410.log
cc14663e.json
cc14663e.values.jsonl

[AlCalzone]

@eumats 5 und nochmal 5?

[AlCalzone]

Das Log scheint mir nicht besonders vollständig, aber ich hab da ne Idee:

cannot reply to NonceGet because no network key was configured!

Du hast verschlüsselt eingebundene Geräte, aber den Netzwerkschlüssel nicht aus dem alten Adapter übernommen.

[eumats]

@alcalzone

Upsi. 5 und 6...

[eumats]

@alcalzone

Eigentlich habe ich damals alle Geräte unverschlüsselt eingebunden. Ich habe es mal versucht um verschlüsseln, aber die Geräte ließen sich dann nicht koppeln.

Ich schaue aber morgen noch mal...

Edit: Was meinst Du mit das Log war nicht vollständig? Der Adapter lief da 10min. War das zu kurz?
Die die betreffenden Geräte wurden ja erkannt. Daher dachte ich es reicht aus.