HMIP SWDO Meldeverzögerung bei Schutz ändern

[nimmnenkeks]

... ein Auslöser/Trigger greift, der Systemzustand des TFK's noch nicht bekannt ist, wird die SysVar auf "unbekannt" gesetzt.

Nein, auch bei der tausendundelften Wiederholung gewinnt diese Aussage nicht an Wahrheitsgehalt. Aber ich habe keine Lust, das immer und immer wieder ausführlich darzulegen. Kurzversion: Es findet lediglich eine Bedingungsprüfung statt und zusätzlich werden Programme durch die Statusübermittlung von netzversorgten Aktoren (werden bei Systemstart abgefragt) getriggert.

"Reboot mit System und Ablauflogik"

Wenn man solche Konstrukte einsetzt, sollte man auch ganz genau wissen, was man tut und vor allem mal das System wenigstens ansatzweise verstanden haben....

Warum hat das so lange gedauert???
Habe mich echt gewundert, das DU so lange für Deine pers. Ablehnung einer alternativen Vorgehensweise benötigt hast.

Kann es sein, dass Du nicht wirklich liest, schreibe ich Swahili?

Was löst denn bitteschön bei einer Bedingungsprüfung etwas aus?

Ess soll auch Umsetzungen geben, die nicht nur auf netzbetriebene Aktoren basieren.
Schreibe bitte auch dazu, dass batteriebetriebene Sensoren teilweise bis zu 60min. benötigen, bis sie ihren Status melden.
Zumindest die IP-Sensoren (auch Aktoren wie die IP-Heizkörperthermostate).
Ist klasse, wenn man im Bad eine Lüftung auf Basis der Luftfeuchte umsetzen möchte...

Ein Anfänger wir mutmasslich keine alten Broken (HM-Classic) zu völlig überteuerten Preisen (gegenüber IP-Geräten) beziehen.


Scheinbar hast Du die Vorteile des Programmaufbaus von BadenPower noch nicht verstanden?

ALLE Auslöser/Trigger eines so aufgebauten Programms stehen in einem Block.
Wie geht das bitte bei "üblichem UI Programmaufbau" wenn die Sache etwas komplexer werden soll?
Klar kann man für jeden Furz ein Programm schreiben.
Doch wer hunderte von Programmen (kommt ja immer auf den individuellen Ausbauwunsch an) nutzt, um Komplexität (auch wieder relativ) zu vermeiden, dabei den Überblick behält...
der ist auch in der Lage einen Programmaufbau nach der von mir verlinkten Methode zu verstehen.

Nenne mir doch bitte die Vorgehensweise über die UI, ein Programm zu Testzwecken komplett (nicht nur das erste Dann) auszuführen, bei welchem das gesamte Programm durchlaufen wird.
Das geschieht über die VT's vortrefflich, da in der UI nutzbar.
Eine nützliche Möglichkeit, gerade bei Einstieg in Programmerstellung.

Ebenso kann man eine VT anlegen, welche die SysVar "SYS True" steuert.
Z.B macht ein extra angelegter "Raum"; nur für die dem Raum zugeordneten VT's, die Sache noch leichter, mal eben Szenarien zu testen.
Oder der Fall, "mal eben" alle noch dem verlinkten Programmaufbau erstellten Programme deaktiviern (mach das mal mit der Kästchenklickerei in der UI).
Die Unzulänglichkeiten der UI sind oft am Anfang nicht hinreichend bekannt, also warum diese mit dem üblichen Programmaufbau hinnehmen?

Kommen weitere Kenntnisse hinzu kommt man ja auch um Skripte nicht herum.
Erst recht nicht bei z.B. der detaillierteren Auswertung von Helligkeitswerten der IP-Sensoren (HmIP-SMI, HmIP-SMI55) für Beleuchtungszenarien.
Da muss man auch noch externe Tools nutzen, da die UI manche Werte gar nicht zulässt.

Selbstverständlich wird hier gern nach der "üblichen Vorgehensweise" beim Programmaufbau vorgegangen.
Es ist jedoch auch nix dabei mal über den Tellerrand zu schauen (auch wenn manche Antworten auf den Fred so verfasst sind ,als hätte "Jehova" gesagt).

Ein Hinweis auf alternative Vorgehensweise(n) schadet niemanden, er zeigt NUR andere Möglichkeiten.
Es jedem geneigten Leer dieses Freds selbst überlassen, seine Umsetzung so zu gestalten, wie er es selbst möchte!

[Xel66]

Warum hat das so lange gedauert???

Nun ja, ab und zu muss mich mal auch dem realen Leben widmen und/oder meine Brötchen verdienen.

Was löst denn bitteschön bei einer Bedingungsprüfung etwas aus?

Öhmmm, der Trigger eines Programms!? Was sonst? Und Statusrückmeldungen und das Setzen von Defaultwerten sind Trigger (auch bei Systemstart). Hinzu kommt die aktive Prüfung von Zeitmodulen auf Gültigkeit usw. bei Systemstart.

Ess soll auch Umsetzungen geben, die nicht nur auf netzbetriebene Aktoren basieren.

Dafür ist ja die Zwischenspeicherung des TFK-Status ein probater Lösungsansatz. Dem habe ich ja auch nicht widersprochen.

Schreibe bitte auch dazu, dass batteriebetriebene Sensoren teilweise bis zu 60min. benötigen, bis sie ihren Status melden.

Nö, da ich es voraussetze, dass bekannt ist, dass Batteriesensoren im Gegensatz zu Aktoren (und da auch nur wenn WOR aktiviert ist, was bei gruppierten Heizkörperthermostaten - auch IP - automatisch aktiviert wird, wie könnten sonst prompte Solltemperaturänderungen umgesetzt werden) nicht abgefragt werden können. Und ansonsten lasse ich mich selten vorschreiben, was ich tu und was ich lass (solange ich mich im Rahmen gesetzlicher Vorschriften, moralischer Normen und der Naturgesetze bewege).

Ist klasse, wenn man im Bad eine Lüftung auf Basis der Luftfeuchte umsetzen möchte...

Sollte kein Problem sein, denn Thermostate übermitteln ihren Status spätestens nach drei Minuten. Und dann gibt es als Abfrage die Solltemperatur (Absenktemperatur bei offenstehendem Fenster) oder auch ggf. der entsprechende Datenpunkt bei IP-Thermostaten, der auch nicht durch einen Reboot beeinflusst wird. Muss man nur abfragen.

Scheinbar hast Du die Vorteile des Programmaufbaus von BadenPower noch nicht verstanden?

Damit habe ich mich vor Jahren mal auseinandergesetzt und für mich entschieden, dass das überflüssig ist.

Wie geht das bitte bei "üblichem UI Programmaufbau" wenn die Sache etwas komplexer werden soll?

Wie kommt es denn nur, dass ich z.B. aufwändige Heizungs- und Beschattungsszenarien nur mit den Mitteln der WebUI umsetzen konnte?

Klar kann man für jeden Furz ein Programm schreiben.

So ist das System nun mal gedacht. Und gerade wegen der ressourcenschonenden Arbeitsweise wegen der ausschließlich ereignisgesteuerten Abarbeitung ist das absolut kein Problem. Es ist nicht zielführend, die Anzahl der Programme zu minimieren, um den "Überblick" nicht zu verlieren oder stattdessen auf zyklisch laufende Scripte zu setzen. Die CCU arbeitet nach dem Highlander-Grundsatz ("Es kann nur Einen geben!"). Sie besitzt nur eine einzige Scriptingengine. Es kann immer nur ein Scipt laufen. Ein hängendes Script kann die ganze CCU lahmlegen. Und z.B. gerade bei Abfragen externer Webserver ist die Wahrscheinlichkeit groß genug, dass mal ein Script wegen Nichtverfügbarkeit des Servers, des Internets oder sonst welcher Netzwerkprobleme "hängt".

Doch wer hunderte von Programmen (kommt ja immer auf den individuellen Ausbauwunsch an) nutzt, um Komplexität (auch wieder relativ) zu vermeiden, dabei den Überblick behält...

Schau mal in meine Sig. Und ich nehme für mich in Anspruch, den Überblick nicht verloren zu haben. Wer natürlich mit irgendwelchen kryptischen Bezeichnungen arbeitet, anstatt aussagekräftige Namen zu benutzen, ist selbst Schuld. Beispiel: alle Programme, die mit der Heizung zu tun haben, tragen bei mir dieses als führenden Namen in der Bezeichnung. Nachgestellt sind dann bestimmte Funktionen wie Sollwertvorgaben (Beispiel: Rollladen-SollwertObenName_des_Fensters für die Steuerung der Behanghöhe). So kann man man auch für eine übersichtliche Programmstruktur selbst sorgen.

Nenne mir doch bitte die Vorgehensweise über die UI, ein Programm zu Testzwecken komplett (nicht nur das erste Dann) auszuführen, bei welchem das gesamte Programm durchlaufen wird.

Die Möglichkeiten der virtuellen Tasten hast Du ja selbst erkannt.

Oder der Fall, "mal eben" alle noch dem verlinkten Programmaufbau erstellten Programme deaktiviern (mach das mal mit der Kästchenklickerei in der UI).

Diesen Anforderungsfall gibt es bei mir nicht und im Normalbetrieb dürfte dieser auch bei anderen Anwendern eher selten sein. Für mich gibt es außer der öfter mal aufgeführten Anleitung, einen DC-Treiber zu identifizieren, kein denkbares Anwendungsszenario "alle" Programme zu deaktivieren. Und zur Identifikation häufig ausgeführter Programme kann man auch ganz gut die Zeitstempel der Programme auswerten.

Die Unzulänglichkeiten der UI sind oft am Anfang nicht hinreichend bekannt, also warum diese mit dem üblichen Programmaufbau hinnehmen?

Weil man sich da eine Krücke einbaut, die man nur mit viel Aufwand wieder loswird. Ist das Gleiche wie das Benennungskonzept (RolladenSollwertRaumname ist nun mal aussagekräftiger als irgendwelche Kürzel WzRSW oder was man hier sonst noch so in Screenshots sieht). Hat man erst mal seine Programmnamen mit solchen Krücken bezeichnet, weil es einem in diesem Moment logisch war, wird man das im Nachgang kaum noch ändern. Sucht man mal dann was, verliert man sich in der Struktur. Und viele vermeintliche "Unzulänglichkeiten" basieren auf Unkenntnis der im Einsteigethread und im WebUI-Handbuch dokumentieren Arbeitsweise des Systems und weil die Anwender mit bestimmten Erwartungen (das System verhält sich gemäß der eigenen Logik-Vorstellungen) herangehen. Das System hat seine Eigenheiten - ja, aber es verhält sich strikt logisch und unter Berücksichtigung der dokumentierten Arbeitsweise auch (bis auf eine kleine Ausnahme) nachvollziehbar, auch wenn manche Anwender das nicht erkennen wollen. Und Einsteiger können das auch ohne Lektüre der angegebenen Dokumentationen nicht.

Kommen weitere Kenntnisse hinzu kommt man ja auch um Skripte nicht herum.

Scripte sind nur für Berechnungen, numerische Vergleiche und Stringhandling zwingend notwendig. Zum Anlegen einer Automation im Sinne von logischen Abfragen von Werten und Status und deren Verknüpfung sind sie grundsätzlich verzichtbar - definitv auch in komplexeren Anwendungsfällen.

Da muss man auch noch externe Tools nutzen, da die UI manche Werte gar nicht zulässt.

Statuswerte, die durch Sensoren an die WebUI gemeldet werden, sind auch so auswertbar und zugelassen. Falls Du da auf CUxD-Wrapperdevices anspielst, ja - ist eine große Hilfe. Setze ich auch gern ein.

Es ist jedoch auch nix dabei mal über den Tellerrand zu schauen (auch wenn manche Antworten auf den Fred so verfasst sind ,als hätte "Jehova" gesagt).

Mit letzterem kann ich nichts anfangen. Auch schaue ich schon über den Tellerrand. Das Grundproblem ist aber, dass hier Einsteigern häufig irgendwelche komplizierten Lösungen um die Ohren gehauen werden, die weit über das Ziel hinausschießen (jemand Anderes bewirbt auch gern und häuft eine Software mit erheblichem Anschaffungswiderstand). Gerade für das initiale Problem gibt es eben eine ganz banale Lösung per WebUI.

Es jedem geneigten Leer dieses Freds selbst überlassen, seine Umsetzung so zu gestalten, wie er es selbst möchte!

Kann jeder grundsätzlich so tun und lassen, wie er selbst mag. Das Problem ist nur, dass gerade Einsteiger mit solchen Lösungen schnell überfordert sein können, noch dazu, wenn sie mit definitiv falschen Darstellungen a la "alle Programme werden bei Systemstart abgearbeitet" in die Irre geführt werden. (Ja, Du hast es etwas präziser, aber trotzdem nicht richtig ausgedrückt). Und gerade diese Einsteiger können dann nicht die Notwendigkeit solcher komplexen Lösungsszenarien bewerten. Schon gar nicht, wenn es (wie für dieses Topic) einen einfachen Lösungsansatz per WebUI gibt.

Und es wird ohne Widerspruch dann schnell als DER einzig mögliche Lösungsweg für das individuelle Problem betrachtet. ich erinnere mich da an eine hochkomplexe Scriptlösung, die wegen ihrer Omnipräsenz schnell als state of the art durch Einsteiger betrachtet wurde. Dabei war dieser Lösungsansatz mit dem Vorhandensein aktuellerer Hardware und ihrer zusätzlichen Möglichkeiten schon lange überflüssig. Spätestens, wenn Scripte nur die Möglichkeiten der WebUI oder (noch schlimmer) der eigentlich geräteinternen Funktionen nachbilden, sind sie nicht notwendig.

Gruß Xel66