UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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! :+1:

[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

[AlCalzone]

FYI: Dass der alias für einen null-Wert 0 ist, ist ein Bug und wird im nächsten JS-Controller behoben.

[Chris_78]

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

FYI: Dass der alias für einen null-Wert 0 ist, ist ein Bug und wird im nächsten JS-Controller behoben.

Danke für die Info. Wieder was gelernt. ;-)

[Chris_78]

@AlCalzone

Ich hätte noch mal eine Frage bzgl. Alias-Werten. Bin mir nicht ganz sicher, ob die Frage zum Adapter gehört oder
eher ein allgemeines Alias Topic ist...

Ich habe mir u.a. für die Z-Wave Geräte Alias-Punkte angelegt:
z.B.

{
  "from": "system.adapter.javascript.0",
  "user": "system.user.admin",
  "ts": 1592986261338,
  "common": {
    "name": "Buero Schalter Licht",
    "role": "variable",
    "desc": "per Script erstellt",
    "type": "number",
    "write": true,
    "read": true,
    "alias": {
      "id": {
        "read": "zwave2.0.Node_004.Multilevel_Switch.currentValue",
        "write": "zwave2.0.Node_004.Multilevel_Switch.targetValue"
      }
    }
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "alias.0.Buero.Licht",
  "type": "state"
}

Das ganze funktioniert soweit gut. Einziges Problem ist, falls ich ioBroker oder den Adapter neu starte sind die Alias-Datenpunkte nicht mehr
befüllt (somit passen die angezeigten Vis-Werte/Statis natürlich nicht mehr). Erst wenn ich den jeweiligen targetValue nutze wird der Wert wieder im Alias
korrekt angezeigt.
Aktuell behelfe ich mir mit einem Skript, dass ich nach Neustart einmal ausführe
(setzt vom jeweiligen Datenpunkt den currentValue in den targetValue):
z.B.

Danach sind die Alias-Werte korrekt "befüllt".
Kann man die Alias-Punkte evtl. optimieren/korrigieren? Allerdings besteht das Problem nur mit den ZWave Alias-Werten.
Die Alias-Werte von meinen Shellies (per Mosquitto angebunden) haben diese Problematik nicht. Diese werden initial sofort befüllt.

Kann man evtl. etwas am Adapter machen? Oder gibt es bereits eine Möglichkeit?

[AlCalzone]

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

Kann man evtl. etwas am Adapter machen? Oder gibt es bereits eine Möglichkeit?

Siehe meine Diskussion mit Nico. Ich überlege, einen leeren targetValue automatisch auf den currentValue zu setzen. Damit dürfte das Problem weg sein.