NEWS
Test Adapter Z-Wave 2 (v0.12.x / 0.13.x)
-
@Bluelightcrew sagte in Test Adapter Z-Wave 2 (v0.12.x / 0.13.x):
Wegen dem E5 das hat ja immer bisschen gedauert,da würde ich mich morgen melden.
Und konntest du schon schauen? Würde das Problem gerne in Adapter-Version 1.0.0 behoben haben
-
@AlCalzone
Sorry
Also kannst du so machen läuft super! Kein E5 mehr und die Thermostate nehmen Befehle an. Danke dir noch mal das du dich so intensiv darum gekümmert hast. -
1.0.0 läuft....
klasse Arbeit... und respekt, dass du es durchgezogen hastp.s.: auch wenn ich noch paar bugs hab
-
@arteck sagte in Test Adapter Z-Wave 2 (v0.12.x / 0.13.x):
auch wenn ich noch paar bugs hab
Na warum sagst du das nicht früher?
-
Also leider ist der Fehler in der 1.0.0 wieder zurück. Also der Verbindungsfehler E5 bei den Thermostaten.
Komischerweise nur 3 von 6. Die Thermostate die nahe am Sender sind funktionieren. -
jo bei mir ist auch der wur drin..es scheint der HOP geht nicht durch
der ist da..
-
@arteck
Ja das Gefühl hab ich auch -
@Bluelightcrew interessant... Haste mal ein log für mich?
-
@AlCalzone
Hier das Log!
Es geht um Node 33,11 und 15
zwave-9647.log -
@Bluelightcrew Ich habe eine Idee. Du erinnerst dich an die json-Datei, die du schonmal bearbeitet hast?
Die sollte unten jetzt etwa so aussehen (hier ein Ausschnitt):
"queryOnWakeup": [ // ["CommandClass", "API method", ...arguments] [ "Battery", "get" ], [ "Thermostat Setpoint", "get" ] ]
Füge hinter dem "get" unter "Thermostat Setpoint" bitte
, 1
ein:"queryOnWakeup": [ // ["CommandClass", "API method", ...arguments] [ "Battery", "get" ], [ "Thermostat Setpoint", "get", 1 ] ]
Dann speichern und Adapter neu starten.
-
@AlCalzone
Super ich sag mal im kurztest laufen jetzt alle wieder!
Manchmal taucht der Fehler aber auch erst später auf,dann würde ich mich Später nochmal melden. -
@Bluelightcrew dann probier ich es auch
-
@arteck
@AlCalzone
Fehler ist leider noch vorhanden. Hat also leider nix gebracht -
@Bluelightcrew Schade... Dann probieren wir es nochmal mit der Version, bei der es mal funktioniert hat - nicht dass wir Geister jagen...
Dazu den entsprechenden Abschnitt so bearbeiten, dass es so aussieht:
"queryOnWakeup": [ // ["CommandClass", "API method", ...arguments] ["Battery", "get"], ["Thermostat Setpoint", "set", 1, "$value$[\"setpoint\", 1]", 0], ["Thermostat Setpoint", "get", 1] ]
Wenn das funktioniert wie gedacht, sollte E5 weg sein, aber der Setpoint wird dann wieder nicht angenommen.
Wenn du mir das bestätigen kannst, haben wir eine Basis, auf der ich einen anderen Ansatz probieren kann.
-
da mach ich doch glatt mit
-
Hallo ihr beiden. Dank artecks Log konnte ich feststellen, dass es wohl nicht an den Abfragen liegt, sondern dass der Node nicht schlafen geschickt wird, wenn ein Ping zu einem anderen schlafenden Node die Warteschlange blockiert.
Bitte folgendes Update installieren und beobachten (gerne mit Log):
cd /opt/iobroker/node_modules/iobroker.zwave2 npm i zwave-js@3.7.0-beta.0
Neustart des Adaptes nicht vergessen
-
@AlCalzone
Also das Erste hat nicht funktioniert,da war ich seid gestern am Testen.
Aber mit der Beta das läuft seid 40 Minuten,ohne Probleme. -
Hallo bei mir ist gestern nach einem Catch leeren bei einem Fibaro double switch im Reiter Meter die Leistungsmessung für den 2 Kanal verschunden.
Ist das schon mal jemanden passiert?
Nutze Version 1.0.0
mfg Stefan -
@AlCalzone
Ich habe soeben mal die Beta 3.70 installiert und die Door_Lock States werden bei mir jetzt angezeigt und auch aktualisiert. Mit welchen States kann ich das Schloss steuern bzw. wie ist der Syntax dazu ? Bei openzwave war es Locked_1: true / false diesen sehe ich hier aber nicht. -
@jupzup Das sollte
targetMode
zum Setzen des Modus (entsperrt, gesichert, innen entsperrt, innen entsperrt mit timeout, ...) sein undcurrentMode
zum Lesen. Kann aber sein, dass da noch was fehlt - die Version ist ja noch nicht offiziell freigegeben bzw. als neue Adapterversion released.Schickst du mir mal einen Screenshot von den Door Lock states?
@FalconSBG ist der Node schon fertig interviewed?