Spaß mit structs

[thesing]

Hallo allerseits,

ich habe heute auf 1.6 geupdated und gleich das neue struct-Feature ausprobiert. Rekusion ging zwar nicht, ließ sich allerdings leicht nachrüsten: https://github.com/smarthomeNG/smarthome/issues/318

In Verbindung mit meinem knx_ets-Plugin (https://knx-user-forum.de/forum/supp...-konfigurieren)
schrumpfen die yaml-Dateien für die Items stark zusammen:

%YAML 1.1
---
Erdgeschoss:
    name: Erdgeschoss
    sv_page: seperator

    Wohnzimmer:
        name: Wohnzimmer
        sv_img: scene_livingroom.svg

        Hue:

            Bridge:
                struct: HueBridge

            Hue2:
                name: Hue2
                struct: HueLamp
                hue_lamp_id: 2

            Hue3:
                name: Hue3
                struct: HueLamp
                hue_lamp_id: 3

        struct: RoomRtrLue
        
    Windfang:
        name: Windfang
        struct: RoomLaRtr
        sv_img: fts_door_open.svg

    Flur:
        name: Flur
        struct: RoomLaRtr
        sv_img: scene_stairs.svg
        
    Kueche:
        name: Küche
        struct: RoomLaRtrAbl
        sv_img: scene_dinner.svg
        
    Bad:
        name: WC
        struct: RoomLaRtrAbl
        sv_img: scene_toilet.svg
        
    Schlafzimmer:
        Hue:
            Hue1:
                name: Hue1
                struct: HueLamp
                hue_lamp_id: 1
    
        struct: RoomLaRtrLue
        name: Schlafzimmer
        sv_img: scene_sleeping.svg
Dachgeschoss:
    Flur:
        name: Flur
        struct: RoomLaRtr
        sv_img: scene_stairs.svg

    Kind1:
        name: Kind1 Zimmer
        struct: RoomLaRtrLue
       sv_img: scene_childs_room.svg

    Arbeit:
        name: Arbeitszimmer
        struct: RoomLaRtrLue
        sv_img: scene_office.svg
        
    Bad:
        name: Bad
        struct: RoomLaRtrAbl
        sv_img: scene_toilet.svg
    
    Kind2:
        name: Kind2 Zimmer
        struct: RoomLaRtrLue
        sv_img: scene_baby.svg

Ich hab mal mein stuct.yaml mit rangehängt.
Jetzt muss ich nur noch ein bisschen mit der Reihenfolge spielen, damit die einzelnen Blöcke in der Smartvisu immer in der "richtigen" Reihenfolge stehen. Aber sonst bin ich zufrieden.

Das nur als Anregung. Vielen Dank an alle am Release beteiligten Leute!

VG
Thomas

[bmx]

Ich finde das prima, das Ihr solche Dinge mit einbringt. Bitte behaltet bei Erweiterungen jedoch stets im Hintergrund, das so etwas nachher auch mit einem Item Editor funktionieren sollte, weil nicht jeder sein SHNG nur über yaml konfigurieren möchte. Zielrichtung sollte sein, das es sowohl möglich sein sollte nur mit yaml Dateien zu arbeiten, als auch nur über einen Editor.
Da Msinn sich da schon ganz viele Gedanken zu gemacht hat geht man Gefahr den Weg zum Editor zu verbauen wenn man solche Features zu früh implementiert. Womöglich müssen solche Features irgendwann inkompatibel revisioniert werden und das wäre ärgerlich für alle, die das einsetzen.
Ansonsten freue ich mich, das es immer mehr werden die aktiv an den Plugins und am Core arbeiten.

[mumpf]

Hi,

bei den Structs (und auch bei relativen Pfaden) hat der derzeitige Ansatz IMHO ein großes Problem: Fehlkonfigurationen sieht man erst im Backend. Man schafft somit eine Situation, in der die Hausautomatisierungsengine (also shNG) längere Zeit lahmgelegt wird, weil man sich in den yaml-Files vertan hat. Das Problem hat man natürlich auch ohne structs und relative Pfade, aber diese erhöhen die Komplexität, weil das Problem nicht sofort ersichtlich ist.

Ich verwende schon seit den Zeiten vor shNG (also noch vom originalen sh.py) einen Präprozessor, der relative Pfade und structs realisiert, sprich - der erzeugt die finalen yaml files. Dieser Präprozessor sorgt für Konsistenzchecks und zeigt z.B. auf, wenn ein expandierter relativer Pfad kein Item findet, rekursive eval_trigger hat etc. Man weiß also VOR dem Neustart von shNG, dass man es mit diesen yaml-Files lahmlegen würde.

Natürlich kann ich meinen Präprozessor weiter verwenden, inzwischen bietet dieser aber funktional kaum Vorteile - außer den erwähnten Konsistenzchecks vorab. Ich wollte hier nur Feedback geben, dass ein shNG-Modus, bei dem man eine Art "Prüfen" machen könnte, ohne die laufende Instanz zu gefährden, die Downtime stark reduzieren würde. Ich kann aus Erfahrung sagen, dass der Fall, dass meine Logikengine wegen im weitesten Sinne syntaktischen Fehlern "down" ist, quasi nicht mehr vorkommt. Wenn, dann kämpfe ich nur mit logischen Fehlern, und die lassen sich nicht durch Prüfungen verhindern...

Sollte nur eine Anregung sein, die an sich tollen Konzepte nicht erst zur Lauf- bzw. Startup-Zeit zu prüfen.

Gruß, Waldemar

[Msinn]

Hi Waldemar,

Ich wollte hier nur Feedback geben, dass ein shNG-Modus, bei dem man eine Art "Prüfen" machen könnte, ohne die laufende Instanz zu gefährden, die Downtime stark reduzieren würde.

Die Idee finde ich gut und nehme das mal in's Backlog auf.

thesing Dein Ansatz (bei Laden der Items die Referenzen aufzulösen) ist die schnell zu implementierende Variante, die aber bei Mehrfachverwendung von geschachtelten Structs diese bei jeder Verwendung wieder zusammen bauen muss und damit die Ladezeit von shNG erhöht. Der Weg an den ich dachte, ist die Referenzen nach dem Laden der structs (und vor dem Laden der Items) aufzulösen und damit bei jeder Verwendung in den Items Ladezeit zu sparen.

In beiden Fällen müsste auch noch eine Prüfung hinzukommen, die feststellt ob es Zirkelbezüge gibt, weil dann shNG nie starten würde, sondern die structs ineinander geschachtelt würden bis der Speicher alle ist.

[henfri]

Hallo,

wenn ich es richtig verstehe, ist der Kniff dabei, dass du Struct und dein KNX-Plugin kombinierst.
Denn die 'Schwäche' der Structs ist ja sonst, dass man nicht soooo viel spart, da man ja doch an jedes Item noch einmal 'ran muss, um die GAs zu definieren.
Das machst du aber über das KNX-Plugin.

Gefällt mir! Ich scheue nur die Umstellung.

Gruß,
Hendrik

[mumpf]

Denn die 'Schwäche' der Structs ist ja sonst, dass man nicht soooo viel spart, da man ja doch an jedes Item noch einmal 'ran muss, um die GAs zu definieren.

Upps, dann hab ich die Structs doch missverstanden. Vorschlag für die Zukunft: Relative GA, genau so wie relative Item-Pfade. Beim Struct-Aufruf gibt man so was wie "12/3/10" mit, im Struct sind die GA definiert mit "+0/+1/+5" und das Ergebnis ist "12/4/15". Das spart dann immens...

Gruß, Waldemar

[thesing]

Msinn Bei meinem aktuellen Setup dauert sind es im Log von "Starting smarthomeNG" zur ersten Logmeldung von Influxdb 8 Sekunden. Dabei ist es egal die Stucts rekursiv aufgelöst werden oder nicht (beide neuen Zeilen auskommentiert). "Gemessen" wurde auf einem Raspberry PI3. Bei EFH-typischen Itembäumen sollte es daher kaum einen Unterschied machen wann man die structs auflöst. Mit den Kreisen hast du natürlich recht. Aber wer sich das so konfiguriert ist selber schuld, und merkt auch schnell das etwas nicht stimmt.

henfri Was ist am Test so schwer? Du musst doch deine Items überhaupt nicht anfassen. Die ganzen GAs können stehen bleiben. Mein Plugin nutzt lediglich das knx_dpt Attribut. Und hast du eh an den relevanten Items. Du kannst also mein Plugin aktivieren, eine knxprod-Datei erzeugen, mit CreateKnxProd signieren und in ETS importieren ohne das sich etwas ändert. Dann kannst du in Ruhe in ETS das smarthomeNG-Geräte konfigurieren. Nun hast du nun in ETS eine maßgeschneiderten Dummy. shNG läuft immer noch über knxd. Erst wenn du du das smarthome-Gerät in ETS programmierst, wird das Plugin wirklich aktiv. Dann solltest du das normale knx-Plugin deaktivieren. Wenn alles funktioniert ist alles schön. Wenn nicht, deaktivierst du das knx_ets-Plugin wieder und aktivierst wieder das knx-Plugin. Das Gerät in ETS kannst du als Dummy behalten. Die ganzen GAs würde ich erst entfernen wenn du eine Weile kein Probleme mit dem knx_ets-Plugin hast.

Ich weiß allerdings nicht ob die benötigt Lib aktuell überhaupt kompiliert. Muss ich gleich mal testen. Ich muss mal schauen ob ich damit dann shNG per ETS neustarten kann

[thesing]

mumpf Ich befürchte das wäre nur von Leuten konfigurierbar, die auch programmieren können.

[mumpf]

Hmm, meinst Du? Ich finde, ein relativer Item-Pfad ist viel anspruchsvoller als ein Offset bei einer GA... Aber ich kann ja auch programmieren .

Für mich machen Struct (also wiederverwendbare Item-Teilbäume) ohne GA-Ersetzung kaum Sinn. Dein KNX-Plugin-Ansatz ist auch interessant, aber wenn ich bedenke, wie oft ich zwecks Übersichtlichkeit Teilbäume umhänge, wäre eine externe GA-Vergabe in der ETS (ich habe knapp 5000 Items) doch zu viel manueller Overhead.

Gruß, Waldemar

[thesing]

mumpf Wenn der sich der Pfad von Items ändert, entsehen halt neue Items. Wenn man das nicht möchte, kann man die Pfade der knxprod-xml per Hand anpassen. Wichtig ist ja nur, dass die KO-zu-Item Zuordnung gleich bleibt. Wenn nur neue Items hinzu kommen, kann man für das Gerät in ETS einfach die knxprod aktualisieren und muss auch nur die neuen KOs verknüpfen.

[Onkelandy]

Hier gibt es by the way noch einen Basic blogeintrag https://www.smarthomeng.de/itemvorlagen-nutzen-structs