AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

jp112sdl
Beiträge: 2704
Registriert: 20.11.2016, 20:01
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 01.04.2019, 20:47

jmaus hat geschrieben:
01.04.2019, 10:28
[*] Beim Hochfahren gibt es mit RaspberryMatic die Möglichkeit Dinge die ein Addon VOR ausführen des ReGaHss, rfd, etc. Dienstes erledigen muss in einen "init" Zweig des Addon rc Skriptes zu stecken. Das nutzt z.B. CUxD damit es VOR dem start von ReGaHss&Co einige Dinge erledigen kann (siehe https://github.com/jens-maus/cuxd/blob/ ... daemon#L61). Damit sollte es dann z.B. möglich sein das du die Dinge die du VOR ReGaHss erledigen musst in dem "init" Zweig deines rc Skriptes abhandelst und damit eigentlich nicht mehr selbst ReGaHss stoppen/starten musst (was eben vermieden werden sollte).
[/list]
Danke, das war ein wichtiger Hinweis, der nun eine Menge Stress abbaut!

Ok... und stan23 war so nett, mir die Frage mit der CCU2 zu beantworten.
Dort gibt es das S55InitAddons nicht - da bleibt die Installation wie gehabt.

VG,
Jérôme

TomMajor
Beiträge: 282
Registriert: 30.08.2017, 23:25
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von TomMajor » 02.04.2019, 00:27

jp112sdl hat geschrieben:
01.04.2019, 20:19

Aber ob nun alles im update_script oder im rc-Script läuft... Warum wäre es im update_script übersichtlicher? Da ist jetzt nur ein bisschen Kopierkram im update_script drin.
Eigentlich findet alles im rc-Script statt, das dann die install-Scripte der einzelnen Devices aufruft.

Wenn jemand eine XML anpasst, muss ich auch im rc-Script ran.
Für mich wirds nur komplizierter, Teile in update_script und Teile im rc-Script laufen zu lassen.

Ich überlege, ob es vielleicht am einfachsten ist, das rc-Script nicht in /etc/config/rc.d abzulegen, wo es erst mit S98StartAddons ausgeführt wird, sondern einen Link in /etc/init.d/ mit einer init-Reihenfolge-Nummer kleiner S61rfd anzulegen.
Ist sicher Geschmackssache mit der Übersichtlichkeit. Das momentan alle Aktionen an 3 Stellen verteilt sind (update_script, rc 'start', install) erschwert mir ziemlich den Durchblick, ich bin aber natürlich nicht so CCU/RM erfahren wie du :wink:

Nachdem was ich heute gelernt habe würde ich sowenig wie möglich im rc-Skript bei init machen, wozu auch, bringt nur Probleme, Startreihenfolge der Dienste, neue FW Versionen ändern da ev. was usw.
- die CCU3 macht eh den reboot, also können wir alles beim install erledigen
- für RM brauchen wir ggf. gar keinen reboot, also erledigen wir alles ebenso im install, müssen halt nur auf die 2x service stop/start achten wie oben geschrieben
- der rc-Skript init wird dazu degradiert, nur zu checken ob Fall backup restore eintritt, dann erneutes install (wobei man da genau schauen müsste wie sich ein 'restore' install vom initialen install unterscheidet)

Erscheint mir konzeptmässig etwas simpler, ist nur eine Idee. Vielleicht teste ich das mal an in nächster Zeit.
Mir brummt jetzt der Kopf, muss die nächsten Tage erst mal drüber meditieren. :mrgreen:

Des Pudels Kernfrage: Warum machst du die ganzen kritischen Sachen im rc init und willst dafür jetzt sogar an die init Reihenfolge ran, anstatt alles vor dem reboot zu erledigen, den Punkt versehe ich nicht, wahrscheinlich habe ich noch irgendeine andere Randbedingung nicht auf dem Schirm :roll:
Viele Grüße,
Tom

jp112sdl
Beiträge: 2704
Registriert: 20.11.2016, 20:01
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 02.04.2019, 07:02

TomMajor hat geschrieben:
02.04.2019, 00:27
Des Pudels Kernfrage: Warum machst du die ganzen kritischen Sachen im rc init und willst dafür jetzt sogar an die init Reihenfolge ran, anstatt alles vor dem reboot zu erledigen, den Punkt versehe ich nicht, wahrscheinlich habe ich noch irgendeine andere Randbedingung nicht auf dem Schirm :roll:
Weil ich keinen Sinn erkenne, es im Update-Script zu erledigen, wenn ich ohnehin beim Hochfahren schauen muss, ob die gesamte Installation nach einem Backup-Restore erneut durchgeführt werden muss.

Und das Argument, man könnte installieren, ohne zu rebooten, ist auch kein Vorteil.
ReGa (was die gesamte Programmabarbeitung betrifft für den Anwender einem Reboot gleich kommt) und RFD müssen ohnehin neu gestartet werden. Ein Reboot dauert auch nicht wirklich lange.

Mit der Installation im 'init' ist mir wirklich sehr geholfen. Da läuft noch keiner der o.g. Dienste.
jp112sdl hat geschrieben:
01.04.2019, 20:19
Ich überlege, ob es vielleicht am einfachsten ist, das rc-Script nicht in /etc/config/rc.d abzulegen, wo es erst mit S98StartAddons ausgeführt wird, sondern einen Link in /etc/init.d/ mit einer init-Reihenfolge-Nummer kleiner S61rfd anzulegen.
An die init-Reihenfolge muss ich somit gar nicht mehr ran, da 'init' von S55InitAddons aufgerufen wird.



TomMajor hat geschrieben:
02.04.2019, 00:27
Das momentan alle Aktionen an 3 Stellen verteilt sind (update_script, rc 'start', install) erschwert mir ziemlich den Durchblick
Und ich finde es so am übersichtlichsten.
  • update_script kopiert lediglich beim Runterfahren erstmal die Addon-Inhalte ins /usr/local
    An dieser Datei muss man eigentlich nie was ändern
  • rc-Script schaut, ob überhaupt eine Installation stattfinden muss und kümmert sich um die Vorbereitung des Systems (ggf. anhalten von Diensten, rw-mounten) und stellt dem RFD vom Benutzer editierte XMLs dem RFD zur Verfügung, sofern er sie in customized_firmware abgelegt hat
    Hier ist die zentrale Baustelle, wenn es CCU FW Updates gibt
  • install_*-Files führen dann alle das jeweilige Geräte betreffenden Modifikationen durch.
    Auch hier muss über CCU-FW-Generationen hinweg nichts geändert werden

VG,
Jérôme

Benutzeravatar
jmaus
Beiträge: 4591
Registriert: 17.02.2015, 14:45
Wohnort: Dresden
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jmaus » 02.04.2019, 07:11

jp112sdl hat geschrieben:
02.04.2019, 07:02
Und ich finde es so am übersichtlichsten.
  • update_script kopiert lediglich beim Runterfahren erstmal die Addon-Inhalte ins /usr/local
    An dieser Datei muss man eigentlich nie was ändern
  • rc-Script schaut, ob überhaupt eine Installation stattfinden muss und kümmert sich um die Vorbereitung des Systems (ggf. anhalten von Diensten, rw-mounten) und stellt dem RFD vom Benutzer editierte XMLs dem RFD zur Verfügung, sofern er sie in customized_firmware abgelegt hat
    Hier ist die zentrale Baustelle, wenn es CCU FW Updates gibt
  • install_*-Files führen dann alle das jeweilige Geräte betreffenden Modifikationen durch.
    Auch hier muss über CCU-FW-Generationen hinweg nichts geändert werden
So finde ich (wenn ich mich erneut einmischen darf) auch am besten. Einen Punkt hattet ihr nämlich noch übersehen. Bei einer CCU2 und CCU3 findet das installieren des Addons via update_script in einer chroot Umgebung statt. Es ist zwar über umwege auch da möglich am read-only rootfs Änderungen vorzunehmen. Gewollt ist es da allerdings nicht.
RaspberryMatic 3.45.7.20190511 @ TinkerS mit ~160 HomeMatic Geräten + ioBroker – GitHubPayPalTwitter

jp112sdl
Beiträge: 2704
Registriert: 20.11.2016, 20:01
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 02.04.2019, 07:16

jmaus hat geschrieben:
02.04.2019, 07:11
Bei einer CCU2 und CCU3 findet das installieren des Addons via update_script in einer chroot Umgebung statt.
Ah okay, das erklärt ein paar anfängliche Probleme von damals :roll:

VG,
Jérôme

TomMajor
Beiträge: 282
Registriert: 30.08.2017, 23:25
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von TomMajor » 02.04.2019, 15:29

jp112sdl hat geschrieben:
02.04.2019, 07:02

Und ich finde es so am übersichtlichsten.
  • update_script kopiert lediglich beim Runterfahren erstmal die Addon-Inhalte ins /usr/local
    An dieser Datei muss man eigentlich nie was ändern
  • rc-Script schaut, ob überhaupt eine Installation stattfinden muss und kümmert sich um die Vorbereitung des Systems (ggf. anhalten von Diensten, rw-mounten) und stellt dem RFD vom Benutzer editierte XMLs dem RFD zur Verfügung, sofern er sie in customized_firmware abgelegt hat
    Hier ist die zentrale Baustelle, wenn es CCU FW Updates gibt
  • install_*-Files führen dann alle das jeweilige Geräte betreffenden Modifikationen durch.
    Auch hier muss über CCU-FW-Generationen hinweg nichts geändert werden
Danke für die Übersicht, das hilft auf jeden Fall für das Verständnis der ganzen Vorgänge.
Und mit der neuen Info bezüglich chroot geht es bei CCU nicht so mit der kompletten Installation in einem Rutsch wie ich mir vorgestellt hatte. :cry:
Viele Grüße,
Tom

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“