Templist Restore

Begonnen von gent, 16 Januar 2019, 22:36:26

Vorheriges Thema - Nächstes Thema

gent

Hallo Martin,

Ja, ich habe das Verhalten immer. Im Wiki habe ich etwas gefunden zum Thema sniffen. Welches device meinst Du? Ich habe ein hmuart, ein cul oder meinst Du das RT Device?

Viele Grüße, Holger
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

amenomade

Das Sniffen vom RT sollte ihm reichen.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

martinp876

Sniffen ist in wiki beschrieben. Den rt als attr logid im io angeben.

fruemmel

#18
Hallo,

ich möchte mich hier einmal einklinken, weil ich ähnliche Probleme mit dem tempList restore habe. Allerdings ist es nicht immer reproduzierbar, da es manchmal auch funktioniert. Ich habe 5 Ventile HM-CC-RT-DN, davon eines gepeert mit einem Thermostat HM-TC-IT-WM-W-EU.

Ich nutze eine vccu mit 2 x HM-LAN. Mir ist nun aufgefallen, dass in HMLAN2 im internal msgLoadHistoryAbs (5 min steps) immer jedem Menge Werte stehen, bei  HMLAN1 in diesem Reading immer nur 0 auftauchen (0/0/0/...). Selbst wenn ich HMLAN2 auf closed setze, bleiben in HMLAN1 die 0-Werte stehen, obwohl die Kommunikation zu dem Homematic-Geräten weiter funktioniert. Ist das ein seltsames Verhalten oder durchaus normal?
Diese Beobachtung hat sich nach einem Firmware-Update der HMLAN erledigt.

Wenn ich im HMinfo-Device ein set tempList restore absetze, bleiben i.d.R. mehrere Ventile auf CMDs_pending hängen, auch länger als 5 Minuten. Zum Teil habe aber den gleichen Effekt wie gent, d. h. R_tempList_State steht auf verified, ein HMinfo tempList verify bringt aber Abweichungen.

Wenn ich im Abstand von z. B. 10 Minuten ein HMinfo tempList restore mache, "erholen" sich die Ventile, d. h. früher oder später sind alle verified und die Werte passen.

Vielleicht kann gent Parallelen zu seiner Installation finden, ansonsten gehe ich auch mit dem Sniffer auf die weitere Suche.

Gruß Wolfgang

martinp876

Zum ersten Punkt.  Wenn das Device in Pending hängen bleibt kann es sei, dass eine Störung den Ablauf unterbrochen hat. Also noch einmal warten.  Wenn es  nach 10 -15min immer noch hängt ein list des Device (Device reicht) hier posten.

fruemmel

Zitat von: martinp876 am 06 Februar 2019, 13:39:44
Zum ersten Punkt.  Wenn das Device in Pending hängen bleibt kann es sei, dass eine Störung den Ablauf unterbrochen hat. Also noch einmal warten.  Wenn es  nach 10 -15min immer noch hängt ein list des Device (Device reicht) hier posten.
Seit meinem Firmware-Update der HM-LAN scheint das Verhalten besser geworden zu sein. Es dauert jedoch noch sehr lange (>10 Minuten), bis R_tempList_State incomplete durch verified ersetzt wird, weil anscheinend die Ventile die bereits übernommenen tempListen nicht zurückmelden. Und das, obwohl Daten wie
desired-temp und measured-temp regelmäßig gesendet werden.

Ein manuelles getConfig auf das Ventil löst das Problem, der Status springt dann zeitnah auf verified. Sollte das aber nicht eigentlich automatisch erfolgen? Oder habe ich da noch ein Konfigurationsproblem?
Ich teste gerade mit dem weekprofile, das Verhalten scheint aber sehr ähnlich oder sogar identisch zu sein.

martinp876

Die Ventile melden nicht zur, fhem fragt nach. Das wird verzögert gemacht um das io zu entlasten. Die listen sind doch relativ lang, auch wenn typisch fast leer.
Du kannst den ablauf prüfen wenn du den wechsel cmdpending, processing und finished beobachtest.
Es geht automatisch, nur nicht max schnell.
Ich könnte es beschleunigen.... Dann wird worst case bei jedem regchange ein getconfig ausgelöst. Also mehrere nacheinander....

fruemmel

Zitat von: martinp876 am 06 Februar 2019, 19:01:29
Du kannst den ablauf prüfen wenn du den wechsel cmdpending, processing und finished beobachtest.

Erstmal vielen Dank, dass Du Dir die Zeit nimmst, meine Fragen zu beantworten!
Ich habe ja auch einen Thermostat HM-TC-IT-WM-W-EU, da geht das i.d.R. sehr schnell und der tempList_State geht auf verified. Bei den Ventilen ist es jedoch eher
der Normalfall, dass das Device auf CMDs_done steht, tempList_State im Clima-channel auf incomplete. Woran kann ich sehen, wann fhem den Status des Ventils erneut abfragt bzw. ein getConfig macht? Ich hatte jetzt wieder einen Fall, wo auch 30 Minuten später der tempList_State noch auch incomplete stand. Mit verbose=5 auf dem Ventil habe ich bisher nicht viel sehen können, außer viele "dupe dont process".
Ich könnte das Thema für mich dadurch lösen, dass ich zeitverzögert nach dem Setzen eines Profils im Wochenplaner nochmal ein getConfig auf die Ventile mache. Aber so wie ich Dich verstehe, müsste das auch jetzt schon automatisch passieren?

martinp876

Der tc ist ein Brust Device. Nach dem Schreiben wird das rückmelden gequeued und , wenn das io nicht die eingestellte belastungsgrenze überschritten hat,wird gesendet.

Beim RT gilt das gleiche Prinzip.  Jedoch wird die queue erst beim Erwachen des RT geprüft, also schon mal einen Zyklus später.
Wenn der RT auf incomplete steht sollte bei get hm protoEvents ganz unten stehen was in der queue  noch auf Verarbeitung wartet . Decives mit incomplete sollten alle drin stehen, sofern autoreadreg nicht als haltet.

=> wenn incomplete wird noch automatisch aktualisiert.
Wenn das niecht der Fall ist,  bug melden

gent

Zitat von: martinp876 am 02 Februar 2019, 19:22:11
Sniffen ist in wiki beschrieben. Den rt als attr logid im io angeben.

Ok, ich habe das jetzt mal gemacht und hatte zum allerersten Mal auf dem RT ein MissingAck. Trotzdem würde ich das Ergebnis gerne schicken. Sollte ich das als PN machen oder hier posten?
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

martinp876

Als pn gehen keine attachements.
Also hier

gent

OK, anbei der Ausschnitt aus dem logfile.
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

martinp876

Sorry, ich sehe kein send. 
Kannst du sicher stellen dass culhm einen restore macht, dass commands pending sind und dann ein done kommt?
Bitte das nächste mal sniffen wie in wiki beschrieben. Macht es  deutlich einfacher und kürzer.
Gerne die logids auf den Prüfling einstellen.

gent

Zitat von: martinp876 am 13 Februar 2019, 20:40:46
Sorry, ich sehe kein send. 
Kannst du sicher stellen dass culhm einen restore macht, dass commands pending sind und dann ein done kommt?
Bitte das nächste mal sniffen wie in wiki beschrieben. Macht es  deutlich einfacher und kürzer.
Gerne die logids auf den Prüfling einstellen.

Ich habe beim sniffen alles so eingestellt, wie im Wiki beschrieben und die Logis auf den RT eingestellt. Das Culhm ein restore macht, kann ich nicht sehen. Commands sind erst pending und dann done. Das stand aber auch schon weiter oben. Mittlerweile ist es mir auch egal ob das Templist restore klappt oder nicht. Ich kann einzelne Modifikationen direkt auf das Thermostat senden. Trotzdem danke für die Analyse.

Viele Grüße, Holger
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

martinp876