[HM-Module] HM-Thermostate: TempList-Änderung nur nach manuellem getConfig

Begonnen von FFHEM, 14 November 2021, 15:49:31

Vorheriges Thema - Nächstes Thema

frank

tipp:
bei rotem cfgState-icon findest du auch eine kurzbeschreibung der fehler im "tooltip" des icons, der erscheint, wenn der mauszeiger über dem icon liegt.
das ist die ausgabe von "get <entity> deviceInfo".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

FFHEM

Vielen Dank für die Hinweise!
Habe die Punkte 4. - 6. auch noch in das Attribut sumERROR hinzugefügt.

Indem ich im zugehörigen Heizungsthermostaten auch das Attribut tempListTmpl auf none - wie im Wandthermostaten - gestellt hatte, war die "team"-Meldung auch weg.

Durch Deinen Tipp
setreading Arbeitszimmerthermostat_Climate R_P2_tempList_State incomplete
und anschließendes manuelles getConfig ist das "updating" bei cfgState nach ca. 60 s verschwunden und steht jetzt auf "ok".
Aber wie Du schon vermutet hast, das bringt auch kein automatisches getConfig zustande.

Ja, scheint an den 3 Listen zu liegen. Werden denn z. Zt. keine 3 Listen mehr "abgearbeitet"? Ist das bei den Umbauarbeiten an CUL_HM weggefallen?



Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

edition

Guten morgen!

Ich klinke mich mal in diesen Beitrag ein und hole ihn wieder nach oben.
Gibt es denn schon neue Erkenntnisse zu dem Thema? Ich kann die Aussage von FFHEM bestätigen, dass es einmal ein automatisches getConfig gab, nachdem man die Temperaturlisten geändert hat. Ich habe im März diesen Jahres meine Heizkörper im Obergeschoss auf HM-CC-RT-DN mit HM-TC-IT-WM-W-EU umgestellt und dabei jeweils alle 3 Temperaturlisten eingerichtet. Das ging noch ohne ein getConfig manuell auszulösen. Was damals auch nocht funktioniert hat, war die automatische Umschaltung der Temperaturlisten mittels DOIF, wie z.B.:

([13:00|Sun] and [Heizkoerper_Wohnzimmer_Climate:R-weekPrgSel] eq "prog1") (set Heizkoerper_Wohnzimmer_Climate regSet weekPrgSel prog2) DOELSEIF ([13:00|Sun] and [Heizkoerper_Wohnzimmer_Climate:R-weekPrgSel] eq "prog2") (set Heizkoerper_Wohnzimmer_Climate regSet weekPrgSel prog3) DOELSEIF ([13:00|Sun] and [Heizkoerper_Wohnzimmer_Climate:R-weekPrgSel] eq "prog3") (set Heizkoerper_Wohnzimmer_Climate regSet weekPrgSel prog1)

Ohne automatisches getConfig bleibt  weekPrgSel nun auf set_progX stehen und am nächsten Sonntag findet keine Umstellung statt.
Da die Temperaturen im Moment niedrig sind und meine Heizung daher durchläuft, wäre es natürlch schön, wenn die Umstellung wieder automatisch funktionieren würde.

Gruß
edition

Beta-User

Zitat von: FFHEM am 03 Dezember 2021, 15:27:02
Ja, scheint an den 3 Listen zu liegen. Werden denn z. Zt. keine 3 Listen mehr "abgearbeitet"? Ist das bei den Umbauarbeiten an CUL_HM weggefallen?
Soweit ich das erkennen kann, gab es in dieser Hinsicht keine Änderungen. Wobei mir unklar ist, wie weekprofile 3 Listen verwalten soll, das kann afaik "nur" eine Liste, so dass es m.E. nicht verwunderlich, dass bei FFHEM da nicht mehr passiert.

Da dieser Thread schon recht "alt" ist, weiß ich auch nicht, ob martinp876 hier mitliest, eventuell wäre es eine gute Idee, einen neuen Thread zu starten, und das Problem nochmal mit "Bordmitteln" (also ohne weekprofile) so zu erläutern, dass Martin das einfach nachstellen kann.

@edition: Das ist _möglicherweise_ ein anderes Thema => neuer Thread. Bitte da auch ein list von dem TC mit einstellen.

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

edition

Hat sich eigentlich erledigt. Ich habe das Problem umgangen, indem das Programm nicht mehr nach der aktuellen Einstellung am Sonntag auf die nächste Woche umgestellt wird. Ich nehme den Google Kalender zur Hilfe, um das Programm umzustellen. Dann ist es egal, ob da prog3, oder set_prog3 steht. Es wird immer umgestellt!

edition

rgbw

Gibt es zu diesem Thema Neuigkeiten oder einen Workaround? Hier beobachte ich das nämliche Verhalten wie FHEM: Nach einer Änderung der ersten Temperaturliste eines HM-TC-IT-WM-W-EU verbleibt das Reading im Kanal *_Climate auf incomplete. Erst nach einem getconfig auf das Device wird die Liste auf die aktuellen Werte gesetzt und mit R_P1_tempList_State=verified bestätgt. Bei den Thermostaten HM-CC-RT-DN dagegen funktioniert die Änderung und wird im Kanal *_Clima aktualisiert.