NEWS
Test Adapter Z-Wave 2 (v1.4.x / 1.5.0 / 1.6.x)
-
@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x):
@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x):
auf folgende Features / BugFixes warte ich noch:
Fibaro Wall Plug E/F: Meter.value_w_consumed vs. Multilevel_Sensor.powerHast du mal mit den Konfigurationsparametern gespielt? https://manuals.fibaro.com/content/manuals/en/FGWPEF-102/FGWPEF-102-EN-A-v2.1.pdf
Könnte sein, dass wegen ungünstiger Thresholds die Reports ausbleiben.Habe ich, hat aber nichts geändert, steht alles wieder auf Standard.
Meter.value_w_consumedwird nur beim Interview aktualisiert, ansonsten wird regelmäßig und je nach Verbrauch (Fernseher) immer und, im Betrieb, oft der DPMultilevel_Sensor.poweraktualisiert.Devolo Sirene / Philio PSE02: Notification Reports über JS/Blockly
Stromverbrauch: Reset-DPFür diese beiden hab ich mal Issues erstellt und versuche sie demnächst anzugehen. Allerdings stehen jetzt erst mal 2,5 Wochen Urlaub an.
Klingt prima!
DANKE@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x):
Habe ich, hat aber nichts geändert, steht alles wieder auf Standard.
Du scheinst nicht alleine zu sein:
https://community.openhab.org/t/fibaro-wall-plug-fgwp102-not-sending-meter-values/33886/5
Schätze da kann ich nicht viel machen. -
Kleines Update: v1.5.0 ist auf dem Weg, Beschreibung oben.
@_nico schreibe mir doch grade nochmal, welche(s) Kommendo(s) du genau senden möchtest, dann kann ich dir sagen wie.Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
Kleines Update: v1.5.0 ist auf dem Weg, Beschreibung oben.
@_nico schreibe mir doch grade nochmal, welche(s) Kommendo(s) du genau senden möchtest, dann kann ich dir sagen wie.@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Kleines Update: v1.5.0 ist auf dem Weg, Beschreibung oben.
@_nico schreibe mir doch grade nochmal, welche(s) Kommendo(s) du genau senden möchtest, dann kann ich dir sagen wie.
Halt die 6 verfügbaren Sounds: https://products.z-wavealliance.org/ProductManual/File?folder=&filename=Manuals/2266/PSE02_UserManual.pdf
Irgendwie muss es auch noch einen „Stillen Alarm“ geben - ohne Ton, aber blinken.
Danke!
-
Hallo @AlCalzone,
zunächst mal vielen Dank für die großartige Arbeit. Ich bin momentan dabei all meine Z-Wave Geräte meiner bisherigen Smart-Home Zentrale zu ioBroker zu migrieren.
Beim Einbinden der Eurotronic Spirit Z-Wave Plus Heizkörperthermostate bin ich auf ein Problem gestoßen. Regeln lassen sie sich korrekt. Da aber die vom Thermostat gemessene IST-Temperatur meist zu hoch ist, bieten die Thermostate die Möglichkeit eine externe IST-Temperatur eines anderen Sensors übermittelt zu bekommen.
Lt. Anleitung läuft das per:
Report incoming: Sensortyp: „Air Temperature“ Skalierung: Celsius and Fahrenheit Genauigkeit: 0, 1 and 2Im Repo des "alten" Z-Wave Adapters gibt es ein Issue mit weiterführenden Links: https://github.com/ioBroker/ioBroker.zwave/issues/102 außerdem hier: https://forum.iobroker.net/topic/22396/eurotronic-spirit-z-wave-ist-temperatur-extern-setzen
Meine Frage: Kann dein Z-Wave Adapter diesen "Report" ans Thermostat senden? Kann ich hierfür die neue Funktion verwenden, die mit 1.5.0 kam (Sirene)?
Danke für deine Antwort.
-
@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Kleines Update: v1.5.0 ist auf dem Weg, Beschreibung oben.
@_nico schreibe mir doch grade nochmal, welche(s) Kommendo(s) du genau senden möchtest, dann kann ich dir sagen wie.Halt die 6 verfügbaren Sounds: https://products.z-wavealliance.org/ProductManual/File?folder=&filename=Manuals/2266/PSE02_UserManual.pdf
Irgendwie muss es auch noch einen „Stillen Alarm“ geben - ohne Ton, aber blinken.
Danke!
@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Irgendwie muss es auch noch einen „Stillen Alarm“ geben - ohne Ton, aber blinken.
Sehe ich in der Anleitung nicht, aber für die anderen probiers mal so:
sendTo( "zwave2.0", "sendCommand", { nodeId: 17, // The target node commandClass: "Notification", // Which command class to use command: "sendReport", // Which command should be sent args: [{ notificationType: 0x01, notificationEvent: 0x01, }], }, ({ error, result }) => { if (error) { log(error, "error"); } else { // Do something with the result (if there is any) // In this case, "undefined" is logged log(JSON.stringify(result)); } }, );Für die anderen Sounds musst du entsprechend der Tabelle aus der Anleitung
notificationTypeundnotificationEventändern.
@kev1 das würde grundsätzlich mit der neuen Funktion gehen, dazu muss ich aber erst eine Möglichkeit einbauen,
Multilevel Sensor Reportszu senden. Bisher sind eigentlich nur diejenigen vorgesehen, die der Adapter im normalen Betrieb auch senden muss (und auf Wunsch die Notification Reports). Ich schreibs mir für die nächste Version mal auf die TODO-Liste.Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
Kleines Update: v1.5.0 ist auf dem Weg, Beschreibung oben.
@_nico schreibe mir doch grade nochmal, welche(s) Kommendo(s) du genau senden möchtest, dann kann ich dir sagen wie.@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Kleines Update: v1.5.0 ist auf dem Weg, Beschreibung oben.
Perfekte Arbeit - @AlCalzone!
Bin nach langer Zeit wieder Up2Date und alles funktioniert mit deiner aktuellen neuen Version 1.5.0 noch immer reibungslos
Die neue Option mit: "sendTo können jetzt aus Skripten heraus Kommandos gesendet werden" ist genial!Weiteres die kommenden Tage
-
@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Irgendwie muss es auch noch einen „Stillen Alarm“ geben - ohne Ton, aber blinken.
Sehe ich in der Anleitung nicht, aber für die anderen probiers mal so:
sendTo( "zwave2.0", "sendCommand", { nodeId: 17, // The target node commandClass: "Notification", // Which command class to use command: "sendReport", // Which command should be sent args: [{ notificationType: 0x01, notificationEvent: 0x01, }], }, ({ error, result }) => { if (error) { log(error, "error"); } else { // Do something with the result (if there is any) // In this case, "undefined" is logged log(JSON.stringify(result)); } }, );Für die anderen Sounds musst du entsprechend der Tabelle aus der Anleitung
notificationTypeundnotificationEventändern.
@kev1 das würde grundsätzlich mit der neuen Funktion gehen, dazu muss ich aber erst eine Möglichkeit einbauen,
Multilevel Sensor Reportszu senden. Bisher sind eigentlich nur diejenigen vorgesehen, die der Adapter im normalen Betrieb auch senden muss (und auf Wunsch die Notification Reports). Ich schreibs mir für die nächste Version mal auf die TODO-Liste.Ich habe vermutlich noch einen Bug gefunden.
Nachdem ich anfangs Probleme bzgl. der Rückmeldungen beim benutzen der Lichtschalter hatte,
funktioniert dies nun gut.Allerdings kommen keine Rückmeldungen im Ordner "Binary_Switch" an. Im "Multilevel_Switch" sieht
alles gut aus.Beispiel: Licht ist aktuell aus:
Werte sind auf "0" (passt)
Im Binary Ordner bleibt der Wert auf "true" (auch wenn ich im Multilevel_Switch Ordner die Werte Manull auf 0 oder 99 ändere)
-
Ich habe vermutlich noch einen Bug gefunden.
Nachdem ich anfangs Probleme bzgl. der Rückmeldungen beim benutzen der Lichtschalter hatte,
funktioniert dies nun gut.Allerdings kommen keine Rückmeldungen im Ordner "Binary_Switch" an. Im "Multilevel_Switch" sieht
alles gut aus.Beispiel: Licht ist aktuell aus:
Werte sind auf "0" (passt)
Im Binary Ordner bleibt der Wert auf "true" (auch wenn ich im Multilevel_Switch Ordner die Werte Manull auf 0 oder 99 ändere)
-
@Chris_78 Kannst du mit dem Binary Switch auch schalten? Oder ist das wieder ein Fall von unnötigem Datenpunkt?
Ich kann mit dem Binary_Switch über den targetValue (true,false) auch schalten.
Der currentValue wird dann auch korrekt aktualisiert. -
@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Irgendwie muss es auch noch einen „Stillen Alarm“ geben - ohne Ton, aber blinken.
Sehe ich in der Anleitung nicht, aber für die anderen probiers mal so:
sendTo( "zwave2.0", "sendCommand", { nodeId: 17, // The target node commandClass: "Notification", // Which command class to use command: "sendReport", // Which command should be sent args: [{ notificationType: 0x01, notificationEvent: 0x01, }], }, ({ error, result }) => { if (error) { log(error, "error"); } else { // Do something with the result (if there is any) // In this case, "undefined" is logged log(JSON.stringify(result)); } }, );Für die anderen Sounds musst du entsprechend der Tabelle aus der Anleitung
notificationTypeundnotificationEventändern.
@kev1 das würde grundsätzlich mit der neuen Funktion gehen, dazu muss ich aber erst eine Möglichkeit einbauen,
Multilevel Sensor Reportszu senden. Bisher sind eigentlich nur diejenigen vorgesehen, die der Adapter im normalen Betrieb auch senden muss (und auf Wunsch die Notification Reports). Ich schreibs mir für die nächste Version mal auf die TODO-Liste.@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Irgendwie muss es auch noch einen „Stillen Alarm“ geben - ohne Ton, aber blinken.
Sehe ich in der Anleitung nicht, aber für die anderen probiers mal so:
sendTo( "zwave2.0", "sendCommand", { nodeId: 17, // The target node commandClass: "Notification", // Which command class to use command: "sendReport", // Which command should be sent args: [{ notificationType: 0x01, notificationEvent: 0x01, }], }, ({ error, result }) => { if (error) { log(error, "error"); } else { // Do something with the result (if there is any) // In this case, "undefined" is logged log(JSON.stringify(result)); } }, );Für die anderen Sounds musst du entsprechend der Tabelle aus der Anleitung
notificationTypeundnotificationEventändern.PERFEKT! DANKE!
Ich werde es testen und berichten, sobald sich ein geeignetes Zeitfenster mit den Kids ergibt.
- Fire siren -
notificationType: 0x01, notificationEvent: 0x01 - Door chime -
notificationType: 0x06, notificationEvent 0x16 - Lock / Arming / 2x Beep -
notificationType: 0x06, notificationEvent: 0x03 - Unlock / Disarm / 1x Beep -
notificationType: 0x06, notificationEvent: 0x04 - Emergency -
notificationType: 0x07, notificationEvent: 0x01 - Police siren -
notificationType: 0x0A, notificationEvent: 0x01 - Fire Alarm -
notificationType: 0x0A, notificationEvent: 0x02 - Ambulance -
notificationType: 0x0A, notificationEvent: 0x03 - Silent alarm (no sound, only LED flashes) -
notificationType: 0x0A, notificationEvent: 0xFE
- Fire siren -
-
@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Irgendwie muss es auch noch einen „Stillen Alarm“ geben - ohne Ton, aber blinken.
Sehe ich in der Anleitung nicht, aber für die anderen probiers mal so:
sendTo( "zwave2.0", "sendCommand", { nodeId: 17, // The target node commandClass: "Notification", // Which command class to use command: "sendReport", // Which command should be sent args: [{ notificationType: 0x01, notificationEvent: 0x01, }], }, ({ error, result }) => { if (error) { log(error, "error"); } else { // Do something with the result (if there is any) // In this case, "undefined" is logged log(JSON.stringify(result)); } }, );Für die anderen Sounds musst du entsprechend der Tabelle aus der Anleitung
notificationTypeundnotificationEventändern.
@kev1 das würde grundsätzlich mit der neuen Funktion gehen, dazu muss ich aber erst eine Möglichkeit einbauen,
Multilevel Sensor Reportszu senden. Bisher sind eigentlich nur diejenigen vorgesehen, die der Adapter im normalen Betrieb auch senden muss (und auf Wunsch die Notification Reports). Ich schreibs mir für die nächste Version mal auf die TODO-Liste.@AlCalzone said in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Ich schreibs mir für die nächste Version mal auf die TODO-Liste.
Super, vielen Dank! Dann sollte einer Verwendung von ioBroker in der nächsten Heizperiode ja nichts im Wege stehen.
Ich habe jetzt noch weitere Tests mit den Eurotronic Spirit angestellt. Dabei ist mir folgendes aufgefallen: Beim Schalten des Heizmodus (z.B. von Off auf Heat), öffnet das Thermostat. Die Ventilstellung (Multilevel_Switch -> currentValue) wird aber nicht übertragen. Im Log ist kein Wert ersichtlich. Sende ich manuell einen fake Wert als targetValue an den Multilevel_Switch, wird der angefahrene Stellwert korrekt zurückgemeldet (der gesendete targetValue wird ignoriert, da nicht im manuellen Modus).
Kurios ist: Im manuellen Modus, d.h. wenn ich nicht per Soll-Temperatur, sondern per vorgegebenen Stellwert regle, wird der Wert immer gemeldet. Im oben beschriebenen Heizmodus hingegen nur sehr sporadisch (fast nie).
Mich würde jetzt interessieren: Ist das ein Firmware-Problem der Eurotronic Spirit oder muss etwas am Adapter angepasst werden? Im Anhang zwei Log-Dateien (log1 = Wert wurde nicht gemeldet, log2 = Wert wurde gemeldet).
DANKE!!
-
Hey, ich habe den Fibaro Motion Sensor nun mit dem Zwave 2 Adaper eingebunden.
Gefunden wurde dieser einwandfrei. Es scheint aber als wenn die Optionen für das "Motion Detection" nicht gezogen werden. Habe den Sensor schon mehrfach gelöscht und wieder eingebunden. Anbei mal Screens.
Über einen Rat wäre ich dankbar.
Anbei das gewünschte Log. (Hier ging es darum das der Datenpunkt für die Bewegungserkennung nicht da ist).
root@IOBroker:/opt/iobroker/node_modules/zwave-js# cat zwave-9910.log 11:33:08.180 DRIVER ███████╗ ██╗ ██╗ █████╗ ██╗ ██╗ ███████╗ ██╗ ███████╗ ╚══███╔╝ ██║ ██║ ██╔══██╗ ██║ ██║ ██╔════╝ ██║ ██╔════╝ ███╔╝ ██║ █╗ ██║ ███████║ ██║ ██║ █████╗ █████╗ ██║ ███████╗ ███╔╝ ██║███╗██║ ██╔══██║ ╚██╗ ██╔╝ ██╔══╝ ╚════╝ ██ ██║ ╚════██║ ███████╗ ╚███╔███╔╝ ██║ ██║ ╚████╔╝ ███████╗ ╚█████╔╝ ███████║ ╚══════╝ ╚══╝╚══╝ ╚═╝ ╚═╝ ╚═══╝ ╚══════╝ ╚════╝ ╚══════╝ 11:33:08.186 DRIVER version 4.0.4 11:33:08.187 DRIVER 11:33:08.187 DRIVER starting driver... 11:33:08.187 DRIVER opening serial port /dev/ttyACM1 11:33:08.260 DRIVER serial port opened 11:33:08.367 DRIVER Dropping message because the driver is not ready to handle it yet. 11:33:09.774 DRIVER loading configuration... 11:33:10.112 DRIVER beginning interview... 11:33:10.114 DRIVER added request handler for AddNodeToNetwork (0x4a)... 1 registered 11:33:10.115 DRIVER added request handler for RemoveNodeFromNetwork (0x4b)... 1 registered 11:33:10.117 CNTRLR beginning interview... 11:33:10.118 CNTRLR querying version info... 11:33:10.123 DRIVER » [REQ] [GetControllerVersion] [P: Controller] 11:33:10.128 DRIVER ACK received from controller for current transaction 11:33:10.131 DRIVER « [RES] [GetControllerVersion] [final] payload: 0x5a2d5761766520342e35340001 11:33:10.132 DRIVER ACK already received, resolving transaction 11:33:10.132 DRIVER resuming send queue 11:33:10.133 CNTRLR received version info: controller type: Static Controller library version: Z-Wave 4.54 11:33:10.133 CNTRLR querying controller IDs... 11:33:10.134 DRIVER » [REQ] [GetControllerId] [P: Controller] 11:33:10.135 DRIVER workOffSendQueue > skipping because a transaction is pending 11:33:10.139 DRIVER ACK received from controller for current transaction 11:33:10.141 DRIVER « [RES] [GetControllerId] [final] payload: 0xd6de6a3401 11:33:10.141 DRIVER ACK already received, resolving transaction 11:33:10.141 DRIVER resuming send queue 11:33:10.142 CNTRLR received controller IDs: home ID: 0xd6de6a34 own node ID: 1 11:33:10.142 CNTRLR querying controller capabilities... 11:33:10.143 DRIVER » [REQ] [GetControllerCapabilities] [P: Controller] 11:33:10.144 DRIVER workOffSendQueue > skipping because a transaction is pending 11:33:10.147 DRIVER ACK received from controller for current transaction 11:33:10.149 DRIVER « [RES] [GetControllerCapabilities] [final] payload: 0x08 11:33:10.149 DRIVER ACK already received, resolving transaction 11:33:10.149 DRIVER resuming send queue 11:33:10.150 CNTRLR received controller capabilities: controller role: primary is in other network: false is SIS present: false was real primary: true is a SUC: false 11:33:10.150 CNTRLR querying API capabilities... 11:33:10.152 DRIVER » [REQ] [GetSerialApiCapabilities] [P: Controller] 11:33:10.152 DRIVER workOffSendQueue > skipping because a transaction is pending 11:33:10.155 DRIVER ACK received from controller for current transaction 11:33:10.161 DRIVER « [RES] [GetSerialApiCapabilities] [final] payload: 0x010100860001005afe81ff884f1f0000fb9f7da067000080008086000000e8730 0000e0000600000 11:33:10.161 DRIVER ACK already received, resolving transaction 11:33:10.161 DRIVER resuming send queue 11:33:10.162 CNTRLR received API capabilities: serial API version: 1.1 manufacturer ID: 0x86 product type: 0x01 product ID: 0x5a supported functions: · GetSerialApiInitData (0x02) · FUNC_ID_SERIAL_API_APPL_NODE_INFORMATION (0x03) · ApplicationCommand (0x04) · GetControllerCapabilities (0x05) · SetSerialApiTimeouts (0x06) · GetSerialApiCapabilities (0x07) · FUNC_ID_SERIAL_API_SOFT_RESET (0x08) · UNKNOWN_FUNC_UNKNOWN_0x09 (0x09) · UNKNOWN_FUNC_RF_RECEIVE_MODE (0x10) · UNKNOWN_FUNC_SET_SLEEP_MODE (0x11) · FUNC_ID_ZW_SEND_NODE_INFORMATION (0x12) · SendData (0x13) · SendDataMulticast (0x14) · GetControllerVersion (0x15) · SendDataAbort (0x16) · FUNC_ID_ZW_R_F_POWER_LEVEL_SET (0x17) · UNKNOWN_FUNC_SEND_DATA_META (0x18) · FUNC_ID_ZW_GET_RANDOM (0x1c) · GetControllerId (0x20) · UNKNOWN_FUNC_MEMORY_GET_BYTE (0x21) · UNKNOWN_FUNC_MEMORY_PUT_BYTE (0x22) · UNKNOWN_FUNC_MEMORY_GET_BUFFER (0x23) · UNKNOWN_FUNC_MEMORY_PUT_BUFFER (0x24) · UNKNOWN_FUNC_FlashAutoProgSet (0x27) · UNKNOWN_FUNC_NVMGetId (0x29) · UNKNOWN_FUNC_NVMExtReadLongBuffer (0x2a) · UNKNOWN_FUNC_NVMExtWriteLongBuffer (0x2b) · UNKNOWN_FUNC_NVMExtReadLongByte (0x2c) · UNKNOWN_FUNC_NVMExtWriteLongByte (0x2d) · GetNodeProtocolInfo (0x41) · HardReset (0x42) · FUNC_ID_ZW_REPLICATION_COMMAND_COMPLETE (0x44) · FUNC_ID_ZW_REPLICATION_SEND_DATA (0x45) · AssignReturnRoute (0x46) · DeleteReturnRoute (0x47) · RequestNodeNeighborUpdate (0x48) · ApplicationUpdateRequest (0x49) · AddNodeToNetwork (0x4a) · RemoveNodeFromNetwork (0x4b) · FUNC_ID_ZW_CREATE_NEW_PRIMARY (0x4c) · FUNC_ID_ZW_CONTROLLER_CHANGE (0x4d) · FUNC_ID_ZW_SET_LEARN_MODE (0x50) · FUNC_ID_ZW_ASSIGN_SUC_RETURN_ROUTE (0x51) · FUNC_ID_ZW_REQUEST_NETWORK_UPDATE (0x53) · FUNC_ID_ZW_SET_SUC_NODE_ID (0x54) · FUNC_ID_ZW_DELETE_SUC_RETURN_ROUTE (0x55) · GetSUCNodeId (0x56) · UNKNOWN_FUNC_SEND_SUC_ID (0x57) · FUNC_ID_ZW_EXPLORE_REQUEST_INCLUSION (0x5e) · RequestNodeInfo (0x60) · RemoveFailedNode (0x61) · IsFailedNode (0x62) · FUNC_ID_ZW_REPLACE_FAILED_NODE (0x63) · UNKNOWN_FUNC_UNKNOWN_0x66 (0x66) · UNKNOWN_FUNC_UNKNOWN_0x67 (0x67) · GetRoutingInfo (0x80) · UNKNOWN_FUNC_LOCK_ROUTE_RESPONSE (0x90) · UNKNOWN_FUNC_GET_PRIORITY_ROUTE (0x92) · UNKNOWN_FUNC_SET_PRIORITY_ROUTE (0x93) · UNKNOWN_FUNC_UNKNOWN_0x98 (0x98) · UNKNOWN_FUNC_UNKNOWN_0xB4 (0xb4) · UNKNOWN_FUNC_WATCH_DOG_ENABLE (0xb6) · UNKNOWN_FUNC_WATCH_DOG_DISABLE (0xb7) · UNKNOWN_FUNC_WATCH_DOG_KICK (0xb8) · UNKNOWN_FUNC_UNKNOWN_0xB9 (0xb9) · UNKNOWN_FUNC_RF_POWERLEVEL_GET (0xba) · UNKNOWN_FUNC_GET_LIBRARY_TYPE (0xbd) · UNKNOWN_FUNC_SEND_TEST_FRAME (0xbe) · UNKNOWN_FUNC_GET_PROTOCOL_STATUS (0xbf) · UNKNOWN_FUNC_UNKNOWN_0xD2 (0xd2) · UNKNOWN_FUNC_UNKNOWN_0xD3 (0xd3) · UNKNOWN_FUNC_UNKNOWN_0xD4 (0xd4) · undefined (0xee) · UNKNOWN_FUNC_UNKNOWN_0xEF (0xef) 11:33:10.163 CNTRLR finding SUC... 11:33:10.164 DRIVER » [REQ] [GetSUCNodeId] [P: Controller] 11:33:10.165 DRIVER workOffSendQueue > skipping because a transaction is pending 11:33:10.168 DRIVER ACK received from controller for current transaction 11:33:10.171 DRIVER « [RES] [GetSUCNodeId] [final] payload: 0x00 11:33:10.171 DRIVER ACK already received, resolving transaction 11:33:10.171 DRIVER resuming send queue 11:33:10.172 CNTRLR no SUC present 11:33:10.176 DRIVER The send queue is empty 11:33:10.212 CNTRLR querying node information... 11:33:10.214 DRIVER » [REQ] [GetSerialApiInitData] [P: Controller] 11:33:10.218 DRIVER ACK received from controller for current transaction 11:33:10.317 DRIVER « [RES] [GetSerialApiInitData] [final] payload: 0x05001d05000000000000000000000000000000000000000000000000000000000 500 11:33:10.318 DRIVER ACK already received, resolving transaction 11:33:10.318 DRIVER resuming send queue 11:33:10.318 CNTRLR received node information: controller role: primary controller is a SUC: false controller is a slave: false controller supports timers: false nodes in the network: 1, 3 11:33:10.322 DRIVER The send queue is empty 11:33:10.323 DRIVER Cache file for homeId 0xd6de6a34 found, attempting to restore the network from cache... 11:33:10.329 CNTRLR [Node 001] trying to load device config 11:33:10.339 CNTRLR [Node 001] device config loaded 11:33:10.344 DRIVER Restoring the network from cache was successful! 11:33:10.350 CNTRLR [Node 001] [Manufacturer Specific] manufacturerId: metadata updated 11:33:10.352 CNTRLR [Node 001] [Manufacturer Specific] productType: metadata updated 11:33:10.354 CNTRLR [Node 001] [Manufacturer Specific] productId: metadata updated 11:33:10.355 CNTRLR [Node 001] [~] [Manufacturer Specific] manufacturerId: 134 => 134 11:33:10.356 CNTRLR [Node 001] [~] [Manufacturer Specific] productType: 1 => 1 11:33:10.356 CNTRLR [Node 001] [~] [Manufacturer Specific] productId: 90 => 90 11:33:10.357 CNTRLR setting serial API timeouts: ack = 1000 ms, byte = 150 ms 11:33:10.358 DRIVER » [REQ] [SetSerialApiTimeouts] [P: Controller] 11:33:10.361 DRIVER ACK received from controller for current transaction 11:33:10.363 DRIVER « [RES] [SetSerialApiTimeouts] [final] payload: 0x640f 11:33:10.363 DRIVER ACK already received, resolving transaction 11:33:10.363 DRIVER resuming send queue 11:33:10.364 CNTRLR serial API timeouts overwritten. The old values were: ack = 1000 ms, byte = 15 0 ms 11:33:10.364 CNTRLR Interview completed 11:33:10.368 DRIVER driver ready 11:33:10.374 CNTRLR [Node 001] Beginning interview - last completed stage: RestartFromCache 11:33:10.374 CNTRLR [Node 001] not pinging the controller 11:33:10.379 DRIVER The send queue is empty 11:33:10.390 CNTRLR [Node 001] Interview stage completed: CommandClasses 11:33:10.390 CNTRLR [Node 001] trying to load device config 11:33:10.396 CNTRLR [Node 001] device config loaded 11:33:10.397 CNTRLR [Node 001] Interview stage completed: OverwriteConfig 11:33:10.397 CNTRLR » [Node 001] requesting node neighbors... 11:33:10.399 DRIVER » [Node 001] [REQ] [GetRoutingInfo] [P: Controller] removeNonRepeaters: false removeBadLinks: false 11:33:10.403 DRIVER ACK received from controller for current transaction 11:33:10.408 DRIVER « [RES] [GetRoutingInfo] [final] node ids: 11:33:10.408 DRIVER ACK already received, resolving transaction 11:33:10.409 DRIVER resuming send queue 11:33:10.409 CNTRLR « [Node 001] node neighbors received: 11:33:10.409 CNTRLR [Node 001] Interview stage completed: Neighbors 11:33:10.410 CNTRLR [Node 001] Interview completed 11:33:10.410 CNTRLR [Node 001] The node is ready to be used 11:33:10.412 CNTRLR [Node 003] Beginning interview - last completed stage: ProtocolInfo 11:33:10.412 CNTRLR » [Node 003] pinging the node... 11:33:10.418 DRIVER » [Node 003] [REQ] [SendData] [P: NodeQuery] │ transmitOptions: 0x25 │ callbackId: 1 └─[NoOperationCC] 11:33:10.419 DRIVER workOffSendQueue > skipping because a transaction is pending 11:33:10.422 DRIVER ACK received from controller for current transaction 11:33:10.437 DRIVER « [RES] [SendData] [confirmation] wasSent: true 11:33:14.565 DRIVER « [REQ] [SendData] [fatal_node] callbackId: 1 transmitStatus: NoAck 11:33:14.566 CNTRLR [Node 003] The node did not respond to the current transaction after 1 attempt s. It is probably asleep, moving its messages to the wakeup queue. 11:33:14.567 CNTRLR [Node 003] The node is now asleep. 11:33:14.570 CNTRLR [Node 003] ping failed: The node is asleep 11:33:14.571 CNTRLR » [Node 003] querying node info... 11:33:14.573 DRIVER The remaining 1 messages are for sleeping nodes, not sending anything! 11:33:14.574 DRIVER Send queue: (1 message) · [REQ] RequestNodeInfo [Node 3, asleep] 11:33:14.575 DRIVER The remaining 1 messages are for sleeping nodes, not sending anything! 11:33:14.575 DRIVER Send queue: (1 message) · [REQ] RequestNodeInfo [Node 3, asleep] 11:33:15.435 CNTRLR [Node 003] [Multilevel Sensor] Illuminance: metadata updated [Endpoint 0] 11:33:15.440 CNTRLR [Node 003] [~] [Multilevel Sensor] Illuminance: 5 => 5 [Endpoint 0] 11:33:15.443 DRIVER « [Node 003] [REQ] [ApplicationCommand] └─[MultilevelSensorCCReport] payload: 0x030a0005 11:33:25.542 CNTRLR [Node 003] [Multilevel Sensor] Illuminance: metadata updated [Endpoint 0] 11:33:25.543 CNTRLR [Node 003] [~] [Multilevel Sensor] Illuminance: 5 => 5 [Endpoint 0] 11:33:25.544 DRIVER « [Node 003] [REQ] [ApplicationCommand] └─[MultilevelSensorCCReport] payload: 0x030a0005 11:33:31.974 DRIVER « [Node 003] [REQ] [ApplicationCommand] └─[SecurityCCNonceGet] 11:33:31.979 DRIVER » [Node 003] [REQ] [SendData] [P: Handshake] │ transmitOptions: 0x24 │ callbackId: 0 └─[SecurityCCNonceReport] 11:33:31.984 DRIVER ACK received from controller for current transaction 11:33:31.997 DRIVER « [RES] [SendData] [final] wasSent: true 11:33:31.997 DRIVER ACK already received, resolving transaction 11:33:31.998 DRIVER resuming send queue 11:33:31.999 DRIVER The remaining 1 messages are for sleeping nodes, not sending anything! 11:33:31.999 DRIVER Send queue: (1 message) · [REQ] RequestNodeInfo [Node 3, asleep] 11:33:32.037 DRIVER Message with invalid data received. Dropping it: 0x0123000400031d98811fdd667df6079ee318256f27a1998d16ff8fb0e9f5a9fd7000946959 11:33:33.631 DRIVER « [Node 003] [REQ] [ApplicationCommand] └─[SecurityCCNonceGet] 11:33:33.635 DRIVER » [Node 003] [REQ] [SendData] [P: Handshake] │ transmitOptions: 0x24 │ callbackId: 0 └─[SecurityCCNonceReport] 11:33:33.640 DRIVER ACK received from controller for current transaction 11:33:33.650 DRIVER « [RES] [SendData] [final] wasSent: true 11:33:33.651 DRIVER ACK already received, resolving transaction 11:33:33.651 DRIVER resuming send queue 11:33:33.652 DRIVER The remaining 1 messages are for sleeping nodes, not sending anything! 11:33:33.653 DRIVER Send queue: (1 message) · [REQ] RequestNodeInfo [Node 3, asleep] 11:33:33.692 DRIVER Message with invalid data received. Dropping it: 0x0124000400031e9881cfb0b67082f7e9737df11479f36d301f33b52ba4a361629d91d176c916 11:33:34.417 DRIVER « [Node 003] [REQ] [ApplicationCommand] └─[SecurityCCNonceGet] 11:33:34.418 DRIVER » [Node 003] [REQ] [SendData] [P: Handshake] │ transmitOptions: 0x24 │ callbackId: 0 └─[SecurityCCNonceReport] 11:33:34.423 DRIVER ACK received from controller for current transaction 11:33:34.432 DRIVER « [RES] [SendData] [final] wasSent: true 11:33:34.432 DRIVER ACK already received, resolving transaction 11:33:34.432 DRIVER resuming send queue 11:33:34.433 DRIVER The remaining 1 messages are for sleeping nodes, not sending anything! 11:33:34.433 DRIVER Send queue: (1 message) · [REQ] RequestNodeInfo [Node 3, asleep] 11:33:34.477 DRIVER Message with invalid data received. Dropping it: 0x0123000400031d988171528ee0b9adacf391cf751ec7226e6bd2391f4541d9ae7160115ad1 11:33:35.657 DRIVER « [Node 003] [REQ] [ApplicationCommand] └─[SecurityCCNonceGet] 11:33:35.659 DRIVER » [Node 003] [REQ] [SendData] [P: Handshake] │ transmitOptions: 0x24 │ callbackId: 0 └─[SecurityCCNonceReport] 11:33:35.665 DRIVER ACK received from controller for current transaction 11:33:35.672 DRIVER « [RES] [SendData] [final] wasSent: true 11:33:35.672 DRIVER ACK already received, resolving transaction 11:33:35.672 DRIVER resuming send queue 11:33:35.673 DRIVER The remaining 1 messages are for sleeping nodes, not sending anything! 11:33:35.673 DRIVER Send queue: (1 message) · [REQ] RequestNodeInfo [Node 3, asleep] 11:33:35.718 DRIVER Message with invalid data received. Dropping it: 0x0124000400031e9881094b4438af2af683a05e61a68427b879a105352c07ed2267b7f6288ebb 11:33:35.932 CNTRLR [Node 003] [Multilevel Sensor] Air temperature: metadata updated [Endpoint 0] 11:33:35.934 CNTRLR [Node 003] [~] [Multilevel Sensor] Air temperature: 26.3 => 26.3 [Endpoint 0] 11:33:35.937 DRIVER « [Node 003] [REQ] [ApplicationCommand] └─[MultilevelSensorCCReport] payload: 0x01220107 11:33:37.688 CNTRLR [Node 003] [Multilevel Sensor] Illuminance: metadata updated [Endpoint 0] 11:33:37.689 CNTRLR [Node 003] [~] [Multilevel Sensor] Illuminance: 5 => 5 [Endpoint 0] 11:33:37.690 DRIVER « [Node 003] [REQ] [ApplicationCommand] └─[MultilevelSensorCCReport] payload: 0x030a0005 11:33:46.829 DRIVER destroying driver instance... -
@AlCalzone said in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Ich schreibs mir für die nächste Version mal auf die TODO-Liste.
Super, vielen Dank! Dann sollte einer Verwendung von ioBroker in der nächsten Heizperiode ja nichts im Wege stehen.
Ich habe jetzt noch weitere Tests mit den Eurotronic Spirit angestellt. Dabei ist mir folgendes aufgefallen: Beim Schalten des Heizmodus (z.B. von Off auf Heat), öffnet das Thermostat. Die Ventilstellung (Multilevel_Switch -> currentValue) wird aber nicht übertragen. Im Log ist kein Wert ersichtlich. Sende ich manuell einen fake Wert als targetValue an den Multilevel_Switch, wird der angefahrene Stellwert korrekt zurückgemeldet (der gesendete targetValue wird ignoriert, da nicht im manuellen Modus).
Kurios ist: Im manuellen Modus, d.h. wenn ich nicht per Soll-Temperatur, sondern per vorgegebenen Stellwert regle, wird der Wert immer gemeldet. Im oben beschriebenen Heizmodus hingegen nur sehr sporadisch (fast nie).
Mich würde jetzt interessieren: Ist das ein Firmware-Problem der Eurotronic Spirit oder muss etwas am Adapter angepasst werden? Im Anhang zwei Log-Dateien (log1 = Wert wurde nicht gemeldet, log2 = Wert wurde gemeldet).
DANKE!!
@kev1 sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Ist das ein Firmware-Problem der Eurotronic Spirit oder muss etwas am Adapter angepasst werden?
Ich tippe auf Konfiguration, da die Reports standardmäßig nicht gesendet werden:
@mech Der Adapter scheint Nachrichten des Nodes nicht dekodieren zu können und ignoriert sie daher. Damit gehts auch mit dem Interview nicht weiter.
Kontrolliere mal, ob der Netzwerkschlüssel richtig eingerichtet ist. Falls ja, brauche ich ein neues Log mit der neuen Version (da einige wichtige Infos zum Entschlüsseln vorher nicht korrekt geloggt wurden). Die Logs befinden sich jetzt in/opt/iobroker/node_modules/iobroker.zwave2/build. Außerdem den Netzwerkschlüssel. -
@kev1 sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Ist das ein Firmware-Problem der Eurotronic Spirit oder muss etwas am Adapter angepasst werden?
Ich tippe auf Konfiguration, da die Reports standardmäßig nicht gesendet werden:
@mech Der Adapter scheint Nachrichten des Nodes nicht dekodieren zu können und ignoriert sie daher. Damit gehts auch mit dem Interview nicht weiter.
Kontrolliere mal, ob der Netzwerkschlüssel richtig eingerichtet ist. Falls ja, brauche ich ein neues Log mit der neuen Version (da einige wichtige Infos zum Entschlüsseln vorher nicht korrekt geloggt wurden). Die Logs befinden sich jetzt in/opt/iobroker/node_modules/iobroker.zwave2/build. Außerdem den Netzwerkschlüssel.D.h. es würde auch Sinn machen den Adapter noch einmal zu updaten?
-
@kev1 sagte in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Ist das ein Firmware-Problem der Eurotronic Spirit oder muss etwas am Adapter angepasst werden?
Ich tippe auf Konfiguration, da die Reports standardmäßig nicht gesendet werden:
@mech Der Adapter scheint Nachrichten des Nodes nicht dekodieren zu können und ignoriert sie daher. Damit gehts auch mit dem Interview nicht weiter.
Kontrolliere mal, ob der Netzwerkschlüssel richtig eingerichtet ist. Falls ja, brauche ich ein neues Log mit der neuen Version (da einige wichtige Infos zum Entschlüsseln vorher nicht korrekt geloggt wurden). Die Logs befinden sich jetzt in/opt/iobroker/node_modules/iobroker.zwave2/build. Außerdem den Netzwerkschlüssel.@AlCalzone said in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Ich tippe auf Konfiguration, da die Reports standardmäßig nicht gesendet werden:
Das hätte ich natürlich dazu schreiben sollen. valveOpeningPercentageReport hatte ich bereits auf 1 gestellt.
-
D.h. es würde auch Sinn machen den Adapter noch einmal zu updaten?
Ich habe das identische Problem. Mich würde allerdings die Firmware Version des Eurotronic interessieren.
In deinem Screenshot ist zu sehen, dass du den Thermostat_Mode = "Manual(31)" eingestellt hast.
Diesen gibt es bei mir gar nicht.
Ich habe zur Auswahl:- Off(0)
- Heat(1)
- Energy heat(11)
- Full power(15)
Firmware wird bei mir die Version "0.16" gemeldet (unter "Version/firmwareVersions").
-
Ich habe das identische Problem. Mich würde allerdings die Firmware Version des Eurotronic interessieren.
In deinem Screenshot ist zu sehen, dass du den Thermostat_Mode = "Manual(31)" eingestellt hast.
Diesen gibt es bei mir gar nicht.
Ich habe zur Auswahl:- Off(0)
- Heat(1)
- Energy heat(11)
- Full power(15)
Firmware wird bei mir die Version "0.16" gemeldet (unter "Version/firmwareVersions").
@Chris_78 said in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Mich würde allerdings die Firmware Version des Eurotronic interessieren.
In deinem Screenshot ist zu sehen, dass du den Thermostat_Mode = "Manual(31)" eingestellt hast.
Diesen gibt es bei mir gar nicht.Manual habe ich selbst hinzugefügt.
{ "0": "Off", "1": "Heat", "11": "Energy heat", "15": "Full power", "31": "Manual" }Firmware Version ist die 0.15.
-
D.h. es würde auch Sinn machen den Adapter noch einmal zu updaten?
-
@Chris_78 said in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Mich würde allerdings die Firmware Version des Eurotronic interessieren.
In deinem Screenshot ist zu sehen, dass du den Thermostat_Mode = "Manual(31)" eingestellt hast.
Diesen gibt es bei mir gar nicht.Manual habe ich selbst hinzugefügt.
{ "0": "Off", "1": "Heat", "11": "Energy heat", "15": "Full power", "31": "Manual" }Firmware Version ist die 0.15.
@kev1 31 (0x1f) ist laut Anleitung der Manufacturer-Modus, indem das Gerät auf Multilevel Switch reagiert. Warum der bei der Abfrage nicht dabei ist, wundert mich ein wenig:
Der Spirit Z-Wave Plus wechselt in den Stellwertbetrieb und ermöglicht das Steuern des Ventilöffnungsgrads über die Befehlsklasse Multilevel Switch.
Kannst du mir vielleicht auch mal ein Log machen, bei dem du eine Aktualisierung des Multilevel States bei manueller Betätigung erwartest? Vielleicht wird ja doch was verschluckt.
Hat aber ca. 2 Wochen Zeit, vorher kann ich mir das voraussichtlich nicht anschauen. -
@kev1 31 (0x1f) ist laut Anleitung der Manufacturer-Modus, indem das Gerät auf Multilevel Switch reagiert. Warum der bei der Abfrage nicht dabei ist, wundert mich ein wenig:
Der Spirit Z-Wave Plus wechselt in den Stellwertbetrieb und ermöglicht das Steuern des Ventilöffnungsgrads über die Befehlsklasse Multilevel Switch.
Kannst du mir vielleicht auch mal ein Log machen, bei dem du eine Aktualisierung des Multilevel States bei manueller Betätigung erwartest? Vielleicht wird ja doch was verschluckt.
Hat aber ca. 2 Wochen Zeit, vorher kann ich mir das voraussichtlich nicht anschauen.@AlCalzone said in Test Adapter Z-Wave 2 (v1.4.x / 1.5.x):
Kannst du mir vielleicht auch mal ein Log machen, bei dem du eine Aktualisierung des Multilevel States bei manueller Betätigung erwartest? Vielleicht wird ja doch was verschluckt.
Gerne! Ich habe noch mal ausführlicher getestet:
Versuch 1: Umschalten vom Modus OFF auf HEAT. Thermostat-Motor summt hörbar, der Multilevel_Switch bleibt aber unverändert bei 0. off-heat.txt
Versuch 1.1: Wenn ich in diesem Zustand nun manuell einmal targetValue=0 an das Thermostat sende (was keine Auswirkungen hat, da es sich nicht im manuellen Modus befindet), meldet das Thermostat die korrekte currentValue zurück. manuell_target_0.txt
Versuch 1.2: Danach wieder Umschalten von Modus HEAT auf OFF. Hier wird der Stellwert korrekt übertragen. heat-off.txt
Versuch 2: Manuelle Schaltungen der Temperatur am Thermostat. Beim ersten mal wird der Stellwert korrekt übertragen. Bei den weiteren Schaltungen nicht. manuelle-schaltung.txt
Versuch 3: Nach einer manuellen Schaltung am Thermostat (und Hören des Thermostatmotors), senden wir wieder die targetValue=0. Die currentValue wird erfolgreich aktualisiert. manuelle-schaltung_target_0.txt
Gibt es eine Möglichkeit die currentValue manuell (z.B. alle 10 Minuten) zu aktualisieren? Das Senden einer targetValue um das zu erzwingen klingt nach einem schlechtem Workaround?
Im Log sieht man definitiv, dass das Thermostat trotz Ansteuern des Stellmotors nicht immer Werte liefert. Heißt das, dass diese nur nicht durch den Adapter verarbeitet wurden oder heißt das, dass definitiv nichts gesendet wurde?
Support us
592
Online32.4k
Users81.4k
Topics1.3m
Posts