Howto - Vermeidung von Programmstarts nach Neustart der CCU
Moderator: Co-Administratoren
-
- Beiträge: 475
- Registriert: 05.12.2016, 19:04
- Hat sich bedankt: 31 Mal
- Danksagung erhalten: 4 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
Ich habe zum Thema Reboot noch eine andere Frage. Es wurde hier schon mehrfach diskutiert, daß die Geräte, insbesondere die batteriebetriebenen, nach dem Neustart einen undefinierten Status haben und man dieses Manko lindern könnte, indem man den Status in Systemvariablen sichert, deren Inhalt bei einem ordnungsgemäßen Reboot erhalten bleibt. Nun gibt es ja auch das schöne Addon CUXD, mit dem sich virtuelle Geräte erstellen lassen. Ich nutze diese z.B. zur automatisierten Ermittung statistischer Daten (MAX, MIN, Durchschnitt), mußte aber feststellen, daß die CUX-Geräte leider genauso ihre Daten vergessen wie die realen Geräte in der CCU. Wäre es nicht möglich bzw. sinnvoll, wenn wenigstens die virtuellen CUX-Geräte ein Gedächtnis über den Reboot hinaus hätten? Momentan sehe ich als einzigen Ausweg, daß man die statistischen Daten über eigene Programme mit Hilfe von Systemvariablen berechnet. Wie ist da Eure Meinung zu?
Viele Grüße,
debianatoe
debianatoe
- robbi77
- Beiträge: 13919
- Registriert: 19.01.2011, 19:15
- System: CCU
- Wohnort: Landau
- Hat sich bedankt: 182 Mal
- Danksagung erhalten: 749 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
Stimmt ja so eigentlich nicht …nach dem Neustart einen undefinierten Status haben
Die alten TFKs haben nach einem Neustart immer den Zustand geschlossen, und dieser ist immer so definiert. Nur mit dem unterschied das er nicht dem realen Zustand entspricht, wenn das Fenster während dem Neustart geöffnet war.
-
- Beiträge: 475
- Registriert: 05.12.2016, 19:04
- Hat sich bedankt: 31 Mal
- Danksagung erhalten: 4 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
Vielen Dank für die Präzisierung und Richtigstellung! Am Problem ändert das allerdings nicht viel und es gibt ja auch noch andere batteriebetriebene Geräte neben den TFKs.robbi77 hat geschrieben: ↑30.01.2022, 13:12Stimmt ja so eigentlich nicht …nach dem Neustart einen undefinierten Status haben
Die alten TFKs haben nach einem Neustart immer den Zustand geschlossen, und dieser ist immer so definiert. Nur mit dem unterschied das er nicht dem realen Zustand entspricht, wenn das Fenster während dem Neustart geöffnet war.
Viele Grüße,
debianatoe
debianatoe
- Roland M.
- Beiträge: 9914
- Registriert: 08.12.2012, 15:53
- System: CCU
- Wohnort: Graz, Österreich
- Hat sich bedankt: 257 Mal
- Danksagung erhalten: 1421 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
Hallo!
Der Grund ist einfach: Während eines Neustarts der CCU, der ja auch ein paar Minuten dauert, kann so manch ein Fenster geöffnet oder geschlossen werden. Somit wäre auch der alte Zustand wieder falsch. Und zweiter Punkt: wenn man ein Miniprogramm "WENN Fenster auf DANN SV=wahr SONST SV=falsch" auf Änderung auslösen lässt, dann ändert sich der Zustand ja beim Neustart auch und die SV wird erst mit dem falschen Wert überschrieben.
Die einzige Abhilfe, die mir einfällt, wäre, der SV neben "offen" und "geschlossen" auch noch einen Zustand "unbekannt" zu geben und beim Neustart die SV auf "unbekannt" zu setzen. Somit wäre bis zum ersten eigenen Lebenszeichen des Sensors zumindest klar, dass der Status nicht vertrauenswürdig ist.
Roland
Meine Meinung ist, dass man sich über diese Eigenschaft im Bewussten sein sollte, ich für meine Person mache aber keine Klimmzüge über Systemvariablem.debianatoe hat geschrieben: ↑30.01.2022, 13:00Es wurde hier schon mehrfach diskutiert, daß die Geräte, insbesondere die batteriebetriebenen, nach dem Neustart einen undefinierten Status haben und man dieses Manko lindern könnte, indem man den Status in Systemvariablen sichert, deren Inhalt bei einem ordnungsgemäßen Reboot erhalten bleibt.
Der Grund ist einfach: Während eines Neustarts der CCU, der ja auch ein paar Minuten dauert, kann so manch ein Fenster geöffnet oder geschlossen werden. Somit wäre auch der alte Zustand wieder falsch. Und zweiter Punkt: wenn man ein Miniprogramm "WENN Fenster auf DANN SV=wahr SONST SV=falsch" auf Änderung auslösen lässt, dann ändert sich der Zustand ja beim Neustart auch und die SV wird erst mit dem falschen Wert überschrieben.
Die einzige Abhilfe, die mir einfällt, wäre, der SV neben "offen" und "geschlossen" auch noch einen Zustand "unbekannt" zu geben und beim Neustart die SV auf "unbekannt" zu setzen. Somit wäre bis zum ersten eigenen Lebenszeichen des Sensors zumindest klar, dass der Status nicht vertrauenswürdig ist.
Roland
Zur leichteren Hilfestellung bitte unbedingt beachten:
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
- Bezeichnung (HM-... bzw. HmIP-...) der betroffenen Geräte angeben (nicht Artikelnummer)
- Kurzbeschreibung des Soll-Zustandes (Was soll erreicht werden?)
- Kurzbeschreibung des Ist-Zustandes (Was funktioniert nicht?)
- Fehlermeldungen genau abschreiben, besser noch...
- Screenshots von Programmen, Geräteeinstellungen und Fehlermeldungen (direkt als jpg/png) einstellen!
-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...
-
- Beiträge: 475
- Registriert: 05.12.2016, 19:04
- Hat sich bedankt: 31 Mal
- Danksagung erhalten: 4 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
Für die Fenster sehe ich das genauso. Mir geht es hier aber mehr um die Statistiken von Meßgeräten. Da ist es verkraftbar, wenn man während des Reboots einen Ausfall der Meßwerte für ca. 10min hat. Aber es ist ärgerlich, wenn durch den Reboot um 22h abends die gesamte Tagesstatistik gelöscht wird. Und genau das passiert aktuell bei den 90er CUX-Geräten. Um das zu vermeiden, nutze ich das "Gedächtnis" der Systemvariablen.Roland M. hat geschrieben: ↑30.01.2022, 14:05Meine Meinung ist, dass man sich über diese Eigenschaft im Bewussten sein sollte, ich für meine Person mache aber keine Klimmzüge über Systemvariablem.
Der Grund ist einfach: Während eines Neustarts der CCU, der ja auch ein paar Minuten dauert, kann so manch ein Fenster geöffnet oder geschlossen werden. Somit wäre auch der alte Zustand wieder falsch. Und zweiter Punkt: wenn man ein Miniprogramm "WENN Fenster auf DANN SV=wahr SONST SV=falsch" auf Änderung auslösen lässt, dann ändert sich der Zustand ja beim Neustart auch und die SV wird erst mit dem falschen Wert überschrieben.
Die einzige Abhilfe, die mir einfällt, wäre, der SV neben "offen" und "geschlossen" auch noch einen Zustand "unbekannt" zu geben und beim Neustart die SV auf "unbekannt" zu setzen. Somit wäre bis zum ersten eigenen Lebenszeichen des Sensors zumindest klar, dass der Status nicht vertrauenswürdig ist.
Viele Grüße,
debianatoe
debianatoe
-
- Beiträge: 14297
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 601 Mal
- Danksagung erhalten: 1529 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
Kann man machen, wird aber relativ wenig nützen. Du verkomplizierst massiv das gesamte Systemsetup. Damit Du eine Zustand speichern kannst musst Du ja diese Systemvariable bei jeder Statusänderung mitführen. Dann musst Du auch noch dafür sorgen, daß dieser gespeicherte Staus (Systemvariable) persistiert wird (Sicherung der regadom), um auch bei einem unvorhergesehen Systemstart (Spannungsausfall) einen validen Status zu haben.
Dein Problem ist jetzt zusätzlich, dass dieser Default-Status auch beim Reboot gesetzt wird, also praktisch auch das gleiche Speicherprogramm triggert. Das Programm musst Du dann auch noch zusätzlich gegen eine Statusänderung bei Reboot sichern. Und das ganze Konstrukt kann noch zusätzlich durch das manchmal übliche Abschalten der zyklischen Statusmeldungen verkompliziert werden. Und den ganzen Spaß darfst Du dann sowohl für alle batteriebetriebenen Geräte, CUxD-Geräte und alle HmIP-Geräte machen (letztere werden auch beim Systemstart nicht abgefragt).
In meinen Augen ist es dagegen einfacher, solche Unwägbarkeiten bei der eigenen Programmierung zu berücksichtigen und etwas fehlertolerant seine Programme zu designen. Ein Beispiel aus meiner Programmierung: Wenn ich die Keymatic zum Verschließen des Hauses beim Verlassen aktiviere, bekommt sie als ersten Befehl den in der CCU gespeicherten Status und danach erst mit Verzögerung den eigentlichen Schließbefehl. So fange ich auch eventuelle mechanische Stellungsänderung durch Schlüsselbenutzung oder Drehen am Handrad ab (diese Maßnahmeverhindert auch ein "auf Block fahren" der Keymatic). Eine andere Fehlertoleranz ist, Programme nicht auf Defaultwerte von Sensoren zu triggern (reine Temperatursensoren werden z.B. auf 0°C gesetzt). Beispiel aus meiner Programmierung: ich triggere die Systemvariable "Heizperiode" nicht allein auf einen Sensorwert, sondern werte zusätzlich die Tiefsttemperatur des vorhergegangenen Tages aus.
Ich bin nicht grundsätzlich gegen diesen Workaround aus diesem Thread und benutze ihn auch zum Unterdrücken von Push-/Mailmeldungen beim Systemstart durch das Setzen von Defaultwerten oder Statusabfragen. Auch mein Keymatic-Programm habe ich damit gesichert. Aber ich finde es sinnfrei, ihn in jedes Programm einzubauen, ohne wirklich begriffen zu haben, wie das Teil wirkt und warum. Und jemand, der den Workaround in Programmen mit einem SONST einsetzt, hat die Wirkungsweise nicht begriffen. Just my2ct.
Gruß Xel66
Dein Problem ist jetzt zusätzlich, dass dieser Default-Status auch beim Reboot gesetzt wird, also praktisch auch das gleiche Speicherprogramm triggert. Das Programm musst Du dann auch noch zusätzlich gegen eine Statusänderung bei Reboot sichern. Und das ganze Konstrukt kann noch zusätzlich durch das manchmal übliche Abschalten der zyklischen Statusmeldungen verkompliziert werden. Und den ganzen Spaß darfst Du dann sowohl für alle batteriebetriebenen Geräte, CUxD-Geräte und alle HmIP-Geräte machen (letztere werden auch beim Systemstart nicht abgefragt).
In meinen Augen ist es dagegen einfacher, solche Unwägbarkeiten bei der eigenen Programmierung zu berücksichtigen und etwas fehlertolerant seine Programme zu designen. Ein Beispiel aus meiner Programmierung: Wenn ich die Keymatic zum Verschließen des Hauses beim Verlassen aktiviere, bekommt sie als ersten Befehl den in der CCU gespeicherten Status und danach erst mit Verzögerung den eigentlichen Schließbefehl. So fange ich auch eventuelle mechanische Stellungsänderung durch Schlüsselbenutzung oder Drehen am Handrad ab (diese Maßnahmeverhindert auch ein "auf Block fahren" der Keymatic). Eine andere Fehlertoleranz ist, Programme nicht auf Defaultwerte von Sensoren zu triggern (reine Temperatursensoren werden z.B. auf 0°C gesetzt). Beispiel aus meiner Programmierung: ich triggere die Systemvariable "Heizperiode" nicht allein auf einen Sensorwert, sondern werte zusätzlich die Tiefsttemperatur des vorhergegangenen Tages aus.
Ich bin nicht grundsätzlich gegen diesen Workaround aus diesem Thread und benutze ihn auch zum Unterdrücken von Push-/Mailmeldungen beim Systemstart durch das Setzen von Defaultwerten oder Statusabfragen. Auch mein Keymatic-Programm habe ich damit gesichert. Aber ich finde es sinnfrei, ihn in jedes Programm einzubauen, ohne wirklich begriffen zu haben, wie das Teil wirkt und warum. Und jemand, der den Workaround in Programmen mit einem SONST einsetzt, hat die Wirkungsweise nicht begriffen. Just my2ct.
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
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
-
- Beiträge: 475
- Registriert: 05.12.2016, 19:04
- Hat sich bedankt: 31 Mal
- Danksagung erhalten: 4 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
So negativ würde ich das nicht sehen. Ja, es wird komplizierter und ich bin für eine einfachere Alternative offen.
Das ist richtig und wird natürlich die Grundlast der CCU etwas erhöhen.
Diese Maßnahme würde aus meiner Sicht über das Ziel hinausschießen. Ich habe trotz Energiewende deutlich mehr geplante Reboots als Stromausfälle. Sollte sich das in Zukunft ändern, könnte man über eine USV nachdenken. Stand heute würde ich die seltenen Stromausfälle in Kauf nehmen.
Danke für den Tip! Das werde ich tun.
Diesen Hinweis verstehe ich nicht. Kannst Du das bitte genauer erläutern, wodurch das Abschalten der zyklischen Statusmeldung zu einem Problem werden könnte?
Nein, das werde ich nicht tun, weil das übertrieben wäre. Ich werde den Aufwand nur für die Geräte betreiben, bei denen mir die Statistik wichtig ist. Ich werde das auch erst einmal nur mit einem Gerät testen. Bei den meisten Geräten ist die Statistik nicht so wichtig, daß sich der Aufwand lohnen würde. Zumindest ist das meine persönliche Einschätzung, aber das kann natürlich jeder machen, wie er mag.
Vielen Dank für Deine Tips! Bei der Programmierung hat man meist nur den laufenden Betrieb vor Augen. Und Du hast vollkommen recht, daß man eigentlich auch den Fall des Neustarts in den Programmen berücksichtigen müßte. Ich werde das beherzigen und meine Programme mal diesbezüglich überarbeiten. Es ist allerdings schon Spezialwissen, daß TFKs beim Neustart geschlossen und reine Temperatursensoren auf 0°C gesetzt werden. Man müßte ja für jedes Gerät wissen, was die CCU beim Neustart für einen Default-Wert annimmt. Gibt es dazu eine Doku? Oder muß man sich das mühsam selbst erarbeiten? Konkret würde mich interessieren, was für ein Default-Status beim Wassermelder HmIP-SWD angenommen wird, denn der meldet mir bei jedem Neustart eine eingebildete Überschwemmung.Xel66 hat geschrieben: ↑30.01.2022, 14:29In meinen Augen ist es dagegen einfacher, solche Unwägbarkeiten bei der eigenen Programmierung zu berücksichtigen und etwas fehlertolerant seine Programme zu designen. Ein Beispiel aus meiner Programmierung: Wenn ich die Keymatic zum Verschließen des Hauses beim Verlassen aktiviere, bekommt sie als ersten Befehl den in der CCU gespeicherten Status und danach erst mit Verzögerung den eigentlichen Schließbefehl. So fange ich auch eventuelle mechanische Stellungsänderung durch Schlüsselbenutzung oder Drehen am Handrad ab (diese Maßnahmeverhindert auch ein "auf Block fahren" der Keymatic). Eine andere Fehlertoleranz ist, Programme nicht auf Defaultwerte von Sensoren zu triggern (reine Temperatursensoren werden z.B. auf 0°C gesetzt). Beispiel aus meiner Programmierung: ich triggere die Systemvariable "Heizperiode" nicht allein auf einen Sensorwert, sondern werte zusätzlich die Tiefsttemperatur des vorhergegangenen Tages aus.
Ich habe z.B. ein Frostwarnprogramm, das um so aktiver wird, je näher sich die Temperatur 0°C nähert. Wenn beim Neustart grundsätzlich erst einmal 0°C gemeldet werden, brauche ich mich also nicht zu wundern, daß es zu Fehlaktivitäten kommt. Wie wäre in diesem Fall Dein Programmiervorschlag? Ich denke, daß der Workaround von Seite 1 in diesem Fall das Einfachste wäre.
Und genau dafür würde ich das auch einsetzen wollen.
Das sehe ich genauso. Natürlich werde ich diesen Workaround nur in die Programme einbauen, in denen es nötig ist. Und das sind bei mir sicherlich nur wenige.Xel66 hat geschrieben: ↑30.01.2022, 14:29Auch mein Keymatic-Programm habe ich damit gesichert. Aber ich finde es sinnfrei, ihn in jedes Programm einzubauen, ohne wirklich begriffen zu haben, wie das Teil wirkt und warum. Und jemand, der den Workaround in Programmen mit einem SONST einsetzt, hat die Wirkungsweise nicht begriffen. Just my2ct.
Viele Grüße,
debianatoe
debianatoe
- robbi77
- Beiträge: 13919
- Registriert: 19.01.2011, 19:15
- System: CCU
- Wohnort: Landau
- Hat sich bedankt: 182 Mal
- Danksagung erhalten: 749 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
Einmal Neustarten und in der Webui die Zustände ansehen …Man müßte ja für jedes Gerät wissen, was die CCU beim Neustart für einen Default-Wert annimmt. Gibt es dazu eine Doku? Oder muß man sich das mühsam selbst erarbeiten? Konkret würde mich interessieren, was für ein Default-Status beim Wassermelder HmIP-SWD angenommen wird, denn der meldet mir bei jedem Neustart eine eingebildete Überschwemmung.
Für den Wassermelder weißt du es ja schon …
-
- Beiträge: 475
- Registriert: 05.12.2016, 19:04
- Hat sich bedankt: 31 Mal
- Danksagung erhalten: 4 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
So: ich habe den Test durchgeführt und die Original-"Anwesenheit" umbenannt. Nach ein paar Minuten war eine neue SV "Anwesenheit" vorhanden, d.h. HM-pdetect legt diese SV offenbar automatisch wieder an, wenn keine mehr da ist. Weitere Folgen muß ich jetzt beobachten.
Viele Grüße,
debianatoe
debianatoe
-
- Beiträge: 14297
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 601 Mal
- Danksagung erhalten: 1529 Mal
Re: Howto - Vermeidung von Programmstarts nach Neustart der CCU
Mal abgesehen davon, dass das in den wenigsten Fällen überhaupt einen Sinn ergeben kann (mir fällt momentan nicht mal einer ein), beraubt man sein System des Selbstheilungseffektes. Bei einem Reboot haben die TFK z.B. eben alle den Zustand "geschlossen" unabhängig davon, wie sie vorher standen oder in der Zwischenzeit verändert wurden. Mit aktiven zyklischen Statusmeldungen hat man nach spätestens einer Stunde wieder einen den tatsächlichen Gegebenheiten entsprechenden Status im System. Mit abgeschalteten Meldungen kann das dann durchaus etwas länger dauern (den trotz der deaktivierten Meldungen, werden trotzdem hin und wieder Statusmeldungen ausgesendet (braucht man ja allein schon wegen der Batteriestatusüberwachung). Nur bei klassischen HM-Tastern gibt es sowas nicht.debianatoe hat geschrieben: ↑30.01.2022, 18:44Kannst Du das bitte genauer erläutern, wodurch das Abschalten der zyklischen Statusmeldung zu einem Problem werden könnte?
Einfach wäre das, ja. Bei einem Programmiervorschlag kommt es ja auch auf die Nebenbedingungen an. Wie beschrieben, werte ich für meine Umschaltung die Vortageswerte mit aus. Ich habe in meinem System auch gleitende Durchschnittswerte. Die fangen solch plötzlichen Extremwerte von allein ab. Hier bleibt eben nur, nicht direkt auf den Messwert zu triggern, sondern auf einen gespeicherten Wert.debianatoe hat geschrieben: ↑30.01.2022, 18:44Wie wäre in diesem Fall Dein Programmiervorschlag? Ich denke, daß der Workaround von Seite 1 in diesem Fall das Einfachste wäre.
Ja, aber häufig sind hier auch Screenshots zu sehen, in denen der Workaround wegen definitiv falscher Aussagen zum Triggerverhalten beim Systemstart in alle Programme eingebaut wird. So z.B. auch in Programme, die durch eine Tastenbetätigung getriggert werden. Bei solchen Triggern ist es einfach von absolut jeder Sinnhaftigkeit befreit und beweist, dass derjenige Anwender nicht verstanden hat, worum es überhaupt geht, bzw. das solche Blödsinnsbehauptungen, dass beim Systemstart "alle Programme gestartet werden" auf fruchtbaren Boden gefallen sind. Auch durch eine noch so häufige Wiederholung gewinnt dieser Blödsinn nicht an Wahrheitsgehalt und beweist nur, dass diejenigen, die das behaupten, sich nicht mit der Funktionsweise des Systems auseinandergesetzt haben. Zumindest zählt das Verständnis der Funktionsweise der CCU nicht zu deren Kernkompetenzen. Ja, es werden beim Systemstart standardmäßig die Bedingungen von Programmen geprüft und ggf. auch ausgeführt, aber eben aus ganz anderen Gründen (weil die Prüfung einer Bedingung ein WAHR ergeben hat oder das Programm ein SONST enthält). Dass an der Aussage nichts dran ist, kann man selbst nachprüfen, wenn man sich mal die Zeitstempel der Programme nach einem Reboot anschaut. Man wird viele finden, die keinen bekommen haben. Hier wurde keine Bedingungsprüfung durchgeführt und schon gar nichts ausgeführt.debianatoe hat geschrieben: ↑30.01.2022, 18:44Natürlich werde ich diesen Workaround nur in die Programme einbauen, in denen es nötig ist. Und das sind bei mir sicherlich nur wenige.
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
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