Umstellung Winter-->Sommer: tempList restore geht bei den hm-tc-it-wm-w-eu nicht

[isy]

Moin zusammen,
ich habe heute morgen auf "Sommer" umgestellt. Dazu hatte ich schon seit Längerem eine tempListSommer und eine tempListWinter (siehe auch Wiki) in Betrieb.

--> Bei den 15 HM-CC-RT-DN hat die Umstellung ohne Probleme gelaufen.
--> Bei allen 8 hm-tc-it-wm-w-eu bleibt der Status "MISSING ACK"

Jedes einzelne getConfig funktioniert ohne Probleme bei den hm-tc-it-wm-w-eu.

Update 10.6.21:
Eine tempList pro hm-tc-it-wm-w-eu, damit nur eine übertragen wird.
--> Funktioniert, viel Arbeit

Über Nacht hat sich nichts geändert.
- 1 HM-SEN-MDIR-O-3 Fehler bei register read, mit getConfig wieder OK (Leiter erforderlich, nun denn!)
- 2 TC haben Schrott in den Peerings stehen, beides mit Reset repariert, anschließend neu Peeren und tempList hochladen usw.
- 5 DN haben Schrott in den Peerings, alle Reset usw.

Bei meiner Installation (VCCU, 2 HM-MOD-UART, 1 CCU3 für HM-IP) scheint die Massenübertragung der tempList an die TC und DN zu Übertragungsproblemen zu führen. Einzelne Übertragungen funktionieren.

Im Herbst werde ich noch ein mal zurückdrehen müssen auf die "Winter" tempList.
Ich werde dann wieder auf die alte Methode "Sommer" umstellen, nämlich alle gepeerten TC auf "mode manu" und "desired on", die restlichen DN, die ohne TC laufen,  dito.
Das erzeugt vermutlich wesentlich weniger Funklast.

[isy]

Moin zusammen,
zurück auf Winter-Betrieb geht auch wieder nicht, allerdings haben sich alle DN (15 Stück) perfekt umgestellt, ohne ein Mucken.
Zusätzlich das 2. HM-UART deaktiviert und die CCU3 ausgeschaltet.

Ergebnis: Siehe vorher, viel Arbeit, resetten und neu einrichten.

[martinp876]

mir noch nicht klar, was das Problem ist. Bei mir funktioniert es - somit muss ich verstehen, was du machst.
Bestandsaufnahme - bestätigen, korrogieren:

1) die Templist sind angelegt. Es gibt ein file "tempList.cfg" oder ähnliches.
    Im File sind min 2 Profile angelegt: "Sommer" und "Winter"
2)bei den RT/TC sind die Profile in der Drop-down liste zu sehen beim Kommando "tempTmplSet"
3) ich nutze Attr webCmd desired-temp:controlMode:tempTmplSet
    Damit kann ich  die Profile schnell und einfach in einer Übersicht umstellen.

4) getConfig setzt nicht die Temp-Listen sondern liest die Daten aus dem Device zurück.

Eine tempList pro hm-tc-it-wm-w-eu, damit nur eine übertragen wird.

Unklar. Übertragen werden immer nur die Änderungen zum Stand, welchen CUL_HM kennt.
Wenn also eine Templist 3 Profile hat (TC) und sich 2 nicht ändern wird auch nichts gesendet.
=> es ist nicht notwendig den TC auf eine Liste zu beschränken.
Gelesen wird immer alles. Partiell lesen stellt das Device nicht zu Verfügung.

Ob im cfg file ein oder mehr liste stehen ist egal. Die Liste muss immer an jedes Device gesendet werden. Eine pro Devices - heisst? Eine Templst welche an alle Devices identisch geschickt wird kosten identisch Sendekapazität wie unterschiedliche Templist je device.

Ein getConfig je device ist immer der gleiche Aufwand sendetechnisch. TC sind burst devices. Das kostet Credits. Sollte aber noch klappen bei 15 stück.

Vorschlag: nehme dir ein Device vor und führe ein getConfig aus.Wenn es nicht klappt sniffe und poste das Resultat

[isy]

Hi Martin,
danke für den Support!

Zu deinen Fragen:
1) Es gibt eine TempList für Sommer und eine für Winter, also 2 Dateien mit 2 versch. Namen. Dort sind die Wochenprogramme für die 15 DN und die 8 TC angelegt. Umschaltung per Attribut im HMInfo, wie im Wiki dokumentiert, dann

Code Auswählen Erweitern

set HMinfo tempList restore zum restore der jeweiligen Datei.

2) Bei den TC sind die Wochenprogramme zu sehen, ganz normal ("verified"), bis dahin die "Sommer" Daten, jetzt natürlich die Winterdaten.

3) Guter Tipp, mache ich manuell bis dato.

4) Genau so ist es. Nach den tempList restore starte ich getConfig und dann sieht bei den DN alles gut aus. Bei den TC standen noch die "Sommer" Daten im List. Der Status bei den TC bleibt übrigens "Nak", auch nach Tagen. Auch nach weiteren getConfig.

EINE tempList pro TC:
Ich habe dann die "Winter" Datei dahingehend geändert, dass ich nur die Settings für einen einzigen TC drin gelassen habe. Damit werden nicht 8 TC angesprochen (die standen ja noch auf "Sommer"), sondern nur der eine. 8 TC auf einen Rutsch (also die Wochenprogramme für 8 TC in einem File) geht auch nicht. Immer "Nak" am Ende als Status bei allen 8 TC.
Wenn also nur ein TC angesprochen wird klappt die Übertragung. Ein getConfig und alles sieht gut aus. So habe ich mir jetzt geholfen. Alle 8 sind wieder OK.

Weitere Tests machen echt viel Arbeit leider!
Wenn ich jetzt nur einen TC auf "Sommer" restore, klappt das ja.
Wenn ich alle 8 auf "Sommer" restore, dann sind u.U wieder die Peerings defekt (da steht dann Schrott drin). Was dann die DN ebenso betrifft. Also zurücksetzen und neu peeren. Das wäre blöd! Das ist so passiert bei der Winter nach Sommer Umstellung.

Es sieht m.E. nach nach Übertragungsproblemen bei den TC aus. Liegt vielleicht am Burst Modus, alle senden "gleichzeitig" irgendwie.
Die 15 DN machen keine Probleme, da drücke ich nach dem restore auch bei jedem nacheinander die Programmiertaste nach dem getConfig.

Das alles bei deaktiviertem 2tem HM-UART und der CCU3. Der FS20-CUL war noch eingeschaltet, also 2 Sender auf 868 MHz in der Luft. Der 433er-CUL war noch eingeschaltet, könnte auch was damit zu tun haben, die Teile haben so gut wie keine Selektivität.

Vorschlag: nehme dir ein Device vor und führe ein getConfig aus.Wenn es nicht klappt sniffe und poste das Resultat
Das funktioniert!

VG Helmut

P.S. Ich nutze die tempList seit Jahren. Die Auftrennung Sommer/Winter habe ich neu eingerichtet dieses Frühjahr.
Mir fiel auf dieses Frühjahr, dass früher (sagen wir mal vor 1 Jahr) beim tempList restore im Browser alle Devices angezeigt wurden (als Liste), aber ich glaube mich daran zu erinnern, dass "skipped" o.ä. angezeigt wurde, wenn die tempList pro Device sich nicht geändert hatte. Heute werden alle Devices aufgelistet mit dem gleichen Text.
Ist das korrekt?

[MadMax-FHEM]

Wenn ich alle 8 auf "Sommer" restore, dann sind u.U wieder die Peerings defekt (da steht dann Schrott drin). Was dann die DN ebenso betrifft. Also zurücksetzen und neu peeren. Das wäre blöd! Das ist so passiert bei der Winter nach Sommer Umstellung.

Die Peerings werden IM Gerät selbst gespeichert und DAS ist wichtig!

Die "Anzeige" in fhem nur "sekundär" und verm. wegen den NACK (get Config liest zurück)...

Also ein Reset und neu Peeren ist (denke ich) total überflüssig...

Nur meine Meinung dazu...
...abwarten was Martin dazu meint.

Gruß, Joachim

[isy]

Hallo Joachim,
das ist klar.

Peerings defekt äußert sich vor allem dadurch, dass die Temperaturen zw. DN und TC nicht mehr synchron laufen.

Von den FM im HMInfo configCheck rede ich gar nicht, das ist ja nur die äußere Darstellung.
Nach Batteriewechsel, "clear" der errorMSG usw. geht dann auch getCOnfig wieder. Danach kann man die defekten Peerings (da steht dann hier und da auch Datenmüll drin) im FHEMWEB sehen.

Die Schrottdaten in den Peerings lassen sich durch die üblichen Befehle "set....Channel....unpeer" nicht entfernen, da es die Channels/Devices nicht gibt.
Daher habe die die betroffenen DN und TC zurückgesetzt.
In Summe 2 Tage Arbeit.
Danach hatte ich eigentlich mit dem Thema tempList abgeschlossen und nur noch wieder letztmalig in das "Winter" Programm umgeschaltet. Mit den u.g. Problemen bei den TC.
Seltsamerweise (erfreulich!) sind die DN beim Umstellen von Sommer auf Winter die Tage nicht betroffen gewesen

VG Helmut