Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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.
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
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.
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
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
Bei dem Treppenlicht-Aktor, den man nicht abschalten kann, und Ihn über die GUI aktivieren möchte.
Umgang mit einem gesperrten Aktor.
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 ...
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.
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.
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
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.
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.
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
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 :-(
@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.
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.
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar