Inkonsistenzen bei HmIP bzgl. getParamset() vs. getParamsetDescription()

[jp112sdl]

Oder meldest du dich etwa freiwillig?

Ja. Alles andere wäre inkonsequent.

Wäre es nicht ausreichend das beim booten zu machen? Kann das denn jede Woche plötzlich auftreten?

Wobei ich Michael hier zustimme.
So wie ich es verstanden habe, kann das fehlerhafte Verhalten nur dann auftreten,
- wenn eine falsche (zu neue) Gerätefirmware eingespielt wird, die mehr Parameter unterstützt, als die aktuelle CCU Version (sprich HMIPServer) verwaltet.
- wenn ein Gerät mit einem neueren Firmware-Versionsstand ausgeliefert wird, als von der aktuell laufenden CCU-FW unterstützt wird
An dieser Stelle ist der "Murks" noch nicht feststellbar.

Wird dann ein CCU-FW-Update durchgeführt, dessen Version nun die neuere Geräte-Firmware mit ihren neuen/zusätzlichen Parametern unterstützt, hängt in der Gerätekonfigurationsdatei (in /etc/config/crRFD/data) weiterhin der alte Parameterstand "fest".
Der HMIPServer ist darauf getrimmt, diese Datei nur dann zu aktualisieren, wenn ein Gerätefirmware-Update erfolgt

Insofern würde es ausreichen, wenn das Skript einmalig nach einem CCU-FW-Update läuft.

Und wie schon an anderer Stelle erwähnt - gehört hier eigentlich der HMIPServer dahingehend gefixt (oder erweitert), solche Inkonsistenzen beim Starten selbst zu reparieren.

[jmaus]

Sonntags, 05:00 Uhr.

Wäre es nicht ausreichend das beim booten zu machen? Kann das denn jede Woche plötzlich auftreten?

Könnte man, wenn man sicherstellen könnte bzw. genau wüsste wann man das machen sollte. Ist im Startup nicht ganz so einfach, denn HmIPServer und ReGaHss müssen ja gestartet sein damit das alles funktioniert was der Skript macht. Da war es einfach einfacher nen cronjob zu machen. Tut ja auch nicht weh die paar sekunden pro woche.

[jmaus]

Und wie schon an anderer Stelle erwähnt - gehört hier eigentlich der HMIPServer dahingehend gefixt (oder erweitert), solche Inkonsistenzen beim Starten selbst zu reparieren.

Ist halt nicht in unserer Hand und eQ3 sieht das Problem aktuell noch nicht als wirklich relevant an wie es aussieht.

[jp112sdl]

Könnte man, wenn man sicherstellen könnte bzw. genau wüsste wann man das machen sollte. Ist im Startup nicht ganz so einfach, denn HmIPServer und ReGaHss müssen ja gestartet sein damit das alles funktioniert was der Skript macht.

10min. nach einem Neustart sollten ausreichend sein.
Den at-Scheduler gibt es im RaspberryMatic Image nicht. Aber mit sleep könnte die Ausführung in der crontab verzögert werden.

Code: Alles auswählen

@reboot sleep 600 && /bin/checkHmIPconsistency.tcl

Der tägliche Alarm ist vielleicht für diejenigen nervig, die nicht die Möglichkeit haben, den Fehler gleich zu beseitigen.
Gerade wenn man Push-Meldungen einsetzt, die bei Alarmen etwas höher priorisiert sind.
Der Alarm kommt jeden Tag aufs Neue.

Bis zum nächsten Release ist die Deaktivier-Option über die erweiterten Einstellungen wohl mit drin.
Das führt zwar dazu, dass 1x deaktiviert, es wohl nie wieder eingeschaltet wird und dann wieder der Zustand herrscht, dass man gar nix mehr von den Inkonsistenzen mitbekommt.

[jmaus]

Könnte man, wenn man sicherstellen könnte bzw. genau wüsste wann man das machen sollte. Ist im Startup nicht ganz so einfach, denn HmIPServer und ReGaHss müssen ja gestartet sein damit das alles funktioniert was der Skript macht.

10min. nach einem Neustart sollten ausreichend sein.
Den at-Scheduler gibt es im RaspberryMatic Image nicht. Aber mit sleep könnte die Ausführung in der crontab verzögert werden.

Code: Alles auswählen

@reboot sleep 600 && /bin/checkHmIPconsistency.tcl

Darüber hatte ich auch schon nachgedacht, aber sleep 600 muss auch nicht treffsicher sein und wer sagt das dann alles bereits ordnungsgemäß hochgefahren ist?!? Oder ich bau etwas in das check Skript selbst ein was auf den HMIPServer und ReGaHss start wartet und dann erst weiter macht. Aber auch da wissen wir ja das ReGa mitunter ne weile braucht um sich "einzupendeln". Aber ja, prinzipiell bin ich auch dafür das nur 1x beim Start diese Prüfung stattfindet und es nicht zwingend regelmäßig 1x die Woche passieren muss. Vielleicht finden wir ja noch einen guten Kompromiss...

Der tägliche Alarm ist vielleicht für diejenigen nervig, die nicht die Möglichkeit haben, den Fehler gleich zu beseitigen.
Gerade wenn man Push-Meldungen einsetzt, die bei Alarmen etwas höher priorisiert sind.
Der Alarm kommt jeden Tag aufs Neue.

Warum täglich? Der aktuelle cronjob ist doch so eingestellt das 1x die *Woche* das ausgeführt wird.

Bis zum nächsten Release ist die Deaktivier-Option über die erweiterten Einstellungen wohl mit drin.
Das führt zwar dazu, dass 1x deaktiviert, es wohl nie wieder eingeschaltet wird und dann wieder der Zustand herrscht, dass man gar nix mehr von den Inkonsistenzen mitbekommt.

Ich bin ehrlich eh kein große Fan davon mehr und mehr solche Dinge in die erweiterten Einstellungen als WebUI Element hinzuzufügen, denn sonst krankt das ganze irgendwann genauso wie Windows. Nämlich das man hunderte Optionen hat die keiner mehr durchschaut. Deshalb würde ich am liebsten in der Tat für diese simple Prüfaktion eigentlich gar kein "NoXXXXCheck" vorsehen, denn ich denke das sollte wirklich bei jedem ausgeführt werden. Für das "SetInterfaceClock" haben wir ja auch keien NoXXXCheck Option und das aus gutem grund.

[MichaelN]

Darüber hatte ich auch schon nachgedacht, aber sleep 600 muss auch nicht treffsicher sein und wer sagt das dann alles bereits ordnungsgemäß hochgefahren ist?!

Dann mach halt sleep 3600
Es ist ja nicht Zeit kritisch.
Und nach 1 Stunde sollte das System wieder rund laufen.

[jmaus]

Darüber hatte ich auch schon nachgedacht, aber sleep 600 muss auch nicht treffsicher sein und wer sagt das dann alles bereits ordnungsgemäß hochgefahren ist?!

Dann mach halt sleep 3600
Es ist ja nicht Zeit kritisch.
Und nach 1 Stunde sollte das System wieder rund laufen.

Inzwischen solltest du mich kennen und wissen, das ich solche "murky" Sachen wirklich nicht gerne mag und daher bessere/stabilere Lösungen finden möchte. Solche "sleep XXX" Verzögerungen existieren in 99% der Fälle nur um entweder ein Workaround für ein vermeintlich unlösbares Problem zu haben oder schlichtweg die Faulheit des Erfinders auszugleichen

[jp112sdl]

Warum täglich? Der aktuelle cronjob ist doch so eingestellt das 1x die *Woche* das ausgeführt wird.

Ja stimmt, die letzte 0 hatte ich übersehen.

Ich bin ehrlich eh kein große Fan davon mehr und mehr solche Dinge in die erweiterten Einstellungen als WebUI Element hinzuzufügen,

Na gut, war zwar schon fertig, aber ist nicht weiter schlimm.

Für das "SetInterfaceClock" haben wir ja auch keien NoXXXCheck Option und das aus gutem grund.

Da steckt ja auch eine notwendige Funktion dahinter, um den HM Geräten die Uhrzeit mitzuteilen.

[jp112sdl]

weil eQ3 die 1.22.8 Firmware freigegeben hatte mit einer falschen CCU minVersion Angabe, sodass Nutzer wie ich die sehr früh die 1.22.8 FW der FSM16 einspielen lassen hatten leider dieser Geräteparameter dem HMIPServer noch nicht bekannt war und dies nun erst mit der 3.67.10 Version wohl überhaupt der Fall ist. Das hatte dann eben zur Folge das man zwar die 1.22.8 Firmware des FSM16 installiert hatte, aber der HMIPServer von dem neuen Parameter gar nichts mitbekommen konnte, eben weil die interne Gerätebeschreibung nicht passte. Das selbe passiert dann sicherlich auch Leuten die hier regelmäßig auftauchen mit neueren Gerätefirmwareversionen als das was für die CCU Firmware vorgeschrieben wird und denen dann eben ein downgrade vorgeschlagen wird.

Die Datei wurde ausgetauscht und unter dem selben Namen wieder veröffentlicht:
viewtopic.php?f=58&t=75048&p=753800#p753800

[jmaus]

weil eQ3 die 1.22.8 Firmware freigegeben hatte mit einer falschen CCU minVersion Angabe, sodass Nutzer wie ich die sehr früh die 1.22.8 FW der FSM16 einspielen lassen hatten leider dieser Geräteparameter dem HMIPServer noch nicht bekannt war und dies nun erst mit der 3.67.10 Version wohl überhaupt der Fall ist. Das hatte dann eben zur Folge das man zwar die 1.22.8 Firmware des FSM16 installiert hatte, aber der HMIPServer von dem neuen Parameter gar nichts mitbekommen konnte, eben weil die interne Gerätebeschreibung nicht passte. Das selbe passiert dann sicherlich auch Leuten die hier regelmäßig auftauchen mit neueren Gerätefirmwareversionen als das was für die CCU Firmware vorgeschrieben wird und denen dann eben ein downgrade vorgeschlagen wird.

Die Datei wurde ausgetauscht und unter dem selben Namen wieder veröffentlicht:
viewtopic.php?f=58&t=75048&p=753800#p753800

Ich weiss Und was denkste wer das angetriggert hatte?