Addon Generierung automatisieren

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

Moderator: Co-Administratoren

HMSteve
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

Re: Addon Generierung automatisieren

Beitrag von HMSteve » 07.04.2021, 19:45

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

Benutzeravatar
FUEL4EP
Beiträge: 584
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 77 Mal
Kontaktdaten:

Re: Addon Generierung automatisieren

Beitrag von FUEL4EP » 07.04.2021, 20:26

@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:

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
In rfftypes XML steht als Kanadefinition:

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"
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:

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

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

Re: Addon Generierung automatisieren

Beitrag von jp112sdl » 07.04.2021, 20:29

HMSteve hat geschrieben:
07.04.2021, 19:45
Jérôme, kannst Du mich bitte ggf korrigieren, dann kann der Post als kleine Doku auch fuer andere dienen.
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)

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 Generierung automatisieren

Beitrag von jp112sdl » 07.04.2021, 20:32

FUEL4EP hat geschrieben:
07.04.2021, 20:26
hb-uni-sen-lev-us
FUEL4EP hat geschrieben:
07.04.2021, 20:26
Manche Parameter haben ein webuiInsertParam(CAPACITIVE_FILLING_LEVEL_SENSOR|DISTANCE_OFFSET), andere nicht (CAPACITIVE_FILLING_LEVEL_SENSOR|FILLING_LITER). Woran liegt das?
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.

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 Generierung automatisieren

Beitrag von jp112sdl » 07.04.2021, 20:34

FUEL4EP hat geschrieben:
07.04.2021, 20:26
Warum gibt es für HB_GENERIC_VOLT|HB_VOLTAGE keine Übersetzung?
Weil ${stringTableVoltage} schon von eQ-3 mitkommt. Bzw. mitkam. Flog irgendwann raus... hatte ich dann an anderer Stelle wieder eingefügt

VG,
Jérôme ☕️

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

Benutzeravatar
FUEL4EP
Beiträge: 584
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 77 Mal
Kontaktdaten:

Re: Addon Generierung automatisieren

Beitrag von FUEL4EP » 07.04.2021, 21:07

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
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).
Geht da auch so ein Prefix-Ansatz?

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

HMSteve
Beiträge: 537
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 13 Mal
Danksagung erhalten: 95 Mal

Re: Addon Generierung automatisieren

Beitrag von HMSteve » 07.04.2021, 22:04

jp112sdl hat geschrieben:
07.04.2021, 20:29
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)
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

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

Re: Addon Generierung automatisieren

Beitrag von jp112sdl » 07.04.2021, 22:09

FUEL4EP hat geschrieben:
07.04.2021, 21:07
Spricht da was dagegen?
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.

VG,
Jérôme ☕️

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

Benutzeravatar
FUEL4EP
Beiträge: 584
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 77 Mal
Kontaktdaten:

Re: Addon Generierung automatisieren

Beitrag von FUEL4EP » 07.04.2021, 22:34

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:

Code: Alles auswählen

<parameter id="MY_HUMIDITY" operations="read,event">
wird zu

Code: Alles auswählen

<parameter id="MY_HUMIDITY" trans_de=„Luftfeuchte“ trans_en=„humidity“ operations="read,event">
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.
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

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

Re: Addon Generierung automatisieren

Beitrag von jp112sdl » 07.04.2021, 22:38

FUEL4EP hat geschrieben:
07.04.2021, 22:34
Geht das? Oder stolpert der eine oder andere Parser dann über die neuen Attributeinträge?
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 :mrgreen:

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“