Ja. Alles andere wäre inkonsequent.
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.