Test Adapter Z-Wave 2 (v1.4.x / 1.5.0 / 1.6.x)

[AlCalzone]

@Chris_78 Danke für die Logs - schaue ich mir an. Das ist äußerst seltsam...

[_nico]

@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x):

@AlCalzone

Kurze Frage nochmal zum Thema "Interview".
Sollte ich Batteriebetriebene Geräte manuell "Erneut interviewen" und "Aufwecken"? Oder passiert das nach einem Tag / einer Woche automatisch, dass die Geräte alle verfügbaren DPs melden?

@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x):

@_nico Wenn neue CCs hinzugefügt werden, die deine Geräte unterstützen, dann musst du sie neu interviewen. Diese Abfrage passiert nämlich nur 1x. Ansonsten ist das eigentlich nur nötig, wenn sich Fehler in den gespeicherten Infos eingeschlichen haben.

Das Interview von batteriebetriebenen Geräten kannst du beschleunigen, indem du sie manuell aufweckst. Ansonsten schreitet das Interview immer ein wenig voran, wenn sie aufwachen.

Ich habe, weil ich noch mit meinen Aliases beschäftigt bin, ein paar Mal ioBroker neugestartet. Dabei ist mir aufgefallen, dass bei jedem Neustart / Start des Z-Wave 2 Adapters ein Interview versucht wird. Das ist so richtig? Oder läuft bei mir irgendwas falsch?

2020-07-01 10:46:10.074  - info: zwave2.0 (6181) Node 16: interview completed, all values are updated
2020-07-01 10:46:16.025  - info: zwave2.0 (6181) Node 17: interview completed, all values are updated
2020-07-01 10:46:16.717  - info: zwave2.0 (6181) Node 18: ready to use
2020-07-01 10:46:16.764  - info: zwave2.0 (6181) Node 18: is now awake
2020-07-01 10:46:18.102  - info: zwave2.0 (6181) Node 19: ready to use
2020-07-01 10:46:18.121  - info: zwave2.0 (6181) Node 19: is now awake
2020-07-01 10:46:22.503  - info: zwave2.0 (6181) Node 22: ready to use
2020-07-01 10:46:22.548  - info: zwave2.0 (6181) Node 22: is now awake
2020-07-01 10:46:22.845  - info: zwave2.0 (6181) Node 23: ready to use
2020-07-01 10:46:22.863  - info: zwave2.0 (6181) Node 23: is now awake
2020-07-01 10:47:06.908  - info: zwave2.0 (6181) Node 22: interview completed, all values are updated
2020-07-01 10:47:07.321  - info: zwave2.0 (6181) Node 23: interview completed, all values are updated
2020-07-01 10:47:07.499  - info: zwave2.0 (6181) Node 24: ready to use
2020-07-01 10:47:07.553  - info: zwave2.0 (6181) Node 24: is now awake
2020-07-01 10:47:10.760  - info: zwave2.0 (6181) Node 25: ready to use
2020-07-01 10:47:10.770  - info: zwave2.0 (6181) Node 25: is now awake
2020-07-01 10:47:54.187  - info: zwave2.0 (6181) Node 24: interview completed, all values are updated
2020-07-01 10:47:56.091  - info: zwave2.0 (6181) Node 25: interview completed, all values are updated
2020-07-01 10:47:56.466  - info: zwave2.0 (6181) Node 26: ready to use
2020-07-01 10:47:56.473  - info: zwave2.0 (6181) Node 26: is now awake
2020-07-01 10:48:13.731  - info: zwave2.0 (6181) Node 27: ready to use
2020-07-01 10:48:13.740  - info: zwave2.0 (6181) Node 27: is now awake
2020-07-01 10:48:39.083  - info: zwave2.0 (6181) Node 26: interview completed, all values are updated
2020-07-01 10:48:53.262  - info: zwave2.0 (6181) Node 28: ready to use
2020-07-01 10:48:53.317  - info: zwave2.0 (6181) Node 28: is now awake
2020-07-01 10:48:53.342  - info: zwave2.0 (6181) Node 29: ready to use
2020-07-01 10:48:53.427  - info: zwave2.0 (6181) Node 29: is now awake
2020-07-01 10:48:57.452  - info: zwave2.0 (6181) Node 27: interview completed, all values are updated
2020-07-01 10:49:36.330  - info: zwave2.0 (6181) Node 28: interview completed, all values are updated
2020-07-01 10:49:36.487  - info: zwave2.0 (6181) Node 29: interview completed, all values are updated
2020-07-01 10:49:36.669  - info: zwave2.0 (6181) Node 32: ready to use
2020-07-01 10:49:36.681  - info: zwave2.0 (6181) Node 32: is now awake
2020-07-01 10:49:39.261  - info: zwave2.0 (6181) Node 37: ready to use
2020-07-01 10:49:39.309  - info: zwave2.0 (6181) Node 37: is now awake
2020-07-01 10:49:46.138  - info: zwave2.0 (6181) Node 32: interview completed, all values are updated

Gruß Nico

PS: Habe gestern den Cache geleert, alle Nodes danach erfolgreich und erneut interviewed.

[Chris_78]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.4.x):

@Chris_78 Danke für die Logs - schaue ich mir an. Das ist äußerst seltsam...

Soll oder kann ich noch etwas testen? Cache löschen, Netzwerk heilen,... ?

[AlCalzone]

@_nico Das ist richtig so. Beim ersten Mal wird ein vollständiges Interview durchgeführt (alle Fähigkeiten etc. werden abgeefragt). Wenn das einmal durch war, wird ein partielles Interview gemacht. Dabei werden nur noch die möglicherweise aktualisierten Werte abgefragt (z.B. Schalter-Status, etc.)

@Chris_78 nein, ich schaue mir deine Daten später an und melde mich.

[Chris_78]

@_nico
Ist bei mir auch so. Bin bisher davon ausgegangen das es so korrekt ist.

@AlCalzone
Nur so ein Gedanke...
Normalerweise ändert sich an der Konfiguration bzw. den Geräten ja relativ selten etwas.
Wäre es möglich beim Start einfach die vorhande Konfig/Cache einzulesen ohne neu zu interviewen?
Falls evtl. Änderungen vorhanden sind, könnte man das (neu) interviewen über einen passenden Schalter in den Adapter-Einstellungen
umsetzen.
Keine Ahnung ob das so möglich ist.

[AlCalzone]

@Chris_78 sagte in Test Adapter Z-Wave 2 (v1.4.x):

Wäre es möglich beim Start einfach die vorhande Konfig/Cache einzulesen ohne neu zu interviewen?

Das ist doch schon so. Einige Dinge müssen aber neu abgefragt werden, weil sie sich geändert haben könnten - z.B. Licht, Rollo, Temperaturen, Sensorwerte, ...

Grundsätzlich ist nach der ersten Kontaktaufnahme mit einem bereits interviewten Gerät nach einem Neustart sofort die Nutzung möglich (ready). Allerdings werden die Nachrichten noch nicht höher priorisiert als das Interview, weshalb die Reaktionen anfangs etwas träge sind.

[_nico]

Hi @AlCalzone es geht mir nochmal um den DP TargetValue bei den Shuttern - egal ob Fibaro, Qubino oder Devolo.

Nach jedem Neustart des Z-Wave Adapters wird das TargetValue, nach ein paar Sekunden, auf 0 gesetzt.

Das hat zur Folge, dass die Anzeige in Apple Home (über YAHKA) spinnt, da man hier CurrentValue und TargetValue getrennt von einander verknüpft. HomeKit denkt, dadurch, dass das TargetValue auf 0 gesetzt wurde, CurrentValue ist 99 und der Rollladen sich jetzt eigentlich schließen müsste.

Entweder ich baue mir ein Skript, welches 60 Sekunden nach Adapter start, das TargetValue je Rollladen auf den Wert des CurrentValue anpasst oder du setzt nach dem "Interview" / "Init" das TargetValue auf den Wert des CurrentValue.

Was ist deine Meinung dazu?

Gruß Nico

[AlCalzone]

@Chris_78 sagte in Test Adapter Z-Wave 2 (v1.4.x):

Kannst du die Konfiguration so ändern, dass die Gruppe 1 angepasst wird? Gruppe 11 kann somit entfernt werden. Falls dies möglich ist.

Ich habe das Log (25606) mal testweise für Node 004 interpretiert. Der Node berichtet, dass sowohl Gruppe 1 als auch 11 als Root-Gerät zugeordnet sind. Steht auch so in der Cache-Datei.
Das deckt sich aber nicht mit deinen Screenshots. Hast du denn lange genug gewartet?
Gruppe 11 habe ich ergänzt, weil meines Wissens die Temperatur-Reports nicht über Gruppe 1 kommen.

Die Rollos sind schon entsprechend konfiguriert - der Adapter muss hier aber wohl die bestehende Verknüpfung löschen, bevor er die andere hinzufügen kann.

Bei Node 14 hakt es immer noch beim Interview - seltsamerweise läuft das 2x parallel und beißt sich. Versuchs vielleicht nochmal ohne dabei einzugreifen.

[AlCalzone]

@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x):

Nach jedem Neustart des Z-Wave Adapters wird das TargetValue, nach ein paar Sekunden, auf 0 gesetzt.

Kannst du mir das mal in einem Log abbilden? Kommt mir komisch vor.

[_nico]

@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x):

@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x):

Nach jedem Neustart des Z-Wave Adapters wird das TargetValue, nach ein paar Sekunden, auf 0 gesetzt.

Kannst du mir das mal in einem Log abbilden? Kommt mir komisch vor.

Hi @AlCalzone, klar - kein Problem. Die Log ist im Anhang. Nur nochmal um Missverständnisse vorzubeugen.

---

Es passiert, nachdem das Node, nach dem Neustart des Adapters, interviewed wird. Der Rollladen fährt aber an keine neue Position, er bleibt wie und wo er ist. Im Alias-DP wird der Wert auf 0 geändert, der DP "targetValue" ist einfach "leer" (null o.ä.) - was nicht gehen dürfte, da der DP eine "number" ist mit "min 0" und "max 99".

Devolo Shutter: 005, 017, 018, 019, 022, 023, 024, 025, 026, 027, 028, 029, 037

---

Bei der Gelegenheit kannst du dir mal noch das Node 054 anschauen, es ist ein Fibaro Wall Plug E/F. Leider habe ich nur einen, kann also nicht vergleichen. Es geht um den Verbrauch, hier ist der DP Meter.value_w_consumed recht statisch - ändert sich nur sehr selten. Was komisch ist! Dafür gibt es den DP Multilevel_Sensor.power welchen den Verbrauch anzeigt. Ich glaube, somit ist auch Meter.value_kWh_Consumed falsch. Soll das so? Kann man das ändern?

Bei meinen Devolo Steckdosen oder den Fibaro Double Switches (Unterputz) ist es "ordentlich" - Meter.value_w_consumed und Meter.value_kWh_Consumed.

---

Gruß Nico

zwave-10578.log

[Chris_78]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.4.x):

@Chris_78 sagte in Test Adapter Z-Wave 2 (v1.4.x):

Kannst du die Konfiguration so ändern, dass die Gruppe 1 angepasst wird? Gruppe 11 kann somit entfernt werden. Falls dies möglich ist.

Ich habe das Log (25606) mal testweise für Node 004 interpretiert. Der Node berichtet, dass sowohl Gruppe 1 als auch 11 als Root-Gerät zugeordnet sind. Steht auch so in der Cache-Datei.
Das deckt sich aber nicht mit deinen Screenshots. Hast du denn lange genug gewartet?

Ich habe alle Interviews abgewartet. Mittlerweile sind auch einige Adapter-Neustarts durchgeführt worden. Da ich noch nicht alle Geräte geändert habe sind noch Qubino Schalter
mit der Gruppe 1 - Root Endpoint vorhanden (z.B. Node 17; 24; 29).
Aber da die Änderung zu Root-Gerät nach einem Neustart erhalten bleibt, pass das aus meiner Sicht. Danke noch mal für die Anpassung.

Gruppe 11 habe ich ergänzt, weil meines Wissens die Temperatur-Reports nicht über Gruppe 1 kommen.

Gut zu Wissen. Das werde ich bei Gelegenheit mal Testen.

Die Rollos sind schon entsprechend konfiguriert - der Adapter muss hier aber wohl die bestehende Verknüpfung löschen, bevor er die andere hinzufügen kann.

Da alle Rollos nur eine Root-Endpunkt Verknüpfung hatten, bin ich davon ausgegangen, dass du diese nicht mit angepasst hattest. Die Root-Gerät Anapssung bleibt aber
auch hier konstant bestehen. Eigentlich passt jetzt alles.

Bei Node 14 hakt es immer noch beim Interview - seltsamerweise läuft das 2x parallel und beißt sich. Versuchs vielleicht nochmal ohne dabei einzugreifen.

Eigentlich habe ich nicht groß eingegriffen. Hatte zwischendurch nur mal ein "Erneut interviewen" getriggert. Ich werde Node 14 wohl durch einen Shelly ersetzen.
Die Handhabung ist sowieso etwas problematisch. Node 14 ist Unterputz verbaut, um 2 Steckdosen zu steuern. Zum inkludieren oder exkludieren muss aber ein
Schalter/Taster angeschlossen werden. In der Richtung sind die Shellies wohl etwas einfacher zu handhaben

Noch eine andere Frage:
Wie sicher ist die neue Firmware Update Funktion? Beim Aoetec 4-fach Schalter wird die Funktion angeboten. Hast du evtl. Links um Updates zu beziehen?

[AlCalzone]

@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x):

Im Alias-DP wird der Wert auf 0 geändert, der DP "targetValue" ist einfach "leer" (null o.ä.) - was nicht gehen dürfte

Doch, das macht Sinn. Vielleicht ein Bug im Alias? leer heißt einfach es gibt keinen Wert. Dann darf allerdings auch kein 0 im Alias auftauchen.

Wie sicher ist die neue Firmware Update Funktion?

Ich hab es zigfach getestet, ohne Probleme. Allerdings habe ich auch sicher gestellt, dass ich die richtige Firmware auswähle. Es kann durchaus sein, dass das Gerät nach dem Upload einer falschen Firmware Schrott ist - das wollte ich nicht testen.
Der Standard gibt hier zwar Möglichkeiten zur Prüfung, dass man keine falsche Firmware hochlädt, allerdings enthalten die Update-Dateien diese Informationen in der Regel nicht.

Für meine WallMote hab ich beim Support nachgefragt, dass er auf einer alten Firmware sei, ich aber kein Update finden kann. In 2-3 Tagen hatte ich dann die EXE-Datei zum Update erhalten, die du direkt dem Adapter füttern kannst. Manche findest du auch direkt auf der Seite von Aeotec.

Hatte zwischendurch nur mal ein "Erneut interviewen" getriggert.

Und damit für die Überschneidung gesorgt

[_nico]

@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x):

@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x):

Im Alias-DP wird der Wert auf 0 geändert, der DP "targetValue" ist einfach "leer" (null o.ä.) - was nicht gehen dürfte

Doch, das macht Sinn. Vielleicht ein Bug im Alias? leer heißt einfach es gibt keinen Wert. Dann darf allerdings auch kein 0 im Alias auftauchen.

Hi @AlCalzone, ja es scheint am Alias zu liegen, dass er aus "null" "0" macht. Finde nicht, dass es ein Bug ist. Es ist halt "null", er erwartet eine Zahl zwischen 0 und 99.

Aber egal, auch wenn ich die DPs direkt in YAHKA (HomeKit) verknüpfe, ohne Alias, bleibt das Problem bestehen - auch wenn es "null" ist - nur das nicht "öffnen" sondern "schließen" da steht.

Wenn du das Verhalten vom Adapter so korrekt findest, überlege ich mal, wie ich es bei mir lösen könnte.

[AlCalzone]

@_nico Ich muss da nochmal drüber nachdenken. Faktisch gibt es beim Start keinen Zielwert, außer das Gerät ist zufällig gerade in Bewegung. Könnte Sinn machen es in diesem Fall auf currentValue zu setzen, aber über die Implikationen muss ich mir noch klar werden.

[_nico]

@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x):

@_nico Ich muss da nochmal drüber nachdenken. Faktisch gibt es beim Start keinen Zielwert, außer das Gerät ist zufällig gerade in Bewegung. Könnte Sinn machen es in diesem Fall auf currentValue zu setzen, aber über die Implikationen muss ich mir noch klar werden.

Ja, sehe ich auch so - bin ähnlich im Zwiespalt, was das korrekt Verhalten wäre.
Ich denke, ich könnte das Problem über den read Parameter in der Alias-Funktion lösen.

UPDATE: Leider geht es über den Alias, ohne Skript, nicht so, wie ich es gerne hätte. Also, wenn du es Implementierst, wenn es Sinn macht, wäre es cool!

[Chris_78]

@_nico said in Test Adapter Z-Wave 2 (v1.4.x):

@AlCalzone sagte in Test Adapter Z-Wave 2 (v1.4.x):

@_nico sagte in Test Adapter Z-Wave 2 (v1.4.x):

Im Alias-DP wird der Wert auf 0 geändert, der DP "targetValue" ist einfach "leer" (null o.ä.) - was nicht gehen dürfte

Doch, das macht Sinn. Vielleicht ein Bug im Alias? leer heißt einfach es gibt keinen Wert. Dann darf allerdings auch kein 0 im Alias auftauchen.

Hi @AlCalzone, ja es scheint am Alias zu liegen, dass er aus "null" "0" macht. Finde nicht, dass es ein Bug ist. Es ist halt "null", er erwartet eine Zahl zwischen 0 und 99.

Aus meiner Sicht verhält sich ioBroker hier richtig. Das ganze liegt an dem Number/Zahlen Format. Ich bin mir zwar nicht ganz sicher wie es in Javascript gehandhabt wird, vermute aber
das es ähnlich/gleich sein wird. Ich selber programmiere in Java (obwohl ich die letzten Jahre etwas "eingerostet" bin. ).
In Java gibt es kein "null" für Zahlenwerte. Null wird "intern" in eine "0" konvertiert. Ebenso gibt es auch keine führenden Nullen bei Zahlenwerte. Diese werden automatisch
entfernt.

Aber egal, auch wenn ich die DPs direkt in YAHKA (HomeKit) verknüpfe, ohne Alias, bleibt das Problem bestehen - auch wenn es "null" ist - nur das nicht "öffnen" sondern "schließen" da steht.

Wenn du das Verhalten vom Adapter so korrekt findest, überlege ich mal, wie ich es bei mir lösen könnte.

[AlCalzone]

@Chris_78 sagte in Test Adapter Z-Wave 2 (v1.4.x):

Aus meiner Sicht verhält sich ioBroker hier richtig

Nein das ist inkonsistent. Normale Datenpunkte haben die bewusste Möglichkeit, keinen Wert (d.h. null) zu haben. Dass es in Aliassen nicht geht, ist meiner Meinung nach ein Bug.
Java kennt auch nullable Datentypen (ähnlich wie C#): https://stackoverflow.com/questions/14321175/how-to-write-nullable-int-in-java

[Chris_78]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.4.x):

@Chris_78 sagte in Test Adapter Z-Wave 2 (v1.4.x):

Aus meiner Sicht verhält sich ioBroker hier richtig

Nein das ist inkonsistent. Normale Datenpunkte haben die bewusste Möglichkeit, keinen Wert (d.h. null) zu haben. Dass es in Aliassen nicht geht, ist meiner Meinung nach ein Bug.
Java kennt auch nullable Datentypen (ähnlich wie C#): https://stackoverflow.com/questions/14321175/how-to-write-nullable-int-in-java

Die Möglichkeit beim initieren besteht unter gewissen Umständen. Meines Wissens kann der Null Wert aber nicht aus einem Zahlentyp gelesen werden. Die Aliassen sind ja "Kopien" bzw.
lesen die Werte ja aus den verknüpften Datenpunkten. Beim Auslesen des originalen Datenpunkt müsste das "Null" zur "0" (im Alias Datenpunkt) werden.
Aber wie gesagt ich bin in der Richtung schon ein wenig eingerostet

[AlCalzone]

@Chris_78 sagte in Test Adapter Z-Wave 2 (v1.4.x):

Meines Wissens kann der Null Wert aber nicht aus einem Zahlentyp gelesen werden.

Doch! Probiere es einfach mal in nem Skript aus: getState("dp.mit.nullwert").val ist dann === null.

[_nico]

@AlCalzone

Da ich sowieso irgendwie noch die manuelle Steuerung am Schalter abfangen musste, damit sich die TargetPosition für HomeKit anpasst - damit der richtige Status angezeigt wird - fängt das Skript jetzt auch gleich noch die Interviews der Shutter ab und setzt die TargetPosition, wenn kein Stromverbrauch, auf den Wert der CurrentPosition.

Das Blockly-Skript ist ein ziemlicher Brain-Fuck geworden - da ich nicht für jeden, der 13 Shutter, ein eigenes Skript schreiben wollten! Trotz alledem, wollte ich es abschließend hier noch posten:

• Aliases, ordentlich sortiert und identisch - wichtig sind für das Skript PositionCurrent, PositionTarget und ConsumptionCurrent:
  

• Aufzählung des Aliases CurrentPosition der Rollläden
  

• Blockly-Skript
  blockly-rolllaeden-brainfuck.txt

Gruß Nico