JP-HB-Devices Addon - V5 - Tester gesucht

[jp112sdl]

Hallo an alle, die das JP-HB-Devices Addon für den CCU-Support der Homebrew AskSin++ Geräte einsetzen.

Ich habe in den letzten Tagen die Addon-Installationsroutinen komplett umgebaut, um den Pflegeaufwand zu verringern und auch die Deinstallation zu verbessern. Bisher sind doch immer noch Fragmente in Systemdateien verblieben.

Bis auf das Eintragen der Gerätetypen in die DEVDB.tcl habe ich komplett auf die bisherige Methode mittels sed (Datei öffnen - prüfen ob Zeile schon drin - Zeile einfügen - Datei schließen) nun komplett verzichtet und füge alle Änderungen mittels patch ein.

Das Editieren der Dateien (besonders bei den Übersetzungen) ist für mich nun wesentlich angenehmer.

Die Installationsgeschwindigkeit ist dabei rapide gestiegen. Auf meinem Raspberry Pi Testsystem mit (sicher nicht der schnellsten) SD-Karte ergeben sich dabei folgende Zeiten:

• alte Methode mit sed: 2m 36.65s
• neue Methode mit patch: 0m 28.73s

Desweiteren habe ich mir die Mühe gemacht, ein Testskript zu bauen, um beim Neuerscheinen einer CCU-Version sofort prüfen zu können, ob sich noch alle Patch-Files anwenden lassen.
Außerdem habe ich mir ein kleines Archiv mit CCU-/RaspberryMatic Versionen angelegt, um auch die Abwärtskompatibilität (soweit mir verfügbar bzw. der jeweils letzten Build-Version einer Hauptversion) prüfen zu können.

Aktuell werden (fehlerfrei) getestet:

Code: Alles auswählen

ccu2-2.53.27
ccu2-2.55.10
ccu2-2.57.4

RaspberryMatic-3.37.8.20180922
RaspberryMatic-3.41.11.20190126
RaspberryMatic-3.45.7.20190622
RaspberryMatic-3.47.22.20191130
RaspberryMatic-3.49.17.20200131
RaspberryMatic-3.51.6.20200621
RaspberryMatic-3.53.34.20201121
RaspberryMatic-3.55.10.20210213
RaspberryMatic-3.57.4.20210320

ccu3-3.47.10
ccu3-3.47.15
ccu3-3.47.18
ccu3-3.47.22
ccu3-3.49.17
ccu3-3.51.6
ccu3-3.53.26
ccu3-3.53.30
ccu3-3.55.10
ccu3-3.55.5
ccu3-3.57.4

Auf meiner Testanlage mit einer RaspberryMatic auf einem Rpi 3 und 2 Versionen in VirtualBox läuft das alles problemlos.
Aber wie das im Labor so ist - da geht es ja meistens immer.

Wer also auch mal testen möchte, findet die neue Version >>>hier<<<.
Und bitte unbedingt die Hinweise lesen, wie das Upgrade ablaufen muss!

Ob die Installation erfolgreich war, kann u.a. mithilfe des Logfiles geprüft werden.
Es ist auf der CCU zu finden unter

Code: Alles auswählen

/usr/local/addons/jp-hb-devices-addon/log/jp-hb-devices-addon-inst.err

Sie sieht im Idealfall so aus:

Code: Alles auswählen

### Applying common patch file channels.fn.patch
- done
### Applying common patch file datapointconfigurator.fn.patch
- done
### Applying common patch file functions.fn.patch
- done
### Applying common patch file header.htm.patch
- done
### Applying common patch file ic_common.tcl.patch
- done
### Applying common patch file methods.conf.patch
- done
### Applying common patch file rhs.fn.patch
- done
### Applying common patch file rhs.tcl.patch
- done
### Applying common patch file sliderControl.js.patch
- done
### Applying common patch file stringtable_de.txt.patch
- done
### Applying common patch file translate.lang.extension.js.patch
- done
### Applying common patch file translate.lang.js.patch
- done
### Applying common patch file translate.lang.stringtable.js.patch
- done
### Applying common patch file webui.js.patch
- done
Applying ge_345 patch file programs.htm.patch
- done
Applying ge_345 patch file side.inc.patch
- done

[FUEL4EP]

Hi Jérôme,

Dein neuer Patch-Ansatz gefällt mir

Beim ersten Überfliegen kamen bei mir folgende Fragen auf:

1. Du patchst immer mit absoluten Zeilenindizes. Was bedeutet das für andere Addons, die auch Zeilen in die Konfigurationsdateien einfügen und damit gegebenenfalls die Zeilenindizes verändern? Muss da eine bestimmte Reihenfolge eingehalten werden? Wie kommen sich da unterschiedliche Addons mit unterschiedlicher Einfügemethodik und Löschmethodik nicht ins Gehege? Bisher haben unsere Addons nicht in absolute Zeilenindizes, sondern relativ vor oder nach Suchstrings eingetragen.

2. Ein Sensor braucht nach wie vor Einträge in verschiedenen Pachdateien. Wie stellst Du sicher, dass die Einträge zueinander konsistent und vollständig sind? Meine Idee dafür ist, wie von mir in einem anderen Thread angeregt, dafür eine XML + XSD-Schema Datenbank aufzubauen, die die Vollständigkeit und Konsistenz sicherstellt: Also ein vorgelagerter Generator entweder mit xlst oder mit Groovy, der die Patchdateien erzeugt. Die Frage 1. ist damit m.E. aber nicht gelöst.

.. soviel für heute.

[jp112sdl]

Was bedeutet das für andere Addons, die auch Zeilen in die Konfigurationsdateien einfügen und damit gegebenenfalls die Zeilenindizes verändern?

Nichts - patch hat keine Probleme mit Zeilenversatz.
Es ist auch üblich, dass sich die Zeilenpositionen verändern, wenn eQ-3 selbst was an den Dateien verändert.
Das ist kein Problem.

Zum Ermitteln der Stelle, wo patch den Inhalt einfügt, werden 6 fixe Zeilen benötigt. 3 vor und 3 nach dem Einfügen.
Da habe ich mich am OCCU orientiert und geschaut, wo in den letzten Jahren nichts verändert wurde.

Ein Sensor braucht nach wie vor Einträge in verschiedenen Pachdateien. Wie stellst Du sicher, dass die Einträge zueinander konsistent und vollständig sind?

Es gibt aus meiner Sicht keinen Blueprint. Es ist nie absehbar, in welchen Dateien Änderungen vorgenommen werden müssen, außer der DEVDB.tcl und der webui.js.
Das habe ich gedanklich auf dem Schirm.
Alles weitere, wie z.B. Übersetzungen, ergibt sich im Laufe des Geräte-Entwicklungsprozesses.
Wenn ich z.B. in einem Sketch einen neuen eigenen List0 Parameter hinzufüge, der auch übersetzt werden muss, mache ich das auch sofort im Addon.

eine XML + XSD-Schema Datenbank aufzubauen, die die Vollständigkeit und Konsistenz sicherstellt: Also ein vorgelagerter Generator entweder mit xlst oder mit Groovy, der die Patchdateien erzeugt.

Lohnt sich aus meiner Sicht nicht, nur für 2 Dateien, aber jeder hat halt seinen eigenen Workflow.


Den größten Benefit in der Patch-Variante sehe ich darin, die Dateien nun direkt editieren zu können.
Statt im Install-Skript unleserlich sowas wie

Code: Alles auswählen

webuiInsertParam="HB_RINGER_CHANNEL"
webuiInsertValue="stringTableHbRingerChannel"
webuiInsert="\n"
webuiInsert="${webuiInsert}elvST['$webuiInsertParam'] = '\${$webuiInsertValue}';"
if [ -z "`cat $webuiFile | grep \"$webuiInsertParam\"`" ]; then sed -i "s/\($webuiSearchBegin\)/\1$webuiInsert/g" $webuiFile; fi

einzufügen, kann man es direkt in der webui.js als

Code: Alles auswählen

elvST['HB_RINGER_CHANNEL'] = '${stringTableHbRingerChannel}';

einfügen.

Und so verhält es sich ja dann auch mit anderen Dateien (ggf. stringtable_de.txt oder translate.lang*)

[Matthias K.]

Hab das mal auf meinem Produktivsystem (RPi3B mit RaspberryMatic 3.57.4.20210320) getestet.

Variante 2 hat wunderbar funktioniert, jp-hb-devices-addon-inst.err sieht nach Firmware-Drüberbügeln sauber aus.

[jp112sdl]

Ich habe mich nun gänzlich von dem Konzept "Ein Install-File per Device" verabschiedet.
Das macht die Struktur wesentlich übersichtlicher.
https://github.com/jp112sdl/JP-HB-Devic ... /src/addon

Es gibt nur noch "inst_additional.sh", das einige wenige Sonderfälle behandelt (Dateien kopiert, channels.htm editiert), sowie das "inst_devdb.sh" Skript, das nun die gesamte DEVDB-Integration vornimmt.
Die Geräteliste wird dabei aus der >>>devdb.csv<<< gelesen.

Zudem habe ich ein "Warndreieck" in die WebUI eingebaut, das erscheint, wenn bei der Addon-Installation Probleme auftraten.
Das Symbol lässt sich anklicken, so dass die Logdatei direkt heruntergeladen werden kann.

[FrankenKai]

Hi,
ich habs auch nach Variante 2 auf einer CCU3 mit der 3.57.5 erfolgreich getestet.
Kein Wanrndreieck
Gruß
Kai

[Baxxy]

Hi Jérôme,

da die V5.0 ja nun "offiziell" ist habe ich sie mal auf einem frischen RM-Nightly (RaspberryMatic-3.57.5.20210424) installiert.

Bis auf zwei "Schönheitsfehler" in der Add-On Übersicht (Einstellungen > Systemsteuerung > Zusatzsoftware) sieht alles gut aus.

V5.0 auf 3.57.5.20210424 Nightly

vs.
V4.2 auf 3.57.4.20210401Nightly

(Diverse Browser getestet sowie Cache-Leerung durchgeführt)

Grüße
Baxxy

[jp112sdl]

Bis auf zwei "Schönheitsfehler" in der Add-On Übersicht

Seltsam. An der Stelle hab ich ja nu gar nix angefasst

Code: Alles auswählen

http://<ccu>/addons/jp-hb-devices-addon/jp-hb-devices-addon.png

zeigt auch kein Bild an?

Bei mir sieht das so aus

[Baxxy]

404 Not Found
ist aber alles da wo es hingehört.

Auf dem anderen System (Upgrade von 4.2 auf 5.0 mit anschließendem drüberbügeln der RM-Firmware) passt alles.

Ich mache nochmal neu und gucke ob sich das reproduzieren lässt.

Grüße
Baxxy

[jp112sdl]

ist aber alles da wo es hingehört.

Evtl. ein Rechteproblem. Ich installier auch mal den letzten nightly

EDIT: Bei mir tritt das Problem nicht auf (3.57.5.20210424)