Addon Generierung automatisieren

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

Moderator: Co-Administratoren

FUEL4EP
Beiträge: 306
Registriert: 01.11.2017, 17:26
Hat sich bedankt: 48 Mal
Danksagung erhalten: 34 Mal

Re: Addon Generierung automatisieren

Beitrag von FUEL4EP » 07.04.2021, 23:06

Hi Jérôme,

Danke.

Du hast ja ganz viele rftypes XML geschnitzt. Wie bist Du da vorgegangen? Hast Du jeweils ein vergleichbares EQ-3 Orginalgerät als Vorlage genommen und dann angepasst?

Oder gibt es doch ein XML Schema (XSD) für die rftypes XML? Sprich eine maschinenlesbare Spezifikation, was erlaubt ist.

Oder gibt es nur Versuch und Irrtum bei neuer Funktionalität?

Sorry für die vielen Fragen. Ich will ja nur verstehen, damit ich es gegebenenfalls automatisieren kann.
Ich weiß, dass Handbetrieb schneller sein kann. Dennoch halte ich es hier gerne mit dem Kant‘schen Imperativ.
Grüße

Ewald

jp112sdl
Beiträge: 8470
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 474 Mal
Danksagung erhalten: 1116 Mal
Kontaktdaten:

Re: Addon Generierung automatisieren

Beitrag von jp112sdl » 08.04.2021, 06:46

FUEL4EP hat geschrieben:
07.04.2021, 23:06
Hast Du jeweils ein vergleichbares EQ-3 Orginalgerät als Vorlage genommen und dann angepasst?
Ja, bei fast 100% der Geräte.

Komplizierter wird es dann noch, wenn du eigene Steuerelemente unter "Geräte und Bedienung" anzeigen willst.
Dann musst du neben dem "bisschen" Geräte-XML und Übersetzungskram noch die Ansicht selbst bauen.
Bildschirmfoto 2021-04-08 um 06.11.45.png
Oder aber auch bei den Geräteeinstellungen, wie hier z.B. noch mit dem Info-Button drin oder der horizontalen Trennlinie:
Bildschirmfoto 2021-04-08 um 06.14.11.png
Horbi hat auch für sein Codeschloss-Projekt eine eigene Config-Seite gebaut:
https://github.com/trilu2000/HB-CDL-6#ccu-integration
und da seitens der XML ein paar eigene Parameter verwendet
https://github.com/trilu2000/HB-CDL-6/b ... #L140-L195

FUEL4EP hat geschrieben:
07.04.2021, 23:06
Oder gibt es doch ein XML Schema (XSD) für die rftypes XML?
Ich kenne mich mit sowas nicht aus. Vielleicht hilft dir das hier weiter:
https://github.com/TomMajor/SmartHome/t ... -error-usw

FUEL4EP hat geschrieben:
07.04.2021, 23:06
Oder gibt es nur Versuch und Irrtum bei neuer Funktionalität?
Ja. Oftmals ziehen Kleinigkeiten eine ganze Menge an Folgeanpassungen nach.

Wichtig ist, viel zu testen.
Nur weil unter Einstellungen->Geräte oder Status und Bedienung alles gut aussieht, ist noch nicht klar, ob die Easymode-Profile für Direktverknüpfungen passen oder wie sich das Gerät in Programmen darstellt (sowohl im WENN als auch im DANN).

Ich starte den RFD nach Anpassungen an den XML Dateien auch immer 1x auf der SSH-Shell manuell mit -l 0, um zu sehen, ob alles passt.
Das ist für mich die sicherste Bank, weil ich dann weiß, dass auch kein Murks drinsteht.

Dein Vorteil ist, dass du bisher nur ausschließlich einfache Sensoren erstellt hast.
Das ist sehr übersichtlich, es werden nur Werte vom Gerät zur CCU gesendet, es gibt keine LINK-Paramsets, keine Aktorkanäle (also wo was an das Gerät gesendet wird), keine speziellen Frames.

Hab grad mal geschaut... ich fasse mittlerweile 20 WebUI Files an, um alle Geräte mit ihren Eigenheiten zu implementieren. :shock:

VG,
Jérôme ☕️

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

PN sind deaktiviert!

FUEL4EP
Beiträge: 306
Registriert: 01.11.2017, 17:26
Hat sich bedankt: 48 Mal
Danksagung erhalten: 34 Mal

Re: Addon Generierung automatisieren

Beitrag von FUEL4EP » 08.04.2021, 08:12

Hi Jérôme,

vielen Dank für Deine ausführlichen Antworten. So langsam wird mir klar, wie groß das Fass ist.

Mein Respekt, wie Du es schaffst im 'Reverse Engineering' bis zu 20 WebUI Files fehlerfrei anzufassen an, um alle Geräte mit ihren Eigenheiten zu implementieren.

Ich werde mich zuerst mal auf den trivialen Fall der Sensoren kaprizieren. Die komplizierten Anpassungen überlasse ich Dir als 'Oberguru' und den anderen 'Gurus' :D

Man kann übrigens als der Menge aller bekannten rftypes XMLs ein Schema (XSD) erzeugen, das man dann zur Prüfung eines neuen rftypes XML heranziehen kann:

https://stackoverflow.com/questions/262 ... -xml-files.

Das erlaubt aber noch keine Rückschlüsse, was der RFD an zusätzlicher Syntax unterstützt. Es hilft aber sicher, 'Vertipper' früh zu finden.

Sobald ich was Brauchbares habe, melde ich mich bei Dir.
Grüße

Ewald

jp112sdl
Beiträge: 8470
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 474 Mal
Danksagung erhalten: 1116 Mal
Kontaktdaten:

Re: Addon Generierung automatisieren

Beitrag von jp112sdl » 08.04.2021, 10:22

Auch ich kratze nur an der Oberfläche, ohne genau zu wissen, warum manches so ist, wie es ist.
Bei der XML z.B. sowas wie >>>auth_violate_policy<<<
Der ist bei "Immer-An-Geräten" get und bei den "Tiefschlafgeräten" reject.
Wofür das jedoch gut ist, welche Methode da wie drauf zugreift oder diesbezüglich verarbeitet, ist mir unklar.

VG,
Jérôme ☕️

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

PN sind deaktiviert!

TomMajor
Beiträge: 1430
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 122 Mal
Danksagung erhalten: 279 Mal
Kontaktdaten:

Re: Addon Generierung automatisieren

Beitrag von TomMajor » 08.04.2021, 12:01

jp112sdl hat geschrieben:
07.04.2021, 22:38

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.
Da hier im thread meine Arbeiten auch ein oder zweimal erwähnt wurden gebe ich auch mal meine 2ct dazu.

ich sehe das ähnlich wie Jerome. Als ich in 2018 mit eigenen Geräten und xml anfing gab es viel Konversation mit ihm und ich bin Jerome sehr dankbar über seine Hilfe damals. Er war praktisch der Einzige mit dem man über HM homebrew Geräte und xml dazu direkt reden konnte, bei all der closed source und fehlender Doku zu dem Thema. :D

Respekt vor deiner Arbeit, Ewald. Wegen der individuellen Eigenheiten der Geräte, die Vielfalt ist bei HM m.E. sehr groß, wirst du das imho nicht perfekt (gültig für alle) hinbekommen und immer wieder Arbeit in den Automaten investieren müssen. Sehe auch die Gefahr viel mehr Zeit in das Projekt zu versenken als wenn man mal ab und zu ein Gerät händisch nachzieht/anpasst.
Das wäre natürlich anders wenn du 20 neue Geräte pro Woche raushaust, dann lohnt sich ein Automat auf lange Sicht. Aber auch dann bleibt das Problem der Perfektion wegen den individuellen Geräte-Eigenheiten..
Viele Grüße,
Tom

HMSteve
Beiträge: 194
Registriert: 20.08.2019, 06:23
Hat sich bedankt: 6 Mal
Danksagung erhalten: 26 Mal

Re: Addon Generierung automatisieren

Beitrag von HMSteve » 08.04.2021, 12:40

jp112sdl hat geschrieben:
07.04.2021, 22:38
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:
Bin dabei. Medium bitte. 500g. Minimum. :lol:

FUEL4EP
Beiträge: 306
Registriert: 01.11.2017, 17:26
Hat sich bedankt: 48 Mal
Danksagung erhalten: 34 Mal

Re: Addon Generierung automatisieren

Beitrag von FUEL4EP » 08.04.2021, 13:53

Hi Jérôme,

vielen dank nochmals für Deine Unterstützung und Korrektur meines gestrigen Lapsus.

Ich glaube, ich hab es jetzt verstanden wie es für meine einfachen Sensoren geht :D
Der Script AsksinPP_addon_generator.groovy ist korrigiert und ein neues Addon wurde erzeugt. Und siehe da: Alle Übersetzungen im WebUI sind nun richtig:
WebUI.png
Das neu erzeugte Addon hb-ep-devices-addon.tgz.txt ist beigefügt. Bitte schau mal drüber, ob das nun korrekt ist. Im Voraus herzlichen Dank!

Alle Install- und Uninstall-Skripte wurden wieder automatisch erzeugt. Das dauert jetzt nur noch wenige Sekunden.

Details sind hier zu finden. Das Addon ist noch nicht freigegeben.

Zur Zeit werden die XML Konfigurationsdateien für den Generator noch händisch erzeugt: Beispiel: HB-UNI-SENSOR-THPD-BME280_addon_control.xml. Als nächsten Schritt werde ich das Rohgerüst dieser Konfigurationsdateien aus den entsprechenden rftypes XML ableiten. Das ist mit groovy eine relativ einfache Übung :D
Zunächst werde ich die Konfigurationsdateien meiner anderen Sensoren nachziehen, so dass dort die Übersetzungen auch überall stimmen.Schon gemacht :D Die Automatisierung trägt schon erste Früchte :D :D Das geht jetzt wie das 'Mäusemelken' :D :D :D

Update 13. April 2021: Es gibt nun eine frühe Version eines groovy-Skripts zur Extraktion der zu übersetzenden Strings aus einer rftypes XML: extract_rftypes_XML.groovy. Euer Feedback ist willkommen.
Aufruf (groovy muss auf Eurem Rechner installiert sein):

Code: Alles auswählen

groovy extract_rftypes_XML.groovy [<rftypes XML file>]
Ein Beispiel der Ausgabe für die rftpes XML 'hb-rc-12-ep-c.xml' ist angehängt.
Noch zu tun ist:

- Scanne 'webui.js', 'stringtable_de.txt' und translate.lang.stringtable.js' on EQ-3's 'occu' und prüfe auf bereits existierende Einträge.
- Erzeuge die Steuerdatei für die Erzeugung der install und uninstall Skripte.
Dateianhänge
extract_rftypes_XML.log
(3.43 KiB) 1-mal heruntergeladen
hb-ep-devices-addon.tgz.txt
(156.7 KiB) 4-mal heruntergeladen
Grüße

Ewald

Antworten

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