Howto - Vermeidung von Programmstarts nach Neustart der CCU

Problemlösungen und Hinweise von allgemeinem Interesse zur Haussteuerung mit HomeMatic

Moderator: Co-Administratoren

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von Xel66 » 05.12.2018, 11:04

dtp hat geschrieben:
05.12.2018, 10:43
...den automatischen Start von Programmen unmittelbar nach bzw. mit dem Neustart der CCU zu unterbinden. In aus meiner Sicht weit über 90 % aller Fälle ist das durchaus sinnvoll.
Siehst Du, bei mir ist das Verhältnis gerade genau andersrum. Bei mir sind es (lass mich nachschauen...) acht Programme, die diese Variable enthalten (bei 200+ Programmen auf der CCU). Und nach meinen Beobachtungen macht das System genau das, was ich von ihm erwarte.
dtp hat geschrieben:
05.12.2018, 10:43
Ich kann Dein Szenario mit den Rollläden ehrlich gesagt nicht ganz nachvollziehen.
Dann spiele dieses gedanklich mal nicht an einem manuell ausgelösten Reboot durch, bei dem man ggf. vor dem System sitzt, sondern an einem recht wahrscheinlichen Szenarion eines kurzzeitigen (wenn auch seltenen) Spannungsausfall. Und der kommt mit hoher Wahrscheinlichkeit, wenn Du vielleicht gerade nicht zu Hause bist (und im schlechtesten Zustand bist Du gerade im Urlaub).
dtp hat geschrieben:
05.12.2018, 10:43
Erstens wird eine CCU relativ selten neu gestartet (zumindest sollte sie das)
Genau, und warum muss ich denn ein System für diesen Fall so beeinflussen?
dtp hat geschrieben:
05.12.2018, 10:43
und zweitens kommt es noch seltener vor, dass ausgerechnet unmittelbar nach dem Neustart ein Programm zum Steuern von Aktoren ausgeführt werden muss.
Es muss genau dann, wenn um beim obigen Beispiel zu bleiben, der Zustand von Aktoren in einen für (z.B.) diesen Zeitpunkt vorgesehen Zustand gebracht werden soll, oder eben im Fall von Rollladenaktoren mit ihrem 50%-Behanghöhen-Startwert in die elektronische Sollstellung gebracht werden sollen (sie laufen ja nicht, sondern in dem Fall wird nur die vom Aktor übermittelte Stellung auf die tatsächliche Sollstellung gebracht. Anderes Beispiel Heizungssteuerung durch selbst eingebaute Aktoren (OK, sicherlich ein verschwindend geringer Anteil der Anwender). Hier ist es eben auch zielführend, die Bedingungsprüfung direkt nach dem Systemstart durchzuführen.

Noch ein einfaches Beispiel. Eine Außenbeleuchtung soll in der Nacht eingeschaltet sein. Dazu ist im Zeitmodul die Zeit von 22:00 bis 06:00 Uhr hinterlegt. Im DANN wird die Beuchtung eingeschaltet und im SONST aus. Soweit einfach. Was passiert, wenn nun die Systemvariable im WENN verknüpft ist? Auch bei einem Reboot in der Zeit nach 22:00 Uhr bzw. bei jedem Reboot wird die Lampe ausgeschaltet. Ist das zielführend? Eher nicht. Das System macht nicht, was der Anwender beabsichtigt hat, aber das, was er programmiert hat.. Aber so ist es angelegt.
dtp hat geschrieben:
05.12.2018, 10:43
... gesamte System tot, so dass z.B. Zustandsänderungen von Sensoren nicht erfasst werden können. Alleine dadurch entstehen schon Inkonsistenzen im System, die erst mit erneuter Erfassung eines Sensorzustands bereinigt werden können.
Ja, und Fenstersensoren haben grundsätzlich den Zustand "geschlossen" bei einem Systemstart, auch wenn die Fenster vorher auf waren. Das Problem wirst Du auch mit der Variable nicht in den Griff bekommen (außer Du bildest die Fenstersensoren in Systemvariablen ab).
dtp hat geschrieben:
05.12.2018, 10:43
Hinzu kommt, dass hier sehr viele User davon berichtet haben, dass ihre CCU sich nach einem Neustart seltsam verhält
Jo, weil sie es so programmiert haben. Oft auch durch eine Benutzung der Option "SONST". Die CCU macht das nicht von allein, sondern auf Grund der Ergebnisse der Bedingungsprüfungen. Siehe auch mein einfaches Beispiel oben. Und diese hat der Anwender in Programmen angelegt. Dort kann man ja, wenn man es nicht besser weiß, die Systemvariable einsetzen. Und es ist ja auch zielführend. Nur ein globales Einfügen in alle Programme ist eben nicht zielführend. Insbesondere nicht, wenn das SONST im Programm Verwendung findet. Und darum geht es.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

dtp
Beiträge: 10655
Registriert: 21.09.2012, 08:09
System: CCU
Wohnort: Stuttgart
Hat sich bedankt: 320 Mal
Danksagung erhalten: 501 Mal

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von dtp » 17.12.2018, 07:32

Xel66 hat geschrieben:
05.12.2018, 11:04
Noch ein einfaches Beispiel. Eine Außenbeleuchtung soll in der Nacht eingeschaltet sein. Dazu ist im Zeitmodul die Zeit von 22:00 bis 06:00 Uhr hinterlegt. Im DANN wird die Beuchtung eingeschaltet und im SONST aus. Soweit einfach. Was passiert, wenn nun die Systemvariable im WENN verknüpft ist? Auch bei einem Reboot in der Zeit nach 22:00 Uhr bzw. bei jedem Reboot wird die Lampe ausgeschaltet. Ist das zielführend? Eher nicht. Das System macht nicht, was der Anwender beabsichtigt hat, aber das, was er programmiert hat.. Aber so ist es angelegt.
Wenn ich hierzu noch mal kurz mein Eingangsposting zitieren darf:
dtp hat geschrieben:
16.08.2015, 11:30
5. In WebUI-Programmen, die beim Start der CCU nicht mehr ausgeführt werden sollen, füge in JEDE Wenn- bzw. Sonst-Wenn-Abfrage die UND-verknüpfte Zusatzbedingung "CCU SV Status Normalbetrieb nur prüfen" ein. Vermeide auf jeden Fall Sonst-Abfragen am Ende dieser WebUI-Programme, da diese SONST-Zweige nach einem Neustart der CCU definitiv ausgeführt werden.
Ich persönlich habe kein einziges Programm, in dem ich einen SONST-Zweig nutze. Das macht für mich vieles einfacher und nachvollziehbarer.
CCU3 mit stets aktueller FW und den Addons "CUxD" und "Programmedrucken", ioBroker auf Synology DiskStation DS718+ im Docker-Container;
einige Projekte: zentrales Push-Nachrichten-Programm zPNP, DoorPi-Videotürsprechanlage, An- und Abwesenheitsdetektion per Haustürschloss, zentrales Programm zur Steuerung von Beschattungsgeräten zBSP.

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von Xel66 » 17.12.2018, 13:45

dtp hat geschrieben:
17.12.2018, 07:32
Ich persönlich habe kein einziges Programm, in dem ich einen SONST-Zweig nutze.
Ich meide das SONST auch größtenteils. Aber mit der hier diskutierten Vorgehensweise (globales Sperren von Programmen bei Systemstart) schafft man sich ein Problem, das man ohne dieses Vorgehen nicht hätte und letztenendes die Funktionalität (SONST) auch noch zusätzlich einschränkt bzw. fehlanregt.

Ich habe aber noch nirgends gelesen, dass den Anwendern, die das so global einsetzen, geraten wurde, in den betreffenden Programmen das SONST nicht zu benutzen. Das ist aber die logische Konsequenz, die sich daraus ergibt. Mit dem Vorgehen macht man also zwei der vom Hersteller vorgesehenen und in vielen Fällen zielführenden Funktionalitäten kaputt (einerseits, das Hinstellen von Zuständen, die auf Grund der Gegebenheiten das Soll zu diesem Zeitpunkt darstellen - z.B. Rollladen nachts runter- und andererseits die Funktionalität der logischen Verknüpfung "SONST"). Man schafft also Probleme, wo eigentlich keine sind. Sinnvoll ist in meinen Augen irgendwie anders.

Aber die Diskussion führt zu nichts. Wenn jemand alle seine Programme bei Systemstart sperren will, dann soll er das tun. Dann ist es aber nicht zielführend, anschließend darüber rumzujammern, dass die CCU nicht das macht, was man programmiert hat. Kann sie ja auch nicht, weil der Anwender das Hinstellen konsistenter Zustände kaputgemacht hat. Gerade bei Zeittriggern kann sie das dann nicht mehr, weil ggf. die Triggerpunkte schon Vergangenheit sind. Mein Statement: Der Hersteller hat sich was dabei gedacht, diese Bedingungsprüfung bei Systemstart einzubauen. Für die Programme ist der Anwender selbst verantwortlich. Es ist zielführend, einzelne (ggf. sicherheitsrelevante) Programme wie Keymatic etc. zu sperren. Eine globale Sperrung aller Programme ist nicht zielführend, besonders nicht, wenn man die Funktionalität "SONST" nutzen will. Und bei Programmen, die z.B. durch Tastenbetätigung getriggert werden, ist das sogar überflüssig, weil deren Bedingungsprüfung beim Systemstart kein WAHR ergeben kann.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

SMA
Beiträge: 95
Registriert: 16.04.2015, 13:28

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von SMA » 28.03.2019, 09:15

Und noch ein Hinweis, der sich erst im Laufe dieses Threads herausgestellt hat. Das nachfolgende Programm scheint erst bei Systemen mit einer gewissen Mindestanzahl angemeldeter HM-Komponenten reibungslos zu funktionieren. Dabei ist aber derzeit unklar, wo die Grenze liegt. Eine zuverlässige Funktionsweise dürfte nach Erfahrungsberichten für Systeme mit mindestens 20 bis 30 Komponenten gegeben sein.
Hallo dtp,

es ist schon eine Weile her bei mir. Gibt es dazu eigentlich mittlerweile Neuigkeiten/Lösungen? Ich habe bisher leider in meinem kleinen Home-Setup keine Lösung dafür gefunden... Zwischenzeitlich hatte ich überlegt, einfach 30 CUxD-Geräte anzulegen...

Grüße
SMA
Privat
1 Kanäle in 1 Geräten und 16 CUxD-Kanäle in 1 CUxD-Geräten:
1x CUX28, 1x HM-Sec-SCo


Ehemalig studentische Projektgruppe
Übersicht des Haus-Projekts (Neubau)
1x CCU2 (Untergeschoss/Stahlbau) || 2x LAN-Gateway (Erdgeschoss/Dachgeschoss)

527 Kanäle in 238 Geräten und 64 CUxD-Kanäle in 17 CUxD-Geräten:
9x HM-Sen-MDIR-O-2, 16x CUX90, 12x HM-LC-Sw2-FM, 18x HM-PB-6-WM55, 33x HM-Sec-SCo, 21x HM-Sec-SD, 19x HM-LC-Bl1PBU-FM, 24x HM-LC-Sw1PBU-FM, 16x HM-TC-IT-WM-W-EU, 19x HM-LC-Sw1-FM, 9x HM-PBI-4-FM, 3x HM-Sec-SD-Team, 1x HM-Sec-TiS, 10x HM-Sec-SC-2, 3x HM-CC-VG-1, 5x HM-Sec-MDIR-2, 2x HM-LC-Sw4-SM, 1x HM-Sen-Wa-Od, 5x HM-LC-RGBW-WM, 1x CUX28, 1x HM-Sen-EP, 3x HM-LC-Dim1T-FM, 1x HM-LC-Sw4-DR, 1x HM-LC-Dim1TPBU-FM, 2x HM-WDS10-TH-O, 1x HM-Sec-WDS-2, 2x HM-ES-PMSw1-Pl, 14x HMW-LC-Sw2-DR, 1x HM-WDS100-C6-O, 2x HMW-IO-12-Sw7-DR

dtp
Beiträge: 10655
Registriert: 21.09.2012, 08:09
System: CCU
Wohnort: Stuttgart
Hat sich bedankt: 320 Mal
Danksagung erhalten: 501 Mal

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von dtp » 28.03.2019, 09:22

Ehrlich gesagt habe ich diesbezüglich keine weiteren Nachforschungen unternommen, weil ich das Problem selbst nicht habe und auch noch nie hatte. 8) :roll:
CCU3 mit stets aktueller FW und den Addons "CUxD" und "Programmedrucken", ioBroker auf Synology DiskStation DS718+ im Docker-Container;
einige Projekte: zentrales Push-Nachrichten-Programm zPNP, DoorPi-Videotürsprechanlage, An- und Abwesenheitsdetektion per Haustürschloss, zentrales Programm zur Steuerung von Beschattungsgeräten zBSP.

Messiahs
Beiträge: 11
Registriert: 22.10.2018, 20:20

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von Messiahs » 14.04.2019, 08:44

Xel66 hat geschrieben:
17.12.2018, 13:45
Eine globale Sperrung aller Programme ist nicht zielführend,....
Vielleicht nicht bei deinem Setup, bei meiner Umgebung wäre es sehr hilfreich.
Aus meiner Sicht ist es noch weniger zielführend "vorinstallierte" Systemvariablen umzubenennen und unnötigen Programmcode zu generieren.
Früher oder später fällt einem soetwas auf die Füße, weil der Hersteller bei einem nächsten FW-Update "seinen" Systemvariablen-Name erwartet.
Lass es einfach den Nutzer entscheiden. Wichtig wäre, dass eine Option über die automatische Programmausführung angeboten wird.
Gerne auch als Option "Programm bei Neustart automatisch ausführen" für jedes einzelne Programm (ähnlich der Option "systemintern").

Gruß
Messi

Benutzeravatar
Black
Beiträge: 5463
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 418 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von Black » 14.04.2019, 10:59

relativ unwahrscheinlich... die benannte variable hat von EQ3 die feste ID 950 und wird danach auch intern behandert (bzw über den Identifier ID_PRESENT)

in der rega und in den programmen sind namen schall und rauch, da geht alles über die IDs (Scripte mal ausgenommen)

es macht durchaus Sinn, ein kontrolliertes hochfahren zu erhalten... (machen SPSen ja auch mit ihren Anlauf OBs 100-102)

es geht auch auf der HM umzusetzen,

wie immer führen da einige Wege nach Rom,- es gibt nicht den goldenen Weg. Meinen würdest du wahrscheinlich auch nicht nehmen wollen, obwohl der bei mir perfekt funktioniert.

Black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von Xel66 » 14.04.2019, 11:19

Messiahs hat geschrieben:
14.04.2019, 08:44
Vielleicht nicht bei deinem Setup, bei meiner Umgebung wäre es sehr hilfreich.
Dann hast Du Deine Programme so angelegt, dass sie abgearbeitet werden.
Messiahs hat geschrieben:
14.04.2019, 08:44
Früher oder später fällt einem soetwas auf die Füße, weil der Hersteller bei einem nächsten FW-Update "seinen" Systemvariablen-Name erwartet.
Ist in dem Falle eher mit an Sicherheit grenzender Wahrscheinlichkeit nicht zu erwarten, da die Umbenennung lediglich in WebUI erfolgt und die CCU intern mit den iseID arbeitet, Benamungen von Systemvariablen grundsätzlich vorgesehen sind, diese Variable nicht für interne Zwecke benutzt wird und es gibt noch vielerlei anderer Gründe.
Messiahs hat geschrieben:
14.04.2019, 08:44
Lass es einfach den Nutzer entscheiden.
Mach ich doch. Kann jeder machen, wie er will. Eine sauberere Programmierung wäre aber zielführender.
Messiahs hat geschrieben:
14.04.2019, 08:44
Wichtig wäre, dass eine Option über die automatische Programmausführung angeboten wird.
Da fangen die Missverständnisse schon an. Es wird kein Programm automatisch ausgeführt (im Sinne, wie man eine Ausführung in WebUI über die Schaltfläche anregen kann, bei dem grundsätzlich der erste Dann-Zweig abgearbeitet wird), sondern es werden die vom Nutzer angelegten Bedingungen geprüft und dann der Aktionszweig durchlaufen, der bei der Bedingungsprüfung ein WAHR ergibt.
Messiahs hat geschrieben:
14.04.2019, 08:44
Gerne auch als Option "Programm bei Neustart automatisch ausführen" für jedes einzelne Programm (ähnlich der Option "systemintern").
Ich sage mal voraus, dass eine solche Option mehr Probleme, Missverständnisse und Supportfälle generieren wird als der jetzige Zustand. Generieren wir mal ein Beispiel. Du legst ein Programm an, welches in der Nacht bestimmte Lichter einschalten soll. Dieses Programm wir im jetzigen Zustand bei einem Reboot oder Systemstart nach Sonnenuntergang die Lichter korrekt einschalten. Mit aktivierter Option wird dieses erst am Folgetag passieren. Was ist nun richtiger? Ich behaupte mal, ersteres, denn der Nutzer erwartet das Verhalten gemäß seiner Programmierung. Das Missverständnis beginnt schon damit, dass die Option impliziert, dass die Lichter in diesem Fall grundsätzlich beim Systemstart eingeschaltet würden. Und dem ist ja definitiv nicht so.

Dieses ist jetzt ein "sichtbares" Beispiel. Was ist mit Programmen, die im Hintergrund irgendwelche Zustände und Systemvariablen hinstellen. Das Ergebnis ist kaum vorhersagbar. Hierfür ein Beispiel: das Setzen einer Systemvariable Heizperiode oder Sommerzeit, welche für Heizungs- oder Beschattungslösungen eingesetzt wird. Hier würde immer bei falsch gesetzter (weil vorher "falsch" gespeicherter) Option der Zustand hinterlegt, der bei der letzten Systemsicherung herrschte.

Spätestens beim Einspielen eines Backups fällt dem Nutzer sowas auf die Füße und er muss alle sonst automatisch gesetzten Zustände kontrollieren und ggf. korrigieren muss (was man z.B. via WebUI derzeit nicht mal kann). Anwender, die jetzt schon mit der Logik der CCU auf Kriegsfuss stehen, wird das noch mehr überfordern, weil sich nichts wie erwartet verhält.

Und ich sage mal voraus, dass viele Anwender die Option mangels besseren Wissens an Stellen setzen, wo es absolut nicht zielführend ist, weil immer wieder behauptet wird, dass alle Programme bei Systemstart ausgeführt werden, was definitiv faktisch falsch ist. Im Nachgang wundern sie sich über inkonsistenten Zustände. Bestes Beispiel war ein User, der die Sperrvariable auf Grund der falsch verstandenen "Empfehlung" aus dem Forum in alle seine Programme und Verzweigungen eingebaut hat. Und genau so würde es mit dieser Option geschehen. Es werden beim Systemstart die Bedingungen geprüft, denn sonst würde der Lösungsansatz mit der Anwesenheitavariable (iseID 950) nicht funktionieren. Merkst Du was? Insofern, jeder ist der Funktionalität seiner Automation eigener Programmierer. :-) Und wenn er sein System auf den Bauch legen will, dann hat er auch die Freiheit dazu. (Mein Wort zum Sonntag :-) )

Gruß Xel66

EDIT: @black Danke für die Unterstützung (komme mir schon vor, wie der einsame Rufer in der Wüste), habe am Smartphone zu lange getippt und Dich dabei wiederholt. Lass es aber trotzdem stehen.
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Messiahs
Beiträge: 11
Registriert: 22.10.2018, 20:20

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von Messiahs » 14.04.2019, 15:45

Naja, kann man alles so sehen, muss man aber gewiss nicht.
Für mich sieht eine sauberere Programmierung zumindest anders aus.
Ich kann auch jeden Tag mein Auto starten und dann überlegen, ob ich überhaupt losfahren muss...

Fest steht zumindest, dass das jetzige Verfahren alles andere als Einsteigerfreundlich ist und nur ein Workaround für fehlende Grundfunktionalitäten darstellt (der m.W. nicht mal für alle Anweder zuverlässig funktioniert).

P.S. Die "Umbenennung" der Systemvariable war nur ein Beispiel.. vielleicht wird auch mal der dort interpretierte Wert interpretiert oder was auch immer...

Benutzeravatar
Black
Beiträge: 5463
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 418 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU

Beitrag von Black » 14.04.2019, 17:00

Ein Beispiel für so eine unsaubere Programmierung ist das tata fahren von Rollos nach einem Reboot. Immer wieder gerne von Anfängern wiederholt. Ist mir früher auch passiert zu anfangszeiten.

Die relevanten Programmen von mir sind so aufgebaut dass sie zwischen manuellem Start, Reboot und normalen Trigger unterscheiden.

Es ist nicht bei jedem Prog notwendig. Gibt aber welche wo es essentiell ist

Just my 2 Cent, black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Antworten

Zurück zu „HomeMatic Tipps & Tricks - keine Fragen!“