Test Adapter ZWave2 (v0.8.x)
-
@AlCalzone sorry, ich war gestern leider verhindert. Hier meine Cache Datei e64b94c3.json
-
@AlCalzone wenn ich den "targetvalue" = 80 setze, dann fährt das Rollo korrekt auf ca 80%. Der "current Value" wird leider nicht aktualisiert.
Auf dem Screenshot siehst du den "currentValue" = 19. Dieser Wert ist korrekt beim aller ersten Mal übernommen worden. Soll heißen, der Node 15 war das erste mal in deinem zwave2 Adapter sichtbar und es stand noch kein Wert in dem Datenpunkt "currentValue". Durch Bedienung des DP Down = true wurde das Rollo heruntergefahren. Down = false stoppte das Rollo bei 19%. Dieser Wert ist immer noch sichtbar. Danach gab es keinerlei Aktualisierung mehr. Das ist bei allen RollerShutter 3 Nodes der Fall gewesen. Das erste Mal klappt, danach nicht mehr. -
@taba_luga Danke schon mal für die Info.
Zu den fehlenden Datenpunkten: Ich schätze, da war das Interview nicht vollständig. Ich baue die Tage mal eine Möglichkeit ein, die Infos zu aktualisieren.
Das andere Problem hoffe ich zumindest teilweise mit der Supervision CC gelöst zu bekommen. Für Aktualisierung nach up/down fürchte ich muss Fibaro ein Firmware-Update liefern (wir werden es aber mal testen).
-
@taba_luga sagte in Test Adapter ZWave2 (v0.8.x):
wenn ich den "targetvalue" = 80 setze, dann fährt das Rollo korrekt auf ca 80%. Der "current Value" wird leider nicht aktualisiert.
Das gleiche Problem habe ich leider auch... aber @AlCalzone ist an der Sache mit dem RolllerShutter 3 wohl dran.
Aber alles braucht halt seine Zeit.Wie ich oben schon geschrieben habe
echt schade das Fibaro den RollerShutter 3 gegenüber dem 2er so verkompliziert hat und dann noch den 2er vom Markt genommen hat
Beim RollerShutter 2 war alles noch wunderbar in Ordnung und jetzt beim Nachfolger RollerShutter 3 nur noch Ärger...
Auch OpenZwave kämpft mit dem Ding rum -
@AlCalzone sagte in Test Adapter ZWave2 (v0.8.x):
Das andere Problem hoffe ich zumindest teilweise mit der Supervision CC gelöst zu bekommen. Für Aktualisierung nach up/down fürchte ich muss Fibaro ein Firmware-Update liefern (wir werden es aber mal testen).
Noch zur Info @AlCalzone zum RolllerShutter 3:
Ich habe festgestellt, wenn ich den targetValue Wert 2 x manuell eingebe, bei der zweiten Eingabe der currentValue Wert automatisch den targetValue Wert erhält - currentValue ist dann also mit dem TargetValue Wert identisch.
Wenn ich über einen Trigger den targetValue Wert 2 x setze (auch über eine Verzögerung) ändert sich currentValue aber nicht, nur bei händischer Eingabe bei targetVAlue im ioBroker.
-
@Rolf_KA Ja das liegt daran, dass der sofort nach dem Setzen seinen derzeitigen Status reportet - aber nicht mehr wenn der Zielstatus erreicht ist.
Beim zweiten Setzen ist der Status dann ja schon korrekt. -
Kleines Update an alle: Ich hab euch nicht vergessen - die Implementierung der Supervision CC geht voran. Allerdings erfordert die ein paar Änderungen im Kern, damit dieser Typ von Kommandoklassen korrekt behandelt wird.
Beim Testen hab ich dann allerdings zwei fette Bugs gefunden, die dafür sorgen können, dass die Kommunikation seitens des Controllers hängen bleibt (könnte auch @maloross Probleme mit den unvollständigen Geräten erklären).
Einen davon habe ich (hoffentlich) behoben, der andere wird die nächsten Tage angegangen.Danach gehts hoffentlich weiter mit dem eigentlichen Problem
-
@AlCalzone ich habe nochmal die Aussage von @Rolf_KA getestet, dass der "current value" sich beim zweiten mal eingeben des gleichen "target value" aktualisiert. Das ist bei mir nicht der Fall. Ich kann den "target value" setzen und das Rollo fährt auf den eingestellten Wert. Der "target value" wird allerdings nie bestätigt. Er bleibt immer rot und unbestätigt. Der "current value" aktualisiert sich bei mir nie, egal wie oft ich den gleichen "target Value" eingebe.
-
@AlCalzone sagte in Test Adapter ZWave2 (v0.8.x):
Kleines Update an alle: Ich hab euch nicht vergessen - die Implementierung der Supervision CC geht voran. Allerdings erfordert die ein paar Änderungen im Kern, damit dieser Typ von Kommandoklassen korrekt behandelt wird.
Beim Testen hab ich dann allerdings zwei fette Bugs gefunden, die dafür sorgen können, dass die Kommunikation seitens des Controllers hängen bleibt (könnte auch @maloross Probleme mit den unvollständigen Geräten erklären).
Einen davon habe ich (hoffentlich) behoben, der andere wird die nächsten Tage angegangen.
Danach gehts hoffentlich weiter mit dem eigentlichen Problem@AlCalzone - Keine Sorge, ich glaube an dich und deinem Z-Wave2 Adapter - mein Favorit
Wie schreibe ich immer, alles braucht seine Zeit
-
@AlCalzone ich habe mir gerade deine neue Version 0.8.2 installiert. Bei meinen Heizungsthermostaten kommt es zu Problemen. Sie gehen regelmäßig in den Status dead und sind nicht erreichbar.
Wenn ich vor Ort die Temperatur ändere, dann wachen sie auf. Dazu kommt, wenn sie im Stauts alive sind, kommt die Änderung des "stepoint_heating" an, wird aber auch nicht bestätigt.
Wenn sie im Status dead sind und später aufwachen, dann wird der Wert nicht mehr übernommen.
Bei den Thermostanten handelt es sich um Eurotronic Thermostate.
Falls notwendig, hier noch die Log Datei zwave-1691.log -
@taba_luga Kannst du mir bitte auch noch die Cache-Datei zeigen? Scheint als wurde die WakeUp CC bei denen nicht erkannt.
-
@taba_luga sagte in Test Adapter ZWave2 (v0.8.x):
@AlCalzone ich habe nochmal die Aussage von @Rolf_KA getestet, dass der "current value" sich beim zweiten mal eingeben des gleichen "target value" aktualisiert. Das ist bei mir nicht der Fall. Ich kann den "target value" setzen und das Rollo fährt auf den eingestellten Wert. Der "target value" wird allerdings nie bestätigt. Er bleibt immer rot und unbestätigt. Der "current value" aktualisiert sich bei mir nie, egal wie oft ich den gleichen "target Value" eingebe.
Komisch, wenn ich den targetValue Wert Händisch in ioBroker eingebe, wird dieser bei mir auch kurz mit grün bestätigt.
Gleichzeitig wird der currentValue Wert um +/- 1 geändert und bestätigt, aber eben nicht beim Ende der Rollladenfahrt...
aber daran arbeitet @AlCalzone ja - ich kann mir aber auch gut vorstellen, dass da einiges an Vorarbeit noch notwendig ist.Gebe ich danach den gleichen targetValue Wert nochmal ein, wird der currentValue Wert auf den tagetValue Wert gesetzt.
Bei mir wird da nichts in rot angezeigt.Das gleiche Verhalten ist übrigens auch bei OpenZwaver vorzufinden.
Werde heute auch bei intuitech.de (die bieten auch einen Firmware-Update Service an) nochmal Nachfragen, ob die Firmware Version 5.1 des RollerShutter 3 wirklich der letzte Stand ist.
Ich hatte in einem Forum etwas über eine Firmware Version 5.11 gelesen die das Problem mit der Positionierung beschreibt.
Das war aber vom Mai 2019 und auf meine RollerShutter 3 steht ein Herstelldatum vom 17.10.2019.
Ich gehe daher davon aus, dass die Version 5.1 auch der aktuelle Stand ist.
-
@AlCalzone hier die Cache Datei e64b94c3.json
-
@taba_luga Bestanden die Probleme schon mit der alten Version (wenn nein, welche war das?) oder sind die jetzt erst aufgetaucht?
Dem Log nach zu urteilen werden die Befehle zwar gesendet, es kommt aber keine Bestätigung von den Thermostaten beim Adapter an. Laut http://www.openzwave.com/knowledge-base/msgdropped (Abschnitt "FLiRS Compatibility Issues") könnte es an den benachbarten Nodes oder schlechtem Empfang liegen. Zumindest Node 30 hat keine direkte Verbindung zum Controller.
Hast du Möglichkeiten, Empfangsprobleme auszuschließen? Z.B. Controller näher an die Thermostate bringen? -
@AlCalzone die Thermostate sind in direkter Reichweite der Nodes 15, 16, 17 (Rollershutter3), sowie Node 04, 07 (Fibaro Dimmer 2) Sie hatten vorher (im alten Zwave Adapter) zuverlässiger funktioniert. In den Versionen vor 0.8.2 kann ich das nicht beurteilen, da war ich noch nicht so weit mit meinen Tests.
-
@taba_luga Kannst du mir dann mal einen Log (OZW_Log.txt) des alten Adapters zukommen lassen, damit ich etwaige Unterschiede in der Kommunikation suchen kann?
-
@AlCalzone hier das logfile. OZW_Log.txt
Bei den Thermostaten, die anscheinend direkt mit Node 1 kommunizieren, scheint es keine Auffälligkeiten zu geben. So zumindest die ersten Ergebnisse. (Node 20, 22, 28). -
@taba_luga Hab da was im OZW_Log gefunden (beachte die vorletzte Zeile):
2020-01-10 19:07:02.095 Info, Node030, Sending (Send) message (Callback ID=0x7d, Expected Reply=0x13) - ThermostatModeCmd_Set (Node=30): 0x01, 0x0a, 0x00, 0x13, 0x1e, 0x03, 0x40, 0x01, 0x00, 0x25, 0x7d, 0xe2 2020-01-10 19:07:02.095 Info, Node030, Encrypted Flag is 0 2020-01-10 19:07:02.134 Detail, Node030, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8 2020-01-10 19:07:02.134 Detail, Node030, ZW_SEND_DATA delivered to Z-Wave stack 2020-01-10 19:07:05.701 Detail, Node030, Received: 0x01, 0x07, 0x00, 0x13, 0x7d, 0x01, 0x01, 0x68, 0xfe 2020-01-10 19:07:05.701 Detail, Node030, ZW_SEND_DATA Request with callback ID 0x7d received (expected 0x7d) 2020-01-10 19:07:05.703 Info, Node030, WARNING: ZW_SEND_DATA failed. No ACK received - device may be asleep. 2020-01-10 19:07:05.703 Warning, Node030, WARNING: Device is not a sleeping node. 2020-01-10 19:07:05.703 Error, Node030, ERROR: node presumed dead 2020-01-10 19:07:05.703 Detail, Node030, Expected callbackId was received 2020-01-10 19:07:05.703 Detail, Node030, Expected reply was received 2020-01-10 19:07:05.703 Detail, Node030, Message transaction complete 2020-01-10 19:07:05.703 Detail, 2020-01-10 19:07:05.703 Detail, Node030, Removing current message 2020-01-10 19:07:05.703 Detail, Node030, Notification: Notification - Node Dead 2020-01-10 19:07:05.703 Error, Node030, ERROR: Dropping command because node is presumed dead 2020-01-10 19:07:05.703 Detail, Node030, Removing current messageDanach sendet auch der keine Nachrichten mehr an die #30. Der originale Adapter kommuniziert das nur nicht so aufdringlich
Hast du mal einen Netzwerk-Heal probiert?
-
@AlCalzone wie lange läuft denn der Netzwerk-Heal? Bei mir habe ich unverändert seit ca. 3h die Loading Spinner neben dem Status drehen.
-
@taba_luga In der Regel ein paar Minuten. Schlafende Geräte musst du aber manuell aufwecken.
