Visu-Schnittstelle

[l0wside]

Hallo zusammen,

angeregt von Will habe ich meine eigene Visu gestrickt, die nach etwas händischer Anpassung auch mit sh.py 0.9 noch zusammen läuft. Allerdings muss ich im Moment bei einer Umschaltung die neuen Werte als gegeben annehmen (d.h. bei ausgeschalteter Leuchte und Touch-Event ein "ein" an sh.py absetzen und das Icon auf "an" setzen). Das kann zu Inkonsistenzen führen (z.B. habe ich nicht abschaltbare Treppenhauslichter).

Chrome liefert auf der Netzwerkschnittstelle Folgendes:
Client -> Server {"cmd":"item","id":"keller.werkstatt.leuchten.wand ","val":"0"}
Server -> Client {"items":[["keller.leuchten",false]],"cmd":"item"}
Client -> Server {"cmd":"item","id":"keller.werkstatt.leuchten.wand ","val":"1"}
Server -> Client {"items":[["keller.leuchten",true]],"cmd":"item"}

keller.leuchten ist ein eigenes Item, das per Eval geändert wird, wenn sich keller.werkstatt.leuchten.wand ändert. Die Kommunikation funktioniert also prinzipiell wunderbar.

Lässt sich das Visu-Interface dazu überreden, nach dem Setzen eines Werts von der Visu aus den tatsächlichen Wert zurückzuliefern? Dann erledigt sich das Thema Konsistenz von selbst.

Max

[callidomus]

Hi Max,

Lässt sich das Visu-Interface dazu überreden, nach dem Setzen eines Werts von der Visu aus den tatsächlichen Wert zurückzuliefern? Dann erledigt sich das Thema Konsistenz von selbst.

abgesehen von dem Client der die Änderung des Items veranlasst hat, erhält jeder Client die Updates übermittelt. Wenn Du das verhalten ändern möchtest, so müsstes Du in im Visu-Plugin in der Methode update (bei mir Zeile 265) die Abfrage: "if self.addr != source:" entfernen.

Ich habe das eingebaut, da es Probleme mit dem Slider gab. SH.py liefert 'alte' Werte an den aktiven Client und die Werte hüpfen hin und her.

Bis bald

Marcus

[l0wside]

Wenn Du das verhalten ändern möchtest, so müsstes Du in im Visu-Plugin in der Methode update (bei mir Zeile 265) die Abfrage: "if self.addr != source:" entfernen.

Hallo Marcus,

sorry. Das Problem liegt wohl tiefer. Die Änderung am Visu-Plugin hat funktioniert, aber nicht das gewünschte Ergebnis erzielt. Der gleiche Effekt ergibt sich mit dem CLI.

Problem anhand des Items:

[keller]
    [[flur]]
        [[[leuchten]]]
            [[[[wand]]]]
                type = bool
                knx_dpt = 1
                knx_send = 1/0/11
                knx_listen = 1/0/111
                knx_init = 1/0/111
                visu = yes
                name = Leuchte Flur

Telnet-Session mit dem CLI:

> ls keller.flur.leuchten
Items:
======
keller.flur.leuchten
keller.flur.leuchten.wand = False
> up keller.flur.leuchten.wand = true
[B]Licht geht an[/B]
> ls keller.flur.leuchten
Items:
======
keller.flur.leuchten
keller.flur.leuchten.wand = True
> up keller.flur.leuchten.wand = false
[B]Licht bleibt an[/B]
> ls keller.flur.leuchten
Items:
======
keller.flur.leuchten
keller.flur.leuchten.wand = False

Status auf dem Bus:

# groupreadresponse local:/tmp/eib 1/0/111
Send request
Read from 0.0.0
Response from 1.1.202: 01

Hier ist sh.py inkonsistent zum tatsächlichen Status - die Leuchte ist an, was ein explizites Abfragen auf dem Bus auch so bestätigt, aber sh.py nimmt das letzte bekannte Ereignis - und das ist das (wenn auch erfolglose) Kommando "Leuchte aus".

Ich habe keine fixe Lösung zur Hand. Am ehesten fiele mir noch ein zusätzliches Attribut "force_listen" oder "force_cache" ein, das sh.py dazu zwingt, nach jeder Änderung den aktuellen Status vom eibd zu lesen. Das könnte aber vom Timing her kritisch werden.

Max

[callidomus]

Hallo Max,

ich sehe das Problem an dieser Stelle:

> up keller.flur.leuchten.wand = false
Licht bleibt an

Kannst Du bitte im KNX Plugin folgendes Attribute setzen 'busmonitor = True' und mir einen Debugoutput von SH.py zu dieser Aktion schicken?

Welche KNX-Schnittstelle setzt Du ein? Welchen eibd, auf welcher Maschine?
Startparmameter von eibd?

Bis bald

Marcus

[Robert]

(z.B. habe ich nicht abschaltbare Treppenhauslichter)

Nur für mich kurz zur Sicherheit: Bei dem

> up keller.flur.leuchten.wand = false
Licht bleibt an

handelt es sich ja wohl nicht um ein solches Treppenhauslicht, oder? Falls ja, ist das ja nun auch "missbräuchlich" und kann auch denke ich nie sinnvoll (außer mit einem weiteren Lesevorgang) erkannt werden. Nicht sh.py oder der KNX machen hier ja den Fehler, sondern "der Anwender", in dem er einen "nicht-erlaubten" Wert setzt.

Vorschlag zur Lösung (falls obiges zutrifft - Pseudocode!):

[leuchte_die_ärger_macht-item]
enforce_updates = yes
knx_dpt...
knx_send = böse-GA-die-kein-Aus-akzeptiert
knx_listen = gute-GA-die-tatsächlichen-Status-liefert

[hilfsitem]
eval = groupread(gute-GA-die-tatsächlichen-Status-liefert, cache=False)
eval_trigger = leuchte_die_ärger_macht-item

evtl! funktioniert es sogar, die Hilfsitem-Einträge in das ursprüngliche Item auszulagern...

Grüße
Robert

[callidomus]

Hi Robert,

danke für den Lichtblick :-)

[leuchte_die_ärger_macht-item]
enforce_updates = yes
knx_dpt...
knx_send = böse-GA-die-kein-Aus-akzeptiert
knx_listen = gute-GA-die-tatsächlichen-Status-liefert

[hilfsitem]
eval = groupread(gute-GA-die-tatsächlichen-Status-liefert, cache=False)
eval_trigger = leuchte_die_ärger_macht-item

Ich denke das gibt eine Endlosschleife. Das enforce_updates kann weg.

Bis bald

Marcus

[l0wside]

Nur für mich kurz zur Sicherheit: Bei dem

> up keller.flur.leuchten.wand = false
Licht bleibt an

handelt es sich ja wohl nicht um ein solches Treppenhauslicht, oder?

Hallo Robert,

doch, dabei handelt es sich um eine solche Applikation. Ich sehe das aber nicht als missbräuchlich an - die KNX-Applikation hat ja schon ihren Sinn. Es kann viele Gründe geben, warum ein bestimmter Schaltbefehl eben nicht zum gewünschten Erfolg führt. KNX sieht ja nicht umsonst Rückmeldungen auf dem Bus vor.

Ein Hilfsitem geht natürlich, aber das ist ja höchst unelegant. Dann müsste ich noch für weitere Leuchten Hilfsitems anlegen - beispielsweise ist die Terrassenleuchte gesperrt, wenn der Rolladen unten ist.

Feature-Request: ein weiterer Parameter knx_enforce mit den möglichen Werten "cache" und "read". Ist er gesetzt, wird nach dem Setzen eines Items der tatsächliche Wert vom eibd abgefragt, je nach gesetztem Wert aus dem Cache oder vom Bus.

Gruß,

Max

[Robert]

KNX sieht ja nicht umsonst Rückmeldungen auf dem Bus vor.

Richtig. Aber wenn du das nutzen willst (und ein AUS auf einen entsprechend parametrierten Treppenhausautomaten macht ja nun wirklich nicht sooo viel Sinn) muss du eben wie auch bei der GA (sind ja eben zwei!) auch zwei Items anlegen - Befehl und Status.
Hast du bei den KNX-GAs ja auch gemacht, sonst könntest du dass ja auch nicht unterscheiden. Auf dem KNX "wehrt" sich die Schalt-GA auch nicht und schickt ein "Neee, ich bin TRUE" zurück.

Das führt übrigens in die Ewigkeit: Raffstore gesperrt, Fahrbefehl geht also ins leere. Da müssten jetzt alle! Fahr- und Positionsbefehle per "Readback" "geheilt" werden. Dann vielleicht doch lieber ein zweites Item was ggfl. sogar einen "Fehler" liefern kann wenn die Erwartung nicht eintrifft (also eine Inkonsistenz erkannt wird)!

Der "Readback" muss überdies ggfl. zeitverzögert werden etc... Gibt es eine andere etablierte Logikengine (HS, OpenHAB oder so) die so etwas "heilt"?

Grüße
Robert

ach so: In gewisser Weise gebe ich dir recht, die Quintessenz sollte aber meiner Meinung nach anders aussehen: Durchziehen des Konzepts von getrennten Befehl/Status und die Visu muss dass dann entsprechend darstellen, d.h. ggfl. bleibt der Button aus bzw. der Slider verharrt/spring zurück. Dafür müssten in der smartVISU z.B. die GADs aufgetrennt werden.

[2ndsky]

Visu-Schnittstelle

Würde da auch eher weitere Widgets erstellen, die Status und Schaltbefehl getrennt haben, als zu versuchen, das mit einem Item zu erledigen. Oder einfach zusätzlich anzeigen, dass die Lampe derzeit gesperrt ist. Sonst schaltest du (oder jemand, der die Logik dahinter nicht kennt) und wunderst dich, warum das Item (die Lampe) den Status nicht wechselt. Übrigens kann das auch kein HS und Konsorten

Andersrum, wenn du die Lampe an nem KNX Taster ausmachen willst, der ne Status LED hat... da löst du es auch mit getrennten GAs.

[Robert]

Andersrum, wenn du die Lampe an nem KNX Taster ausmachen willst, der ne Status LED hat... da löst du es auch mit getrennten GAs.

Bzgl. smartVISU: vielleicht gibt es die Möglichkeit, optionale Status-GADs einzuführen, die, wenn nicht angegeben, durch die Schalt-GADs ersetzt werden. Sowas könnte dann rückwärtskompatibel sein!?

[2ndsky]

Visu-Schnittstelle

vielleicht gibt es die Möglichkeit, optionale Status-GADs einzuführen, die, wenn nicht angegeben, durch die Schalt-GADs ersetzt werden. Sowas könnte dann rückwärtskompatibel sein!?

Ginge problemlos... wer machts?

[Robert]

Das ist Sklavenarbeit - kann ich für alle "einfachen" widgets anfangen wenn ich "endlich" (nicht böse gemeint!!! ) meine dynamische Liste bekomme...

[l0wside]

Richtig. Aber wenn du das nutzen willst (und ein AUS auf einen entsprechend parametrierten Treppenhausautomaten macht ja nun wirklich nicht sooo viel Sinn) muss du eben wie auch bei der GA (sind ja eben zwei!) auch zwei Items anlegen - Befehl und Status.
Hast du bei den KNX-GAs ja auch gemacht, sonst könntest du dass ja auch nicht unterscheiden.

Richtig. Aber sh.py führt beides in einem Item zusammen, dann hätte ich auch gerne, dass das Item den richtigen Wert hat.

Daher der Vorschlag mit knx_enforce. Dann schickt das Plugin nach dem Schreibbefehl direkt einen Lesebefehl hinterher. Ist zwar extra Buslast, aber das ist bei meinem Bus völlig egal. Dort geht es zu wie auf der A20 bei Nacht.
Ich schaue heute abend mal, ob ich zu einer Umsetzung komme.

Max

[2ndsky]

Visu-Schnittstelle

Dann schickt das Plugin nach dem Schreibbefehl direkt einen Lesebefehl hinterher.

Damit wirst du immer Timingprobleme haben... Denn, wie lange wartest du mit dem Lesebefehl um sicher zu sein, dass der Busteilnehmer genug Zeit hatte, seinen Status zu ändern? Solange blockierst du das KNX Plugin.

Mach doch einfach ne Logik dafür. In watch_items legst du alle problematischen Items ab. Wenn die Logik getriggert wird frägst du für das auslösende Item knx_listen nochmals zusätzlich ab. Die Logik läuft ja in nem eigenen Thread und kann (fast) beliebig blockieren. Wenn der Status nicht passt, setzt du das entsprechende Item zurück. Musst dann halt nur auf Endlosschleifen achten.

[Robert]

Das Item HAT den richtigen Wert. Nämlich den, der ihm als letztes gegeben wurde. WAS ihm jetzt als letztes gegeben wurde ist noch fraglich.

Nikos Beispiel mit dem Rückmeldeobjekt des Taster war goldrichtig - ich kenne keinen Hersteller der da einen "Readback" anbietet. Auch dort wird dann auf zwei KO aufgesplittet (auf Wunsch des Parametrierenden).

Wenn es denn sein muss: bitte nicht noch ein "enforce", zumal "durchsetzen" gar nicht passt. "Readback" trifft es da doch eher...