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

[_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.

[FalconSBG]

@AlCalzone
Hallo mir ist ein Problem mit dem Smart Implant von Fibaro aufgefallen. Ich habe zwei One wire Temperatursensoren angehängt die Werte werden auch korrekt übertragen nach dem Interview, aber dann nicht mehr aktualisiert. Wenn man erneut Interviewt werden die Werte aktualisiert und bleiben dann wieder gleich.

MfG Stefan

[AlCalzone]

@FalconSBG Schau mal bitte unter Verknüpfungen, ob dort Root-Endpoint eingestellt ist. Wenn ja, wechsle mal auf Root-Gerät und schaue ob sich die Situation verändert.

[FalconSBG]

@AlCalzone Habs umgestellt leider ändert sich an der Situation nichts. Werte werden erst bei einem neu interview geändert. Und dadurch wird auch wieder auf Root-Endpoint in Node 24 umgestellt.

[AlCalzone]

@FalconSBG Ist der denn richtig konfiguriert? Standardmäßig sind die nämlich aus:

[_nico]

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

1. ja, bin nur gerade mit einem etwas größeren Umbau beschäftigt

@AlCalzone Wie läufts bei dir? Bist du mit deinem Umbau durch?

Gruß Nico

[AlCalzone]

@_nico Ne, das wird noch etwas dauern...

:heavy_check_mark: Konzept für einfache Controller-Kommandos und Kommando-Warteschlange
:heavy_check_mark: Implementierung für einfache Controller-Kommandos in Testumgebung
:thinking_face: Konzept für Kommandos an andere Nodes
:x: Implementierung für Kommandos an andere Nodes
:x: Tests am realen System

Falls es jemand genauer wissen will: Ich baue die Kommando-Logik um auf eine (bzw. mehrere verknüpfte) State Machines, damit der Treiber zu jeder Zeit ein definiertes Verhalten hat, ohne dass ich irgendeine komplexe Interaktion übersehe und er einfach stecken bleibt.

Positiver Effekt: Ich kann automatische Tests für jede Interaktion schreiben - das ging vorher nicht.
Negativer Effekt: Das ist ein ziemlicher Brainfuck.... Hier mal ein Ausschnitt der aktuellen Planung:

[FalconSBG]

@AlCalzone Hallo ja war noch auf null gestellt und ich musste wieder auf Root Endpoint zurückschallten aber nun funktioniert es. Danke für die Hilfe.

[_nico]

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

@_nico Ne, das wird noch etwas dauern...

:heavy_check_mark: Konzept für einfache Controller-Kommandos und Kommando-Warteschlange
:heavy_check_mark: Implementierung für einfache Controller-Kommandos in Testumgebung
:thinking_face: Konzept für Kommandos an andere Nodes
:x: Implementierung für Kommandos an andere Nodes
:x: Tests am realen System

Falls es jemand genauer wissen will: Ich baue die Kommando-Logik um auf eine (bzw. mehrere verknüpfte) State Machines, damit der Treiber zu jeder Zeit ein definiertes Verhalten hat, ohne dass ich irgendeine komplexe Interaktion übersehe und er einfach stecken bleibt.

Positiver Effekt: Ich kann automatische Tests für jede Interaktion schreiben - das ging vorher nicht.
Negativer Effekt: Das ist ein ziemlicher Brainfuck.... Hier mal ein Ausschnitt der aktuellen Planung:

Oha, na dann, viel Erfolg und frohes Schaffen!