HM-CC-RT-DN: tempList max. Einträge pro Tag und weitere Fragen

[Trebxson]

Nachfolgendes aus http://forum.fhem.de/index.php/topic,34281.0.html ausgenommen da die gewonnen Erkenntnisse doch höchst interessant sind.



Wie viele Einträge (tempList) kann der HM-CC-RT-DN (1.3)? 7 pro Tag? Das dachte ich bisher. Aber wie ist dann das möglich?

Code Auswählen Erweitern

     2015-03-10 11:01:46   R_0_tempListSat  09:05 18.0 11:05 20.0 12:05 18.0 13:05 20.0 14:05 23.0 16:05 20.0 17:05 22.0 22:05 18.0 23:05 24.0 24:00 18.0
     2015-03-10 11:01:46   R_1_tempListSun  09:05 18.0 11:05 20.0 12:05 18.0 13:05 20.0 14:05 23.0 16:05 20.0 17:05 22.0 22:05 18.0 23:05 24.0 24:00 18.0
     2015-03-10 11:01:46   R_2_tempListMon  09:05 18.0 11:05 20.0 12:05 18.0 13:05 20.0 14:05 20.0 16:05 20.0 17:05 22.0 22:05 18.0 23:05 18.0 24:00 18.0
     2015-03-10 11:01:46   R_3_tempListTue  00:05 18.0 11:05 20.0 12:05 18.0 13:05 20.0 14:05 20.0 16:05 20.0 17:05 22.0 22:05 18.0 23:05 18.0 24:00 18.0
     2015-03-10 11:01:46   R_4_tempListWed  09:05 18.0 11:05 20.0 12:05 18.0 13:05 20.0 14:05 20.0 16:05 20.0 17:05 22.0 22:05 18.0 23:05 18.0 24:00 18.0
     2015-03-10 11:01:46   R_5_tempListThu  09:05 18.0 11:05 20.0 12:05 18.0 13:05 20.0 14:05 20.0 16:05 20.0 17:05 22.0 22:05 18.0 23:05 18.0 24:00 18.0
     2015-03-10 11:01:46   R_6_tempListFri  09:05 18.0 11:05 20.0 12:05 18.0 13:05 20.0 14:05 20.0 16:05 20.0 17:05 22.0 22:05 18.0 23:05 18.0 24:00 18.0
     2015-03-10 11:01:46   R_tempList_State verified


Auch das ist offenbar möglich:

Code Auswählen Erweitern


     2015-03-10 12:21:09   R_0_tempListSat  09:00 18.0 13:00 20.0 13:10 21.5 13:20 22.0 14:00 21.5 16:00 23.0 17:00 20.0 22:10 21.0 22:20 22.5 23:00 24.0 24:00 18.0
     2015-03-10 12:21:09   R_1_tempListSun  09:00 18.0 13:00 20.0 13:10 21.5 13:20 22.0 14:00 21.5 16:00 23.0 17:00 20.0 22:10 21.0 22:20 22.5 23:00 24.0 24:00 18.0
     2015-03-10 12:21:09   R_2_tempListMon  09:00 18.0 16:00 20.0 17:00 22.0 24:00 18.0
     2015-03-10 12:21:09   R_3_tempListTue  09:00 18.0 16:00 20.0 17:00 22.0 24:00 18.0
     2015-03-10 12:21:09   R_4_tempListWed  09:00 18.0 16:00 20.0 17:00 22.0 24:00 18.0
     2015-03-10 12:21:09   R_5_tempListThu  09:00 18.0 16:00 20.0 17:00 22.0 24:00 18.0
     2015-03-10 12:21:09   R_6_tempListFri  09:00 18.0 16:00 20.0 17:00 22.0 24:00 18.0
     2015-03-10 12:21:09   R_tempList_State verified


Das Display des HM-CC-RT-DN bestätigt den Plan. Optimiert der HM-CC-RT-DN intern die Pläne, so, dass er ggf. bei gleichbleibenden Tagen weniger Speicher benötigt?



Desweiteren heißt es in der FHEM-Ref, dass prep und exec die Übertragungslast verringern. Ich nehme an, dies reduziert auch die Loads.
Wenn ich nun jedoch nur einen Wert ändern möchte, z.B. Mon 09:00 18.0 auf 20.0 - spare ich "Loads", wenn ich statt der gesamten Woche nur den einen Tag übertrage? (bedingt durch das nachfolgend notwendige getConfig wohl eher nicht?)



Zum Hintergrund: Ich möchte "ich bin zuHaus|unterwegs|auto"-Buttons in die tempLists der HM-CC-RT-DN gießen. Weiterhin soll die am HM-CC-RT-DN eingestellte desired-temp sofort in die tempList aufgenommen werden, wenn sich HM-CC-RT-DN im auto-Modus befindet. Aus den verschiedenen States + weiteren Fällen (morning ? $hour >= 6 && $hour < 10 etc.) werden die Einträge generiert.

Idee und Code funktioniert, erzeugen jedoch wie man sieht exotische tempLists. Sollte ich diese besser noch glätten / bzw. entsprechende Grenzen diktieren? (btw. wo liegen diese nun?)



Bei weiteren Tests meldet FHEM(?) > To many arguments, max 13 pairs

[LuckyDay]

RTFM  Seite 35

[Trebxson]

I remember. Den Satz habe ich in der Tat nie verstanden. °O(Was definiert Heizphasen vs. Schaltpunkte? ich meine 16°C von 00:00-06:00 müssten im Zweifel auch erst einmal erheizt werden) Der Homematic Konfigurator bot dagegen nur 5 Schaltpunkte womit die Frage klar beantwortet war °O(woher habe ich nur die inzwischen eingebrannten maximalen 7 Schaltpunkte?).

http://www.eq-3.de/Downloads/eq3/pdf_produkte/105165_HM-CC-RT-DN_UM_GE_eQ-3_150129-web.pdf
> Im Wochenprogramm lassen sich für jeden Wochentag separat bis zu 6 Heizphasen (13 Schaltzeitpunkte) einstellen.

Bleibt noch die prep+exec-Frage. Btw. könnte man auch set ... regSet prep ... + set ... tempListWed exec ... zusammen packen? Spart das Loads? °O(Haha... und wie stets mit (obwohl die Syntax Schrott ist, aber vlt. gibt es doch einen Weg?) set ... tempListWed prep + set ... getConfig?)

Vielen Dank bis hierher.

[martinp876]

Exec schreibt alle offenen aenderungen fuer diesen kanal. So die beachreibung...
Laesst sich einfach testen.
Getconfig hat nichts mit schreiben zu tun. Ist nirgends erwaehnt und laesst sich ebenfalls einfach testen

[Trebxson]

Schreiben? Mir ging es darum High-Loads ausgelöst durch Übertragungen vermeiden.

tempLists werden nicht immer korrekt geschrieben, zweitens braucht es immer ein getConfig. Das ist alles sehr viel Last. Dazu die seltenen aber alles aufhängenden CMDs und der Anschein der hmusb ist wieder ausgestiegen. Hintendran können keine Register beschrieben werden, da sonst die neue desired wieder überschrieben wird.
Mir ging es darum die Last zu reduzieren um die tempLists zu einem brauchbaren Werkzeug zu machen um sie auch endlich der Familie zugänglich zu machen. Bisher habe ich nicht das Gefühl, dass sie eine großartige Besserung gegenüber den alten Thermostaten mitgebracht hatten. Statische tempLists, wer braucht so etwas? Wieso sollte ich Abends auf 22-24°C heizen, wenn keiner da ist? Ich kann von meiner Frau nicht verlangen FHEM in irgendeiner Art mit Befehlen zu füttern und das auch noch regelmäßig. Die Oberfläche von FHEM ist dazu viel zu überhäuft mit technischen Details. Der Homematic Konfigurator kachelt ständig ab.
Das muss alles viel einfacher gehen und daran arbeite ich. FHEM ist schon eine sehr gute Unterstützung und inzwischen recht stabile Lösung geworden. Die vorhandenen Dokus sind sehr gut. Aber zu manchen Fragen ist mit Mühe keine Antwort zu finden, es fehlt eine Info oder man hat die Ausführungen nicht richtig verstanden oder es fehlt schlecht eine Idee. Auch die Hilfe hier im Forum ist gut, wenn nicht sogar goldwert.
Dokus kann man zwar fragen, aber sie antworten nicht

> Laesst sich einfach testen.

Das sehe ich nicht so. Tests jeder Art verbraten Loads. Andersherum sehe ich nicht klar woher die Loads kommen. Es sei denn ich schalte die gesamte Anlage ab und lege die Bude für einen Tag auf Eis. Das kann ich gerne im Sommer erledigen oder wenn Frau und Kind nicht da oder ich Vormittags Zeit habe. Bis dahin muss ich reguliert heizen lassen. Ich habe leider kein Testsystem.

Wenn meine Fragen keine zeitnahen Antworten finden, ist das kein Problem. Der Code ist schließlich auch noch da. Mit der Zeit werde ich schon eine Antwort finden und dann hoffentlich daran denken, sie hier zu beantworten. Das schöne wäre sie in der vorhandenen Doku ergänzen zu dürfen.

> RTFM  Seite 35
> Exec schreibt alle offenen aenderungen fuer diesen kanal. So die beachreibung...

Nein, entsprechende Antworten sind dort nicht zu finden oder nicht in entsprechender Form ausgeführt. Beides habe ich zuvor gelesen.

Kann ich durch das Packen der Befehle Loads sparen? Kann ich durch das Weglassen der Wochentage Loads sparen? Lassen sich beliebige Übertragungen packen? Es geht darum die High-Loads zu entspannen.

http://fhem.de/commandref_DE.html
> Der optionale Parameter [prep|exec] erlaubt das Packen von Nachrichten und verbessert damit deutlich die Datenübertragung.

[martinp876]

Schreiben? Mir ging es darum High-Loads ausgelöst durch Übertragungen vermeiden.

klar - exec schreibt, was offen ist. prep schreibt (noch) nicht. Vorteil: das gebündelte Senden packt die Änderungen in möglichst wenige messages.

tempLists werden nicht immer korrekt geschrieben,

hm - so ohne details keine Stellungnahme

zweitens braucht es immer ein getConfig.

zum Schreiben? nein. Zum Verifizieren? ja

Das ist alles sehr viel Last.

so viel wie du sendest. Wenn du ändern willst musst du senden. Wenn du nicht verifizieren willst, schalte es ab.

Dazu die seltenen aber alles aufhängenden CMDs

Bitte? verstehe ich nicht.

und der Anschein der hmusb ist wieder ausgestiegen

wo steigt der hmusb hin?

Hintendran können keine Register beschrieben werden, da sonst die neue desired wieder überschrieben wird.

kommandos werden der reihe nach gequeued und dann gesendet. ggf kannst du die Q des Devices löschen, falls du das brauchst. wenn du ein desiredtemp sendest und dann register änderst  passiert dies in genau der reihenfolge.

Mir ging es darum die Last zu reduzieren.........Die Oberfläche von FHEM ist dazu viel zu überhäuft mit technischen Details. Der Homematic Konfigurator kachelt ständig ab.

die Last kannst du so nicht weiter reduzieren. Statische templisten nutze ich z.B. - es sind die defaults. ein TC-IT erlaubt 2 Wochenplane - das lässt sich mit einem Befehl umschalten - evtl ein Ansatz für dich.
Wenn ich eine "besondere" temp brauche schalte ich das von der Zentrale. Das ist die Ausnahme. Möglich wäre also das Umschalten auf manuell - immer um Mitternacht wieder zurück. Wenn du alles mit deinem Kalender koppeln willst geht das auch. tempList macht default. Besonderen Tage stehen im Kalender, dann wird auf mauell geschaltet und die temp nach einem eigenen Ablauf eingeschaltet.
FHEM CUL_HM stellt ein Interface für die Devices zu Verfügung - ich würde als Operator-interface bezeichnen. Deine Gemahlin zählt scheinbar zu Usern. Hier bietet dir FHEM die freie Programmierbarkeit - erstelle ihr ein Interface nach deinen Bedürfnissen. Entweder mit einem anderen Modul oder ein Eigenbau - üblich in myUtils.

Das muss alles viel einfacher gehen und daran arbeite ich.

gut

FHEM ist schon eine sehr gute Unterstützung und inzwischen recht stabile Lösung geworden. Die vorhandenen Dokus sind sehr gut. Aber zu manchen Fragen ist mit Mühe keine Antwort zu finden, es fehlt eine Info oder man hat die Ausführungen nicht richtig verstanden oder es fehlt schlecht eine Idee. Auch die Hilfe hier im Forum ist gut, wenn nicht sogar goldwert.
Dokus kann man zwar fragen, aber sie antworten nicht

verbessere die wikis!

> Laesst sich einfach testen.

Das sehe ich nicht so. Tests jeder Art verbraten Loads.

der test bei einem RT dauert 15min (max). Load ist minimal. ggf den HMUSB ziehen stecken - allen in Butter

Andersherum sehe ich nicht klar woher die Loads kommen. Es sei denn ich schalte die gesamte Anlage ab und lege die Bude für einen Tag auf Eis

so stehst du allein. Welche Loads? Schicke die Statistiken (oder schaue selbst). Es gibt doch einige, in HMLAN und HMInfo. oder logge einfach einmal mit, sage was du getan hat.

Das kann ich gerne im Sommer erledigen oder wenn Frau und Kind nicht da oder ich Vormittags Zeit habe. Bis dahin muss ich reguliert heizen lassen. Ich habe leider kein Testsystem.

habe ich auch nicht. das testen an einem einzelnen Sensor mache ich dennoch. in 10 min erfriert keiner. wenn es ein overload gibt und ich gerade teste boote in den HMLAN, alles vergessen. die RTs merken das nicht, die Frau auch nicht.

Wenn meine Fragen keine zeitnahen Antworten finden, ist das kein Problem. Der Code ist schließlich auch noch da. Mit der Zeit werde ich schon eine Antwort finden und dann hoffentlich daran denken, sie hier zu beantworten. Das schöne wäre sie in der vorhandenen Doku ergänzen zu dürfen.

Nein, entsprechende Antworten sind dort nicht zu finden oder nicht in entsprechender Form ausgeführt. Beides habe ich zuvor gelesen.

Code Auswählen Erweitern

Optional parameter [prep|exec] allowes to pack the messages and therefore greatly improve data transmission. Usage is to send the commands with paramenter "prep". The data will be accumulated for send. The last command must have the parameter "exec" in order to transmitt the information
hm - was verstehst du nicht?

Kann ich durch das Packen der Befehle Loads sparen?

absolut.

Kann ich durch das Weglassen der Wochentage Loads sparen?

wo weglassen? Es werden alle geänderten register geschrieben. es werden noch nicht einmal alle Werte innerhalb eines Wochentags geschrieben, eben nur die geänderten. eben alles, was du geändert hast. ist doch ganz einfach. Beachte? jedes schreiben hat eine overhead. den spart man mit prep/exec.

Lassen sich beliebige Übertragungen packen?

packen ist kein zippen.... es ist ein optimieren der notwendigen messages zur parameterübertragung. was sind beliebige übertragungen? hier geht es  um Register, also parametrierung, sonst nichts.

Es geht darum die High-Loads zu entspannen.

genau - und kollisionen - und last - und dauer - und sicherheit. Alles verbessert. besser geht nicht. ausser du änderst weniger. das wiederum liegt bei dir.