Automationsdesign für geringe Controller-Auslastung

[STdesign]

Was dürfte denn das beste Design von Automationen sein, um eine (in Summe) möglichst geringe Auslastung des Controllers zu erreichen?

Beispiel: Automation zum Lüften eines innenliegenden Badezimmers. 

• WENN Badtür länger als 2 Minuten geöffnet bleibt
• UND Diverse Fenster oder-verknüpft geöffnet sind
• DANN Heizpause im Bad aktivieren.

Diese Automation läuft also immer, sobald die Tür offen steht. Egal, ob Sommer oder Winter.

Würde es aber Sinn machen, eine Abfrage einzubauen, ob das Bad überhaupt im Heiz-Modus ist, um die unnötige Ausführung der Automation im Sommer zu verhindern? Dies wäre wegen den oder-verknüpften Fenstern nur durch einen weiteren Zustand und Automationen möglich, um eine UND-Verknüpfung mit dem Heiz-Modus hinzubekommen.

Was ist in Summe weniger rechen- und speicherintensiv?

• Die Automation komplett laufen lassen, auch wenn ihr Ausgang (DANN) nichts an der gegenwärtigen Situation ändert.
• Zusätzliche Zustände und Automationen einbauen, um die Ausführung der Automation bei Prüfung der UND-Bedingung situativ abzubrechen.

[GerSch]

Wenn ich Deine Frage richtig verstehe dann hängt das im Wesentlichen davon ab wie genau der Teil funktioniert der letztlich die Automation ausführt. Wenn er ausschließlich über Ereignisse gesteuert wird dann werden Automationen auch nur ausgeführt wenn der entsprechende Zustand eintrifft. z.B. Die Tür wird geöffnet und es löst das entsprechende Ereignis aus. Dieses Ereignis führt dazu das Deine Prüfregeln und ggf. Aktionen ausgelöst werden. Fertig. Eine Prüfung mehr oder weniger dürfte da keinen großen Unterschied machen. In Deinem konkreten Fall ist es halt ein verzögertes Ereignis welches eben 2 Minuten später erst das passende Ereignis auslöst und die definierten Dinge abarbeitet. Optimalerweise müsste das verzögerte Event aber auch gelöscht werden wenn in der Zwischenzeit der Startzustand nicht mehr zutrifft, in Deinem Fall also Tür zu ergo alle wartenden Ereignisse dazu löschen. Damit würde die Automation gar nicht loslaufen. Ich gehe stark davon aus das es so funktioniert alles andere wäre deutlich unpraktischer und aufwändiger umzusetzen.

Rein von der Mächtigkeit sehe ich da nicht viel Unterschied ob Du auf Heizpause prüfst oder nicht. Ggf. ist die Prüfung ob Fenster offen sind intensiv, je nachdem wieviel Fenster Du hast. Hier könnte mglw. ein virtueller Status aushelfen der abbildet ob irgendein Fenster geöffnet ist.

[SebastianHarder]

@GerSch hat das Verhalten schon ziemlich gut beschrieben.
In der Tat kann man da nicht viel verbessern, außer die Automation komplett zu deaktivieren. Aber auch das macht keinen wesentlichen Unterschied.

Die Automation horcht auf Ereignisse der Badtür. Wenn sie geöffnet wird, wird ein Timer registriert, der nach 2 Minuten auslöst, außer die Tür wird vorher wieder geschlossen, dann wird der Timer deregistriert.
Das Abfragen der Fenster in den Bedingungen erfolgt in-memory. Daher auch praktisch keine Last.
Und das Setzen des Zustands im DANN ist auch irrelevant, falls der Zustand sich nicht ändert.

[STdesign]

Danke für die Antworten. Ich nehme erstmal mit, dass es keinen Unterschied macht. Heißt für mich: Ich mache die Automationen und Zustände so übersichtlich wie möglich. Und es ist egal ob eine Automation dann (auch mal unnötigerweise) läuft, obwohl der Endzustand schon vorher anliegt.

[Edit] Die Frage nochmal anders formuliert wäre: "Was belastet den Controller mehr? Automationen, die ausgeführt werden, ohne dass sich das Resultat ändert? Oder zusätzliche Zustände und Automationen (um die Zustände zu (de-)aktivieren), um eine unnötige Ausführung der Automation zu unterdrücken?"

[GerSch]

Das geht dann eher in die Esotherik oder in Richtung Heisenbergsche Unschärferelation. Du musst natürlich den Zustand prüfen um herauszufinden ob er überhaupt einen relevanten Zustand hat. Auch danach folgende Prüfungen verfolgen nur den einen Zweck ob alle Bedingungen vorliegen. Falls nicht dann wir halt auch der Wert nicht geändert aber das weißt D erst nachdem Du alle Rahmenbedingungen geprüft hast. Wenn das InMemory stattfindet dann ist das tatsächlich fast aufwandsneutral und schnell. Letztlich ist alles ein Frage der Menge egal ob auf der einen (Automationen) oder der anderen (Zustände) je mehr es werden um so träger werden sie. Wenn Du künstliche Zuständen verwendest verdoppelst Du ja eigentlich die Menge da für jeden Zustand auch eine entsprechende Automation benötigt wird. Hast Du denn Probleme?

[STdesign]

Du musst natürlich den Zustand prüfen um herauszufinden ob er überhaupt einen relevanten Zustand hat.

Das ist klar, ohne geht's nicht. 

Wenn Du künstliche Zuständen verwendest verdoppelst Du ja eigentlich die Menge da für jeden Zustand auch eine entsprechende Automation benötigt wird.

Das ist ja genau Kern der Frage. Ist dieser zusätzliche Aufwand (hin und wieder Zustände setzen und vor allem speichern) weniger Ressourcen brauchend als das wiederholte (unnötige) ausführen von WENN-Aktionen mit entsprechendem Senden/Empfangen von Signalen oder ggf. gar Botschaften.

Wo liegt also mehr Aufwand: Abarbeiten und prüfen vieler UND-Bedingungen, was allein im Controller stattfindet? Oder dem senden von Aktionen an die Geräte, was durch die Kommunikation nach außen womöglich aufwendiger/ressourcenintensiver ist als rein controllerinterne Tasks (mir geht es nicht um Batterieverbrauch der angefunkten Geräte).

Hast Du denn Probleme?

Nein, ist reine Neugierde. Durch geänderte Lebensumstände passe ich gerade mein Heizungskonzept an. Und wenn ich dahingehend was verbessern könnte, würde ich das u.U. tun. Denn einem Controller I ist mit über 70 Geräten und um die 140 Automationen sicher nicht langweilig. Deshalb die Frage ob eine Strategie entlastender ist als die andere. Bisher habe ich verstanden "Nein", bzw. das eine schwarz/weiß Antwort nicht möglich ist (was nicht unüblich ist).

[KT3]

Hallo @STdesign , so interessant die Diskussion über die Auslastung des Controllers ist, habe ich auch noch ein paar Anmerkungen allgemein zu der Automation:

Wie gehst Du mit der Situation um, das Fenster geöffnet werden, wenn die Badezimmertür schon länger geöffnet ist. Läuft dann eine weitere Automation, die durch das Öffnen der Fenster getriggert wird und auch den Zustand der Tür abfragt und abhängig davon die Heizpause im Bad steuert ?

Macht es ggf. Sinn mehr mit Zuständen zu arbeiten, die durch das Öffnen und Schließen der Fenster gesteuert werden, um sie ggf. für mehrere unterschiedliche Automationen nutzen zu können und die Abfragen zu vereinfachen (auch bzgl. Übersichtlichkeit der Automationen).

Ist es eine Option, beim Lüften und damit Öffnen der Fenster die Heizpause im Bad unabhängig vom Zustand der Tür zu nutzen ?

Unabhängig von der Last des Controllers (schade, dass CPU- und Speicherauslastung nicht angezeigt werden können) würde ich die Automation in den Sommermonaten einfach deaktivieren und nicht über irgendwelche zusätzliche Aktionen ermitteln, ob eine Durchführung Sinn macht.

Macht die Automation überhaupt Sinn; bringt sie Dir Ersparnisse ? 
Das hängt natürlich von den Rahmenbedingungen ab. Bleibt die Tür länger offen ? Wo sind ggf. die offenen Fenster ? Ist dazwischen ein Flur, der relativ konstante Temperatur hält ? Letztendlich bestimmt der Temperaturgradient (Temperaturunterschied) den Verlust der Heizleistung im Bad. 

Tja, das wären meine Denkaufgaben 😀

[STdesign]

Richtig, es gibt eine zweite Automation wie von dir genannt.

Das andere Wege zum Ziel führen können ist richtig. Das ganze ist aber bereits zu Zeiten entstanden in den von Zuständen nur geträumt wurde. Von daher ist das derzeit noch so. Und auch da sind wir wieder bei der Frage: sind zusätzliche Automationen und Zustände strapaziöser?

Die Automation war nur ein Beispiel, bitte nicht daran festklammern. Es gibt zig andere Fälle mit "ver-oderten" Bedingungen, die Aufwand bräuchten um die Ausführung mit einer umklammernden "ver-undeten" Bedingung zu verhindern. Oder man lässt diesen Aufwand. Wir sind also auch hier wieder beim Kern der Frage.

Edit: Und wenn es mit vertretbarem Aufwand möglich ist, möchte ich so viel wie möglich automatisieren. Und nicht jahreszeitabhängig händisch eingreifen. Kann man machen, funktioniert auch. Möchte ich aber nur im Notfall.

[GerSch]

Neugierig geworden habe ich mir mal die Optionen für die Automatisierung angeschaut. Mit den Regeln kann man allerhand abbilden aber geschachtelte Logiken lassen sich nicht abbilden. Da wären virtuelle Zustände ggf. eine Abhilfe.

Wenn Du aber sowieso dabei bist oder eventuell vorhast mal aufzuräumen dann lohnt sich eventuell ein Blick über den Tellerrand. Es ist ohne weiteres möglich die Automationen einem externen System zu überlassen. Mit entsprechenden Vor- und Nachteilen natürlich, aber insbesondere bei den Automationen ergeben sich aus meiner Sicht sehr viel mehr Freiheiten. Je nach Affinität gibt es da unterschiedlichste Ansätze. Das würde Deinem Controller auf alle Fälle deutlich Entlastung verschaffen wenn er die Automationen nicht mehr abfahren müsste 🙂 

[GerSch]

Das ist ja genau Kern der Frage. Ist dieser zusätzliche Aufwand (hin und wieder Zustände setzen und vor allem speichern) weniger Ressourcen brauchend als das wiederholte (unnötige) ausführen von WENN-Aktionen mit entsprechendem Senden/Empfangen von Signalen oder ggf. gar Botschaften.

Ggf. findet sich hier die Antwort. Ich kann mir schwer vorstellen das der Controller beim Eintreten eines Zustandes die Geräte nach ihrem aktuellen Zustand befragt um eine Entscheidung zu treffen. Das würde architektonisch aus meiner Sicht wenig Sinn machen, wäre langsam und stromverschwendend gerade bei batteriebetriebenen Geräten. Eher wird es so sein der das Controller die aktuellen Zustände genaustens kennt da er sie bei jeder Änderung von den Geräten gesendet bekommt und sich merkt. So sollte es zumindestens bei Sensoren sein die per Definition ja jede Zustandsänderung melden (so z.B. Deine Tür bzw. der passende Sensor). Bei Aktoren sieht es natürlich anders aus aber die sind ja üblicherweise das finale Ziel eine Automation.

[STdesign]

Eher wird es so sein der das Controller die aktuellen Zustände genaustens kennt da er sie bei jeder Änderung von den Geräten gesendet bekommt und sich merkt.

Damit steht und fällt das Ganze, richtig. Vielleicht kann ja ein Bosch'ler was dazu sagen, vielleicht @SebastianHarder ?

Zumindest wenn es eine Änderung zu senden gibt, scheint das "strapaziös" zu sein. Andernfalls machen Hinweise, die wohl auch der Support gibt, wie "Teile dein Szenario für Rollläden etagenweise auf" keinen Sinn.

[GerSch]

Zumindest wenn es eine Änderung zu senden gibt, scheint das "strapaziös" zu sein. Andernfalls machen Hinweise, die wohl auch der Support gibt, wie "Teile dein Szenario für Rollläden etagenweise auf" keinen Sinn.

Das erscheint mir allerdings dann auch merkwürdig da ja hier mehrere Automationen mit dem gleichen Trigger (z.B. zu hell, zu windig) gestartet würden und dadurch einen unnötigen Overhead ergeben. Strapaziös ist relativ, üblicherweise sind Aktoren netzgebunden und stören sich daran eher nicht. Der Controller muss natürlich Nachrichten verschicken und ggf. auf Rückmeldung warten aber auch das sollte ihn nicht ins Schwitzen bringen solange wir nicht über dutzende Meldungen reden, aber ich kenne da auch keine Interna die diese These stützen würden.

[GerSch]

Aber ja man müsste sich im Zweifel jede Deiner Automatisierungen anschauen um eventuell vorhandenes Optimierungspotential zu erkennen. Eventuell reicht es ja schon die vorhandenen dahin gehend zu prüfen ob sie wirklich noch benötigt werden. Keine Ahnung ob es eventuell ein Log o.ä. gibt wo man die Systemlast mal prüfen könnte oder Laufzeiten der Automatismen sieht.

[KT3]

Hallo zusammen, Sebastian Harder hat in seiner Antwort doch erwähnt, dass der Zustand der Fenster im Speicher des Controllers abgefragt wird. Wie Ihr zu Recht selbst erwähnt habt, macht das auch Sinn, um sowohl schneller ein Ergebnis zu haben als auch die aufwendige (zeit-, rechenintensiver) Kommunikation mit den Sensoren zu reduzieren (auf Zeitpunkte, die der Sensor durch Änderung triggert).

In geringem Maße wird es zusätzliche Kommunikation geben (z.B. Neustart des Controllers).

Die Kommunikation mit den Geräten ist mit Sicherheit ein Vielfaches komplexer (Abfrage an den Sensor schicken, Mechanismen, um die Vollständigkeit der Kommunikation zu prüfen, Feedback einholen…). Da es keine Gruppenansteuerung der Geräte gibt, müssen am Beispiel der Rollladensteuerungen die Geräte einzeln nacheinander angesteuert werden. Ich denke, dass daher die Empfehlung auf „etagenweise“ erfolgt ist, um ggf. mögliche Zeitverzögerungen zwischen Befehl und Umsetzung zu umgehen.

Zusätzliche „WENN“-Abfragen (Automationen) erzeugen somit nach meinem Verständnis auch keine zusätzlichen Kommunikation zwischen Controller und den Auslösern, da der Auslöser so oder so seine Änderungen an den Controller sendet. Erhöht werden also Speicherbedarf im Controller und Prozessorlast durch die zusätzlichen Verarbeitungen.

Jetzt kann man sich noch überlegen, wie man die Prozessorlast niedrig halten kann. Dann müsste man die notwendigen Rechenoperationen reduzieren. Wenn 1 Zustand (den ich bsp. einmalig beim Fenster öffnen setze) abgefragt wird, ist es natürlich weniger rechenintensiv als wenn ich mehrfach statt dessen alle Fenster abfrage. Ob dies bei der heutigen Leistungsfähigkeit von Prozessoren eine Rolle spielt ? Bestenfalls kann man „vorbeugend“ versuchen, wo möglich Automationen zu vereinfachen oder sonst auf Probleme reagieren.

Meine frühere RWE Smarthome Lösung hat die prozentuale CPU Auslastung und Speicherauslastung des Controllers angezeigt . Da konnte man bei Performanceproblemen mal schauen…

[GerSch]

Soweit so richtig. Wenn man beim Beispiel der Fenster bleibt würde sich durch eine weitere Automation nebst passendem Zustand die Rechenlast nicht unbedingt verringern. Sie würde lediglich zu einem anderen Zeitpunkt stattfinden. In der Automation müsste ja jeweils auch geprüft werden ob noch andere Fenster offen sind wenn eines geschlossen wurde.

Ich denke den SHC sollte man nicht mit handelsüblichen PC Systemen vergleichen. Ich kann nur orakeln aber vermute da wird ein zentraler Mikrokontroller werkeln der durch Chips ergänzt wird welche sich um die verwendeten Protokolle kümmern (soweit ich weiß Zigbee und WLAN auf der Zubehör Seite und LAN für den SHC selbst). Da der SHC schon einige Jährchen auf dem Buckel hat wird der Chip auch nicht mehr taufrisch sein und schon bei Erscheinung des Geräts nicht aus dem Premiumregal gekommen sein um den Preis attraktiv zu halten. Dazu kommen regelmäßige Erweiterungen welche auch nicht dafür sorgen das das System leichtgewichtig bleibt. Auch in der Entwicklung selbst läuft es selten fehlerfrei, hier schlummert ggf. auch noch Ballast. Allerdings schaffen es auch diese Geräte durchaus, je nach Aufbau und Auslastung, mehrere Dutzend Anfragen pro Sekunde rauszuschicken und entsprechend auch die Antworten zu verarbeiten. Kann dann halt mal einen Augenblick dauern. Das kann dann auch mal asynchron geschehen und Warterei zu vermeiden.