Test Adapter Z-Wave 2 (v0.12.x / 0.13.x)

[Bluelightcrew]

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.

[arteck]

jo bei mir ist auch der wur drin..es scheint der HOP geht nicht durch

der ist da..

[Bluelightcrew]

@arteck
Ja das Gefühl hab ich auch

[AlCalzone]

@Bluelightcrew interessant... Haste mal ein log für mich?

[Bluelightcrew]

@AlCalzone
Hier das Log!
Es geht um Node 33,11 und 15
zwave-9647.log

[AlCalzone]

@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.

[Bluelightcrew]

@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.

[arteck]

@Bluelightcrew dann probier ich es auch

[Bluelightcrew]

@arteck
@AlCalzone
Fehler ist leider noch vorhanden. Hat also leider nix gebracht

[AlCalzone]

@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.

[arteck]

@AlCalzone

da mach ich doch glatt mit

[AlCalzone]

@arteck @Bluelightcrew

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

[Bluelightcrew]

@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.

[FalconSBG]

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

[jupzup]

@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.

[AlCalzone]

@jupzup Das sollte targetMode zum Setzen des Modus (entsperrt, gesichert, innen entsperrt, innen entsperrt mit timeout, ...) sein und currentMode 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?

[jupzup]

@AlCalzone
TargetMode sehe ich jetzt nicht anbei mal ein Screenshot:

[AlCalzone]

@jupzup Danke, dann fehlt da tatsächlich noch was.

[AlCalzone]

Hier geht's weiter:
https://forum.iobroker.net/topic/34314/test-adapter-z-wave-2-v1-1-x