Addon Generierung automatisieren
Moderator: Co-Administratoren
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Addon Generierung automatisieren
Hallo Ewald,
weil ich auch ziemlich lange dran sass, bis es lief, nochmal in Kuerze mein Verstaendnis auf Basis eines Beispiels der alten sed-basierten Scripte z.B. in meinem AddOn Version 1.25 unter https://github.com/HMSteve/SG-HB-Devices-AddOn:
Schritt 1: Ergaenzung des Parameters in /www/webui/webui.js:
webuiInsertParam="HBWEATHER|CO2_CALIB_REF" referenziert paramset und parameter_id im xml, dies unbedingt ohne Umlaute etc
webuiInsertValue="stringTableHBWeatherCo2CalibRef" legt den zu uebersetzenden Schluessel an
...
Schritt 2: Hinterlegung des Paerchens in /www/config/stringtable_de.txt:
stringtable_deInsert="HBWEATHER|CO2_CALIB_REF\t\${stringTableHBWeatherCo2CalibRef}"
...
Schritt 3: Hinterlegen der Sprachuebersetzung in /www/webui/js/lang/de/translate.lang.stringtable.js
translate_deInsert="\n \"stringTableHBWeatherCo2CalibRef\" : \"Kalibrierungswert\","
...
Schritt 3a: Uebersetzung Englisch, wenn gewuenscht, in /www/webui/js/lang/en/translate.lang.stringtable.js
translate_enInsert="\n \"stringTableHBWeatherCo2CalibRef\" : \"Calibration Value\","
...
Jérôme, kannst Du mich bitte ggf korrigieren, dann kann der Post als kleine Doku auch fuer andere dienen.
Viele Gruesse,
Stephan
weil ich auch ziemlich lange dran sass, bis es lief, nochmal in Kuerze mein Verstaendnis auf Basis eines Beispiels der alten sed-basierten Scripte z.B. in meinem AddOn Version 1.25 unter https://github.com/HMSteve/SG-HB-Devices-AddOn:
Schritt 1: Ergaenzung des Parameters in /www/webui/webui.js:
webuiInsertParam="HBWEATHER|CO2_CALIB_REF" referenziert paramset und parameter_id im xml, dies unbedingt ohne Umlaute etc
webuiInsertValue="stringTableHBWeatherCo2CalibRef" legt den zu uebersetzenden Schluessel an
...
Schritt 2: Hinterlegung des Paerchens in /www/config/stringtable_de.txt:
stringtable_deInsert="HBWEATHER|CO2_CALIB_REF\t\${stringTableHBWeatherCo2CalibRef}"
...
Schritt 3: Hinterlegen der Sprachuebersetzung in /www/webui/js/lang/de/translate.lang.stringtable.js
translate_deInsert="\n \"stringTableHBWeatherCo2CalibRef\" : \"Kalibrierungswert\","
...
Schritt 3a: Uebersetzung Englisch, wenn gewuenscht, in /www/webui/js/lang/en/translate.lang.stringtable.js
translate_enInsert="\n \"stringTableHBWeatherCo2CalibRef\" : \"Calibration Value\","
...
Jérôme, kannst Du mich bitte ggf korrigieren, dann kann der Post als kleine Doku auch fuer andere dienen.
Viele Gruesse,
Stephan
- FUEL4EP
- Beiträge: 586
- Registriert: 01.11.2017, 17:26
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 76 Mal
- Danksagung erhalten: 78 Mal
- Kontaktdaten:
Re: Addon Generierung automatisieren
@Stefan, danke, das hilft ungemein. Ich werde versuchen, das mal in die Generatorsoftware zu gießen.
Ich denke, es ist auch besser, mit dem parsen der rftypes XML zu beginnen, daraus dann die webUIinserts abzuleiten und die dann gegebenenfalls zu übersetzen. Sollte machbar sein.
Der Übersetzungsstring muss encodeURL() sein.
Die Devicebeschreibung muss encodeAsHTML4() sein.
@Jérôme
Ich habe noch eine Verständnisfrage nach dem Studium einiger Deiner Beispiele: Sensor hb-uni-sen-volt
In install_hb-uni-sen-volt steht:
In rfftypes XML steht als Kanadefinition:
Warum gib es in kein webUIinsert für 'HB_GENERIC_VOLT|HB_VOLTAGE'?
Warum gibt es für HB_GENERIC_VOLT|HB_VOLTAGE keine Übersetzung?
Oder beim hb-uni-sen-lev-us ergibt ein grep CAPACITIVE_FILLING_LEVEL_SENSOR
Manche Parameter haben ein webuiInsertParam(CAPACITIVE_FILLING_LEVEL_SENSOR|DISTANCE_OFFSET), andere nicht (CAPACITIVE_FILLING_LEVEL_SENSOR|FILLING_LITER). Woran liegt das?
In rftypes XML unterscheiden sich beide nicht:
Ich denke, es ist auch besser, mit dem parsen der rftypes XML zu beginnen, daraus dann die webUIinserts abzuleiten und die dann gegebenenfalls zu übersetzen. Sollte machbar sein.
Der Übersetzungsstring muss encodeURL() sein.
Die Devicebeschreibung muss encodeAsHTML4() sein.
@Jérôme
Ich habe noch eine Verständnisfrage nach dem Studium einiger Deiner Beispiele: Sensor hb-uni-sen-volt
In install_hb-uni-sen-volt steht:
Code: Alles auswählen
### Edit stringtable_de.txt ###
stringtable_deFile="/www/config/stringtable_de.txt"
stringtable_deInsert="HB_GENERIC_VOLT|HB_VOLTAGE\t\${stringTablePowerMeterVoltage}"
if [ -z "`cat $stringtable_deFile | grep \"HB_GENERIC_VOLT|HB_VOLTAGE"`" ]; then
echo -e $stringtable_deInsert >> $stringtable_deFile
fi
Code: Alles auswählen
<channel autoregister="true" index="1" type="HB_GENERIC_VOLT" count_from_sysinfo="23.0:1.0">
<paramset type="MASTER" id="HB-UNI-Sen-VOLT_master">
</paramset>
<paramset type="VALUES" id="HB-UNI-Sen-VOLT_values">
<parameter id="HB_VOLTAGE" operations="read,event" control="NONE">
<logical type="float" min="0.0" max="1000.0" unit="V"/>
<physical type="integer" interface="command" value_id="HB_VOLTAGE" no_init="true">
<event frame="MEASURE_EVENT"/>
</physical>
<conversion type="float_integer_scale" factor="10"/>
</parameter>
</paramset>
<paramset type="LINK" id="HB-UNI-Sen-VOLT_link" />
</channel>
</channels>
Warum gib es in kein webUIinsert für 'HB_GENERIC_VOLT|HB_VOLTAGE'?
Warum gibt es für HB_GENERIC_VOLT|HB_VOLTAGE keine Übersetzung?
Oder beim hb-uni-sen-lev-us ergibt ein grep CAPACITIVE_FILLING_LEVEL_SENSOR
Code: Alles auswählen
~/Arduino/RapberryMatic_Addons/JP-HB-Devices-addon/src/addon$ grep CAPACITIVE_FILLING_LEVEL_SENSOR *hb-uni-sen-lev-us*
install_hb-uni-sen-lev-us:webuiInsertParam="CAPACITIVE_FILLING_LEVEL_SENSOR|DISTANCE_OFFSET"
install_hb-uni-sen-lev-us:webuiInsertParam="CAPACITIVE_FILLING_LEVEL_SENSOR|SENSOR_TYPE"
install_hb-uni-sen-lev-us:stringtable_deInsert="CAPACITIVE_FILLING_LEVEL_SENSOR|BATTERY_VOLTAGE\t\${stringTableCapacitiveFillingSensorBatteryVoltage}"
install_hb-uni-sen-lev-us:if [ -z "`cat $stringtable_deFile | grep \"CAPACITIVE_FILLING_LEVEL_SENSOR|BATTERY_VOLTAGE"`" ]; then
install_hb-uni-sen-lev-us:stringtable_deInsert="CAPACITIVE_FILLING_LEVEL_SENSOR|FILLING_LITER\t\${stringTableCapacitiveFillingSensorFillingLiter}"
install_hb-uni-sen-lev-us:if [ -z "`cat $stringtable_deFile | grep \"CAPACITIVE_FILLING_LEVEL_SENSOR|FILLING_LITER"`" ]; then
install_hb-uni-sen-lev-us:stringtable_deInsert="CAPACITIVE_FILLING_LEVEL_SENSOR|FILLING_HEIGHT\t\${stringTableCapacitiveFillingSensorFillingHeight}"
install_hb-uni-sen-lev-us:if [ -z "`cat $stringtable_deFile | grep \"CAPACITIVE_FILLING_LEVEL_SENSOR|FILLING_HEIGHT"`" ]; then
install_hb-uni-sen-lev-us:stringtable_deInsert="CAPACITIVE_FILLING_LEVEL_SENSOR|SENSOR_TYPE\t\${stringTableCapacitiveFillingSensorSensorType}"
install_hb-uni-sen-lev-us:if [ -z "`cat $stringtable_deFile | grep \"CAPACITIVE_FILLING_LEVEL_SENSOR|SENSOR_TYPE"`" ]; then
install_hb-uni-sen-lev-us:stringtable_deInsert="CAPACITIVE_FILLING_LEVEL_SENSOR|DISTANCE_OFFSET\t\${stringTableCapacitiveFillingSensorDistanceOffset}"
install_hb-uni-sen-lev-us:if [ -z "`cat $stringtable_deFile | grep \"CAPACITIVE_FILLING_LEVEL_SENSOR|DISTANCE_OFFSET"`" ]; then
uninstall_hb-uni-sen-lev-us:webuiSearch="CAPACITIVE_FILLING_LEVEL_SENSOR|DISTANCE_OFFSET"
uninstall_hb-uni-sen-lev-us:webuiSearch="CAPACITIVE_FILLING_LEVEL_SENSOR|SENSOR_TYPE"
uninstall_hb-uni-sen-lev-us:stringtable_deSearch="CAPACITIVE_FILLING_LEVEL_SENSOR|BATTERY_VOLTAGE"
uninstall_hb-uni-sen-lev-us:stringtable_deSearch="CAPACITIVE_FILLING_LEVEL_SENSOR|DISTANCE_OFFSET"
uninstall_hb-uni-sen-lev-us:stringtable_deSearch="CAPACITIVE_FILLING_LEVEL_SENSOR|SENSOR_TYPE"
uninstall_hb-uni-sen-lev-us:stringtable_deSearch="CAPACITIVE_FILLING_LEVEL_SENSOR|FILLING_LITER"
uninstall_hb-uni-sen-lev-us:stringtable_deSearch="CAPACITIVE_FILLING_LEVEL_SENSOR|FILLING_HEIGHT"
In rftypes XML unterscheiden sich beide nicht:
Code: Alles auswählen
<parameter id="FILLING_LEVEL" operations="read,event">
<logical type="integer" min="0" max="100" unit="%"/>
<physical type="integer" interface="command" value_id="FILLING_LEVEL" no_init="true">
<event frame="MEASURE_EVENT"/>
</physical>
</parameter>
<parameter id="FILLING_LITER" operations="read,event">
<logical type="float" min="0" max="100000000" unit="L"/>
<physical type="integer" interface="command" value_id="FILLING_LITER" no_init="true">
<event frame="MEASURE_EVENT"/>
</physical>
<conversion type="float_integer_scale" factor="1.0"/>
</parameter>
Zuletzt geändert von FUEL4EP am 07.04.2021, 21:31, insgesamt 2-mal geändert.
Grüße
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: Addon Generierung automatisieren
Ganz wichtig ist die elvST-Sektion noch in der /www/webui/webui.js.
Das sind die Übersetzungen für Geräteeinstellungen (Parameter) und Status und Bedienung (Values).
Die stringtable_de.txt ist z.B für Datenpunkte (z.B. bei Programmen)
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: Addon Generierung automatisieren
FILLING_LITER habe ich beim hb-uni-sen-lev-tof mit eingefügt
https://github.com/jp112sdl/JP-HB-Devic ... ev-tof#L60
Das ist das was ich meinte, dass man den Überblick verliert, was man (gemeinsam genutztes) schon irgendwo mal hinzugefügt hat.
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: Addon Generierung automatisieren
Weil ${stringTableVoltage} schon von eQ-3 mitkommt. Bzw. mitkam. Flog irgendwann raus... hatte ich dann an anderer Stelle wieder eingefügt
- FUEL4EP
- Beiträge: 586
- Registriert: 01.11.2017, 17:26
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 76 Mal
- Danksagung erhalten: 78 Mal
- Kontaktdaten:
Re: Addon Generierung automatisieren
OK, ich sehe, dass ein Generator noch mehr Dateien parsen und durchforsten müsste, um brauchbare Ergebnisse zu liefern:
1. rftypes XML (als Quelle)
2. webui.js (was ist dort schon definiert?)
3. /www/config/stringtable_de.txt (was ist dort schon definiert?)
4. /www/webui/js/lang/de/translate.lang.stringtable.js (was ist dort schon definiert?)
5. /www/webui/js/lang/en/translate.lang.stringtable.js (was ist dort schon definiert?)
Da 2.-5. von der Firmwareversion und anderen installierten Addons abhängen, macht eine Vorwärtsstrategie mehr Sinn:
Alle neuen Einträge für Datenpunkte in 2. - 5. bekommen einen Addon- und Devicespezifischen Prefix, z.B. die Devicemodelnummer, 0xF603, um sie eineindeutig zu machen. Kanalnamen in rftypes XML sind gerätespezifisch zu definieren und damit eindeutig.
Die Devicemodelnummer ist ja schon in rfTypes XML definiert.
Spricht da was dagegen?
Wie ist das für
Ich werde mich zuerst mal auf Datenpunkte fokussieren. Danach sehen wir weiter, was geht ..
1. rftypes XML (als Quelle)
2. webui.js (was ist dort schon definiert?)
3. /www/config/stringtable_de.txt (was ist dort schon definiert?)
4. /www/webui/js/lang/de/translate.lang.stringtable.js (was ist dort schon definiert?)
5. /www/webui/js/lang/en/translate.lang.stringtable.js (was ist dort schon definiert?)
Da 2.-5. von der Firmwareversion und anderen installierten Addons abhängen, macht eine Vorwärtsstrategie mehr Sinn:
Alle neuen Einträge für Datenpunkte in 2. - 5. bekommen einen Addon- und Devicespezifischen Prefix, z.B. die Devicemodelnummer, 0xF603, um sie eineindeutig zu machen. Kanalnamen in rftypes XML sind gerätespezifisch zu definieren und damit eindeutig.
Die Devicemodelnummer ist ja schon in rfTypes XML definiert.
Spricht da was dagegen?
Wie ist das für
Geht da auch so ein Prefix-Ansatz?Ganz wichtig ist die elvST-Sektion noch in der /www/webui/webui.js.
Das sind die Übersetzungen für Geräteeinstellungen (Parameter) und Status und Bedienung (Values).
Ich werde mich zuerst mal auf Datenpunkte fokussieren. Danach sehen wir weiter, was geht ..
Grüße
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Addon Generierung automatisieren
Du meinst, es ist ein "entweder oder"?
Bislang hatte ich sowohl die direkt am device haengenden Config-Parameter als auch die am Kanal haengenden Config-Parameter und die Datenpunkte allesamt sowohl in die elvST-Sektion der webui.js als auch die stringtable_de.txt eingefuegt.
Viele Gruesse,
Stephan
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: Addon Generierung automatisieren
Technisch nicht, halte ich aber für unnötigen Ballast, wenn man das generell für alle Parameter macht.
elvST ist vom Inhalt her identisch mit der stringtable_de
Warum das Zeug doppelt gepflegt wird, kann ich mir auch nicht ganz erklären.
Die JS Methoden wie z.B. st_getValue gibt es in der webui.js und in der /www/config/st_values[.cgi/.js]
Welcher Teil der WebUI nun was genau nutzt... keine Ahnung.
Es gibt noch die ReGaHss Methode webKeyFromStringTable, die auf die stringtable_de.txt zugreift.
- FUEL4EP
- Beiträge: 586
- Registriert: 01.11.2017, 17:26
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 76 Mal
- Danksagung erhalten: 78 Mal
- Kontaktdaten:
Re: Addon Generierung automatisieren
Danke.
Grundsätzlich steht ja die ganze Hierarchie schon in den rftypes XML.
Wäre es möglich, in die rfTypes XML für jeden Knoten zwei weitere Attribute für die Übersetzungen ins Deutsche und Englische einzufügen, also genau an der Quelle, siehe
https://wiki.selfhtml.org/wiki/XML/Regeln/Baumstruktur
Geht das? Oder stolpert der eine oder andere Parser dann über die neuen Attributeinträge?
Beispiel:
wird zu
Das hätte den Charme, dass alles in einem XML festgelegt wird. Wenn keine Übersetzung gewünscht wird, entweder „“ eingeben oder das Attribut entfernen.
Dann wäre die Erzeugung der Insert oder Patch Skripte wieder ziemlich geradlinig.
Grundsätzlich steht ja die ganze Hierarchie schon in den rftypes XML.
Wäre es möglich, in die rfTypes XML für jeden Knoten zwei weitere Attribute für die Übersetzungen ins Deutsche und Englische einzufügen, also genau an der Quelle, siehe
https://wiki.selfhtml.org/wiki/XML/Regeln/Baumstruktur
Geht das? Oder stolpert der eine oder andere Parser dann über die neuen Attributeinträge?
Beispiel:
Code: Alles auswählen
<parameter id="MY_HUMIDITY" operations="read,event">
Code: Alles auswählen
<parameter id="MY_HUMIDITY" trans_de=„Luftfeuchte“ trans_en=„humidity“ operations="read,event">
Dann wäre die Erzeugung der Insert oder Patch Skripte wieder ziemlich geradlinig.
Grüße
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: Addon Generierung automatisieren
Nein.
Der RFD, der diese XML verarbeitet, ist closed source.
Und der verarbeitet nur das, was er kennt.
Du kommst an deine selbst ausgedachten "trans_de" von der WebUI aus nicht ran.
Und ob dem RFD das gefällt, dass da nun Dinge stehen, die er nicht kennt, weiß ich nicht.
Ob das irgendwelche Seiteneffekte hat... keine Ahnung.
Ich würde es nicht machen.
Ich weiß, du bist grad voll eingefahren auf deinen XML-Automaten.
Aber ich hab das Gefühl, dass damit eine größere Baustelle entsteht bzw. mehr Fehlerquellen, als eine Hand voll Addon-Skripte händisch zu verwalten.
So ein Automat ist vielleicht brauchbar, wenn man auf einen Schlag 20 neue Installationsskripte erstellen möchte.
Die Skripte deiner bestehenden Geräte sind ja fertig.
Und irgendwann kommt mal wieder eins dazu... das ist eins. Dann musst du halt 1x wieder ein neues Skript erstellen.
Vielleicht sollten wir mal ein MS Teams Brainstormin-Meeting machen.
Auch als Ersatz zu den zur Zeit nicht möglichen Usertreffen.
@HMSteve: Ich halte auch ein Steak in die Cam