NEWS
Test Adapter Z-Wave 2 (v1.7.x)
-
@zanabria sagte in Test Adapter Z-Wave 2 (v1.7.x):
so, hoffe nun alles zu haben.
Deine Logs sind alle nur ca. 3-5 Sekunden lang. Hast du keins, was ein bisschen länger gelaufen ist?
-
v1.7.3 ist auf dem Weg und fixt zwei Crashes in
Notification CC
@Harry94 -
@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. -
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.....
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 überschriebenBis 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 ?
-
@EvilEls Ist tatsächlich was anderes als bei Harry
-
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-StripsIch bin echt fasziniert was mit den D1-Minis so alles geht...
-
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.
-
@AlCalzone
hi, kann leider keine aktuellere Werte liefern, da ich,- 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.
- 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.
- 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?
-
@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...
-
@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.
-
@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
-
@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 aberfalse
Netzwerk heilen
fehlerfrei.
Irgendwann gehtzwave2.0.Node_xxx.status
dann aufunknown
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!
-
@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. -
@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
-
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?
-
@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.- Adapter stoppen.
/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": { ... } } ... } }
- 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 } } },
- Datei speichern, Adapter wieder starten.
-
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 -
@AlCalzone Nur die Security anzuhängen hat nichts bewirkt.
Mit einem Backup der drei Cache Dateien sind die Nodes wiederalive
undready
.
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 -
@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.
-
@AlCalzone
hier das Log mit den Cache Dateien aus dem Backup: Nodes_aus_Cache.zipNode 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?