Visu-Schnittstelle

[2ndsky]

Visu-Schnittstelle

Die Visu soll m.E. den Zustand der Aktoren darstellen und nicht die Vorstellung davon, was eigentlich sein müsste. Aber mit der Vorstellung bin ich hier wohl alleine :-(

Das tut sie ja, wenn du die GAs auf zwei Items aufteilst. Außerdem ist doch bei der Umsetzung schon was falsch, wenn ich ein Licht schalten kann, das ich eigentlich eben nicht schalten kann.

[JNK]

@lowside: Nein, das sehe ich genauso. Aber das ist Aufgabe des Aktors seinen Status bekannt zu geben. Und wenn er das tut, dann ist doch auch alles im Lot.

Gruss,

der Jan

[l0wside]

Aber ist das den Aufwand (Implementierung & Konfiguration) im Vergleich zu dem Nutzen wert?

Deswegen ja die Umsetzung im KNX-Plugin. Müssten unter 10 Zeilen Code sein, mal sehen. Alternativ ginge natürlich auch noch ein Widget-Parameter, der unzulässige Änderungen verbietet. Das kann aber ganz schön komplex werden.

Die Visu soll m.E. den Zustand der Aktoren darstellen und nicht die Vorstellung davon, was eigentlich sein müsste. Aber mit der Vorstellung bin ich hier wohl alleine :-(

Max

[2ndsky]

Visu-Schnittstelle

Ich denke man kann relativ schnell den Zusammenhang erkenne, wenn draußen ein Sturm tobt, kann ich die Jalousien halt einfach nicht runter lassen.

Schönes, anschauliches Beispiel.

Prinzipiell kann ich die Anforderung nachvollziehen. Gerade jetzt im Urlaub ist es schon gut zu sehen, warum die Jalousien nicht unten sind nachts. Aber dann schau ich halt kurz auf die Wetterstation und dann ist es mir klar. Oder ich mach ein Icon, dass mir den Windalarm visualisiert.

Ob jemand den Aufwand treiben will, sollte jedem selber überlassen werden. Nur sehe ich das KNX Plugin hierfür nicht als die richtige Stelle an.

[callidomus]

Hi,

Da wäre vielleicht ein unsichtbares Widget gut, das ein Item und eine andere Widget ID bekommt. Nimmt das Item einen bestimmten Wert an, wird das referenzierte Widget disabled. So könnte ich auch optisch klar machen, dass sich dieses Item derzeit nicht schalten lässt.

dazu könnte man auch die normalen Widgets kopieren/oder um ein 'Active'-Adresse zu ergänzen. Wenn das Item gesetzt ist, dann wird das Widget angezeigt, ansonsten wird es ausgegraut.

Aber ist das den Aufwand (Implementierung & Konfiguration) im Vergleich zu dem Nutzen wert?
Ich denke man kann relativ schnell den Zusammenhang erkenne, wenn draußen ein Sturm tobt, kann ich die Jalousien halt einfach nicht runter lassen.

Bis bald

Marcus

[2ndsky]

Visu-Schnittstelle

Wenn man es über die GUI anschalten möchte, so sollte man einen GUI-Taster und eine separates Element für den Status verwenden. => zwei Items

Sehe ich auch so. Zumal es gar keinen Sinn macht, dass ich die Lampe über die GUI ausschalten kann, wenn das eh nicht geht. Ich würde ein Icon für den Status machen und einen zustandslosen Trigger für das Treppenhauslicht (so kann ich auch nachtriggern).

Wenn ich einen gesperrten Aktor habe, dann komme ich wohl auch nicht ohne ein separates Item für das Sperr-Objekt aus. Das generisch mit dem reellen Zustand zu verbinden ist wahrscheinlich nicht möglich, da hier die Applikationen und Einstellungen zu unterschiedlich sind.

Da wäre vielleicht ein unsichtbares Widget gut, das ein Item und eine andere Widget ID bekommt. Nimmt das Item einen bestimmten Wert an, wird das referenzierte Widget disabled. So könnte ich auch optisch klar machen, dass sich dieses Item derzeit nicht schalten lässt.

[callidomus]

Anwendungsfälle

Hallo,

bis jetzt sehe ich zwei Anwendungsfälle/Probleme.

1. Bei dem Treppenlicht-Aktor, den man nicht abschalten kann, und Ihn über die GUI aktivieren möchte.
2. Umgang mit einem gesperrten Aktor.

1. Wenn man es über die GUI anschalten möchte, so sollte man einen GUI-Taster und eine separates Element für den Status verwenden. => zwei Items
   Mich würde bei der readback-Variante auch das flippen stören. Ich drücke auf aus und er geht gleich wieder an. Ich drücke nochmal auf aus ...
2. Wenn ich einen gesperrten Aktor habe, dann komme ich wohl auch nicht ohne ein separates Item für das Sperr-Objekt aus. Das generisch mit dem reellen Zustand zu verbinden ist wahrscheinlich nicht möglich, da hier die Applikationen und Einstellungen zu unterschiedlich sind.

Gibt es einen Anwendungsfall, für readback, den ich übersehen habe?
Die Implementierung für readback ist wahrscheinlich wirklich einfach, aber ich sehe momentan noch keinen wirklichen Vorteil das zu integrieren.

Bis bald

Marcus

[2ndsky]

Visu-Schnittstelle

Python für Hausautomatisierung macht sonst auch niemand.

Übrigens sogar der HS

[Robert]

Und nochmal: der Vergleich mit den gesplitteten GA hinkt. sh.py führt Aktion und Status in einem item zusammen.

Du führst das (optional!) bei sh.py zusammen.

Python für Hausautomatisierung macht sonst auch niemand.

Let me google that for you *SCNR*

Aber gut, ich denke die Ansichten klar erläutert. So haben wir schon mindestens zwei Wege die zur Lösung (des ursprünglichen Problems) führen.

Grüße
Robert

[2ndsky]

Visu-Schnittstelle

Warum sollte ich das Plugin blockieren? Ich setze nur das Lesetelegramm ab, die Antwort wird ganz normal asynchron verarbeitet. Das sollte sich in ein paar Zeilen im KNX-Plugin erschlagen lassen.

Na dann, auf auf. Ich sehe das zwar wie Robert, aber wir leben in einer freien Welt

[l0wside]

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.

Warum sollte ich das Plugin blockieren? Ich setze nur das Lesetelegramm ab, die Antwort wird ganz normal asynchron verarbeitet. Das sollte sich in ein paar Zeilen im KNX-Plugin erschlagen lassen. Zugegebenermaßen besteht die Gefahr, dass der Aktor die Telegramme nicht in der Reihenfolge des Eintreffens bearbeitet und deswegen einen alten Status zurückmeldet. Das käme aber auf einen Versuch an.
Natürlich kann man das auch über eine Logik lösen, das wird aber aufwändiger.

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.

Akademisch magst du recht haben. Trotzdem ist die Leuchte an, und sh.py glaubt, sie sei aus - das ist inkonsistent. "knx_readback" als Parameter gefällt mir gut.
Und nochmal: der Vergleich mit den gesplitteten GA hinkt. sh.py führt Aktion und Status in einem item zusammen. Bei KNX wird beides häufig getrennt.

Das Argument "sonst macht´s doch auch niemand" überzeugt mich ansonsten gar nicht. Python für Hausautomatisierung macht sonst auch niemand.

Max

[2ndsky]

Visu-Schnittstelle

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).

Vor allem kenne ich keine Logikengine, die damit auch nur im entferntesten so umgehen kann.

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

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

[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