HS Logikmodule von HSL2 zu HSL3 migrieren

[SirTom]

Moin,

kannst du beschreiben, wie du die Bausteine umwandelst? Das wäre top! Das Problem wird ja an mehreren Stellen auf uns zukommen und ich würde das sonst auch gerne versuchen.

VG Thomas

[BadSmiley]

Man gibt Claude das sdk von gira zu lesen und sagt ihm was man gerne möchte. In Idealfall gibt man ihm die Hilfe vom Baustein zu lesen und sagt ihm welche python Version er verwenden darf. Das klappt alles echt erstaunlich gut.

[hypnotoad]

Hier sind erst einmal zwei Beispielprojekte, ein einfaches und ein komplexes:
- https://github.com/hypnotoad/hsl3_pinger
- https://github.com/hypnotoad/hsl3_kodi (mit externen Bibliotheken)

Die Gira-Bibliotheken und die richtige Python-Version wird über Docker bereitgestellt.
Alle Operationen werden über "make" gesteuert, das hier abgelegt ist:
https://github.com/hypnotoad/hsl_tools
Wenn Du Docker/make nicht verwenden möchtest findest Du die entsprechenden Befehle im Makefile und du kannst sie anderweitig ausführen.

Beim Konvertieren war die Reihenfolge eigentlich immer folgendermaßen:

• config.xml nach config.json umwandeln. Ich verwende dazu ein Beispiel-Json aus einem bestehenden Projekt und habe es nicht geschafft, dies zu automatisieren, obwohl es möglich sein sollte (ich denke mal, dass Claude hier keine Hilfe ist, da die Dokumentation nicht präzise formuliert, wie die Struktur sein muss). Dieser Schritt ist aber sowieso gut, um sich nach Jahren mal wieder mit dem Projekt vertraut zu machen.
• python-Datei X.py umbenennen in hsl3_X.py
• oben in der hsl3-Datei eine leere LogicModule-Klasse definieren mit on_init, on_calc und ggf. on_timer. Anschließend alles alte löschen oder verschieben. Claude kann hier sicherlich helfen, ich fand das aber nicht sonderlich zeitaufwändig.
• einen Test schreiben, mit dem die gewünsche Funktion automatisch getested werden kann. Dazu habe ich eine dummy-Hslframework-Klasse geschrieben. Es gibt inzwischen noch eine andere Klasse auf github.

Durch das testen ohne Homeserver konnte ich mindestens 95% der Fehler vor der Erstellung eines Moduls finden (in den anderen 5% habe ich die Dummy-Klasse verbessert, so dass rückblickend 100% gefunden worden wären). Ich kann dies wirklich jedem empfehlen.

Anschließend ein Modul erstellen, mit Vorher/Nachher-Screenshot nochmal sicherstellen, dass alle Inputs und Outputs gleich geblieben sind und dann in der Praxis nutzen!

[concept]

hypnotoad: das mit dem Testen finde ich interessant. Kannst Du uns genaueres dazu erzählen?

[hypnotoad]

Hier wäre so ein Beispiel: https://github.com/hypnotoad/hsl3_mp...master/test.py . Einfach test.py ausführen und es werden verschiedene Inputs an das HSL3-Modul simuliert und die entsprechenden Outputs verifiziert. Z.B. ob sich die Lautstärke im externen Musikserver sich wirklich geändert hat. Das HSL3-Framework und alle HSL3-Slots werden über Mock-Objekte ersetzt, die sich entsprechend der Dokumentation verhalten.

[concept]

Einfach test.py ausführen

Danke Dir!

Und das lässt Du von der KI ausführen oder lokal auf einem (Linux?)-Gerät?

[hypnotoad]

Das läuft auf meinem Linux-Gerät manuell, wäre bei Windows aber ähnlich (da wäre es

python3 test.py

. Wenn man im großen Stil Software entwickelt, dann werden die Tests automatisch von einem CI-System, z.B. Jenkins, ausgeführt.

Anfangs ist es immer Arbeit, das zum Laufen zu bekommen. Wenn es erst einmal läuft, ist es sehr zeitsparend.

In Verbindung mit KI ist interessant, dass man manuell die Tests spezifiziert, und KI muss sie zum laufen bringen.