NEWS
Test Adapter Z-Wave 2 (v1.8.x)
Test Adapter Z-Wave 2 (v1.8.x)
-
@Chris_78 sagte in Test Adapter Z-Wave 2 (v1.8.x):
Klappt soweit gut. Du bräuchtest doch nur einen Alias anlegen, der die Int-Werte durchreicht (oder habe ich dich falsch verstanden?
Was meinst du mit "Int-Werte"?
Das ist eigentlich nur eine "Kurzschreibweise" eines if-then-else Statements.
"read": "val == '0' ? false : true" -> Falls val==0 setze false ansonsten setze true
"write": "val == true ? 99 : 0" -> Falls value==true setze 99 ansonsten setze 0So kannst du einen True/False-Schalter nutzen um z.B. fixe Dimmer-Werte zu setzen -> false = 0 / true = 99
Achso, verstanden!

@Troya said in Test Adapter Z-Wave 2 (v1.8.x):
@Chris_78 sagte in Test Adapter Z-Wave 2 (v1.8.x):
Klappt soweit gut. Du bräuchtest doch nur einen Alias anlegen, der die Int-Werte durchreicht (oder habe ich dich falsch verstanden?
Was meinst du mit "Int-Werte"?
Sorry, komme ursprünglich aus der Java Welt...
Int = Integer = Zahl
Hier wäre Number die richtige Wahl gewesen
Das ist eigentlich nur eine "Kurzschreibweise" eines if-then-else Statements.
"read": "val == '0' ? false : true" -> Falls val==0 setze false ansonsten setze true
"write": "val == true ? 99 : 0" -> Falls value==true setze 99 ansonsten setze 0So kannst du einen True/False-Schalter nutzen um z.B. fixe Dimmer-Werte zu setzen -> false = 0 / true = 99
Achso, verstanden!

-
Da mein WAF stetig niedriger wird mit den teilweise nicht funktionierenden Nodes: Ich würde dann die problematischen Nodes mit dem alten Zwave-Adapter schalten und den Rest mit dem neuen Zwave2.
Kann ich beide Adapter parallel laufen lassen oder kommen die sich in die Quere?@Troya said in Test Adapter Z-Wave 2 (v1.8.x):
Da mein WAF stetig niedriger wird mit den teilweise nicht funktionierenden Nodes: Ich würde dann die problematischen Nodes mit dem alten Zwave-Adapter schalten und den Rest mit dem neuen Zwave2.
Kann ich beide Adapter parallel laufen lassen oder kommen die sich in die Quere?Das klappt vermutlich nicht, da immer nur ein Adapter auf den Port/ZWave-Stick zugreifen kann.
-
Da mein WAF stetig niedriger wird mit den teilweise nicht funktionierenden Nodes: Ich würde dann die problematischen Nodes mit dem alten Zwave-Adapter schalten und den Rest mit dem neuen Zwave2.
Kann ich beide Adapter parallel laufen lassen oder kommen die sich in die Quere? -
@Troya sagte in Test Adapter Z-Wave 2 (v1.8.x):
teilweise nicht funktionierenden Nodes
Was meinst du?
@AlCalzone
Ist in meinem Alias-target-current-Wirrwarr evtl untergegangen.
Mein erster Beitrag(102), da hab ich im Beitrag danach auch Logs für dich erstellt(107): -
@AlCalzone
Ist in meinem Alias-target-current-Wirrwarr evtl untergegangen.
Mein erster Beitrag(102), da hab ich im Beitrag danach auch Logs für dich erstellt(107):@Troya
Zum Fenstersensor:
accessControl_doorState und der Binary Sensor müssten funktionieren. Wenn die fehlen, stimmt was mit der Konfiguration oder den Verknüpfungen des Geräts nicht. Hier lohnt ein Blick in die Anleitung.
ALARM.Access_Control_1 ist die alte Version der Notification CC. Der müsste accessControl_doorState entsprechen.
Im Zweifel mach mal ein Log, wo du die betätigst.ASUS CFA3010
Hast du den vorm Einbinden auf Security S0 umgestellt? Steht in der Anleitung wie das geht. Security S2 kann der Adapter noch nicht. Es gibt definitiv Leute, die dieses Gerät mit zwave2 schon im Einsatz haben.
nur zwave2.0.Node_003.Binary_Switch.targetValue ohne die 1/2.*
Interviewe das Gerät mal neu (unter Adaptereinstellungen -> Geräte -> Knopf [...])
-
@Troya
Zum Fenstersensor:
accessControl_doorState und der Binary Sensor müssten funktionieren. Wenn die fehlen, stimmt was mit der Konfiguration oder den Verknüpfungen des Geräts nicht. Hier lohnt ein Blick in die Anleitung.
ALARM.Access_Control_1 ist die alte Version der Notification CC. Der müsste accessControl_doorState entsprechen.
Im Zweifel mach mal ein Log, wo du die betätigst.ASUS CFA3010
Hast du den vorm Einbinden auf Security S0 umgestellt? Steht in der Anleitung wie das geht. Security S2 kann der Adapter noch nicht. Es gibt definitiv Leute, die dieses Gerät mit zwave2 schon im Einsatz haben.
nur zwave2.0.Node_003.Binary_Switch.targetValue ohne die 1/2.*
Interviewe das Gerät mal neu (unter Adaptereinstellungen -> Geräte -> Knopf [...])
@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.8.x):
Hast du den vorm Einbinden auf Security S0 umgestellt? Steht in der Anleitung wie das geht. Security S2 kann der Adapter noch nicht. Es gibt definitiv Leute, die dieses Gerät mit zwave2 schon im Einsatz haben.
Fange mal mit dem Schloss an. Habe es exkludiert, auf S0 umgestellt und erneut im sicheren Modus inkludiert.
Sieht eigentlich ganz gut aus:
Jedoch kommen keine Werte rein...Weder wenn ich irgendwo was eintrage noch wenn ich per hand das Schloss öffne und schließe.
zwave2.0.Node_082.status=alive, was gut klingt, jedoch
jedoch zwave2.0.Node_082.ready=false nicht so gut. -
@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.8.x):
Hast du den vorm Einbinden auf Security S0 umgestellt? Steht in der Anleitung wie das geht. Security S2 kann der Adapter noch nicht. Es gibt definitiv Leute, die dieses Gerät mit zwave2 schon im Einsatz haben.
Fange mal mit dem Schloss an. Habe es exkludiert, auf S0 umgestellt und erneut im sicheren Modus inkludiert.
Sieht eigentlich ganz gut aus:
Jedoch kommen keine Werte rein...Weder wenn ich irgendwo was eintrage noch wenn ich per hand das Schloss öffne und schließe.
zwave2.0.Node_082.status=alive, was gut klingt, jedoch
jedoch zwave2.0.Node_082.ready=false nicht so gut. -
@Troya sagte in Test Adapter Z-Wave 2 (v1.8.x):
zwave2.0.Node_082.ready=false
Dann ist das Interview noch nicht durch. Haste mal ein Log?
@AlCalzone
Bitte sehr, einmal Log mit Pommes kommt sofort ...
zwave-1001.logInterview vom Schloss (Node 082) beginnt 20:08 Uhr.
^^^^^^^^^^^^^^^^^^
Außerdem in dem Log findest du den Node 003, der ist der besagte Fibaro welcher nicht schalten möchte. Ich habe den aber während des Logings nicht neu interviewed. Wusste nicht wie der Log zwei Interviews verkraftet bzw. dich beim auswerten stört. Aber vielleicht siehst du ja trotzdem wo das Problem liegt.Im normalen ioBroker Log findet sich folgender Fehler wenn er schalten soll:
zwave2.0 2020-12-23 21:29:13.233 error (1001) Timed out while waiting for a response from the nodeHier noch ein Screenshot vom Objektbaum des Node003:

Um die Fenstersensor kümmern wir uns später, die sind nicht so dringend.
-
@AlCalzone
Bitte sehr, einmal Log mit Pommes kommt sofort ...
zwave-1001.logInterview vom Schloss (Node 082) beginnt 20:08 Uhr.
^^^^^^^^^^^^^^^^^^
Außerdem in dem Log findest du den Node 003, der ist der besagte Fibaro welcher nicht schalten möchte. Ich habe den aber während des Logings nicht neu interviewed. Wusste nicht wie der Log zwei Interviews verkraftet bzw. dich beim auswerten stört. Aber vielleicht siehst du ja trotzdem wo das Problem liegt.Im normalen ioBroker Log findet sich folgender Fehler wenn er schalten soll:
zwave2.0 2020-12-23 21:29:13.233 error (1001) Timed out while waiting for a response from the nodeHier noch ein Screenshot vom Objektbaum des Node003:

Um die Fenstersensor kümmern wir uns später, die sind nicht so dringend.
@Troya Das Schloss macht ganz komisches Zeug...
Erst antwortet es über 5 Sekunden gar nicht, dann spammt es immer wieder den selben temporären Schlüssel statt auf unsere Anfragen zu antworten:21:08:51.165 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.165 SERIAL » [ACK] (0x06) 21:08:51.166 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.195 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.196 SERIAL » [ACK] (0x06) 21:08:51.196 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.229 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.230 SERIAL » [ACK] (0x06) 21:08:51.231 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.290 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.291 SERIAL » [ACK] (0x06) 21:08:51.292 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.368 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.368 SERIAL » [ACK] (0x06) 21:08:51.369 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.385 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.385 SERIAL » [ACK] (0x06) 21:08:51.386 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.484 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.485 SERIAL » [ACK] (0x06) 21:08:51.486 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.496 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.497 SERIAL » [ACK] (0x06) 21:08:51.498 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:52.041 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:52.043 SERIAL » [ACK] (0x06) 21:08:52.043 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:52.099 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:52.100 SERIAL » [ACK] (0x06) 21:08:52.100 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:52.255 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:52.255 SERIAL » [ACK] (0x06) 21:08:52.256 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1dDer Check ist in dem Fall etwas unglücklich, aber da das Schloss auf eine spezielle Anfrage nicht richtig antwortet, vermutet der Treiber dann dass es unverschlüsselt ist.
Folgendes kannst du mal versuchen:
Lerne das Schloss nochmal ab, setze es komplett zurück, stelle nochmal auf S0 falls nötig und lerne es dann wieder an.
Vielleicht findet sich hier aber noch jemand, der das Teil im Einsatz hat - 2-3 Leute hab ich damit schon hier schreiben gesehen.Ich bin die nächsten Tage bei der Familie, hab also nicht ständig Zeit zu antworten.
-
@Troya Das Schloss macht ganz komisches Zeug...
Erst antwortet es über 5 Sekunden gar nicht, dann spammt es immer wieder den selben temporären Schlüssel statt auf unsere Anfragen zu antworten:21:08:51.165 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.165 SERIAL » [ACK] (0x06) 21:08:51.166 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.195 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.196 SERIAL » [ACK] (0x06) 21:08:51.196 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.229 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.230 SERIAL » [ACK] (0x06) 21:08:51.231 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.290 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.291 SERIAL » [ACK] (0x06) 21:08:51.292 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.368 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.368 SERIAL » [ACK] (0x06) 21:08:51.369 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.385 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.385 SERIAL » [ACK] (0x06) 21:08:51.386 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.484 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.485 SERIAL » [ACK] (0x06) 21:08:51.486 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:51.496 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:51.497 SERIAL » [ACK] (0x06) 21:08:51.498 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:52.041 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:52.043 SERIAL » [ACK] (0x06) 21:08:52.043 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:52.099 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:52.100 SERIAL » [ACK] (0x06) 21:08:52.100 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1d 21:08:52.255 SERIAL « 0x0110000410520a9880c6b0a377310c4f1d76 (18 bytes) 21:08:52.255 SERIAL » [ACK] (0x06) 21:08:52.256 DRIVER « [Node 082] [REQ] [ApplicationCommand] └─[SecurityCCNonceReport] nonce: 0xc6b0a377310c4f1dDer Check ist in dem Fall etwas unglücklich, aber da das Schloss auf eine spezielle Anfrage nicht richtig antwortet, vermutet der Treiber dann dass es unverschlüsselt ist.
Folgendes kannst du mal versuchen:
Lerne das Schloss nochmal ab, setze es komplett zurück, stelle nochmal auf S0 falls nötig und lerne es dann wieder an.
Vielleicht findet sich hier aber noch jemand, der das Teil im Einsatz hat - 2-3 Leute hab ich damit schon hier schreiben gesehen.Ich bin die nächsten Tage bei der Familie, hab also nicht ständig Zeit zu antworten.
@AlCalzone
Danke, probiere ich sofort.
kann das vielleicht mit diesem Netzwerkschlüssel für sichere Kommunikation
zusammenhängen? Der war anfangs leer bis ich auf den Neu-Generieren Button gedrückt hab. Hatte damals die Vermutung dass das Schloss da vielleicht einen Wert drin benötigt um kommunizieren zu können:man-shrugging: -
Aktuelle Test Version 1.8.12 Veröffentlichungsdatum 23.02.2021 Github Link https://github.com/AlCalzone/ioBroker.zwave2 Ich habe in letzter Zeit viel hinter den Kulissen gewerkelt, in der nächsten Stunde folgt die neue Version 1.8.0 als Ergebnis dieser Bemühungen.
Changelog
- Konfigurationsdateien für Fibaro Keyfob (keine Sonderzeichen mehr) und Shenzhen Neo PD03Z verbessert
- Nicht-kritische Schritte während des Interviews von
Central Scene CC,Configuration CC V3+undAssociation Group Info CCwerden jetzt übersprungen, wenn das Gerät nicht oder falsch antwortet - Multi Channel Lifeline Associations werden nicht mehr automatisch erstellt, wenn das Gerät die
Multi Channel CCnicht unterstützt - dies sollte die Kompatibilität mit den meisten Qubino-Geräten beheben - Es wurde ein Problem behoben, bei dem das automatische Markieren von Geräten als schlafend unter bestimmten Umständen die serielle Kommunikation mit dem Controller durcheinander gebracht hat.
- Die Eigenschaft
targetValuefür dieBinary Switch,Multilevel SwitchundBasicCCs wird jetzt auch dann erzeugt, wenn sie keinen Wert hat. - Leere Benutzercodes werden jetzt auch als Zeichenketten statt als Buffer behandelt.
- Werte für Notification Events (einmalige Ereignisse) werden jetzt erstellt. Zuvor waren nur Notification-Variablen als States in ioBroker verfügbar
Zusammengefasst:
@gelberlemmy - Die letzten beiden Punkte sollten hoffentlich (ich kanns leider nicht testen) dein Keypad nutzbar machen
@Domoe - Dein Problem mit Node 035 sollte hiermit hoffentlich auch weg sein
Update v1.8.1 (ein Riesen-Patch):
- Der
targetValuevon Switch CCs wird nicht mehr gelöscht, wenn ein Report ohne Zielwert empfangen wird - Konfigurationsdatei für
Jasco ZW3010hinzugefügt - Konfigurationsdatei für
HeatIt Z-TRM3hinzugefügt - Konfigurationsdatei für
Eurotronic Air quality sensor (Luftgütesensor)hinzugefügt - Verbesserte Unterstützung für
Qubino Flush 2 Relay - Die Werte für
Multi Channel Association CC,Z-Wave+ CCundNode Naming and Location CCsind jetzt ausgeblendet Color Switch CC:Setzen des warmweißentargetValuefunktioniert jetzt- Debug-Meldungen, die die Größe der Logdatei unnötig erhöht haben, wurden entfernt
- Das Entfernen einer Node-Verknüpfung (ohne Endpunkt) führt nicht mehr zu einem Fehler, wenn sowohl Multi-Channel- als auch normale Verknüpfungen unterstützt werden.
- Bestimmte
Notification CC Reports werden jetzt korrekt dekodiert. - Unterstützung für
*.gbl-Firmware-Dateien und Aeotec-Updater-Executables, die eine Prüfsumme und ein TargetChip-Byte enthalten, wurde hinzugefügt. - Ein Problem wurde behoben, bei dem unter bestimmten Umständen einem Befehl die falsche Antwort zugeordnet werden konnte
- ... und einige weitere kleinere Bugfixes
Update v1.8.3:
- Konfigurations datei für Technisat Dimmer and series switch hinzugefügt
- Zustand für leere Batterie hat jetzt den Namen
Battery Level Low - Ein Fehler beim Abfragen von
Binary Sensorbehoben, durch den die falschen Sensortypen abgefragt wurden. Betroffene Geräte müssen ggf. neu interviewt werden. - Die Strategie zum erneuten Senden von Nachrichten wurde überarbeitet. Sobald ein Gerät den Empfang bestätigt, wird nun nicht mehr erneut gesendet und stattdessen bis zu 10s (statt 1,6s) auf die Antwort gewartet.
- Werte, die Ereignis-Charakter haben (wie
Central Scenes) werden nun automatisch nach 1 Sekunde geleert.
Update v1.8.5:
- Ein Crash und eine Ursache für Interview-Abbrüche wurde behoben
- Logfiles werden wieder erstellt
- Diverse Gerätekonfigurationen aktualisiert
Update v1.8.6:
Ne ganze Menge an Bugfixes und neuen Konfigurationsdateien. Details siehe https://github.com/zwave-js/node-zwave-js/blob/master/CHANGELOG.md#changelog
Update v1.8.7:
- Die Szenen-ID der
Scene Activation CCwird nun automatisch zurückgesetzt - Einen Fehler behoben, der bei der Konfiguration von Verknüpfungen auftreten konnte
- Zwei potentielle Absturzquellen behoben
- Die Werte des Root-Endpunkts einiger älterer Geräte werden nun korrekt aktualisiert
- Unterstützung für
Aeotec aerQ ZWA009-AUS/Kanada/Mexiko-Version hinzugefügt - Ungültige Optionswerte in vielen Konfigurationsdateien korrigiert
Update v1.8.9:
- Beschriftungen für die Meter CC wurden verbessert und sind nun eindeutig.
- Viele Konfigurationsdateien wurden hinzugefügt und aktualisiert
- Verbesserte Kompatibilität mit einigen Geräten, vor allem
ID Lock 150,Vision Security ZD2102-5,HomeSeer WD200+ currentValueund ähnliche Werte werden jetzt sofort aktualisiert, wenn ein set-type-Befehl erfolgreich ist. Die Verifizierung der Änderung erfolgt nach einer kurzen Verzögerung.
Update v1.8.10:
- Der Start sollte nun schneller sein, insbesondere wenn viele schlafende Geräte im Netzwerk vorhanden sind
- Ein Problem wurde behoben, bei dem Geräte fälschlicherweise als sicher angezeigt wurden. @gelberlemmy
- Verbesserte Unterstützung für Geräte, die diealte
Alarm CCverwenden - Verschiedene Verbesserungen für Zooz- und GE-Geräte
Update v1.8.11:
Thermostat Fan Mode CCundThermostat Fan State CCimplementiert- Mehrere Absturzursachen behoben
- Fehlerhafte Erkennung von sicher eingebundenen Nodes behoben
- Bestimmte
.hex-Firmwaredateien werden jetzt korrekt geparst - Unterstützung für
.bin-Firmwaredateien hinzugefügt - Eine Interviewschleife wurde behoben, wenn Geräte das Ende der Config-Parameterliste nicht korrekt anzeigen
- Schlafende Nodes werden nun sofort als bereit markiert, wenn sie bereits vollständig interviewed wurden
- Selbstständige Nachrichten werden nicht mehr vom Root-Endpunkt auf Endpunkt 1 abgebildet, wenn dieser Endpunkt die betreffende CC nicht unterstützt
- Tonnenweise neue und verbesserte Gerätekonfigurationsdateien
Update v1.8.12:
- Implementierung von "Scene Actuator Configuration CC" und "Scene Controller Configuration CC".
- Behebung eines Problems, bei dem schlafende Knoten die Sendewarteschlange blockieren konnten, wenn noch nicht bekannt ist, ob sie
Wake Up CCunterstützen - Absturz behoben, der beim Loggen einer Nachricht auftreten konnte, während der Treiber noch nicht bereit ist
- Es wurde ein Absturz behoben, der beim Versuch auftreten konnte, ein Gerät zu initialisieren, das nach der Inklusion nicht antwortet
- Der Zustand
stateinThermostat Fan Mode CCist jetzt schreibgeschützt - Konfigurationsparameter können jetzt eine Einheit haben
- Tonnenweise neue und verbesserte Gerätekonfigurationsdateien
- Selbstständige Reports werden nicht mehr fälschlicherweise allen Endpunkten zugeordnet
@AlCalzone ich wünsche fröhliche Weihnachten. Sag einmal ich habe immer noch das Problem, dass sich meine letzten beiden Notes laut Netzwerkkarte nicht mit benachbarten Notes verbinden. Es sind Note 071 und Note 072. Note 071 ist eine Fernbedienung (funktioniert) und Note 072 ein Fibro RBGW Modul (funktioniert auch) Wie schon einmal besprochen, habe ich das Note 072 mehrfach neu interviewt. Aber dieser wird in der Karte nicht anders dargestellt. Netzwerk heilen umgehe ich einmal, denn es funktioniert ja alles tadellos. Es wunder mich halt nur..... Falls Du einmal Zeit und Lust hast, könntest Du ja noch einmal schauen.
Log schicke ich dir via Mail.Euch allen noch ein besinnliche Weihnachtszeit.
Gruß André
-
Hallo zusammen!
Eine kurze Frage: Kann man die NodeId-Lücken eigentlich schießen? Ich hab ein altes Gerät ordentlich über den Button "- Gerät entfernen" abgemeldet und ein baugleiches Neues hinzugefügt und nun funktioniert meine Script nicht mehr, welches die Temperatur einiger Thermostate mittels Schleife einen neuen Wert zuweist.
Vielen Dank und viele GrüßeEDIT: Ich hab nun den Adapter Hard resettet und alle Thermostate neu eingebunden und alles funktioniert wieder normal. Trotzdem die Frage: Ginge das auch einfacher?
Und dann würde ich gerne noch eine Frage hinterherschicken: Kann es sein, dass die Devolo Z-Wave Heizungsthermostate nicht untereinander kommunizieren? Ich hab am entferntesten Punkt immer wieder Probleme, obwohl im regelmäßigen Abstand weitere Heizungen sind. Und in der Netzwerkkarte sehe ich nur eine Verbindung zwischen meinem Fibaro Rauchmelder und einem Fibaro Switch 2 (Node 9 und 10).

-
@AlCalzone
Danke, probiere ich sofort.
kann das vielleicht mit diesem Netzwerkschlüssel für sichere Kommunikation
zusammenhängen? Der war anfangs leer bis ich auf den Neu-Generieren Button gedrückt hab. Hatte damals die Vermutung dass das Schloss da vielleicht einen Wert drin benötigt um kommunizieren zu können:man-shrugging:@Troya sagte in Test Adapter Z-Wave 2 (v1.8.x):
Der war anfangs leer bis ich auf den Neu-Generieren Button gedrückt hab. Hatte damals die Vermutung dass das Schloss da vielleicht einen Wert drin benötigt um kommunizieren zu können
Ja, für verschlüsselte Kommunikation brauchst du den

@gelberlemmy schau ich mir morgen mal an.
@moritzabcde sagte in Test Adapter Z-Wave 2 (v1.8.x):
Ginge das auch einfacher?
Nein, die Lücken werden erst wieder gefüllt, wenn du die 232 möglichen Node-IDs durch hast.
@moritzabcde sagte in Test Adapter Z-Wave 2 (v1.8.x):
Kann es sein, dass die Devolo Z-Wave Heizungsthermostate nicht untereinander kommunizieren?
Ja, das Mesh wird nur durch netzbetriebene Geräte aufgebaut. Batteriebetrieben verbringen die meiste Zeit schlafend, sodass sie da nicht beitragen können.
-
@Troya sagte in Test Adapter Z-Wave 2 (v1.8.x):
Der war anfangs leer bis ich auf den Neu-Generieren Button gedrückt hab. Hatte damals die Vermutung dass das Schloss da vielleicht einen Wert drin benötigt um kommunizieren zu können
Ja, für verschlüsselte Kommunikation brauchst du den

@gelberlemmy schau ich mir morgen mal an.
@moritzabcde sagte in Test Adapter Z-Wave 2 (v1.8.x):
Ginge das auch einfacher?
Nein, die Lücken werden erst wieder gefüllt, wenn du die 232 möglichen Node-IDs durch hast.
@moritzabcde sagte in Test Adapter Z-Wave 2 (v1.8.x):
Kann es sein, dass die Devolo Z-Wave Heizungsthermostate nicht untereinander kommunizieren?
Ja, das Mesh wird nur durch netzbetriebene Geräte aufgebaut. Batteriebetrieben verbringen die meiste Zeit schlafend, sodass sie da nicht beitragen können.
Ich habe meine Z-Wave Stick an einen anderen USB Port hängen müssen. Seitdem bleibt der Adapter gelb. Den Port habe ich geändert. Bei allen anderen Ports erhalte ich im Log eine Fehlermeldung, ich hoffe daher es ist der richtige Port. Hier der Auszug aus dem Log:
zwave2.0 2020-12-28 02:32:17.983 silly (11242) States user redis pmessage zwave2.0.*/zwave2.0.info.healingNetwork:{"val":false,"ack":true,"ts":1609119137962,"q":0,"from":"system.adapter.zwave2.0","user":"system.user.admin","lc":15815246377 zwave2.0 2020-12-28 02:32:17.982 silly (11242) States user redis pmessage zwave2.0.*/zwave2.0.info.exclusion:{"val":false,"ack":true,"ts":1609119137962,"q":0,"from":"system.adapter.zwave2.0","user":"system.user.admin","lc":1581013646426} zwave2.0 2020-12-28 02:32:17.977 silly (11242) States user redis pmessage zwave2.0.*/zwave2.0.info.inclusion:{"val":0,"ack":true,"ts":1609119137961,"q":0,"from":"system.adapter.zwave2.0","user":"system.user.admin","lc":1591774453893} zwave2.0 2020-12-28 02:32:17.974 silly (11242) States user redis pmessage zwave2.0.*/zwave2.0.info.connection:{"val":false,"ack":true,"ts":1609119137961,"q":0,"from":"system.adapter.zwave2.0","user":"system.user.admin","lc":1609112855846} zwave2.0 2020-12-28 02:32:17.955 silly (11242) States system redis pmessage system.adapter.zwave2.0.logLevel/system.adapter.zwave2.0.logLevel:{"val":"silly","ack":true,"ts":1609119137842,"q":0,"from":"system.adapter.zwave2.0","lc":16091191 zwave2.0 2020-12-28 02:32:17.800 info (11242) starting. Version 1.8.0 in /opt/iobroker/node_modules/iobroker.zwave2, node: v14.15.3, js-controller: 3.1.6 host.raspberrypi 2020-12-28 02:32:14.375 info instance system.adapter.zwave2.0 started with pid 11242 host.raspberrypi 2020-12-28 02:32:11.773 info instance system.adapter.zwave2.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) zwave2.0 2020-12-28 02:32:11.193 info (10999) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason zwave2.0 2020-12-28 02:32:11.191 info (10999) terminating zwave2.0 2020-12-28 02:32:11.190 info (10999) Shutting down driver... zwave2.0 2020-12-28 02:32:11.186 info (10999) Got terminate signal TERMINATE_YOURSELF host.raspberrypi 2020-12-28 02:32:11.177 info stopInstance system.adapter.zwave2.0 send kill signal host.raspberrypi 2020-12-28 02:32:11.152 info stopInstance system.adapter.zwave2.0 (force=false, process=true)``` Kann mir hier jemand helfen? -
@Troya sagte in Test Adapter Z-Wave 2 (v1.8.x):
Der war anfangs leer bis ich auf den Neu-Generieren Button gedrückt hab. Hatte damals die Vermutung dass das Schloss da vielleicht einen Wert drin benötigt um kommunizieren zu können
Ja, für verschlüsselte Kommunikation brauchst du den

@gelberlemmy schau ich mir morgen mal an.
@moritzabcde sagte in Test Adapter Z-Wave 2 (v1.8.x):
Ginge das auch einfacher?
Nein, die Lücken werden erst wieder gefüllt, wenn du die 232 möglichen Node-IDs durch hast.
@moritzabcde sagte in Test Adapter Z-Wave 2 (v1.8.x):
Kann es sein, dass die Devolo Z-Wave Heizungsthermostate nicht untereinander kommunizieren?
Ja, das Mesh wird nur durch netzbetriebene Geräte aufgebaut. Batteriebetrieben verbringen die meiste Zeit schlafend, sodass sie da nicht beitragen können.
@AlCalzone said in Test Adapter Z-Wave 2 (v1.8.x):
Ja, das Mesh wird nur durch netzbetriebene Geräte aufgebaut. Batteriebetrieben verbringen die meiste Zeit schlafend, sodass sie da nicht beitragen können.
Vielen Dank für die Infos!
Eine letzte Frage noch: Würde ein weiteres netzbetriebenes Gerät (bei korrekter Positionierung) die Reichweite erweitern, so dass der entfernte Thermostat zuverlässiger angesprochen werden kann? -
@AlCalzone said in Test Adapter Z-Wave 2 (v1.8.x):
Ja, das Mesh wird nur durch netzbetriebene Geräte aufgebaut. Batteriebetrieben verbringen die meiste Zeit schlafend, sodass sie da nicht beitragen können.
Vielen Dank für die Infos!
Eine letzte Frage noch: Würde ein weiteres netzbetriebenes Gerät (bei korrekter Positionierung) die Reichweite erweitern, so dass der entfernte Thermostat zuverlässiger angesprochen werden kann? -
@moritzabcde Wäre zumindest sehr wahrscheinlich
@Markus84 ich sehe keinen Fehler

@AlCalzone said in Test Adapter Z-Wave 2 (v1.8.x):
ich sehe keinen Fehler
Ich habe jetzt noch einen Fehler im Log gefunden:
host.raspberrypi 2020-12-28 14:15:34.923 warn instance system.adapter.zwave2.0 terminated due to SIGABRTKannst du hier vielleicht etwas draus ableiten?
-
@AlCalzone said in Test Adapter Z-Wave 2 (v1.8.x):
ich sehe keinen Fehler
Ich habe jetzt noch einen Fehler im Log gefunden:
host.raspberrypi 2020-12-28 14:15:34.923 warn instance system.adapter.zwave2.0 terminated due to SIGABRTKannst du hier vielleicht etwas draus ableiten?
@Markus84 sagte in Test Adapter Z-Wave 2 (v1.8.x):
terminated due to SIGABRT
SIGABRT sind kritische Fehler in low-level-Bibliotheken. Könnte vom System stammen oder aus der Serialport-Library, das kann ich leider nicht erkennen und auch nicht abfangen

-
@Markus84 sagte in Test Adapter Z-Wave 2 (v1.8.x):
terminated due to SIGABRT
SIGABRT sind kritische Fehler in low-level-Bibliotheken. Könnte vom System stammen oder aus der Serialport-Library, das kann ich leider nicht erkennen und auch nicht abfangen

@AlCalzone Okay, danke für die Antwort. Ich hab jetzt alles mögliche ausprobiert und bekomme jetzt diese Fehlermeldung nach einer Neuinstallation des Adapters:
zwave2.0 2020-12-28 16:55:29.302 error (30129) The Z-Wave driver could not be started: Error: Device or resource busy, cannot open /dev/ttyACM0Hast du hier zufällig eine Idee?
-
@AlCalzone Okay, danke für die Antwort. Ich hab jetzt alles mögliche ausprobiert und bekomme jetzt diese Fehlermeldung nach einer Neuinstallation des Adapters:
zwave2.0 2020-12-28 16:55:29.302 error (30129) The Z-Wave driver could not be started: Error: Device or resource busy, cannot open /dev/ttyACM0Hast du hier zufällig eine Idee?
