Test Adapter ZWave 2 v1.9.x

[arteck]

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

Was es mit den komischen Sensorwerten auf sich hat, weiß ich auch nicht. Hab ich bei mir selbst schon gesehen, aber ich müsste ein Log sehen von dem Moment wo sie angelegt werden, um herauszufinden was das soll. Die gehören da jedenfalls nicht hin. Falls sie dich stören, Node re-interviewen.

die störe nicht ....wollte nur mal reporten

bei mir werden die immer dann angelegt wenn

node review -- dann stehen alle Datenpunkte richtig
dann adapter stopp
dann start

jetzt werden die komischen wieder angelegt

[_nico]

@alcalzone Update auf 1.9.0 hat gut funktioniert. Danke

Da gibt es unter Meter aber einige verwaiste Einträge. (siehe Screenshot)

Müssen wir die manuell löschen oder macht es irgendwann, in zukünftigen Unterversionen, das ZWave 2 Plugin?

[AlCalzone]

@_nico Schätze die hängen im Z-Wave Cache fest und werden deshalb nicht als verwaist erkannt. Am besten mal den betreffenden Node neu interviewen, dann verschwinden die auch.

[_nico]

@alcalzone Jo, da wurde einiges entfernt!

Dafür fehlt jetzt aber value_electric_kwh_consumed und reset. value_electric_kwh_consumed kommt sicher bei der ersten Übertragung des Wertes wieder. Aber reset?

Gruß Nico!

[AlCalzone]

@_nico Öh... Magste mir davon nochmal ein Log machen?

[_nico]

@alcalzone Jo, hier die Log und die 3 Cache-Files.

Archiv.zip

[AlCalzone]

@_nico Jetzt ist alles da, oder seh ich das im Screenshot falsch?

[_nico]

@alcalzone Jup, aber erst nach dem 2. Interview.

[AlCalzone]

@_nico Das letzte Log, ist das vom vollständigen oder vom unvollständigen Versuch?

[_nico]

@alcalzone Natürlich vom vollständigen Versuch.

Hier die Log vom unvollständigen, sind aber 6MB, muss so gegen 10:45 gewesen sein.

zwave-19716.log.zip

Gruß Nico

[AlCalzone]

@_nico Jo, der hat einfach nicht auf die Abfrage geantwortet, welche Meter er unterstützt:

2021-03-17T12:40:30.884Z CNTRLR   [Node 015] Querying meter support timed out, skipping interview...

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