AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

[jp112sdl]

Mach mal

Code: Alles auswählen

./install >> $LOGFILE 2>>$ERRFILE

um zu appenden statt zu überschreiben

[TomMajor]

sehr gut, jetzt geht's. Redirect im append mode >> funktioniert auch im rc.d Skript.
Das install wird ja erst nach dem reboot gemacht, insofern bleiben die logs auch erstmal erhalten (bis zum nächsten reboot)
Danke,

[jp112sdl]

Ich hab bei mir im dev-Branch mal die Logfiles mit ins Installationsverzeichnis gelegt.
https://github.com/jp112sdl/JP-HB-Devic ... ices-addon

Bisher brauchte ich die noch nie, aber ist vielleicht doch ganz gut, sie persistent abzulegen

[jp112sdl]

...da gehts schon los
https://github.com/jens-maus/RaspberryMatic/issues/583

Genauso der HB-UNI-Sensor1

[TomMajor]

ja, war früher oder später zu erwarten.
Insgesamt gefällt mir das ganze Prozedere nicht, gerade wenn jeden Monat eine neue FW kommt.
Ein stable 'Home Automation in use' System sieht anders aus. Mal schauen wie sich das weiterentwickelt.

Irgendwie kommt es mir vor als ob der check_monit nach dem reboot 'ins Leere' läuft.
Das ist der Anfang vom meinem rc.d script bei "start", mit deinen neuen checks:

Code: Alles auswählen

case "$1" in
	""|start)
		echo "Installing $ADDON_NAME $ADDON_VERSION" >> $LOGFILE 2>>$ERRFILE
		if [ ! -f ${ADDON_DIR}/installed ] || [ ! -f ${FIRMWARE_FILE} ]; then

            # check firmware version, generate PATCHVERSION
            check_ccu_fw_version

            # Check if monit process exists
            check_monit
            echo "Status Monit: $MONIT" >> $LOGFILE 2>>$ERRFILE

            # ! to stop ReGaHss/RFD services below, we need to stop the new service watchdog Monit with firmwares >= 3.45 !
            if [ $MONIT -ge 1 ]; then
                echo "Stopping monitoring service for ReGaHss and RFD" >> $LOGFILE 2>>$ERRFILE
                /usr/bin/monit unmonitor ReGaHss
                /usr/bin/monit unmonitor rfd
            fi
	...

und das ist der log

Code: Alles auswählen

Installing hb-uni-sensor1 1.69
Found 3.45.5 - using patchversion 2
Status Monit: 0

(Ich weiss, patchversion brauche ich hier (noch) nicht, ich lasse es trotzdem mal mitlaufen).

Der Monit ist da noch 0, d.h. die Dienste werden anschließend nicht 'unmonitored'.
Lasse ich das ps grep command später von der Konsole laufen ist der Status wie erwartet 1.

[jp112sdl]

Der Monit ist da noch 0, d.h. die Dienste werden anschließend nicht 'unmonitored'.

Hmm... jetzt bin ich verwirrt... der monit-Prozess läuft bei mir auch zum Installationszeitpunkt noch gar nicht - und wird erst nach Beenden der Addon-Installation gestartet?
Daher hätte auch ohne Berücksichtigung von monit die Installation wie bisher laufen müssen.

Bei mir hat die Installation bei 2 Systemen geklappt, ohne dass die Geräte im Posteingang landeten

[jp112sdl]

Wenn die /etc/inittab sequentiell abgearbeitet wird, dann ist eigentlich alles in Ordnung:

Code: Alles auswählen

# Startup the system
...
# now run any rc scripts
::sysinit:/etc/init.d/rcS
# run monit to monitor our important services
null::respawn:/usr/bin/monit -Ic /etc/monitrc
...

Es werden erst alle rc-Skripte ausgeführt, also auch S98StartAddons.
Erst wenn alle abgearbeitet sind, wird monit gestartet.

So würde ich es interpretieren!?

Von daher ist es in ok, dass beim Ausführen der Installation nach einem Reboot keine Konfiguration am monit stattfindet (weil der Dienst da noch nicht läuft).
Führt man das Skript jedoch zur Laufzeit aus, muss monit berücksichtigt werden.

[jmaus]

Hallo Jerome,

ich antworte dir jetzt mal hier direkt anstatt das in einer PN zu machen damit auch alle davon profitieren.

Wenn die /etc/inittab sequentiell abgearbeitet wird, dann ist eigentlich alles in Ordnung:

Code: Alles auswählen

# Startup the system
...
# now run any rc scripts
::sysinit:/etc/init.d/rcS
# run monit to monitor our important services
null::respawn:/usr/bin/monit -Ic /etc/monitrc
...

Es werden erst alle rc-Skripte ausgeführt, also auch S98StartAddons.
Erst wenn alle abgearbeitet sind, wird monit gestartet.

So würde ich es interpretieren!?

Genau so ist es. Die Dinge die man in der /etc/inittab definiert werden in der Tat sequentiell abgearbeitet und somit wird Monit eben erst nach /etc/init.d/rcS gestartet welches wiederum für den Start der init skripte verantwortlich ist. Und durch die Angabe "respawn" wird auch sichergestellt das Monit immer wieder neugestartet wird wenn es plötzlich beendet wird. Somit kann man es eben ausversehen oder mit Absicht nicht mehr "killen", was wiederum im Sinne des Erfinders sein sollte. Und natürlich ist es dadurch so, das Monit erst NACH allen init Skripten gestartet wird und folglich dann auch erst auf irgendwelche "unmonitor" oder "monitor" Befehle hören/reagieren kann.

Von daher ist es in ok, dass beim Ausführen der Installation nach einem Reboot keine Konfiguration am monit stattfindet (weil der Dienst da noch nicht läuft).
Führt man das Skript jedoch zur Laufzeit aus, muss monit berücksichtigt werden.

Du solltest auch noch folgende Dinge bzgl. Addon Installation berücksichtigen:

Im Gegensatz zur CCU3 erlaubt RaspberryMatic folgendes bzgl. Addon Installation/Betrieb:

• es ist möglich Addons direkt OHNE Neustart zu installieren. Das ist sogar der Standard. D.h. ein Addon wird dort direkt zur Laufzeit und nicht erst beim Runterfahren bzw. Neustart der CCU installiert. Ergo musst du in deinem install Skript des Addons - wenn du unbedingt und zwingend ReGaHss+rfd stop/neustarten musst auch entsprechend das im install-script tun. Am besten ist das übrigens im Falle von RaspberryMatic mit dem folgenden Monit Aufruf zu machen:

  Code: Alles auswählen

  monit stop ReGaHss

  D.h. man kann einfach als Kommando "stop" mit dem Dienstname schicken und er setzt dann nicht nur das monitoring für diesen Dienst aus sondern beendet den Dienst sogar. Umgedreht dann natürlich analog dazu einfach "start" als Kommando um den Dienst wieder zu starten.
• 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).

Hoffe das klärt deine offenen Fragen und erlaubt dir deine Addons etwas besser auf die neuen Gegebenheiten einzustellen.

[TomMajor]

Vielen Dank an @jmaus für die Erläuterungen, dass schafft definitiv weitere Klarheit.
Das Problem mit der RM "init" Zweig Lösung ist dass man trotzdem weiteren code für CCU3 braucht, wenn ich das richtig sehe. Das verkompliziert leider die AddOn Pflege und Testfälle weiter.

@jp112sdl
Wir brauchen das Start/Stop von ReGaHss und rdf u.a. deswegen weil DEVDB.tcl und webui.js gepatcht werden, ist das richtig?

Wenn monit immer erst nach den init Skripten gestartet wird, wie wir gerade lernen, dann verzichten wir auf den monit check und müssen nur sicherstellen das unsere AddOn Installation immer nach dem reboot gemacht wird, dann wären wir safe?

Führt man das Skript jedoch zur Laufzeit aus, muss monit berücksichtigt werden.

Können wir diesen Fall verhindern bzw. in welcher user Konstellation/Aktion kann der auftreten?

[jmaus]

Vielen Dank an @jmaus für die Erläuterungen, dass schafft definitiv weitere Klarheit.
Das Problem mit der RM "init" Zweig Lösung ist dass man trotzdem weiteren code für CCU3 braucht, wenn ich das richtig sehe. Das verkompliziert leider die AddOn Pflege und Testfälle weiter.

Das stimmt momentan. Aber wie bei vielen Dingen die RaspberryMatic von einer CCU3 unterscheiden ist es auch hier so, das es zumindest geplant ist diese Änderung in einer der nächsten CCU3 Firmwares zu übernehmen. Damit sollten dann die Unterschiede der Addon Installationsroutinen zwischen RM und CCU3 sich wieder erledigt haben.

@jp112sdl
Wir brauchen das Start/Stop von ReGaHss und rdf u.a. deswegen weil DEVDB.tcl und webui.js gepatcht werden, ist das richtig?

Ich wollte diesbzgl. übrigens schon länger einmal vorschlagen das ihr mir einmal versucht detailliert darzulegen was genau ihr da denn bitte genau patcht. Denn dann kann ich sehen bzw. mit eQ3 ggf. darüber diskutieren ob man da nicht eine API schaffen kann mit dem man auf einfacherem Wege andere Komponenten einbinden lassen kann als durch dieses DEVDB/webui.js gepatche. Vielleicht gibt es dann irgendwie ein Verzeichnis oder ähnliches wo ihr eure Anpassungen hinterlegt und dann werden diese automatisch übernommen oder die Gerätedefinitionen die ihr da hinzufügt werden dann via "include" oder ähnlichem hinzugefügt. Dann könnt ihr euch das aufwendige Pflegen von Patchen ja eigentlich sparen. So zumindest die Theorie.

Wenn monit immer erst nach den init Skripten gestartet wird, wie wir gerade lernen, dann verzichten wir auf den monit check und müssen nur sicherstellen das unsere AddOn Installation immer nach dem reboot gemacht wird, dann wären wir safe?

Warum trennt ihr nicht einfach das auspacken+verteilen auf das Verzeichnis des Addons von dem eigentlich Installieren/Patchen der DEVDB, etc.? Bei einer CCU3 könnt ihr einfach beides während der addon installation machen weil addons ja beim runterfahren als letzter schritt installiert wird. Und bei RaspberryMatic dann einfach im "init" Zweig die DEVCB/webui.js patches durchführen und im "start" Zweig des rc Skriptes nur das Addon/Daemon starten (wenn es sowas gibt).