Anzeige Tür offen mit HmIP-SRH und HmIP-BSL

[tbs.stbr]

Hallo zusammen,

aufgrund von Duty Cycle Problemen möchte ich gerne ein paar Programme restrukturieren, die ich deaktiviert habe. Vorher hatte ich ein recht einfaches Programm welches jedes Mal einfach funkt, wenn sich ein Türgriff dreht.

Habt ihr einen Tipp, wie ich möglichst zentralenfunkarm in HmIP-BSL (blaues Licht unten) anzeigen kann, wenn eine oder mehrere von insgesamt 5 Fenstergriffen geöffnet sind?

Ich hatte mich schon fast gefreut, dass das generell per Direktverknüpfung geht, wenn aber zwei Türen offen sind und ich mache eine davon zu, dann wird durch die Direktverknüpfung natürlich das Signallicht einfach ausgeschaltet.

Ich bin leider nicht sehr firm, was die Logik des Systems angeht. Hat jemand nen Tipp, wie ich die Funktion behalten kann?

[Roland M.]

Hallo!

Also ich mache diese Dinge immer über Systemvariablen.

WENN Fenster1 offen
ODER Fenster2 offen
ODER ...
DANN Status_Fenster_gesamt = offen
SONST Status_Fenster_gesamt = geschlossen

WENN Status_Fenster_gesamt offen
DANN Anzeige rot
SONST Anzeige grün


Roland

[dtp]

Ich mache es auch über eine Systemvariable.

Da ich aber neben geöffnet und geschlossen auch den Zustand gekippt erfassen möchte, wird's ein klein wenig aufwändiger, wenn man mehrere Fenster kombinieren will.

[tbs.stbr]

Danke an beide.
Manchmal sieht man den Wald vor lauter Bäumen nicht.

Variablen waren mir schon bekannt und habe ich nun so umgesetzt. Ich hoffe, dass das zur Duty Cycle Entlastung beiträgt.

Kurze Rückfrage an dtp: Wofür hast du den Check der CCU immer mit drin? Geht es nur darum die Chance zu erhöhen, dass die zugewiesene Variable die korrespondierende Wirklichkeit häufiger korrekt abbildet?

[Xel66]

Geht es nur darum die Chance zu erhöhen, dass die zugewiesene Variable die korrespondierende Wirklichkeit häufiger korrekt abbildet?

Sehr schöne Formulierung! Nein, es geht darum, zu verhindern, dass das Programm angeblich zum Systemstartzeitpunkt ausgeführt wird. Manchmal ist dieses auch kontraproduktiv, da ja das System den Aktor- und Systemvariablenzustand beim Systemstart so hinstellen will, wie es für die aktuellen Bedingungen richtig wäre. Dieses wird mit dieser Maßnahme vermeintlich verhindert (aber in diesem Beispiel mit den Griffsensoren nur um den Zeitraum zwischen Systemstart und erster Sensorrückmeldung/-aktualisierung verschoben). Es gab da zu dem Thema mal einen Thread. Benutzt wird hierzu die originale Anwesenheits-Systemvariable, mit ihrer ganz speziellen Eigenschaft, beim Reboot immer auf "WAHR" geschaltet zu werden (Staus wird nicht gespeichert!).

Gruß Xel66

[dtp]

Weil ich absolut vermeiden will, dass meine CCU beim Neustart irgend etwas durchführt. Ist System. Außerdem habe ich keine Lust, darüber nachzudenken, welches Programm nun nach einem Neustart was machen darf und welches nicht.

In den zurückliegenden sieben Jahren gab es zwei, oder drei ungesteuerte Neustarts meiner CCU nach längerem Stromausfall (meine USV kann nur ca. 45 Minuten überbrücken, in denen sie FRITZ!Box, DiskStation, CCU3 und einen Switch versorgt). Ansonsten erfolgt ein Neustart bei mir nur kontrolliert.

Man kann Zustandsänderungen während eines ca. siebenminütigen Neustarts der CCU eh nicht erfassen. Daher ist mir meine Vorgehensweise der systematischen Unterdrückung von Programmausführungen nach einem Neustart in sämtlichen Programmzweigen lieber. Aber ich bin auch jemand, der HM-Skripte deutlich lieber mag, als WebUI-Programme.

[Xel66]

Weil ich absolut vermeiden will, dass meine CCU beim Neustart irgend etwas durchführt.

Der Wunsch ist soweit nachvollziehbar, aber eben nicht zielführend. Beispiel: Du ziehst ein Backup (meinetwegen bei Systempflege in der Nacht). Unterstellen wir weiterhin, Du hast ein Systemproblem, welches ein Einspielen des Backups notwendig macht. Dieses machst Du bedarfsmäßig am Tag. Im Originalzustand würde die CCU alles was zeitgesteuert ist so wie am Tag hinstellen, alles was abhängig von abgefragten Aktorstatus ebenfalls. Nur bei Tür- und Drehgriffkontakten kommt dieses ins Straucheln, weil beide beim Systemstart eine Default-Stellung haben, weil eben beide nicht abfragbar sind. Für Thermosensoren ist das Prinzip der Verzögerung über diese Variable bis zur ersten Übermittlung eines Messwertes (in der Regel um drei Minuten) auch zielführend.

Noch ein Beispiel: Neustart durch Spannungsausfall (hier unterstelle ich mal, dass die wenigigsten Anwender die CCU durch eine USV gesichert haben). Wo stehen danach die Rollladenaktoren in ihrer Statusrückmeldung? Bei 50% Behanghöhe. Was spricht nun dagegen, wenn die Programme die Rollladen in die für den aktuellen Zeitpunkt vorgesehen Stellung fahren? Nichts, denn es ist vom Hersteller schlicht so vorgesehen. Sie würden ja je nach Zeitpunkt nicht mal ihre reale Stellung verändern, nur der Status wird korrigiert. Eine Verhinderung dieses Automatismusses zum Systemstart unterbindet dieses und die Aktoren stehen im Nirvana. Darum ist ein Einsatz nach dem Prinzip "Gießkanne" eben nicht zielführend und kann eben auch nicht pauschal allen Anwendern mit der nachweisbar falschen Behauptung, dass sonst alle Programm beim Systemstart "gestartet" würden, empfohlen werden.

Außerdem habe ich keine Lust, darüber nachzudenken, welches Programm nun nach einem Neustart was machen darf und welches nicht.

Genau das ist der Punkt. Gerade der oben gepostete Screenshot ist ein Beispiel, weswegen das Prinzip "Gießkanne" nicht zielführend ist. Geh mal Dein Programm unter der Maßgabe durch, dass die Sensorenstatus alle Stunde aktualisiert werden und beim Systemstart einen Defaultwert zugewiesen bekommen. Du wirst feststellen, dass die Systemvariablen bei der Aktualisierung des ersten Sensors einen Zustand einnehmen können, der absolut nichts mit der Realität gemein hat, weil die Statusübermittlung der Sensoren nämlich nicht zeitlich synchron läuft und bei Batteriesensoren der aktuelle Status nicht gezielt durch die CCU abfragbar ist. Sie switchen also nicht nachvollziehbar bei Systemstart, sondern irgendwann im Zeitbereich von einer Stunde um. Das ist zwar ohne die Systemvariable auch nicht anders, aber Dein Vorgehen wiegt Dich nicht in (einer eben nicht vorhandenen) Sicherheit. Und bei Systemstart wäre das noch nachvollziehbar, bis zu einer Stunde danach nicht mehr unbedingt.

Man kann Zustandsänderungen während eines ca. siebenminütigen Neustarts der CCU eh nicht erfassen.

Stimmt auch, daher ist das Vorgehen erst recht wert, hinterfragt zu werden. Daher wäre es bei solchen Sensoren zielführender, ihren Status in einer Systemvariable abzubilden, die einen Systemstart "überlebt". Programme können dann mit diesem Staus arbeiten. Für oben beschriebenes Einspielen eines Backup ist das aber auch keine Lösung.

Aber ich bin auch jemand, der HM-Skripte deutlich lieber mag, als WebUI-Programme.

Dieser Umstand ist mir durchaus bekannt. Aber genau hier bietet Script auch keine Lösung an, im Gegenteil. Häufig werden Scripte zyklisch gestartet, um irgendwelche Statusabfragen oder Aktionen zu tätigen. Scripte hängen aber an den gleiche Status wie die WebUI. Da ist mir die Ereignissteuerung der originalen Firmware schon lieber. Und die Programme im WebUI sind für interessierte Anwender im Zweifel auch nach Jahren nachvolliehbar. Bei Scripten stoßen viele schon eher an ihre Grenzen und betreiben c&p, ohne zu wissen, was sie dort tun.

Bei einer Anwendernachfolge (Krankheit, Scheidung, Tod etc.) ist die Wartung mit irgendwelchen Sonderlocken umso schwieriger und man sollte überlegen, was man seiner Familie antut, wenn man mal selbst ausfällt. Mal ganz abgesehen davon, dass eine verbastete Immobilie schwieriger zu veräußen sein dürfte. Mein Nachwuchs ist technisch nicht untinteressiert, aber beschäftigt sich nicht mit der Hausautomation außer sie zu benutzen. Aber ich traue ihm durchaus zu, bei Problemen sich in die Programmierung unter Verwendung der Herstellerdokumentation zu Geräten und WebUI reinzuarbeiten. Scripting für Triviallösungen legt die Latte aber eindeutig höher. Darum mein Prinzip KISS. Und eine Maßnahme ist, alles was mit der WebUI umgesetzt werden kann, wird auch dort gemacht. Scripte kommen nur dort zum Einsatz, wo es nicht zu umgehen ist (Berechnungen, Vergleiche, Iteration, String-Handling).

Gruß Xel66

[dtp]

Wir brauchen das Thema hier nicht zig mal im Forum an den verschiedensten Stellen zu diskutieren, denke ich. Ich habe meine Vorgehensweise, du hast deine. Beides scheint für denjenigen bestens zu funktionieren.

[Xel66]

... nicht zig mal im Forum an den verschiedensten Stellen zu diskutieren, denke ich.

Nein, müssen wir nicht, aber ich habe darauf hingewiesen und auch auf Deinen Thread verlinkt, aber eben entsprechende Zusatzinformationen gegeben, dass dieses Vorgehen ein Workaround und keine Lösung ist und wegen möglicher Nabenwirkungen eben nicht nach dem Gießkanneprinzip an alle möglichen und unmöglichen Stellen eingefügt werden, wie dieses vielfach geschieht. Vielmehr sollte dieser Workaround nur an ganz bestimmten Stellen, wo es unbedingt notwendig ist, einsetzen.

Gerade heute habe ich einen Thread gesehen, in dem jemand die Variable in einem durch einen Zeitpunkt getriggerten Programm eingefügt hat. Dort ist es definitiv überflüssig, weil der Zeitpunkt bei der Bedingunsprüfung bei Systemstart nur zu einem einzigen Zeitpunkt WAHR sein kann und folglich mit sehr, sehr hoher Wahrscheinlichkeit nicht bei Systemstart ausgeführt wird.

Ich habe meine Vorgehensweise, du hast deine. Beides scheint für denjenigen bestens zu funktionieren.

Nein, ich habe diesbezüglich keine spezielle Vorgehensweise, sondern nutze das System und die Funktionalität so wie es vorgesehen ist. Den Workaround nutze ich dort wo er unbedingt notwendig ist. Ich habe ihn z.B. in meine Mail und Push-Programme eingebaut, weil ich sonst bei Systemstart durch die Statusaktualisierungen und -wechsel von Pushnachrichten und Mails erschlagen werden und die Trulla (Alexa) unablässig quasselt. Mein Statement ist eigentlich nur als mahnender Finger vor unbeabsichtigten und unerwarteten Nebenwirkungen und Information für andere Anwender zu sehen.

Gruß Xel66