TempList: tempListG restore vs tempList restore

Begonnen von DecaTec, 02 September 2016, 10:49:10

Vorheriges Thema - Nächstes Thema

DecaTec

So, mir ist nun aufgefallen, dass die Batterien der TCs fast leer waren. Habe diese heute morgen mal ausgetauscht. Vielleicht hängt das ja damit zusammen.

Zitat von: martinp876 am 08 September 2016, 20:30:31
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.

autoReadReg steht überall auf 5_readMissing.

Zitat von: martinp876 am 08 September 2016, 20:30:31
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.

OK, diese Attribute waren mir neu.
Ich habe nun autoLoadArchive auf "1_load" und autoArchive auf "1" gesetzt (bei letzterem erscheint übrigens kein Dropdown an der Oberfläche, sondern nur ein normales Input-Feld - macht es hier Sinn, andere Werte außer "0" oder "1" zu verwenden?).

Mal sehen, ob diese Änderungen die Probleme lösen. Ich melde mich nochmal, wenn ich mehr weiß...

DecaTec

So, nach den ganzen Änderungen (und neuen Batterien) scheint das nun alles so zu funktionieren wie erwartet.
Mir ist nur aufgefallen, dass nach dem Setzen der tempListen die Thermostate (mehr oder weniger) sofort mit den neuen Temperaturen arbeiten. Ein set HMinfo tempListG verify ist allerdings auch nach Stunden noch der Meinung, dass einige tempLists nicht passen. Aber nach ca. 1 Tag wird hier "passed" angezeigt.

Die Sache mit dem Overload muss ich mal im Auge behalten. Manchmal kommt er, manchmal nicht.
Hier ist mir aufgefallen, dass wenn der Overload kommt, kommt dieser zwei mal direkt hintereinander - im Abstand weniger Minuten. Das kann ich mir auch nicht so recht erklären, da der HMLan ja nach dem ersten Overload sofort "dicht gemacht" haben sollte.

frank

ZitatDie Sache mit dem Overload muss ich mal im Auge behalten. Manchmal kommt er, manchmal nicht.
Hier ist mir aufgefallen, dass wenn der Overload kommt, kommt dieser zwei mal direkt hintereinander - im Abstand weniger Minuten. Das kann ich mir auch nicht so recht erklären, da der HMLan ja nach dem ersten Overload sofort "dicht gemacht" haben sollte.
das passt schon, da der hmlan immer alle messages der letzen stunde betrachtet. er macht also nicht unbedingt eine stunde dicht bei overload. wenn vor 55 minuten zb 10% des kontingentes verbraucht wurden, werden diese in ca. 5 minuten wieder frei, dann also ca 90%.

dein hmlan braucht mindestens fw 0.964, damit fhem die aktuelle load kennt, um ggf "schonend" mit dem kontingent zu arbeiten.
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

martinp876

Was ist die Meldung wenn das verify nicht passt?
Auch nach Update vom Wochenende?