Problem mit Heizgruppe

[Xel66]

Ok, falls es nicht doch einen alten eTRV in HM gibt, Thema verfehlt. Es geht um HMIP.

Völlig Wumpe. Das Verfahren ist ähnlich (siehe zwei Absätze tiefer).

Aber auch bei HMIP ist es möglich über RPC alle Parameter auf einen Schlag zu setzen.

Geht bei klassischem HM auch und heißt dort "PARTY_MODE_SUBMIT". Ich habe es mir einfach gemacht und einfach diesen Parameter aus dem manuell veränderten Thermostat ausgelesen und in andere geschrieben. Fertig. Durch diese Vorgehensweise habe mir die eigene Erstellung des SUBMIT-Parameters aus den eingegebenen Daten per Script erspart und es war ja auch nicht notwendig, weil ich die Parameter direkt am Thermostat in Augenhöhe über Drehrad eingegeben, von dort ausgelesen und in andere kopiert habe.

Daher gibt es nur eine Einsparung des DC, wenn das eine Script nicht optimiert, das andere jedoch optimiert ist.

Ahh! Du hast also mein Intension für mein Post verstanden! Genau darum ging es! Und da ist es egal, wie das Gerät heißt und aus welcher Serie es kommt. Funkhygiene ist das Stichwort. Die Ressource DC ist nun mal begrenzt und mit umfangreichen Aktionen an einer Vielzahl von Geräten kann man da schon mal an die Grenze 100% kommen. Daher sind Maßnahmen, die das Funkaufkommen minimieren, extrem zielführend.

Da diese Schaltvorgänge jedoch recht selten stattfinden, dürfte es für einen Anfänger einfacher sein die Datenpunkte einzeln zu setzen.

Wenn er damit aber in ein DC-Problem bei vielen Thermostaten rennt, eher nicht. Gerade beim Szenario "der Anwender verlässt das Haus" und stellt noch auf die Schnelle seine Rückkehr ein, kann das bei vielen Geräten und ggf. zusätzlichen Aktionen durch das Verlassen des Hauses (Schließen der Rollläden, Benutzung eines elektronischen Schlossantriebes etc.) eng werden. Wer will schon, dass das System gerade wenn man (als seltener Vorgang) weg in den Urlaub will, in eine DC-Begrenzung rennt und ggf. Aktionen nicht ausgeführt werden?! Kommt auf den Umfang des Systems an. In Kleininstallationen in einer Zweizimmerwohnung eher kein Problem. Bei "größeren" Häusern mit vielen Heizkörpern eher schon. Meine Hütte ist sehr überschaubar, aber solche Aktionen haben "früher" gern mal erste Warnschwellen meiner DC-Überwachung grissen. Darum bin ich sensibel für das Thema Duty Cycle.

Der nächste Schritt ist es dann durch dieses Verfahren allen Geräten einen neuen "COMBINED_PARAMETER" zu verpassen bei dem dann die nicht vorhandene Dokumentation überflüssig wird.

Da war klassisches HM mit dem SUBMIT-Parameter fortschrittlicher und sogar für die manuelle Konfiguration am Gerät geeignet.

Gruß Xel66

[Tyfys]

"PARTY_MODE_SUBMIT". Ich habe es mir einfach gemacht und einfach diesen Parameter aus dem manuell veränderten Thermostat ausgelesen

Wäre zu schön.

Der Parameter PARTY_MODE_SUBMIT ist nur schreibend - lt. Handbuch - und meiner Beobachtung
Kann man aber einfach zusammensetzen.

[Henke]

Die gesamte Umschaltung muss bei größeren Installationen zeitlich gestaffelt werden um Probleme mit dem CS zu vermeiden. Die 3 Befehle machen dabei keinen Unterschied. Lief früher bei mir so und ist mit RCP nicht viel besser. Wenn die Heizungsgruppen die neuen Einstellungen bekommen, sei es Absenkthemperatur, Urlaubsmodus oder Aus, dann werden die Daten weitergeleitet an den FALMOT, Heizkörper und zurück zur CCU.
Erfahrungswert von jemanden der die Umschaltung auf alle möglichen Arten schon programmiert hat mit 13 FB Kreisen und 6 zusätzlichen HK.
Erfahrung, Wissen, kein Raumfahrer...

[Xel66]

Wäre zu schön.

Was ich da genau wo gelesen, zusammengesetzt und hingeschrieben habe, weiß ich nicht mehr so genau. Ich habe das Projekt damals (in den 10er Jahren) nicht weiter verfolgt und mich bei längeren Abwesenheiten für die einfache Umschaltung auf manuell ECO entschieden. Der deutliche einfachere und DC-schonendere Weg. Kürzere Telegramme - weniger DC. Und vor allem, ohne fancy iterierende Scripte. Einfach, automatisch mit den Möglichkeiten der CCU. Nicht weil ich es nicht per Script kann, sondern weil es auch so geht. KISS eben.

Die zeitliche Staffelung ist zwar eine Möglichkeit, auch zielführend, aber eben auch nur ein Feigenblatt. Und per Script, dass durch irgendwelche Gewerke iteriert auch nicht so einfach umzusetzen. Funkhygiene (also Minimierung des Funkaufkommens) ist deutlich wirksamer.

Erfahrung eines Anwenders, der den Spaß schon seit mehr als zehn Jahren betreibt (als man sich noch mit der Begrenzung auf 200 Scriptvariablen rumschlagen musste), mit der CCU-Logik nicht auf Kriegsfuß steht und sie durch Scripting zu überlisten sucht und auch schon diverses programmiert hat. Bei den ersten Thermostaten gab es viele heutige Features noch nicht mal. Und ich steuere meine komplette Heizungsanlage über die CCU-Logik. Nur solche Dinge wie Schichtplan- und Feiertagsberechnung laufen mangels Möglichkeiten der CCU-Logik als Scripte (auch schon seit 04.2015). Insofern... schönen Tag noch.

Gruß Xel66

[Henke]

Was ich da genau wo gelesen, zusammengesetzt und hingeschrieben habe, weiß ich nicht mehr so genau.

Trump/Bidden Syndrom? Hmm, ich würde sagen, ups, stimmt, geht nicht auszulesen, habe ich wohl zusammengesetzt. Nennt sich, wie du so gerne simplifizierst (vereinfachst): Reflektieren und Fehler bei der Aussage eingestehen. Aber das ist ja nicht jedermanns Ding.

Der Rest, weil du es nicht kannst, KISS, Gewerke iterieren und die Krönung "Funkhygiene", nun ja, Bullshit oder einfach nur die Perspektive aus einem begrenzten Horizont. Die meisten, die mehr als ein paar Programme/Scripte machen wechseln auf eine Alternative die nicht so viele Bugs hat.

aber eben auch nur ein Feigenblatt

Bei benutzten Direkverknüpfungen hat man keinen Einfluss auf den Funk außer entsprechende Pausen zu setzen.
( Nun ja, stimmt nicht ganz. Ich bekomme durchaus mit was durch RCP kommt und könnte damit es in den Leerlaufphasen senden. Aufwand und Nutzen und die unkalkulierbare Verzögerung passte bei dem Konzept jedoch nicht. )
Der Rest läuft automatisch. Wenn ich z.B. mehrmals auf "Alle-Auto" klicke, geht nur beim erstem mal ein Befehl raus und auch nur an die, die nicht schon auf Auto stehen. Das sind Dinge, die mir vom den Nodes automatisch abgenommen werden im Gegensatz zu CCU-Programmen.

KISS sieht so aus:

Screenshot 2024-03-19 043034.jpg (9.35 KiB) 223 mal betrachtet

führt zu:

Ziemlich übersichtlich für mehrere komplexe Aufgaben, oder?

Am geilsten fand ich aber diesen vollkommen unqualifizierten Kommentar:

und sie durch Scripting zu überlisten sucht

Tja, nicht immer von sich selber auf andere schließen...

In dem Flow oben wird weder ein Script, TCL, noch die Rega genutzt. Das läuft direkt über den HMIP-Server und überlistet nix, sondern steuert einfach direkt. Keine Tricks, sauber und schnell und durch Typescript schon gut abgesichert gegen Tippfehler (xml-rcp (homematic-version und original) zusammengefasst, aktualisiert, Fehler behoben und in eine Typescript Datei portiert, Info für potentielle Mitleser).

Das Ansteuern durch RCP reduziert sich dabei au folgenden Eingabe: "["${msg.device}:1", "VALUES", {"CONTROL_MODE": 1,"SET_POINT_TEMPERATURE": ${msg.payload}}]", ziemlich simpel und kein Hexenwerk.
Im Prinzip die TCL Version von Baxxy über den SDV von Black, nur ohne Script und TCL.
Versuche das etwas eleganter über xmlrcp.PutParamset mit mehreren Parametern zu gestalten sind jedoch gescheiter. Mein Verdacht ist, das xmlrcp.PutParamset eigentlich nur "setValue" aufruft. Das passt von den Parametern auch besser. Da ich jedoch die Ankündigung der neuen HAP ohne Cloud als klares Zeichen für ein Ende der CCU_Programme und Scripte sehe, habe ich es relativ schnell eingestellt.
Strategisch halte ich das auch für den richtigen Weg. Es beendet den Murks, sichert den Anwenderkreis der nicht an den Himmel/Cloud glaubt und eröffnet langfristig die Option jederzeit die Cloud zu beenden ohne den Großteil der Kunden zu verlieren.

[Xel66]

Trump/Bidden Syndrom? Hmm, ich würde sagen, ups, stimmt, geht nicht auszulesen, habe ich wohl zusammengesetzt.

An welcher Stelle genau versagt Dein Verständnis für den direkt auf die zitierte Passage folgenden Satz "Ich habe das Projekt damals (in den 10er Jahren) nicht weiter verfolgt und mich bei längeren Abwesenheiten für die einfache Umschaltung auf manuell ECO entschieden."? Also ist nix mit auslesen. Ich habe es nach anfänglichen funktionierenden Experimenten grundsätzlich anders umgesetzt und so ist es seit Mitte der 10er Jahre. Warum? Das habe ich auch geschrieben.

Der Rest, weil du es nicht kannst, KISS, Gewerke iterieren und die Krönung "Funkhygiene", nun ja, Bullshit oder einfach nur die Perspektive aus einem begrenzten Horizont.

Über begrenzte Horizonte brauchen wir uns nicht auszutauschen. Den Meinigen kannst Du nicht ansatzweise beurteilen. Deine soziale Kompetenz kann aber jeder Mitleser bei solchen Äußerungen selbst bewerten. Irgendwie habe ich ein Déjà-vu (aus einer Zeit weit vor Deinem Registrierdatum). Wenn Argumente/Fakten ausgehen, kommen schnell Beleidigungen ins Spiel.

Die meisten, die mehr als ein paar Programme/Scripte machen wechseln auf eine Alternative die nicht so viele Bugs hat.

Nun ja, wenn man das Wissen um die Bugs und deren Handling hat, kann man selbst umfangreiche Automationen auch mit Bordmitteln umsetzen. Die von Dir angeführten "(M)meisten" haben einfach keinen Bock, sich mit dem System auseinanderzusetzen (Handbücher/Anleitungen lesen oder eigene Erfahrungen machen ist ja so oldschool - man muss ja YT-Videos folgen) und müssen eben stylisch irgendwelche Dinge mit der Maus hinschubsen, um dann Code zu generieren. Oder sie kopieren Scripte anderer und sind dann nicht in der Lage, den kleinsten Problemen abzuhelfen. Wer hier im Forum eifrig mitliest, kann das fast täglich beobachten. Die Klickorgie ist zwar im Original ähnlich, funktioniert aber strikt logisch, wenn auch mit ein paar zu beachtenden Eigenheiten. Es gibt auch Leute, die sich dicke Puschen aufs Auto ziehen und Spoiler anbauen und Tieferlegungssätze einbauen. Kann man machen, muss man aber nicht. Hauptsache dicke Hose, aber der Brief liegt nicht bei denen zu Hause.

Wenn ich z.B. mehrmals auf "Alle-Auto" klicke, geht nur beim erstem mal ein Befehl raus und auch nur an die, die nicht schon auf Auto stehen.

[ ] Du hast verstanden, wie Direktverknüfungen funktionieren.
Leider funktionieren Direktverknüpfungen "unwesentlich" anders, aber das sind Nebensächlichkeiten. [Achtung! Niveau fällt!]Behalte Deine Meinung und schubse mit der Maus irgendwelche Icons hin und her und klopfe Dir auf die Brust, welch toller Programmierer Du bist.[/Ende Niveausenke] Und nein, KISS sieht definitv nicht so aus. Auch mein "alle-Lichter-aus" WebUI-Programm generiert keine Befehle an ausgeschaltete Leuchtmittel. Ist aber eine elende Klickerei beim Erstellen (aber das ist ja nur einmalig). Dafür funktioniert es mit Bordmitteln. Warum ich darauf rumreite? Ganz einfach. Hätte ich einen Hardware- oder SD-Kartendefekt o.ä. an der CCU/RM zu beklagen, habe ich binnen weniger Minuten ein Ersatzsystem (zur Not mit Teilen aus der Bastelkiste) aufgesetzt und nach dem simplen Einspielen eines Backups oder Stecken der Reserve-SD mit der Vorgängerinstallation ein lauffähiges System. Ich brauche nichts nachzuinstallieren, azupassen o.ä.. Einfach System starten und ggf. Rekeying, wenn ich ein anderes Funkmodul einsetzen müsste, abwarten. Das ist KISS!

Tja, nicht immer von sich selber auf andere schließen...

In dem bezogenen Kontext ist das Nachbilden von logischen Verknüpfungen (also 1:1-Abbildung simpler Logik-Funktionalitäten der WebUI als Script) genau das. Der Anwender ist nicht willig, sich mit der Funktionsweise der CCU-Logik auseinanderzusetzen. Man kann auch umfangreiche Automationen mit Bordmitteln umsetzen. Läuft hier seit mehr als 10 Jahren. Die Diskussion führe ich schon seit der Zeit des unsäglichen Heizungsscripts in dem mittlerweile dem System innewohnende Funktionalitäten mit einem starren Script nachgebaut wurden. Das hatte mal mit den beschränkten Möglichkeiten der ersten Thermostatgeneration durchaus seine Berechtigung, war aber wegen seiner Handlingprobleme so präsent, dass auch Neueinsteiger mit damals aktueller Hardware (mit Heizprofilen etc.) diese Lösung einsetzen wollten, weil sie es für die "state of the art"-Lösung hielten, obwohl es gar nicht notwendig war.

Lediglich für Dinge, die die WebUI nicht beherrscht (Berechnungen, numerische Vergleiche, String-Handling, externe Kommunikation), muss man zwangsweise auf Scripte ausweichen, wenn man entsprechende Funktionalitäten nutzen will. Das bedeutet aber im Umkehrschluss eben nicht, dass man auch simple WENN-DANN-Logik auf diese Weise abbilden muss. Und die große Masse der Anwender hat nach meinen Beobachtungen definitv keine hochkomplexen Anforderungen an automatischen Funktionalitäten, die der Installation einer zweiten Logikebene bedürften. Die bauen ein paar Automatismen, nenen es Smarthome und steuern den Rest ganz stylisch per Visu oder App manuell. Sie gehen nur den Typen mit der Flöte auf den Leim. Hameln ist überall.

Als ich mit dem Zeug angefangen habe, gab es die ganzen fancy Optionen (Node, Middleware) noch gar nicht. Vielleicht würde ich es heutzutage etwas anders machen, aber eine weitere Logikebene würde ich nicht auf der CCU installieren. Eher eine Middleware einsetzen. Aber mit zusätzlicher notwendiger Hardware potenziere ich die Ausfallwahrscheinlichkeit.

Da ich jedoch die Ankündigung der neuen HAP ohne Cloud als klares Zeichen für ein Ende der CCU_Programme und Scripte sehe, habe ich es relativ schnell eingestellt.

Auch auf die Werbung reingefallen? Die Aussagen des Standpersonals beinhalteten aber nach Aussage eines andere Forenmitglieds andere Informationen. Da das Produkt noch nicht mal ansatzweise fertig ist, ist es aber müßig, dessen Funktionsweise, -umfang und Schnittstellen zu diskutieren.

Gruß Xel66

[Tyfys]

Nur mal zum Thema Scripten :

Auszug aus der Script - Doku :

Es kann jedoch zu Situationen kommen .....wenn die Komplexität der Reaktionen zunimmt, ......
Aus diesem Grund ist es möglich, als Reaktion auf ein Ereignis ein Script auszuführen – das
Homematic Script. Homematic Script erlaubt den Zugriff auf die gesamte Logikschicht der
Homematic Zentrale. So lassen sich sämtliche angelernten Geräte über Homematic Script
fernsteuern.

[Xel66]

Ja! Heißt aber nicht, daß man das machen muss/sollte (zumindest kann ich das daraus nicht ableiten), sondern dass der Zugriff möglich ist. Nun ist das Problem aber, dass eine Iteration durch ein Gewerk schneller laufen kann/schneller läuft, als die Funkpakete ausgehenden, der Aktor geschaltet, die Rückmeldung und somit der Status im der ReGa aktualisiert ist.

Somit landen ggf. viele Funkbefehle für."viele" Geräte im Puffer. Wie groß der ist? Keine Ahnung. Es ist nur bekannt, dass bei vielen Aktionen die mit "sofort" abgelegt.werden, es regelmäßig zu Glitches kommt. Das System ist alt, und früher wurde noch mit Speicher gespart. Ich persönlich führe viele Stabilitätsprobleme des Hmipservers auf exzessive Nutzung von Iterationen zurück. Ich nutze selbst solche Scripte, generiere aber daraus keine Funkbefehle, sondern nur Datemsammlungen on Systemvariablen für die Anzeige und den Versand von gesammelten Informationen. Da gibt es eher keine Probleme, weil keine "verzögernde" Funkstrecke enthalten ist.

Gruß Xel66

[Tyfys]

Es ist nur bekannt, dass bei vielen Aktionen die mit "sofort" abgelegt.werden, es regelmäßig zu Glitches kommt

Man kann Aktoren aber auch per Script mit verzögert um .... schalten.

auf exzessive Nutzung von Iterationen

Ging es hier nicht um Urlaubsmodus, da wird das in der Heizperiode vielleicht 1,2,3 oder auch 4 mal verwendet, oder?

[Xel66]

Man kann Aktoren aber auch per Script mit verzögert um .... schalten.

IRC zählt das zu den Alleinstellungsfeatures bei Nutzung der Raspberrymatic. Allerdings kann ich es nicht überprüfen, da ich die Originalfirmware schon seit ewigen Zeiten nicht mehr einsetze. Liege ich richtig, gilt dieser Rat auch nur eingeschränkt. Dann müsste man bei jedem Treffer die Verzögerung erhöhen, um die Befehle zu serialisieren. Ich schaue mir ja viele Scripte hier nebenbei an, aber sowas habe ich noch nirgends entdecken können. Insofern... theoretisch, ja.

Ging es hier nicht um Urlaubsmodus, da wird das in der Heizperiode vielleicht 1,2,3 oder auch 4 mal verwendet, oder?

Ja, ging darum. Die Anzahl ist soweit auch plausibel. Aber wie so oft dienen solche Threads als Ideengeber für andere Anwendungen, die vielleicht dann öfter/täglich/stündlich/ereignisgetriggert or whatever laufen. Daher ist es durchaus zielführend, auch darauf hinzuweisen und nicht erst, wenn das Kind bereits im Brunnen liegt. Und wenn ich mich hier so umschaue, dann werden Iterationen durch Gewerke per Script für die verschiedensten Zwecke eingesetzt. Stößt man dann auf Stabilitätsprobleme, hat man das als Ursache vielleicht im Hinterkopf. Macht man nur Datensammlung (z.B. Anzahl geöffneter Fenster), dann ist das kein Problem, weil ja nur in eine Systemvariable geschrieben wird. Das kann die Firmware. Versucht man aber viele Geräte per Funk anzusprechen, kann das ein Problem geben.

Gruß Xel66