Test Adapter Z-Wave 2 (v1.7.x)

[AlCalzone]

v1.7.3 ist auf dem Weg und fixt zwei Crashes in Notification CC @Harry94

[EvilEls]

@AlCalzone Moin!
Bei mir ist gerade die 1.7.2 beim Adapter Neustart mit diesem Fehler abgestürzt.
Habe es nicht hinbekommen, den Fehler ein weiteres Mal zu reproduzieren.
Dennoch vllt für dich von Interesse:

host.zaphod	2020-10-03 11:58:59.110	info	Restart adapter system.adapter.zwave2.0 because enabled
host.zaphod	2020-10-03 11:58:59.110	info	instance system.adapter.zwave2.0 terminated with code 0 (NO_ERROR)
host.zaphod	2020-10-03 11:58:59.109	error	Caught by controller[0]: at StateNode.getInitialState (/opt/iobroker/node_modules/xstate/lib/StateNode.js:1026:21)
host.zaphod	2020-10-03 11:58:59.109	error	Caught by controller[0]: at StateNode.resolveTransition (/opt/iobroker/node_modules/xstate/lib/StateNode.js:787:35)
host.zaphod	2020-10-03 11:58:59.109	error	Caught by controller[0]: at Object.resolveActions (/opt/iobroker/node_modules/xstate/lib/actions.js:389:19)
host.zaphod	2020-10-03 11:58:59.109	error	Caught by controller[0]: at Object.updateContext (/opt/iobroker/node_modules/xstate/lib/utils.js:399:25)
host.zaphod	2020-10-03 11:58:59.109	error	Caught by controller[0]: at Array.reduce (<anonymous>)
host.zaphod	2020-10-03 11:58:59.108	error	Caught by controller[0]: at /opt/iobroker/node_modules/xstate/lib/utils.js:417:31
host.zaphod	2020-10-03 11:58:59.108	error	Caught by controller[0]: at data (/opt/iobroker/node_modules/zwave-js/src/lib/driver/SerialAPICommandMachine.ts:173:29)
host.zaphod	2020-10-03 11:58:59.108	error	Caught by controller[0]: at SendDataRequest.serialize (/opt/iobroker/node_modules/zwave-js/src/lib/controller/SendDataMessages.ts:118:37)
host.zaphod	2020-10-03 11:58:59.108	error	Caught by controller[0]: at SecurityCCCommandEncapsulation.serialize (/opt/iobroker/node_modules/zwave-js/src/lib/commandclass/SecurityCC.ts:624:23)
host.zaphod	2020-10-03 11:58:59.107	error	Caught by controller[0]: at throwNoNonce (/opt/iobroker/node_modules/zwave-js/src/lib/commandclass/SecurityCC.ts:612:10)
host.zaphod	2020-10-03 11:58:59.105	error	Caught by controller[0]: Error: Security CC requires a nonce to be sent!
zwave2.0	2020-10-03 11:58:58.576	info	(13718) Terminated (NO_ERROR): Without reason
zwave2.0	2020-10-03 11:58:58.574	info	(13718) terminating
zwave2.0	2020-10-03 11:58:58.573	info	(13718) Cleaned everything up!
zwave2.0	2020-10-03 11:58:58.560	info	(13718) Resetting node status...
zwave2.0	2020-10-03 11:58:58.520	error	at StateNode.getInitialState (/opt/iobroker/node_modules/xstate/lib/StateNode.js:1026:21)
zwave2.0	2020-10-03 11:58:58.520	error	at StateNode.resolveTransition (/opt/iobroker/node_modules/xstate/lib/StateNode.js:787:35)
zwave2.0	2020-10-03 11:58:58.520	error	at Object.resolveActions (/opt/iobroker/node_modules/xstate/lib/actions.js:389:19)
zwave2.0	2020-10-03 11:58:58.520	error	at Object.updateContext (/opt/iobroker/node_modules/xstate/lib/utils.js:399:25)
zwave2.0	2020-10-03 11:58:58.520	error	at Array.reduce (<anonymous>)
zwave2.0	2020-10-03 11:58:58.520	error	at /opt/iobroker/node_modules/xstate/lib/utils.js:417:31
zwave2.0	2020-10-03 11:58:58.520	error	at data (/opt/iobroker/node_modules/zwave-js/src/lib/driver/SerialAPICommandMachine.ts:173:29)
zwave2.0	2020-10-03 11:58:58.520	error	at SendDataRequest.serialize (/opt/iobroker/node_modules/zwave-js/src/lib/controller/SendDataMessages.ts:118:37)
zwave2.0	2020-10-03 11:58:58.520	error	at SecurityCCCommandEncapsulation.serialize (/opt/iobroker/node_modules/zwave-js/src/lib/commandclass/SecurityCC.ts:624:23)
zwave2.0	2020-10-03 11:58:58.520	error	at throwNoNonce (/opt/iobroker/node_modules/zwave-js/src/lib/commandclass/SecurityCC.ts:612:10)
zwave2.0	2020-10-03 11:58:58.520	error	(13718) Error: Security CC requires a nonce to be sent!
zwave2.0	2020-10-03 11:58:58.520	error	(13718) uncaught exception: Security CC requires a nonce to be sent!
zwave2.0	2020-10-03 11:58:58.519	info	(13718) Shutting down driver...
zwave2.0	2020-10-03 11:58:58.518	error	at StateNode.getInitialState (/opt/iobroker/node_modules/xstate/lib/StateNode.js:1026:21)
zwave2.0	2020-10-03 11:58:58.518	error	at StateNode.resolveTransition (/opt/iobroker/node_modules/xstate/lib/StateNode.js:787:35)
zwave2.0	2020-10-03 11:58:58.518	error	at Object.resolveActions (/opt/iobroker/node_modules/xstate/lib/actions.js:389:19)
zwave2.0	2020-10-03 11:58:58.518	error	at Object.updateContext (/opt/iobroker/node_modules/xstate/lib/utils.js:399:25)
zwave2.0	2020-10-03 11:58:58.518	error	at Array.reduce (<anonymous>)
zwave2.0	2020-10-03 11:58:58.518	error	at /opt/iobroker/node_modules/xstate/lib/utils.js:417:31
zwave2.0	2020-10-03 11:58:58.518	error	at data (/opt/iobroker/node_modules/zwave-js/src/lib/driver/SerialAPICommandMachine.ts:173:29)
zwave2.0	2020-10-03 11:58:58.518	error	at SendDataRequest.serialize (/opt/iobroker/node_modules/zwave-js/src/lib/controller/SendDataMessages.ts:118:37)
zwave2.0	2020-10-03 11:58:58.518	error	at SecurityCCCommandEncapsulation.serialize (/opt/iobroker/node_modules/zwave-js/src/lib/commandclass/SecurityCC.ts:624:23)
zwave2.0	2020-10-03 11:58:58.518	error	at throwNoNonce (/opt/iobroker/node_modules/zwave-js/src/lib/commandclass/SecurityCC.ts:612:10)
zwave2.0	2020-10-03 11:58:58.518	error	(13718) Error: Security CC requires a nonce to be sent!
zwave2.0	2020-10-03 11:58:58.456	error	(13718) unhandled promise rejection: Security CC requires a nonce to be sent!
Unhandled	2020-10-03 11:58:58.456	error	promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
zwave2.0	2020-10-03 11:58:56.016	info	(13718) Node 3: interview completed, all values are updated

Update:
Ah, ich sehe gerade, dass ist wohl das gleich Problem wie @Harry94 hat. Probiere die 1.7.3.

[Flopsi]

@AlCalzone

Ich glaube das das Problem mit meinen Werten daran liegt das ich akkus in den Motion Augen habe...

Weil da wo 96 Prozent angezeigt wird ist eine Normale Batterie drin.....in allen anderen ein Akku.....

@Chris_78

Du schreibst im Changelog zur 1.7.2:
Option hinzugefügt, um die Kompatibilität mit älteren Switches zu verbessern. Ich bin nicht sicher, ob es sinnvoll ist, das global zu machen, daher erst mal als (standardmäßig ausgeschaltete) Option. Wenn diese aktiviert ist, wird targetValue bei Binary und Multilevel Switches immer mit currentValue überschrieben

Bis jetzt hat es mir eher geholfen weil die Werte die vorher (null) waren jetzt nach einen Neustart sauber sind.

Wie löst du das den mit den tragent / current Werten ?

[AlCalzone]

@EvilEls Ist tatsächlich was anderes als bei Harry

[Chris_78]

@Flopsi

Ich habe mir für alle Z-Wave Geräte jeweils ein Alias angelegt (Read-Value: currentValue / Write-Value: targetValue).

Nach ioBroker oder ZWave-Adapter Neustart habe ich ein Skript durchlaufen lassen, das mir die Alias-Werte einmal initial wieder
befüllt (targetValue -> currentValue).
Hat soweit gut funktioniert. Ich habe aktuell leider noch nicht getestet, ob die Werte jetzt initial gefüllt werden. Wenn ja könnte ich
mein Skript raus werfen.
Im Moment bin ich ganz gut beschäftigt Steuerungen mit dem D1-Mini zu realisieren
-> Bewegungsmelder
-> Lichtsteuerungen mit den W2812b LED-Strips

Ich bin echt fasziniert was mit den D1-Minis so alles geht...

[Flopsi]

@Chris_78

Bis jetzt habe ich keine Problme wurde alles initial gefüllt mit der neuen Funktion, aber ich werde das Langzeit testen so oft starte ich mein iobroker nicht.

[zanabria]

@AlCalzone
hi, kann leider keine aktuellere Werte liefern, da ich,

1. Den Adapter komplett gelöscht und neu installiert habe. Diese Neuinstallation bracht aber nichts für mein RAZBERRY2 Aufsteckmodul! Eine Verbindung zu Zwave2 kam nicht zu stande, also Zustandsampel auf gelb.
2. Erneut den Adapter komplett gelöscht und neu installiert. Ein 2. vorhandenes RAZBERRY2 Aufsteckmodul gestest! Eine Verbindung zu Zwave2 kam nicht zu stande, also Zustandsampel auf gelb.
3. Erneut den Adapter komplett gelöscht und neu installiert. Ein 3. vorhandenes ZMEEUZBB USB-Modul gestest! Eine Verbindung zu Zwave2 kam zu stande, also Zustandsampel auf grün. Die Ernüchterung kam aber schon beim einlernen des 1. Aktors. Eine anschließende Rollladenkalibrierung konnte ich machen, aber weitere Befehle wie up oder down, steuern über TargetValue ging nicht.
   Ich bin am verzweifeln. Hilft jetzt nur noch eine komplette Neuinstallation des Systems?

[arteck]

@zanabria ich weiss nicht warum du so ne installorgie veranstalltest.

sry aber .. DAS IST SCHWACHSINN

installiere den adapter .. mach das LOG AN <--- WICHTIG und zeigmal was da steht.. anstatt hier dein Amplsystem zu presentieren...

[AlCalzone]

@zanabria sagte in Test Adapter Z-Wave 2 (v1.7.x):

Eine Verbindung zu Zwave2 kam nicht zu stande, also Zustandsampel auf gelb.

Das heißt nur, dass noch nicht alle Interviews durchgelaufen sind. Schau bitte erstens in den ioBroker-Log ob dort Fehler vom Adapter auftauchen. Falls ja, hier posten.

Und zweitens poste mal einen erweiterten Log von einem Adapterstart der länger als 5 Sekunden geht. Bei deinen letzten Logs war noch nicht mal die Initialisierungsroutine des Sticks durchgelaufen. Ich würde mal (je nach Netzwerkgröße) 5 Minuten bis 1 Stunde anpeilen.

[Flopsi]

@zanabria
Hast du alles richtig eingestellt in dem Adapter ... Schnittstelle richtig ?

bei mir ist das diese:

Welchen Stick hast du ?

Weist du wie das geht mit dem LOG ?

3.

Speichern und Schließen
4.

5.

Filter an nur auf zwave2.0 jetzt schauen wann er deine Module alle eingelesen hat 15 min mal warten ich weis ja nicht wie viele Module du hast.

Log z.b. mit Filezilla herunterladen

Pfad:

/opt/iobroker/node_modules/iobroker.zwave2/build

Das LOG hier hochladen.

Ich hoffe ich habe keinen Schritt ausgelassen falls ja bitte was sagen @AlCalzone oder wer anders

[EvilEls]

@AlCalzone
Habe seit 1.7.3 Probleme mit den zuvor unauffälligen Nodes 2 und 3.
Für beide bekommt der Adapter kein Interview mehr zustande.
Das Log umfasst ca 10 Min. Die Interviews sind aber auch nach Stunden noch nicht da.
Auch erneutes Auslösen der Interviews bringt nichts.

zwave2.0	2020-10-04 21:56:00.137	info	(5310) Node 3 is alive
zwave2.0	2020-10-04 21:55:56.321	info	(5310) Node 3: interview restarted
zwave2.0	2020-10-04 21:55:54.108	info	(5310) Node 2 is alive
zwave2.0	2020-10-04 21:55:54.062	info	(5310) Node 2: interview restarted

Erreichbar und alive sind die Nodes. zwave2.0.Node_xxx.ready bleibt aber false
Netzwerk heilen fehlerfrei.
Irgendwann geht zwave2.0.Node_xxx.status dann auf unknown

Habe mit und ohne die neuen Optionen (Timeout +, Sendeversuche +) versucht. Selbes Ergebnis.

Bin Schrittweise die Versionen zurück gerollt, bis 1.6.3. Aber selbst da bekommen ich keine Interviews mehr für die Nodes.
Habe die Dimmer zurückgesetzt. Trotzdem kein Interview.

Bevor ich Kahlschlag mache, kannst du evtl. an den Logs was erkennen. ob es ein (behebbares) Software Problem ist?

Die Logs: 2020-10-04.zip

Besten Dank im Voraus!

[zanabria]

@AlCalzone, @Flopsi ,
habe das Problem gefunden.
Nachdem ich im Ausschlußverfahren und nicht im Schwachsinn, @arteck, die Hardware ausschließen konnte habe ich die Bootdateien geprüft. Da habe ich in der "cmdline.txt", am Ende der Datei eine Zusatzzeile gefunden, die vor dem Update von Node.js nicht drin war. Es war was mit "xxxPi3xxx". Zeile entfernt, neu gestartet und der Adapter war wieder lauffähig. Hat auch alle Aktoren erkannt und wieder richtig Interviewt.

[AlCalzone]

@EvilEls Hast du Node 2 und 3 sicher eingebunden? Irgendwas ist da komisch... Node 2 behauptet, er wäre ein Multilevel Power Switch:

21:30:42.991 CNTRLR « [Node 002] received response for protocol info:
                      basic device class:    Static Controller
                      generic device class:  Multilevel Switch
                      specific device class: Multilevel Power Switch
[...]

behauptet dann aber, er unterstützt nur die folgenden 3 CCs:

21:30:43.319 CNTRLR « [Node 002] node info received
                      supported CCs:
                      · Z-Wave Plus Info
                      · Device Reset Locally
                      · Powerlevel
                      controlled CCs:

Aufgrund der ersten Aussage wird zu diesen noch die "Pflicht"-CC Multilevel Switch ergänzt, auf deren Interview vom Node aber keine Antwort kommt.

---

Node 4 (ein ähnliches Gerät?) gibt zusätzlich noch Security CC als unterstützt an:

21:30:43.493 CNTRLR « [Node 004] node info received
                      supported CCs:
                      · Z-Wave Plus Info
                      · Device Reset Locally
                      · Powerlevel
                      · Security

und berichtet dort, dass Multilevel Switch CC verschlüsselt unterstützt ist:

21:30:44.615 DRIVER « [Node 004] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[SecurityCCCommandsSupportedReport]
                            reportsToFollow: 0
                            supportedCCs:
                            · Version
                            · Manufacturer Specific
                            · All Switch
                            · Binary Switch
                            · Multilevel Switch
                            · Meter
                            · Notification
                            · Association
                            · Multi Channel Association
                            · Association Group Information
                            · Configuration
                            controlledCCs:
                            · Multilevel Switch

[EvilEls]

hi @AlCalzone!
Danke für dein Feedback!

Ich habe an dem ganzen z-wave Setup rein gar nichts verändert. Lediglich auf die 1.7.3 ge-updated.
Node 2 und 3 (https://support.qubino.com/support/solutions/articles/44001757253-qubino-din-dimmer) liefen bis vor wenigen Tagen noch tadellos.

Node 4 (https://support.qubino.com/support/solutions/articles/44001757250-qubino-flush-dimmer) ist in der Tat ein ähnliches Gerät.

Bis vor Kurzem sah das noch so aus:

20:51:24.933 CNTRLR « [Node 002] received response for protocol info:
                      basic device class:    Static Controller
                      generic device class:  Multilevel Switch
                      specific device class: Multilevel Power Switch
                      is a listening device: true
                      is frequent listening: false
                      is a routing device:   true
                      is a secure device:    unknown
                      is a beaming device:   true
                      maximum baud rate:     40000 kbps
                      version:               4

20:51:25.295 CNTRLR « [Node 002] node info received
                      supported CCs:
                      · Z-Wave Plus Info
                      · Device Reset Locally
                      · Powerlevel
                      · Security
                      controlled CCs:

Irgend eine Idee, warum die beiden Nodes das auf einmal machen könnten?

[AlCalzone]

@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):

Irgend eine Idee, warum die beiden Nodes das auf einmal machen könnten?

Ne keinen Schimmer - aber anscheinend vergessen die auch gerne mal zu berichten, dass sie manche Dinge können... Eventuell lohnt es sich, mal beim Support nachzufragen.
Einen Workaround hätte ich - du solltest danach nur vermeiden, den Cache zu löschen, sonst gehts wieder von vorne los.

1. Adapter stoppen.
2. /opt/iobroker/iobroker-data/zwave2.0/cache/<deine-home-id>.json mit einem Editor öffnen

Die Datei enthält eine Struktur, die in etwa so aussieht:

{
    "nodes": {
        "1": {
            "id": 1,
            ...
        },
        "2": {
            "id": 2,
            ...
            "commandClasses": {
                ...
            }
        },
        "3": {
            "id": 3,
            ...
            "commandClasses": {
                ...
            }
        }
        ...
    }
}

3. Nach der Zeile mit commandClasses von Node 2 und 3 jeweils bitte folgendes einfügen:

                "0x98": {
                    "name": "Security",
                    "endpoints": {
                        "0": {
                            "isSupported": true,
                            "isControlled": false,
                            "secure": true,
                            "version": 1
                        }
                    }
                },

4. Datei speichern, Adapter wieder starten.

[AlCalzone]

v1.7.4 ist da, mit einigen Stabilitätsverbesserungen. Unter anderem sollte sie den berühmten E5-Fehler beheben, der sich in 1.7.0 wieder eingeschlichen hat. Danke fürs Testen @arteck

[EvilEls]

@AlCalzone Nur die Security anzuhängen hat nichts bewirkt.
Mit einem Backup der drei Cache Dateien sind die Nodes wieder alive und ready.
Sie lassen sich aber nicht steuern aus dem iobroker. Weder Multilevel- noch Binary-Switch.
Configuration lässt sich übertragen.
Habe den Support befragt.

Das es Probleme mit den Dimmern gibt, scheint aber nicht ganz neu:
https://community.openhab.org/t/status-updates-for-qubino-relays-dimmers-generally-do-not-work/32527/280

[AlCalzone]

@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):

Sie lassen sich aber nicht steuern aus dem iobroker. Weder Multilevel- noch Binary-Switch.
Configuration lässt sich übertragen.

Kannste mir davon mal ein Log machen bitte? Und die Cache-Dateien vor dem Backup würde ich auch gerne sehen.

[EvilEls]

@AlCalzone
hier das Log mit den Cache Dateien aus dem Backup: Nodes_aus_Cache.zip

Node 3 steuern über Multi- oder Binary Switch geht nicht.
Config übertragen (zwave2.0.Node_003.Configuration.maximumDimmingValue) scheint zu funktionieren. Wenn auch langsam. Wert steht ein paar Sekunden auf rot bevor Ack kommt.

Hier Log mit gelöschtem Cache: Cache_geloescht.zip
Dimmer nicht steuerbar und auch keine Config übertragbar.

Der Support sagt:

The secure modes in the z-wave are S0, S2 Authenticated and S2 unauthenticated. There was probably a gateway update that cause this as our devices are not updatable remotely.​

Gibt es eine Möglichkeit mit zwave-js < 5.2. zu testen?

[AlCalzone]

@EvilEls Ich glaube nicht, dass irgend eine andere Adapter-Version daran was ändert - die machen die gleichen Abfragen.
Mit den Cache-Dateien aus dem Backup wird zwar versucht, die Security CC zu interviewen, aber selbst darauf antwortet Node 3 nicht mehr. Ich würde den Support mal fragen, wie es sein kann, dass der Node überhaupt keine Security mehr unterstützt (und sonst auch nix).

Falls sie sich selbst vergewissern wollen, das ist was der Node behauptet zu können:

14 bytes:
01 - Start of Frame
0c - 12 bytes follow
00 - type: Request
49 - function type: ApplicationUpdateRequest
84 - update type: NodeInfo_Received
03 - node ID 3
06 - 6 bytes follow
04 - basic device class: Static Controller
11 - generic device class: Multilevel Switch
01 - specific device class: Multilevel Power Switch
5e - CC supported: "Z-Wave Plus Info"
5a - CC supported: "Device Reset Locally"
73 - CC supported: "Powerlevel"
58 - checksum

während es für Node 4 wie folgt aussieht:

15 bytes:
01 - Start of Frame
0d - 13 bytes follow (!)
00 - type: Request
49 - function type: ApplicationUpdateRequest
84 - update type: NodeInfo_Received
04 - node ID 4
07 - 7 bytes follow (!)
04 - basic device class: Static Controller
11 - generic device class: Multilevel Switch
01 - specific device class: Multilevel Power Switch
5e - CC supported: "Z-Wave Plus Info"
5a - CC supported: "Device Reset Locally"
73 - CC supported: "Powerlevel"
98 - CC supported: "Security S0" (!)
c7 - checksum

Es ist also eindeutig, dass Node 3 "vergessen" hat, dass er Security kann. Die Support-Aussage erscheint mir etwas abwimmelnd.

Falls du auf dieser Front nicht weiter kommst, bleibt dir wie ich fürchte nur noch eine Lösung:

1. Gerät ablernen
2. Gerät auf Auslieferungszustand zurücksetzen
3. Gerät wieder anlernen