AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

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

Moderator: Co-Administratoren

TomMajor
Beiträge: 1790
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von TomMajor » 01.04.2019, 12:27

jmaus hat geschrieben:
01.04.2019, 11:24
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.
Das klingt für mich gut, ich hatte das AddOn Konzept von Jerome vor ca. 1 Jahr übernommen, er ist die Hauptperson im Homebrew Sensor AddOn Geschäft, :D soll er noch was dazu sagen.
Am Beispiel HB-UNI-Sensor1, hauptsächlich werden dort die Verweise auf die 250/50 png Bilder gepatcht und in DEVDB.tcl muss das Device natürlich neu angelegt werden.
https://github.com/TomMajor/SmartHome/b ... n/install

Und natürlich ganz wichtig, es wird die xml Beschreibung für das Gerät nach firmware/rftypes kopiert.
https://github.com/TomMajor/SmartHome/b ... nsor1.xml

Wenn es ein Verzeichnis geben würde wo wir Devicename, .png und .xml reinlegen könnten und das wird dann automatisch übernommen, das wäre aus meiner Sicht genial.
Wir können das gern am Beispiel HB-UNI-Sensor1 mal entwicklen, was imho ein einfacher Start wäre.
Bei Projekten wie dem 4,2 ePaper wird es dann nicht mehr ganz so einfach, aber die genannten Änderungen braucht es auch.
jmaus hat geschrieben:
01.04.2019, 11:24
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).
Müssen wir uns anschauen, klingt nicht schlecht, Danke für den Hinweis.
Viele Grüße,
Tom

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 01.04.2019, 12:34

Für mich wird das hier grad alles sehr komplex.
Auch in Bezug, die Unterstützung für Homebrew Geräte bzw. das Addon für CCU2-Nutzer weiterhin bereitzustellen.
jmaus hat geschrieben:
01.04.2019, 11:24
Ich wollte diesbzgl. übrigens schon länger einmal vorschlagen das ihr mir einmal versucht detailliert darzulegen was genau ihr da denn bitte genau patcht.
Je nach Gerät,
  • /www/config/devdescr/DEVDB.tcl
  • /www/webui/webui.js
  • /www/config/stringtable_de.txt
  • /www/webui/js/lang/de/translate.lang.stringtable.js (teilweise auch /en/)
  • /www/webui/js/lang/de/translate.lang.extension.js (teilweise auch /en/)
  • /www/config/ic_common.tcl
  • /www/rega/pages/tabs/admin/views/programs.htm
  • /www/rega/esp/datapointconfigurator.fn
  • /www/rega/esp/functions.fn
  • /www/rega/esp/side.inc
  • /www/rega/pages/index.htm
Wichtig ist halt nur, dass ReGa (und rfd) die HB-Geräte beim Starten schon kennt, damit sie nicht unbekannt in Posteingang wandern.
Und auch die o.g. Modifikationen benötigen einen Restart der ReGa.

Eine kurzfristige Lösung werden wir wohl nicht finden.
Bin grad noch zwiegespalten, denn das bisherige Konzept gefiel mir gut und es funktionierte.
Gemeldete Fehler nach über 2000 Installationen: 1 (war aber mir geschuldet).

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 01.04.2019, 12:41

jmaus hat geschrieben:
01.04.2019, 11:24
Bei einer CCU3 könnt ihr einfach beides während der addon installation machen weil addons ja beim runterfahren als letzter schritt installiert wird.
Das klappt(e) aber nicht bei der CCU2.
Dann müsste man für diese doch wieder auf das bisherige Konzept zurückgreifen

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

TomMajor
Beiträge: 1790
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von TomMajor » 01.04.2019, 12:57

Aber ist es nicht so dass 80% :?: (habe nicht nachgezählt) deiner HB Geräte auch nur die beschriebenen Änderungen bei DEVDB und webui brauchen?
Dann hättest du da auch eine Arbeitsersparnis in Zukunft wenn das über eine API gehen würde und müsstest nur die "harten" Fälle wie ePaper patchen, oder?
Und die CCU2 Pflege wäre imho nicht so schlimm da z.B. der ganze jetzige Aufruhr ausgelöst durch monit wäre dort nicht, also auch nichts zu ändern.
Viele Grüße,
Tom

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 01.04.2019, 14:26

TomMajor hat geschrieben:
01.04.2019, 12:57
Aber ist es nicht so dass 80% :?: (habe nicht nachgezählt) deiner HB Geräte auch nur die beschriebenen Änderungen bei DEVDB und webui brauchen?
Dann hättest du da auch eine Arbeitsersparnis in Zukunft wenn das über eine API gehen würde
Ich sehe da leider keine Ersparnis, denn die paar Kleinigkeiten sind schon im Kopf eines jeden Install-Skripts enthalten.
Wenn ich ein neues Gerät hinzufüge, ändere ich lediglich die Werte (Gerätename, Bildname) in den Variablen.
z.B.

Code: Alles auswählen

DEVICE="HB-OU-MP3-LED"
DEVICE_IMG=hb-ou-mp3-led.png
DEVICE_THUMB=hb-ou-mp3-led_thumb.png
DEVICE_DESC="MP3 Player with adressable LED"
Der Rest ist ja schon da.
Und beim Beispiel HB-OU-MP3-LED wäre auch noch mehr in der webui.js anzupassen...
Irgendwie ist halt doch bei jedem Gerät irgendeine Kleinigkeit anders als bei anderen.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

TomMajor
Beiträge: 1790
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von TomMajor » 01.04.2019, 19:47

Ich finde nach wie vor dass der API Vorschlag von jmaus eine Sache ist die sich lohnen würde anzusehen, da dies für die Zukunft und den mainstream CCU3/RM für viele HB AddOns eine enorme Erleichterung bei Firmware Updates wäre, wenn auch nicht per se für alle (ePaper, HB-OU-MP3-LED).
Würde wie gesagt meine Unterstützung anbieten um das mal exemplarisch für den HB-UNI-Sensor1 anzutesten.

Für den aktuellen Stand, warum patchen wir eigentlich im 'start' Zweig des init Skripts?
Können wir nicht alles im update_script erledigen, kopieren, patchen, eben alles was nötig ist. Bei CCU3 gibt es dann einen Zwangsreboot (korrekt?) und bei RM gehen wir mit exit code 0 raus (kein reboot).
Und im 'start' Zweig des init Skripts müssen wir genau gar nichts machen, klingt das nicht verführerisch :?:
Also in etwa so

update_script:

Code: Alles auswählen

CCU3			RM
------------------------------------------
-			check auf FW version und monit, stop ReGaHss/rfd direkt bzw. via monit
copy all files		copy all files
patch all files		patch all files
<Zwangsreboot>		start ReGaHss/rfd direkt bzw. via monit
-			exit 0 - kein reboot
Viele Grüße,
Tom

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 01.04.2019, 19:52

TomMajor hat geschrieben:
01.04.2019, 19:47
Können wir nicht alles im update_script erledigen, kopieren, patchen, eben alles was nötig ist
Was ist mit: "Jemand setzt ein blankes System auf und spielt ein Backup ein." ?

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

TomMajor
Beiträge: 1790
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von TomMajor » 01.04.2019, 20:07

Hatte ich nicht auf dem Schirm, das wäre dann doch eine Aktion für den 'start' Zweig, update_script erneut ausführen.

Ich verstehe den neu eingeführten check auf monit im 'start' immer weniger da dieser ja nach reboot noch nicht läuft, deswegen wollte ich mal ein alternatives Konzept diskutieren, wo alles im update_script gemacht wird (und wo CCU3/RM Eigenheiten berücksichtigt werden, z.B. kein reboot für RM) und was ggf. übersichtlicher wäre.
Viele Grüße,
Tom

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 01.04.2019, 20:19

TomMajor hat geschrieben:
01.04.2019, 20:07
Ich verstehe den neu eingeführten check auf monit im 'start' immer weniger da dieser ja nach reboot noch nicht läuft
Der Check ist für 2 Fälle:
1.) Zum Testen starte ich nicht jedes Mal neu, sondern führe das rc-Skript manuell aus. Und da läuft monit.
2.) aufgrund des Tickets hatte ich das Gefühl, monit funkt dazwischen.
TomMajor hat geschrieben:
01.04.2019, 20:07
was ggf. übersichtlicher wäre.
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.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: AddOn Entwicklung - kritische Änderungen wegen neuer Firmware

Beitrag von jp112sdl » 01.04.2019, 20:29

Das mit dem 'init' im rc-Script werde ich aber umsetzen.
Dann läuft das Script VOR ReGa und RFD, das ist am besten.
Muss nur morgen mal schauen, ob es /etc/init.d/S55InitAddons auch auf der CCU2 gibt. Heut habe ich keinen Zugriff drauf.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Antworten

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