nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Die Zustände statt mit Logikvariablen, mit Wertelisten anzubilden und bei einem Reboot den Zustand "unbekannt" zu setzen, bis Sensoren die Zustände an CCU übermitteln ist doch einfach genial (bei zustand "unbekannt" passiert eben nix).
Bei Zustand "CCU rebootet" mit der Standardlösung wird auch kein Programm abgearbeitet. Die richtigen Zustände werden nach Übermittlung der Sensoren hingestellt. Wo ist der Unterschied? Wird die CCU nicht durch "Stecker ziehen" neu gestartet, sind die Zustände vor dem Runterfahren bekannt und werden abgespeichert. Der einzige Pferdefuß sind Batteriesensoren. Da muss man sich anders behelfen. Aber auch hier helfen Systemvariablen.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Kein Rollladen tanzt Samba, weil die SysVars nicht passen, oder wird gefahren, weil die SysVar den falschen Wert enthält.
Wenn die Systemvariable nicht den richtigen Zustand enthält, dann ist was anderes im Argen. Auch diese Lösung kann nicht verhindern, dass die CCU falsche Zustände gespeichert hat. Sie stellt nur einen "vorgegebenen" hin. Der muss dann mit der Realität nichts zu tun haben. Nun denn, wenn's hilft.... Bei mir sind allerdings noch keine Rollladen Ballett gefahren, weil ich die CCU neu gestartet habe. Unter anderem, weil ich Steuerungen über SONST weitgehend vermeide.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Berechnungen von täglichen Skripten können gesteuert abgearbeitet werden (Bsp. Timer-Skripte, Kalenderdatebberechnung, setzen von Sonnendaten aus einer CSV-Datei, Heizparameter ermitteln, u.v.m.).
Eine Monsterlösung für Probleme, die man sich mit anderen Monstern geschaffen hat. Timer-Scripte? Nutzt der Normaluser eher weniger. Für andere gibt es CUxD-Timer, die ihren Stand auch über einen Reboot behalten. Kalenderdatenberechnung? Hmmm... Einige wenige Zustände sind für eine Hausautomation interessant, aber wie ich schon im dazugehörigen Thread geschrieben habe, interessiert es die CCU wenig, wie ein Feiertag heißt, sondern nur, ob ein Feiertag ist, um dann bestimmte Aktionen nicht oder zu anderen Zeiten ablaufen zu lassen. Da tut es auch das wesentlich bedienerfreundliche Feiertagsscript, das die Tage berechnet. Das Kalenderscript ist für mich schon grenzwertig, weil man die Daten händisch erfassen muss, es aber in der GUI keine Möglichkeit gibt, diese einigermaßen komfortabel einzurichten. Um Termine in einer Visu darzustellen gibt es iCal-Adapter, die den Job wesentlich komfortabler erledigen und man muss Daten nur an einer Stelle pflegen und hat mit allen Devices den gleichen Datenstand. Außerdem ließe sich das Script bei Systemstart auch ohne die Beteiligung der Monsterlösung abarbeiten. Das System würde das auch out of the box tun, denn so ist es vorgesehen.
Sonnendaten aus CSV? Wenn man es braucht... Wieviele Anwender davon gibt es? Sonnenauf- und -untergang stellt das System selbst zur Verfügung. Es gibt durchaus weniger pflegeintensive Ansätze. Und damit meine ich nicht unbedingt das Sonnenstandsscript. Selbst das ist für viele Anwender der Overkill. Man benötigt es eigentlich nur für Elevationsabhängige Steuerungen und um Astro-Ereignistrigger vorzuziehen. Verzögerungen kann man im System selbst abbilden und azimutale Steuerungen lassen sich teils mit reinen Zeitsteuerungen abbilden.
Heizparameter kann man über Temperaturen ermitteln. Ich wüsste nicht, was diese Lösung dabei helfen soll. Die Heizperiode kann man in einer Systemvariable speichern und die ist auch nach einem Reboot da. Sonstige Zeitsteuerungen sind in den Thermostaten hinterlegt. Eine solche Krücke baucht man wieder nur, wenn man z.B. die Heizungskompenenten per Script steuert, was aber nur bei Verwendung der alten Thermostate einen wirklichen Nutzen bringt. In in aktueller Hardware vorhandenen Zeitsteuerungen und die normalen Programmmöglichkeiten sind da viel nützlicher und ressourcenschonender.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Hinzu kommt, dass eben die Programme ganz anders aufgebaut werden können, als es in den Anfängerbeiträgen gebetsmühlenartig propagiert wird.
Die "gebetsmühlenartigen" Empfehlungen sind eben auch für den weniger ambitionierten Anwender und Einsteiger geeignet, der auch mit dem hier verlinkten Lösungsansatz überfordert wäre (nicht die Lösung, in der es hier im Thread eigentlich geht!). Sie folgen dem KISS-Prinzip (keep it simple and stupid). Und sie sind für alle Anwender überschaubar. Letztendlich orientieren sich diese Empfehlungen an den Eigenheiten des Systems. Man braucht sich nur hier im Forum mal umschauen, an welchen wirklichen "Problemen" es manchmal scheitert. Da würde die Lektüre der Anwendertipps und deren Anwendung viele Fragen von vornherein beantworten. Das Script kann das eher nicht, denn Einsteiger stoßen teils schon bei simplen Konstrukten an Verständnisprobleme. Ein solches Monster würde es nicht besser machen.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Der Nachteil bei dem "Sonst,Wenn-Gefrickel" ist doch dass "Abfangen" aller Eventualitäten, je mehr Dinge im WENN berücksichtigt werden sollen.
Was hilft da diese Lösung im täglichen Betrieb? Nichts, da sie nur beim Reboot zur Anwendung kommt. Insofern ein mehr als überschaubarer Nutzen.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Ebenso das gerne propagierte "Programme Splitten" entfällt bei BadenPowers Programmaufbauten.
Nicht unbedingt und es ist nicht zielführend, Monster zu bauen, die im Nachgang niemand mehr überschauen kann (KISS-Prinzip). Dedizierte Programme für genau einen Vorgang sind überschaubarer und für die Programmübersicht (zusammengehörige Funktionen) hat sich eine standardisierte Namensgebung bewährt. Beispiel: Alle Programme, die die Heizung steuern, beginnen eben mit dem Namen "Heizung...". Und gegensätzliche Aktionen in einem Programm mit den gleichen Triggern hat schon so manche Anwender zur Verzweiflung gebracht, weil die CCU eben ihre "eigene Logik" besitzt oder weil der Anwender eine falsche Vorstellung hat (will eine Lampe an der Haus- UND an der Wohnzimmertür einschalten - abgebildet in Logik aber ein ODER notwendig). Auch da kann der Lösungsansatz wenig helfen. Das Splitten von Programmen ist eher ein optisches als ein funktionelles Problem.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
So aufgebaute Programme sind wesentlich übersichtlicher und man verliert auch nicht (auch als Anfänger) die Übersicht, selbst wenn man auf über 100 Zustände in einem Programm reagiert.
Wer baut sowas? Einsteier eher nicht. Das Programm läuft bei Reboot. Wie oft bootest Du Dein System? Wenn das häufiger außer bei Updates notwendig ist, dann hast Du ein anderes Problem, welches gelöst gehört, und nicht das eine Problem mit einem Monster bekämpfen. Und Einsteiger bauen eher selten Programme mit 100 Triggern. Wenn Du häufiger Stromausfälle hast, dann würde ich eher an eine USV denken, als per Software Probleme zu lösen, die ich ohne sie gar nicht hätte.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Ob der Aufwand der Reboot-Abarbeitung umfänglicher ist, als in jedem Programm den ccu-Reboot-Status x-fach mit einzubauen, oder das 1x im Programm zu prüfen, muss schliesslich jeder selbst entscheiden.
Jo, wenn er es überblicken kann. Man benötigt es eben nicht in jedem Programm. Den "unbekannt"-Status müsste man dann aber in jedem Programm berücksichtigen. Ich sehe keine Vereinfachung - eher im Gegenteil. Es gibt z.B. in meinem System (>200 Programme, siehe Sig.) nur ganz wenige Programme (genau sechs - gerade nachgeschaut), die die Reboot-Variable enthalten. Weil eben keine Monster vorhanden sind, deren Zustand sich nicht abschätzen lässt, und die mit solchen Lösungen bekämpft werden müssen. Und vier von den sechs Programmen enthalten sie nur, um durch den Systemstart bedingte unplausible und wiederholte Meldungen per TTS, Mail und Push bis zum abgeschlossenen Systemstart zu unterdrücken bzw. einen durchgeführten Systemstart über die eben genannten Kanäle zu melden. Macht noch zwei funktionelle Programme, die ich bei "Reboot" sichern will (u.a. Keymatic). Der Rest der Programme ist "eigensicher", weil einfach, angelegt.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Einmal ein paar Programme anlegen und eine gänzlich vom Standard abweichende und übersichliche Programmaufbaumöglichkeit ist eben ein nicht zu unterschätzender Nutzen.
Welcher? Wenn jemand ein System aufbaut, welches sich grundsätzlich vom Standard unterscheidet und eigentlich ein Pflegefall ist, ist es für andere Anwender umso schwerer, sich dort reinzudenken. Man stelle sich nur mal vor, jemand "erbt" so ein System und ist deswegen auf Hilfe angewiesen oder kommt durch Erwerb in dessen Besitz. Es gab auch in der Vergangenheit schon hier ein paar Beiträge, die sich mit derartigen Problemstellungen (Systempflege bei Kauf/Scheidung/Tod) beschäftigten. Wer soll solche Pflegefälle dann noch überblicken? Bei Monsterprogrammen ist es umso schwieriger. Und letztendlich ist "Übersichtlichkeit" nur ein Nutzen für den Anwender. Der CCU ist es egal wie ein Programm heißt und an welcher Stelle es im GUI steht.
nimmnenkeks hat geschrieben: ↑22.10.2018, 23:37
Klar, kann man alles machen "wie immer", ist und bleibt aber immer noch "k...."
Etablierte Standards haben sich im Leben und in der Industrie durchgesetzt und sind auch zielführend (nicht umsonst gibt es sowas wie DIN und andere Vorschriften). Nur Standards ermöglichen auch eine Interaktion verschiedener Systeme. Wenn man krampfhaft etwas anders machen will nur um des Andersseins willen, dann muss man eben selbst mit den Auswirkungen zurecht kommen. Das heißt nicht, dass man nichts neu erfinden kann! Ganz und gar nicht. Ich will keine Weiterentwicklung verteufeln, aber der oben verlinkte Ansatz (nicht die Lösung, in der es hier im Thread eigentlich geht!) ist m.E. den Teufel mit dem Beelzebub auszutreiben. Man baut sich eine Monsterproblemlösung für ein vorher ins System geholte Monsteranwendung. Aber mit dem "Neu" hat man bei bestehenden komplexen Systemen so seine Probleme. Das ist so wie ein Sportfahrwerk unter ein Standardauto zu schrauben. Bei den in Wohngebieten teilweise eingebauten Bodenwellen zur Verkehrsberuhigung hat der "ambitionierte Anwender" dann seine Probleme. Er muss dann mit seinem "Anderssein" zurechtkommen. Kann man machen - muss man aber nicht. Jeder wie er will.
Fazit: Es ist wie es ist. Die hier eigentlich im Thread-Topic vorgestellte Methode mit der unlöschbaren Anwesenheitsvariable ist die Lösung, mit der die meisten Anwender zurecht kommen, die erprobt und übersichtlich ist, und deren Nebenwirkungen man abschätzen kann. Man benötigt dazu genau ein Programm und diese spezielle Variable und kann damit alle Programme, bei denen es notwendig erscheint, gegen Ausführung beim Start sichern, wenn es denn überhaupt notwendig ist.
Gruß Xel66
