Neues HM-CC-RT-DN flutet Log-Datei

[holmexx]

Das habe ich ganz aus den Augen verloren: 22:46 Uhr, beide Geräte: cfgState ok. Ich glaube, der CUL braucht anderes Futter, oder?

[holmexx]

Ich möchte eine Zusammenfassung geben:

Seit dem Aufspielen der Firmware v0.42 vor ~48 Stunden gab es nur noch 2 Mal eine "_sfail _noAnsw"-Meldung im Log. Das dürfte dann wohl ungünstigem Zusammentreffen von Toleranzen geschuldet sein. Es hat auch keine Auswirkungen auf die Gesamtfunktionalität. Die "NAME undef for did"-Meldungen sind gar nicht mehr aufgetreten. Was richtig lange dauert (2 Stunden oder mehr), ist, bis cfgState ok nach einem getConfig in den Readings auftaucht. Darauf muss ich mich einstellen. Ich denke, dass ein zu frühes peering (hier Fensterkontakt) dann nicht auf Anhieb erfolgreich ist; oder es scheint nur so, da halt cfgState noch nicht ok ist und in den Readings z.B. des WindowRec-Channels RegL_01 und RegL_07 fehlt.

Vielen Dank an Ansgar für das kurzfristige Erstellen der neuen Firmware und für die Geduld mit mir.

Gruß
Holger.

[noansi]

Hallo Holger,

mit HMinfo kannst Du noch nützliche Infos sammeln, z.B. Batterie ok oder Motor Fehler. siehe Attribute sumERROR und sumStatus.

Dann gibt es noch automatisches Speichern der mühsam ergatterten Registerzustände in HM_Info_Save.dat.
bei HMInfo habe ich mir die Attribute
autoArchive auf 1
autoLoadArchive auf 1_load
configDir auf /opt/fhem
configFilename auf HM_Info_Save.dat
autoUpdate auf 08:00
gesetzt. Dann holt sich fhem bei Reboot die Register aus HM_Info_Save.dat.

autoUpdate bewußt auf 8 Stunden, damit es nicht stört und so viel ändert sich auch nicht, dass man es öfter bräuchte.

Gruß, Ansgar.

[frank]

Hinweis: 48FAD6 ist ein in der Zwischenzeit hinzugekommender Fensterkontakt, der aber keinerlei Probleme bereitet. Alle anderen hier auftauchenden Geräte gehören nicht zu mir.

das sieht aber nicht so aus.

Code Auswählen Erweitern

2024.09.19 18:46:24 3: LogHist Scully:  02977280 A F001 06920868 00 0D BC A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02977552 A F001 06921140 00 0D BD A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02978075 A F001 06921664 00 0D BE A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02978920 A F001 06922508 00 0D BF A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02980078 A F001 06923664 00 0D C0 A610 48FAD6 250258 06010000 -50dB
...
2024.09.19 18:46:24 3: LogHist Scully:  02981496 A F101 06925084 00 0D C1 A610 48FAD6 250258 06010000 -50dB
das sieht für mich eigentlich danach aus, dass der fk keine antwort von der zentrale bekommt und daher die message wiederholt.
allerdings ist es seltsam, dass die wiederholungen fortlaufende message nummern haben.
das kenne ich so nicht.


zeig mal ein "get list full" vom fk.

[noansi]

Hallo Holger,

hier https://forum.fhem.de/index.php?msg=1321390 gibt es eine aktualisierte Version.
Ich habe den SPI Zugriff auf den Tranceiver korrigiert, sollte besser funktionieren, als der Stand, den Du jetzt hast.

Gruß, Ansgar.