TempList: tempListG restore vs tempList restore

[DecaTec]

Hallo,

Ich bin gerade dabei, die Heizungssteuerung Jahreszeitabhängig zu gestalten. "Abgeguckt" habe ich die Idee bei diesem Wiki-Artikel.

Zunächst habe ich dazu verschiedene TempList-Files angelegt (tempListFruehling.cfg, tempListSommer.cfg, usw.).
Dann bei HMinfo:

Code Auswählen Erweitern


attr HMinfo configDir ./FHEM
attr HMinfo configTempFile tempListSommer.cfg,tempListHerbst.cfg,tempListWinter.cfg,tempListFruehling.cfg


Bei den Thermostaten dann z.B.:

Code Auswählen Erweitern


attr Wohnzimmer.Thermostat_Climate tempListTmpl Wohnzimmer.Thermostat_Climate
attr Wohnzimmer.Thermostat autoReadReg 5_readMissing


Umgeschaltet wird dann per at:

Code Auswählen Erweitern


define EsIstFruehling at *00:00:00 IF ($month>=3 && $month<6 && [Dummy.Jahreszeit:state] ne "Frühling") ({SetJahresZeitFruehling()})


SetJahresZeitFruehling ist eine Funktion in 99_myUtils.pm:

Code Auswählen Erweitern


sub
SetJahresZeitFruehling()
{
   Log 1, ("Jahreszeit: Frühling");
   fhem ("set Dummy.Jahreszeit Frühling");
   fhem ("attr HMinfo configTempFile tempListFruehling.cfg,tempListSommer.cfg,tempListHerbst.cfg,tempListWinter.cfg");
   fhem ("set HMinfo tempListG restore");
   }


Wenn diese Funktion nun aufgerufen wird (über das at oder auch manuell, werden die tempLists ordentlich gesetzt, also R-weekPrgSel und R_P1_0_tempListSat, R_P1_0_tempListSun, etc. OK, der HMLan bringt hier meist direkt einen Overload, aber das sollte hier nicht das Problem sein.
Aber: Es ändert sich nichts an der desired-temp im Climate-Kanal der Thermostate. Auch nach 12h Wartezeit.

Ein set HMinfo tempListG status liefert dann Einträge wie:

Code Auswählen Erweitern

././FHEM/tempListHerbst.cfg:Wohnzimmer.Thermostat_Climate : Wohnzimmer.Thermostat_Climate : failed Entries: ...

Es macht auf mich fast den Eindruck, als ob das

Code Auswählen Erweitern

set HMinfo tempListG restore wir ein verify wirkt, aber die tempListen nicht wirklich wiederherstellt...

Nun habe ich etwas rumprobiert und habe die Funktion nun abgeändert. Aus

Code Auswählen Erweitern

fhem ("set HMinfo tempListG restore");
wird

Code Auswählen Erweitern

fhem ("set HMinfo tempList restore"); (ohne das G bei tempList).

Nun werden die tempListen übernommen und auch die desired-temp.

Ich frage mich nun, wo der Unterschied zwischen tempList und tempListG beim restore ist. Eigentlich sollte man ja tempListG nehmen, da dies global wirkt.

[DecaTec]

OK, nach weiterem Rumprobieren klappt es anscheinend auch mit Umstellen auf set HMinfo tempList restore (ohne "G") nicht mehr.

Die tempLists werden gesetzt und sind aktiv. Nur die desired-temp wird nicht an das eingestellte Wochenprogramm angepasst. set HMinfo tempListG status immer noch mit Failed entries.

Habe ich vielleicht irgendein Detail übersehen?

[DerFrickler]

das kann durchaus schon mal etwas dauern, aber mit "controlMode auto" im Device sollte es klappen

[DecaTec]

controlMode steht bereits auf "auto".

Dass die Heizung nicht sofort umspringt, ist klar und soweit auch i.O.
Aber nach ein paar Stunden sollte das doch geschehen, oder?

Eine weitere Ungereimtheit:
Das tempList-File für die Heizungsthermostate (nicht Wandthermostate):

Code Auswählen Erweitern


entities:Heizung_Clima
R_0_tempListSat>24:00 0.0
R_1_tempListSun>24:00 0.0
R_2_tempListMon>24:00 0.0
R_3_tempListTue>24:00 0.0
R_4_tempListWed>24:00 0.0
R_5_tempListThu>24:00 0.0
R_6_tempListFri>24:00 0.0


Einfach alles aus, diese werden ausschließlich über die (gepeerten) Wandthermostate gesteuert.

Nach einem restore zeigt set HMinfo tempListG status folgende Meldung:

Code Auswählen Erweitern

././FHEM/tempListHeizung.cfg:Heizung_Clima : Buero.Heizung_Clima : failed Entries:     Buero.Heizung_Clima :R_0_tempListSat mismatch 24:00 0.0 ne 24:00 00.0 ## ...

Man beachte 0.0 <> 00.0
Ein String-Vergleich schlägt hier natürlich fehl, ich frage mich nur, wo der zweistellige Nullwert herkommt.

[LuckyDay]

0 Grad, ist kein gültiger Wert

5.5 entspricht off , bzw ich arbeite immer mit 6 Grad als tiefster Wert , da man mit on -off schlecht rechnen kann

[DecaTec]

0 Grad wurden bei mir bisher immer als OFF interpretiert...

Edit:
wenn ich das tempList-File für die Heizungsthermostate so anpasse:

Code Auswählen Erweitern


entities:Heizung_Clima
R_0_tempListSat>24:00 5.5
...

kommt beim set HMinfo tempListG status im Prinzip die gleiche Meldung:

Code Auswählen Erweitern

././FHEM/tempListHeizung.cfg:Heizung_Clima : Buero.Heizung_Clima : failed Entries:     Buero.Heizung_Clima :R_0_tempListSat mismatch 24:00 5.5 ne 24:00 05.5 ## ...

Wieder wird hier eine 0 mit "reingeschmuggelt"...

[martinp876]

Scheint ein Fehler im Parser zu sein. Die Temperatur wird mit xx.x angegeben. Dass man auch x.x angeben kann ist Komfort und offenbar nicht oder nicht korrekt implementiert.
Nachdem es bei mir aber geht werde ich deinen Fall einmal nachstellen.

Off ist 5.0 oder 4.5, muss ich noch einmal nachsehen. 5.0 ist einstellbar, danach sollte off kommen.
Beim alten tc war das anders.

Und gute Frage: funktioniert off in der templisten.... mal testen.

[martinp876]

G Kommandos sind inhaltlich identisch zu den anderen. Jedoch wird nur eine Option angeboten was es erlaubt eine dropdown Liste im Web zu realisieren. Kommandos ohne G haben ein Eingabefenster in dem man neben der Option einen filter setzen kann - bei hminfo.

Das Problem der führenden null sollte gelöst sein, Update ab morgen

[DecaTec]

Das Problem der führenden null sollte gelöst sein, Update ab morgen

Danke! Werde es mal testen.

[DecaTec]

Nach dem Update wird die "Führungs-Null" nicht mehr bei set HMinfo tempListG status angemeckert, das klappt schonmal.
Jedoch ist die Führungs-Null im Climate-Kanal wieder vorhanden (z.B. R_P1_0_tempListSat 24:00 00.0). Das dürfte aber nichts ausmachen.

Allerdings gibt es beim Umschalten der tempListen immer sofort einen Overload (war vor dem Update ja auch so). Sollte das Ganze nicht "vorsichtig" übertragen werden, da es sich nicht um eine zeitkritische Aktion handelt (also bei HighLoad erst einmal aussetzen, um einen Overload zu vermeiden)? Kann/muss ich hier was an meiner Konfiguration ändern?

[martinp876]

Overload hmmm. Wie viele device  betreibst du und wieviele bekommen eine neue templist?
Weiter: nutzt du burst zum übertragen automatisch? Hast du also das Attribut gesetzt?
Oder nutzt du tcit? Die machen burst automatisch.
Also brauche ich die Anzahl RT und tc-it getrennt.
Eine Verzögerung hierzu habe ich hierzu (noch) nicht vorgesehen.

[DecaTec]

Welche Devices in welcher Anzahl: siehe Signatur.

Folgende Logik verwende ich dabei:
Die HM-CC-RT-DN sind zunächst einmal "dumm". Sprich, die haben alle eine tempList von R_0_tempListSat>24:00 0.0 usw. Sind also im Grundzustand aus. Gepaired sind diese mit den HM-TC-IT-WM-W-EU. Nur an diesen werden aktiv die tempLists geändert. Die Wandthermostate geben dann die Temperatur an die Heizungsthermostate weiter.

Code Auswählen Erweitern

get Thermostat reg burstRx (HM-TC-IT-WM-W-EU) und

Code Auswählen Erweitern

get Heizung reg burstRx (HM-CC-RT-DN) liefert beides ein "on". Also denke ich mal, dass Burst hier aktiv ist.
Wie kann ich das ausstellen? set [Thermostat|Heizung] regSet burstRx off? Habe ich dadurch dann Nachteile?

[martinp876]

An den RT sollte nichts uebertragen werden. Das kannst du kontrollieren indem du bei get hm protoEvents nachsieht.
Das Register kannst du ausschalten, aber warum? Koennte batterie sparen... sonst nichts.
Du kannst aber das nicht empfohlene Attribut burstaccess gesetzt haben. Das solltest du löschen.

Bei den tc ist burst immer an und man muß auch einen senden. Bei 4 devices sollte es nun kein Problem sein. Wenn es klappt sollten die Register uebertragen werden und ggf zurückgelassen werden. Das sind erst einmal 8 bursts was 8% der stundenlast bedeutet.
Du könntest einmal den gesamten Ablauf sniffen. Dann werde ich nachsehen und prüfen, was man optimieren kann und wo die messages liegen bleiben.

[DecaTec]

Heute nacht um 0:00 wurden die Heizungen noch einmal umgeschaltet.

An den RT sollte nichts uebertragen werden. Das kannst du kontrollieren indem du bei get hm protoEvents nachsieht.

Wie es aussieht, wird an die RTs was übertragen. Kann ich mir nicht erklären, da keine neue tempList für die RTs gesetzt wurde. Und die neuen Temperaturen bekommen die ja über das peering mit den TCs mit. Das sollte dann nicht über FHEM/HMLan laufen, oder?

get HMinfo protoEvents liefert nun heute morgen folgendes:

Code Auswählen Erweitern


protoEvents done:
    name                      :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    Buero.Heizung             : done           |  -       | 59:      | 1:       # 5        |  -       |  -       | 1:       
    Buero.Thermostat          : done           |  -       | 257:     | 1037:    # 13       | 1:       |  -       | 2:       
    Kueche.Heizung            : done           |  -       | 42:      |  -       # 5        |  -       |  -       | 1:       
    Kueche.Thermostat         : done           |  -       | 227:     | 109205:  # 26       | 2:       |  -       | 3:       
    Schlafzimmer.Heizung      : done           |  -       | 58:      | 1:       # 5        |  -       |  -       | 1:       
    Schlafzimmer.Thermostat   : done           |  -       | 182:     | 556:     # 27       | 2:       |  -       | 2:       
    Wohnzimmer.HeizungFenster : done           |  -       | 44:      | 1:       # 5        |  -       |  -       | 1:       
    Wohnzimmer.HeizungTv      : done           |  -       | 42:      |  -       # 5        |  -       |  -       | 1:       
    Wohnzimmer.Killswitch     :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -       
    Wohnzimmer.Thermostat     : pending        | 36 pending| 123:     | 7:       # 6        | 1:       |  -       |  -       
================================================================================================================
    sum                       0                |36        |1034      |110808    #97        |6         |0         |12       


Komisch ist, dass ein TC nun nach 7 Stunden immer noch 36 pending Commands hat...

Du kannst aber das nicht empfohlene Attribut burstaccess gesetzt haben. Das solltest du löschen.

Das ist nirgends gesetzt.


Werde dann mal den Ablauf mitsniffen. Werde aber wohl erst am Wochenende dazu kommen.


Edit:
Ich sehe gerade, dass wohl in einige Register Müll geschrieben wurde.
Aus dieser tempList

Code Auswählen Erweitern


entities:Wohnzimmer.Thermostat_Climate
R_P1_0_tempListSat>05:00 16.0 24:00 20.5
R_P1_1_tempListSun>05:00 16.0 24:00 20.5
R_P1_2_tempListMon>05:00 16.0 24:00 20.5
R_P1_3_tempListTue>05:00 16.0 24:00 20.5
R_P1_4_tempListWed>05:00 16.0 24:00 20.5
R_P1_5_tempListThu>05:00 16.0 24:00 20.5
R_P1_6_tempListFri>05:00 16.0 24:00 20.5
R_P2_0_tempListSat>24:00 16.0
R_P2_1_tempListSun>24:00 16.0
R_P2_2_tempListMon>24:00 16.0
R_P2_3_tempListTue>24:00 16.0
R_P2_4_tempListWed>24:00 16.0
R_P2_5_tempListThu>24:00 16.0
R_P2_6_tempListFri>24:00 16.0
R_P3_0_tempListSat>24:00 16.0
R_P3_1_tempListSun>24:00 16.0
R_P3_2_tempListMon>24:00 16.0
R_P3_3_tempListTue>24:00 16.0
R_P3_4_tempListWed>24:00 16.0
R_P3_5_tempListThu>24:00 16.0
R_P3_6_tempListFri>24:00 16.0


resultiert z.B. dieser Eintrag im Climate-Kanal des entsprechenden TCs:

Code Auswählen Erweitern


R_P2_1_tempListSun 05:45 08.0 05:45 08.0 05:45 08.0 05:45 08.0 05:45 08.0 05:25 08.0 05:45 08.0 05:45 08.0 05:45 08.0 05:45 08.0 05:45 08.0 05:45 08.0 05:45 08.0


Andere Einträge sind auch incomplete:

Code Auswählen Erweitern

R_P2_3_tempListTue incomplete


Kann ich mir jetzt nicht erklären, woran das liegen könnte.

[martinp876]

Fhem Vergleich die gelesenen Register mit den gewünschten neuen Werten. Uebertragen wird nur dir Differenz. Nichts, wenn nichts geändert wurde.
Wenn du nun die Register nicht oder nicht komplett gelesen hast kann fhem nicht vergleichen und muss alles uebertragen.
Wenn du ein incomplete hast fehlen fhem Register.

Also Stelle sicher dass fhem alle register hat. Ab besten auch aktuelle. Hierzu  autoreadreg setzen. Hminfo configcheck prüft u.a. das alles ab und zeigt dir was nicht komplett ist.
Wenn du alle Register gelesen hast solltest du dies sichern. Hminfo autoarch und autoloadarch sind hilfreiche Attribute.
Das ist eine Voraussetzung für effizientes arbeiten.

Danach kannst du noch einmal probieren die templisten zu uebertragen. Vorher immer ein hm clear msgevents Ents machen damit du bei protoevents sehen kannst was neu ist.