KNX/EIB Virtuelle Zustände speichern - wie?

[ingenotec]

Hallo zusammen,

da ich verschiedene Ansätze, aber keine zufriedenstellende Lösung für mein Problem habe, dachte ich mir, ich frage euch mal...

Ich möchte einen virtuellen Zustand "Lichtautomatik EIN/AUS" verwenden, der (wie der Name schon sagt) die komplette Automatik für das Licht im Haus ein- oder ausschalten kann. Zusammen mit einer UND-Verknüpfung und der dazugehörigen Logik werden die Lichter dann eben automatisiert geschaltet - oder eben nicht. So weit, so gut.

Nun möchte ich die Automatik über einen Taster und die dazugehörige LED eines Gira Tastsensor 3 ein/ausschalten können. Das würde prinzipiell auch funktionieren, nur habe ich ein Problem, falls der Tastsensor oder der Bus insgesamt neu gestartet wird. Denn die Tastsensor 3 kennen kein Read-On-Init.

Also müsste ich den aktuellen Wert von "Lichtautomatik EIN/AUS" zyklisch senden, das Flag "Aktualisieren" des Tasters und der LED setzen und irgendwo einen Lesevorgang triggern, oder... ?

Wie macht Ihr denn so etwas? Und wo speichert Ihr solche "Automatik EIN/AUS" Werte? In einem Eingang eines Logik-Moduls (ich verwende übrigens das von OpenKNX) mit aktiviertem Lesen-Flag? Das kann halt nicht zyklisch senden...
Alternativ als Logik-Ausgang, das kann zyklisch senden oder verzögert nach Busspannungswiederkehr. Aber dann bräuchte ich zwei GAs für die Automatik (Eingang und Ausgang Logikmodul), Quasi mit Rückmeldung. Aber eigentlich würde ich das gerne vermeiden...

Gibt es noch andere Möglichkeiten, auf die ich vielleicht noch nicht gekommen bin? Gibts da irgend ne "Best Practise"?

Ich freue mich auf eure Ideen!

[DerStandart]

Wie macht Ihr denn so etwas? Und wo speichert Ihr solche "Automatik EIN/AUS" Werte?

Solche Dinge habe ich in IP-Symcon. So konfiguriert, dass es den Wert bei einer Leseanfrage auf den Bus sendet. Habe so etwas aber auch schon mal mit dem MDT Logikmodul realisiert. Da dann über die Funktion "nach Reset senden".

[coko]

Zum OpenKNX-LogikModul siehe:
Beispiel 8: Wert bei Stromausfall speichern und nach Neustart wieder auf den Bus senden

Für mehre Zustände und Zustandswechsel (wie z.B. beenden des Automatikmodus nach gewisser Zeit) gibt es ansonsten noch die OpenKNX Zustandsautomaten. Mit aktivierter Rekonstruktions-Option wird der letzte Zustand soweit möglich nach einem Neustart wiederhergestellt.

[mumpf]

coco: Sein Problem ist ja nicht der Neustart vom Logikmodul, sondern der Neustart vom seinem Tastsensor. Das ist natürlich bitter, wenn ein Tastsensor keine KOs nach dem Neustart lesen kann.

ingenotec: Du hast die Probleme erfasst und beschrieben, insofern gehe ich davon aus, dass Du KNX-Logiken ausreichend verstanden hast .

ich verwende übrigens das von OpenKNX

Sehr gute Entscheidung ...

Alternativ als Logik-Ausgang, das kann zyklisch senden oder verzögert nach Busspannungswiederkehr. Aber dann bräuchte ich zwei GAs für die Automatik (Eingang und Ausgang Logikmodul), Quasi mit Rückmeldung. Aber eigentlich würde ich das gerne vermeiden...

Warum vermeiden? Das ist eigentlich KNX-Standard. Du schaltest einen Zustand und bekommst einen jederzeit lesbaren Status (auch wenn Dein Taster diesen nicht lesen kann). Aber es geht auch mit einer GA, nur muss man aufpassen, dass man sich keine Telegrammschleuder baut wegen der Rückkopplung. Deswegen empfehle ich 2 GA in meinen Beispielen.

Also müsste ich den aktuellen Wert von "Lichtautomatik EIN/AUS" zyklisch senden, das Flag "Aktualisieren" des Tasters und der LED setzen und irgendwo einen Lesevorgang triggern, oder... ?

Du brauchst auf keinen Fall beides. Entweder zyklisch senden oder mit A-Flags und GroupValueRead arbeiten. Im Folgenden ein Beispiel mit zyklisch senden:

Wenn Du es mit dem OpenKNX-Logikmodul und einer GA machen willst:

• Du verbindest Eingang und Ausgang mit der selben GA
• Eingang kann dann speichern, wie bisher
• Bei der Logik musst Du unbedingt einstellen, dass sie nur bei Änderungen getriggert wird (eventuell macht es Sinn "nur bei Änderung, aber erstes Telegramm immer senden, wegen Neustart des Logikmoduls, musst Du ausprobieren).
• Bei der Signalverarbeitung sagst Du zur Sicherheit beim Wiederholfilter, dass keine Wiederholungen durchgelassen werden sollen.
• Zyklisch senden stellst Du auf den Zyklus, der Dir genehm ist - wahrscheinlich musst Du ja nur das EIN-Signal zyklisch senden, das AUS ist nicht notwendig, weil Dein Taster ja nach einem Neustart schon AUS sein wird.

Das war es eigentlich. Ich hab das jetzt nicht ausprobiert, aber das sollte klappen. Wenn es Probleme gibt, kannst Du Dich ja nochmal melden.
Ich versuche bei mir zu Hause zyklische Telegramme zu vermeiden (außer bei Sensor-Messwerten) - nicht wegen der Buslast, sondern weil sie häufig unbeabsichtigt Logiken triggern. Oder wenn es sein muss, für so eine Reparatur "von hinten rum" dann auf einer extra GA, die ich dann an den benötigten Stellen als hörende GA nutze. Dann bin ich sicher, dass das nirgendwo anders stört. Aber das muss jeder selber wissen...

Viel Erfolg,
Waldemar

[coko]

coco: Sein Problem ist ja nicht der Neustart vom Logikmodul, sondern der Neustart vom seinem Tastsensor. Das ist natürlich bitter, wenn ein Tastsensor keine KOs nach dem Neustart lesen kann.

Kompletter Bus-Neustart wurde auch mit genannt. Sofern es keine Möglichkeit gibt den Neustart des Tasters (kurzfristig) zu erkennen, wird es wohl schwierig ohne ein zyklisches Senden.

Falls der Taster direkt beim Neustart ein In-Betrieb-Telegramm sendet, dann könnte man die Abweichung vom regrlmäßigen Intervall erkennen (mit Zustandsautomat recht einfach umzusetzrn).

Falls Teilfunktionen wie eingebaute Logiken eine Startkonfiguration haben, dann lässt sich das ganze ggf. darüber auslesen.

[Chade]

Wenn du einen freien Aktorkanal hast: schalte den und nimm seinen Status als Indikator.

[mumpf]

Er hat sich schon das Logikmodul, warum sollte er da einen Schaltaktorkanal verschwenden?

Gruß Waldemar

[ingenotec]

Also erst mal vielen Dank für eure zahlreichen Antworten! Irgendwie beruhigt es mich doch, dass die Lösung nicht ganz so einfach ist und ich einfach nur nicht draufgekommen bin...

@mumpf: Die Entscheidung für OpenKNX ist mir recht leichtgefallen... wer meine Vergangenheit kennt, weiß, dass ich zu meiner Studienzeit ein Gebäudeautomatisierungssystem auf CAN-Basis entwickelt hat - das hatte viele Ähnlichkeiten, aber natürlich auch einige positive wie negative Unterschiede. Aber die Ideologie war damals schon, eine Open-Source-Alternative zu KNX zu entwickeln, die für jedermann zugänglich ist. Leider war damals die Zeit noch nicht reif genug und die Hardware zu teuer, deswegen ist das ganze versandet. Aber es hat viel Spaß gemacht und Stoff für meine Bachelor- und Diplomarbeit gebracht. Und ich weiß umso mehr die Arbeit von euch zu schätzen und ziehe meinen Hut vor dem, was Ihr auf die Beine gestellt hat. Echt super!

Zu den Vorschlägen: Ich weiß, ich bin in manchen Dingen vielleicht etwas zu penibel, aber ich hätte gern eine möglichst saubere und verständliche Lösung. Das "Zweckentfremden" von Schaltausgängen, Status-LEDs, Taster-Logiken oder sonstigem mag sicher funktionieren - aber spätestens nach einiger Zeit und vielleicht noch ohne gescheite Doku ist so etwas grausam zu warten.

Meine Philosophie ist es auch, ausschließlich Komfortfunktionen in externe Systeme wie HomeAssistant oder externe Server auszulagern, weil die Ausfallwahrscheinlichkeit viel höher ist als bei nativen KNX-Komponenten. Auch wenn ich HUE einsetze, so sind die Lampen trotzdem über einen Schaltaktor gesteuert und wenn der Heartbeat von HomeAssistant als Gateway und Komfortsteuerung fehlt, können Taster und BWM die Lampen direkt zumindest EIN/AUS schalten. Das ist extrem förderlich für den WAF. 😆

Beim zyklischen Senden sehe ich es genauso wie mumpf - das würde ich nicht aus Trafficgründen vermeiden wollen, sondern weil ich denke, dass das bei einem sauber konfigurierten Bussystem normalerweise nicht nötig sein sollte und die beschriebenen Nebeneffekte haben könnte. Sobald nicht der Wert des Telegramms ausgewertet wird, sondern es als Trigger dient, muss man das bei Wiederholungen im Hinterkopf behalten - das machts natürlich auch etwas komplizierter. Wenn ich auf "abwesend" schalte, soll bei der Flanke geschaltet werden, der entsprechende Zustand aber auch jederzeit zur Auswertung in Logiken etc. gespeichert werden. Für eine Flanke muss aber der letzte Wert gespeichert sein, sonst hab ich nur nen Trigger. Und das ist leider nicht bei allen Herstellern gleich konsistent behandelt. Eigentlich sollte ein Gerät, das irgendwelche Werte braucht, die zumindest beim Booten abfragen können - aber selbst die recht beliebten Tastsensor 3 von Gira können das nicht... schade. Also brauchts wieder einen Workaround.

Auch das Hochfahren eines KNX-Busses hätte ich gern sauber definiert, auch wenn der Bus idealerweise nie stromlos ist und redundant versorgt wird. Ohne zyklisches Senden wird sonst die Status-LED zur Anzeige des "Automatik Zentral" quasi nie den wahren Wert anzeigen, weil sich dieser normalerweise nie ändert. Das soll nur im Notfall sämtliche Automatiken deaktivierbar machen, solange der Notfall nicht eintritt, bleibt es immer auf EIN. Das nach einem Busausfall manuell zu triggern fände ich jetzt aber auch etwas unprofessionell...

Ich werde jetzt auf jeden Fall erst mal die Variante mit dem Logikkanal ausprobieren - das hört sich für mich nach der derzeit saubersten Lösung an. Aber das mit den zwei GAs verstehe ich noch nicht so ganz. Ja, bei einem Schaltaktor ist es klar - ich sende einen Schaltbefehl und der Status kommt, sofern der Schaltvorgang erfolgreich war. Das ist zwar auch wieder problematisch, wenn ich z.B. 3 Lampen schalte, muss ich ja eine Lampe für die Rückmeldung auswählen. Wenn gerade die aber kaputtgeht, bekomme ich einen falschen (=keinen) Status, obwohl 2 der Lampen vielleicht geschaltet haben. Okay, das ist vielleicht konstruktionsbedingt so und definitiv besser als bei ioBroker, bei dem es ein zusätzliches Flag bei ein und demselben Objekt gibt (aber das ist ein anderes Thema).
Aber wenn ich eine Automatik ein-/ausschalte habe ich doch nichts, das mir sagen könnte: Ja, die Automatik konnte eingeschaltet werden. Ich sende doch quasi keinen Befehl, sondern einen Status auf den Bus. Also ist das, was ich sende, gegeben und muss nicht bestätigt werden. Warum sollte ich dann mit 2 GAs arbeiten? Nur, weils oft so gemacht wird? Aber ein BWM sendet doch auch direkt einen Status, wenn ich ein Schaltobjekt durch eine Logik jage, habe ich vielleicht sogar 2 oder 3 GAs für den Befehl und wenn ich z.B. mehrere Fensterstati mit einer Logik verknüpfe, habe ich dort auch Status/Status. Wieso empfiehlst du 2 GAs? Ausschließlich wegen der Gefahr der Rückkopplungen? Oder hat das einen anderen Grund?

Viele Grüße