basic.stateswitch wechselt visualisierten Zustand obwohl Aktor gesperrt

[simon2k]

Hallo,
ich habe eine schaltbare Steckdose in smartvisu über das basic.stateswitch-Widget visulisiert:

{{ basic.stateswitch('', 'eg.buero.verbraucher.steckdose.schalten', 'icon', [0,1], ['it_pc.svg','it_pc.svg']) }}

Das zugehörige Item ist folgendermaßen angelegt:

eg:
    buero:
        verbraucher:
            steckdose:
                schalten:
                    type: bool  
                    visu_acl: rw
                    knx_dpt: 1
                    knx_listen: 3/1/110
                    knx_send: 3/0/110
                    knx_init: 3/1/110​

Im Normalzustand bildet das Widget immer den Status des Schaltaktors ab. Alles ok.
Sperre ich allerdings den Aktor, wird auf 3/0/110 vom Aktor keine Anwort zurückgesendet!
So wird deutlich, dass der visualisierte Zustand nicht aus 3/1/110 kommt, sondern mit dem "Sollwert" 3/0/110 in der Visu wechselt! Auch der Wert aus/ein auf 3/0/110 toggelt als ob 3/0/110 direkt rückgekoppelt wird.

Wie muss ich das Item anlegen damit immer der Status des Aktors (3/1/110) angezeigt wird?
Die Lösung ist bestimmt nicht kompliziert!

Vielen Dank für die Hilfe!

[wvhn]

Das item ist richtig angelegt. Das Problem ist, dass der smarthomeNG-Treiber von smartVISU das item nicht nur an smarthomeNG sendet, sondern auch gleich den internen Wertespeicher von smartVISU aktualisiert. Das kannst Du ändern, indem Du in ./drivers/smarthomeNG.js die Zeile 58 auskommentierst:

    write: function (item, val) {
        io.send({'cmd': 'item', 'id': item, 'val': val});
      // widget.update(item, val);
    },
​

Dann sollte der Treiber darauf warten, dass das item seitens smarthomeNG aktualisiert wird.

Für Rückmeldung, ob das klappt, wäre ich dankbar.

Gruß
Wolfram

[stoepf]

Ich hab das selbe Problem und hab deinen Vorschlag gerade ausprobiert. Funktioniert auch teilweise.
Zusätzliche musste ich

eval: value if not sh..Sperre() else None

in das SmarthomeNG-Item einfügen.
Das Item in SmarthomeNG hat sonst den falschen Zustand und meldet den falschen Zustand zurück.

Gruß Stefan

[wvhn]

Moin Stefan,

Danke für die Rückmeldung. „Funktioniert teilweise“ ist natürlich nicht der Anspruch für ein nächstes Release. Kannst Du eingrenzen, unter welchen Bedingungen es nicht funktioniert? Oder ist die eval-Zeile schon die vollständige Lösung?

Gruß
Wolfram

[bmx]

Wäre es nicht besser das Widget zu erweitern um bei gesperrtem Widget den Switch auch als gesperrt darzustellen?

[stoepf]

Hallo Wolfram,

Kannst Du eingrenzen, unter welchen Bedingungen es nicht funktioniert?

Sorry hier etwas detaillierter:
Nur mit deiner Änderung:

[io.smarthomeng] receiving data:  {"cmd": "item", "items": [["Licht", true]]}
[io.smarthomeng] sending data:  {"cmd":"item","id":"Licht","val":"1"}

In SmarthomeNG ist das Item trotz Sperre True.

Oder ist die eval-Zeile schon die vollständige Lösung?

Wenn das Eval in SmarthomeNG eingefügt ist:

[io.smarthomeng] sending data:  {"cmd":"item","id":"Licht","val":"1"}​​

Das Item bleibt auf False und sendet damit keine Antwort.

Die Änderung wäre meiner Meinung nach nicht verkehrt. Außer dadurch wird irgendwas anderes kaputt gemacht.

Der Vorschlag von bmx wäre natürlich die Goldlösung.

[simon2k]

Danke für den Tip!
Wundert mich ehrlich gesagt, dass ich der Erste bin, dem das auffiel.
Ich habe den fix getestet, aber bei mir wechselt das Widget jedoch trotzdem den Status. Scheint keine Wirkung zu haben.
Ich vermute auch, dass das Problem tiefer liegen könnte, als nur in der smartvisu.
Ich bin zwar noch nicht ganz durchgestiegen, wie die verschiedenen Schichten bis zum Bus zusammenspielen, aber knxd-webif wird auch der Sollstatus als aktueller "Wert" abgebildet. Würde das das Unterbinden des Widget-Updates die Lösung sein, hätten wir eine Inkonsistenz zwischen dem Wert in knxd und der Darstellung in der Visu. Das könnte nicht absehbare Auswirkungen haben. (z.B. in einer smhNG-Logik)

Aber Saubersten wäre wirklich das aktive Áuswerten des sperren-KOs und wenn gesperrt, das Unterbinden von

 io.send({'cmd': 'item', 'id': item, 'val': val});

OnTop die Visu des gesperrten Zustands über das "basic.stateswitch"-Widget wäre natürlich deluxe!

[wvhn]

Der Fix sorgt dafür, dass smartVISU nur noch das anzeigt, was es von shNG über den Websocket gemeldet bekommt. Das ist glaube ich kein Fehler. Ich kann das auch als Option in der Konfiguration anlegen.

Die tiefer gehende Frage ist, wie shNG die items behandelt. Wenn ich per Visu oder im Admin Interface auf ein item schreibe, nimmt dieses den Wert sofort an, oder wartet es auf Rückmeldung vom Bus (wenn sich die Adressen für knx_send und knx_listen unterscheiden)? Eigentlich sollte das Warten auf die Rückmeldung der Normalfall sein, wenn wir erwarten, dass die items immer die Zustände der Aktoren repräsentieren.

Die Deluxe-Version könnt Ihr heute schon erzeugen, indem Ihr ein item für den Sperrzustand bereit stellt und den Stateswitch mit einem status.collapse versteckt, wenn die Sperrung aktiv ist.

Gruß
Wolfram

[stoepf]

Danke für die Idee mit dem collapse.
Hier mein Codeschnipsel:

{{ status.collapse('locked', 'Sperre', '1') }}
<span data-bind="locked">
{{ basic.stateswitch('', 'Licht', 'icon', '', 'light_light.svg') }}
</span>

{{ status.collapse('unlocked', 'Sperre', '0') }}
<span data-bind="unlocked">
{{ basic.symbol('', 'Licht', '', 'light_light.svg', '0', '', 'icon0') }}​
{{ basic.symbol('', 'Licht', '', 'light_light.svg', '1', '', 'icon1') }}​
</span>​

Für mich wäre das so OK.

Gruß Stefan

[simon2k]

Vielen Dank Wolfram für den Tip mit dem collapse!
Werde das dann auch so lösen.
Wobei das Beispiel von stopef schon viel Text für eine "einfache" Funktion ist.
Wenn ich jetzt denke, dass ich das für jedes Item so anlegen sollte, dann bläht das die ganze Sache schon ein wenig auf!

Wie oben bereits beschrieben, der angezeigte Wert unter "Wert" im WebIf von knxd ändert sich mit dem Sollwert von knx_send! Ich geh mal davon aus, dass dies der echte, aktuelle interne Wert von smhNG ist. Dieser wird dann wahrscheinlich auch in Logiken weiterverarbeitet?
Ohne es zu testen: Wenn ich z.B. in Smartvisu dann einen Sollwert auf True setze, der auf dem Aktor aber gesperrt ist, triggert die Logik mit True, obwohl der Istwert sich nicht ändert....Jetzt könnte man sich natürlich darüber streiten, ob dann die Logik auf den Sollwert in diesem Fall sinvoll ist. :-)

Nur zum Verständnis: Ich habe versucht das Update auf meinem PI unter /var/www/html/diver/io_smarthomeng.js durch Auskommentieren zu verhindern. Hat aber nicht gewirkt. Neustart hatte ich natürlich gemacht. Bin ich in der falschen Datei gewesen?

[wvhn]

Die Datei ist die richtige. Neustart musst Du für smartVISU nicht machen, aber den smartVISU-Cache löschen und die Seite neu laden.
Der Fix hilft allerdings nicht, wenn in shNG nicht verhindert wird, dass ein gesperrtes item dort einen neuen Wert annimmt. Das erledigt der eval-Ausdruck von stoepf. smartVISU sendet ja weiterhin einen Schaltbefehl, aktualisiert die Anzeige aber erst mit Antwort des Backends und nicht mehr über den internen Kurzschluss.

Gruß
Wolfram

[wvhn]

Der smartVISU Fix ist jetzt als Option im Develop. Als Default ist die Aktualisierung durch das Backend voreingestellt.

Gruß
Wolfram