Ankündigung

Einklappen
Keine Ankündigung bisher.

Erste Erfahrung mit HSL 2.0-Framework

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Erste Erfahrung mit HSL 2.0-Framework

    Mein HS 3 war seit geraumer Zeit auf Firmware 4.3. In letzter Zeit hatte ich auch nichts Bemerkenswertes entwickelt. Zufällig sah ich, dass der aktuelle Stand der Firmware bei 4.8 ist. Leider nicht für meine Hardware! Ich habe festgestellt, dass sich beim Homeserver wider mein Erwarten wieder ein bißchen was tut und habe den Upgrade auf 4.5 durchgeführt. Beim Stöbern stellte ich fest, dass es Neues im Bereich der Entwicklung von Logikbausteinen gibt. Ich wollte eh eine kleine Logik bauen und hatte mich bereits wieder über die graphische Logik-Ebene geärgert, war also dabei, mir einen klitzekleinen Baustein zu erstellen. Da dachte ich, ich nutze mal HSL 2.0. Im Forum fand ich überhaupt nichts Brauchbares zu diesem Thema, was natürlich immer an falschen Suchbegriffen liegen kann. Also habe ich mich selbst durchgebissen.

    Bis ich die Idee hinter HSL 2.0 in etwa begriffen hatte und in der Lage war damit umzugehen, habe ich schon ein paar Stunden gebraucht.
    Der sogenannte "Generator" erzeugt einem aus einem XML-Skript indem man u.a. Ein- und Ausgänge des Logik-Bausteins definiert, ein Python-Skript, das wiederum diese Variablen enthält und das man um die eigentliche Logik ergänzen muß. Ich habe den Vorteil, dass ich bereits ein bißchen in Python programmiert habe. Insoweit tue ich mich, immer wieder mit einem Blick in die Python-Dokumentation, weil ich immer nur das lerne, was ich gerade brauche um es dann gleich wieder zu vergessen, nicht zu schwer.

    Ich hatte relativ schnell eine brauchbar erscheinende Logik, baute gemäß Gebrauchsanleitung den entstanden ".hsl" Baustein in den Homeserver, bastelte mir eine Testmöglichkeit im Graphischen Logikeditor und der Visu und - es tat sich nichts! Bisher hatte ich auf der Debugseite immer unter Exceptions geschaut. Da war alles sauber. Dann fiel mir ein, dass HSL 2.0 auch eine Debug-Möglichkeit offeriert. Diese habe ich genutzt und siehe da, es war ein Fehler notiert. Ich hatte eine Variable in Großbuchstaben definiert und in Kleinbuchstaben angesprochen. Das mag Python nicht. Schnell korrigiert, wieder auf den Homeserver geladen und siehe da, es klappt. Was war passiert? HSL 2.0 nutzt nicht oder nicht nur Exceptions, dort hatte ich gesucht, für das Reporting von Fehlern, sondern eine neue Rubrik, HSL 2.0 und das ist auch noch der zweitletzte Eintrag. Ich habe dann noch ein paar Verbesserungen vorgenommen und nach einem weiteren kurzen Test, die neue Funktion scharfgeschaltet.

    Vorläufiges Fazit:

    Bisher hatte ich komplexe Logiken auf drei Ebenen gebaut. Die graphische Ebene muß sein, für einfachste Logiken reicht sie auch aus. Für meine Bedürfnisse bin ich recht oft auf die zweite Ebene, Erstellung eigener Logikbausteine, gegangen, die einem mehr Freiheiten und mehr Einfluß bietet. Wenn es aber komplexer wird, muß man in Python programmieren. Dazu hat mir Nils vor ein paar Jahren (2014) den Baustein "Beta: Logikbaustein 12253_LibLoader" zur Verfügung gestellt, Danke!. Er erlaubt selbst geschriebene Python-Module einzubinden. Das habe ich auch immer wieder genutzt.

    Mit HSL 2.0 fallen jetzt die zweite (Logikbaustein bisheriger Art) und dritte Ebene (Python-Modul) wieder zusammen. Das macht natürlich auch die Skalierung von wenig komplex bis sehr komplex einfacher.

    Mit dem Erstellen von Logiken in Python fällt auch der eine oder andere Komfort weg. Aufgefallen ist es mir bei den Ausgängen. Bisher mußte ich nur eine 1 oder 2 eingeben, um zu entscheiden zwischen Ausgabe bei Berechnung oder bei Änderung. Das muß ich jetzt ausprogrammieren mit "if ... then ... else". Der große Vorteil ist aber vor allem die erhöhte Transparenz und meine (fast) unbegrenzte Einflußmöglichkeit.

    Was mir weniger gefällt, ist die Verteilung des Logikbausteins auf mehrere Dateien, die auch noch zu unterschiedlichen Sprachen, XML und Python, gehören.

    Was mir wiederum sehr gut gefällt, ist die Möglichkeit, Tests außerhalb des Homerservers und das auch noch rekursiv zu fahren. Ich speichere meine Eingabewerte und kann diese nach einer Änderung des Quellcodes einfach wieder abrufen und die Tests erneut durchführen. Das ist schon sehr nett. Man kann auch die Debug-Seite außerhalb des Homeservers abrufen und so z.B. (siehe oben) Syntaxfehler vor der Übertragung auf den Homeserver finden.

    Alles in allem würde ich sagen, ein wesentlicher Schritt vorwärts, jedenfalls für diejenigen, die sich trauen in Python zu programmieren. Möglicherweise gibt es aber noch bessere Lösungen. Eure Erfahrungen würden mich natürlich auch sehr interessieren. Ich hoffe, mein Beitrag war nicht zu lang

    Zuletzt geändert von Lucien; 03.02.2019, 16:23.

    #2
    Hi Lucien,

    sorry wenn ich dich diesbzgl. ein wenig wieder runter holen muss.
    HSL2.0 ist tot

    Vom Prinzip macht(e) das auch nur das was ich schon seit fast 10 Jahren mit den Bytecode-Bausteinen gemacht hab nur in ein "irgendwas" eingepackt.

    Der Generator und auch die "closed" source framework Dateien sind leider in der für den aktuellen HS 4.7+ nicht nutzbar da sie mit Python 2.6 (welches auch für die Erstellung von Bausteinen empfohlen wird) nicht nutzbar da die "neuen" Firmware Versionen auf Python 2.7 basieren. Das ist leider auch nirgends groß vermerkt, außer im ehemaligen Feldtestforum dazu, welches aber inzwischen abgeschaltet ist.

    Wenn du Logikbausteine mit Python-Code erstellen willst würde ich dir das .hsb Format von mir empfehlen, dass der LogikGen.py ( https://knx-user-forum.de/forum/%C3%...r-und-debugger ) zu .hsl machen kann.

    Dort hast du kein "unnützes" Framework, welches nicht vom HS bereitgestellt wird, sondern mit in jeden Logikbaustein integriert wird.
    Nils

    aktuelle Bausteine:
    BusAufsicht - ServiceCheck - Pushover - HS-Insight

    Kommentar


      #3
      Hi Nils, danke für die Aufklärung! Werde mich mit Deinem Generator beschäftigen. Schönen Sonntag noch:

      Kommentar


        #4
        Gerne, kein Thema. Wenn Fragen dazu sind immer raus damit. Mit dem erklären von Funktionen steh ich manchmal ein bisschen auf dem Kriegsfuß aber ich weiß von mehren das sie mit dem .hsb besser klar kommen als mit dem HSL2.0
        Nils

        aktuelle Bausteine:
        BusAufsicht - ServiceCheck - Pushover - HS-Insight

        Kommentar


          #5
          Guten Morgen, zwei Anmerkungen:
          1. Totgesagte leben länger, wie's scheint. Für die Version 2.1 des HSL 2.0-Frameworks, die man hier https://www.gira.de/service/download...d.html?id=3501 herunterladen kann, gilt laut Dokumentation: "Für Experte/FW Version 4.5 wird nur Python Version 2.6.x unterstützt!" und "Für Experte/FW Version ab 4.6 wird nur Python Version 2.7.x unterstützt!".
          2. Das Feldtestforum hatte ich leider nicht mitgekriegt. Es wäre schön, wenn im KNX EIB Forum wenigstens eine Essenz der damaligen Diskussion zu finden wäre. Vielleicht hätte ich mir dann ein bißchen Aufwand gespart.
          Macht aber nichts. Erfahrung sammeln schadet nichts. Jetzt schaue ich mir mal Deine Lösung Nils an. Ich denke, die kleine Logik umzubauen sollte nicht so schwierig sein. Ich melde mich spätestens mit einer Erfolgsmeldung.

          Kommentar


            #6
            Nun, die erste einfache .hsb - Datei mit eingebettetem Python-Code habe ich erstellt, erfolgreich auf den HS gebracht und dort ebenso erfolgreich ausgeführt. Es ist in der Tat so, dass der zu übertragende Logik-Baustein sehr klein baut. Das ist bisher der Hauptvorteil Deiner Lösung, Nils, für mich. Mit den Online-Debugging - Möglichkeiten habe ich mich bisher nicht beschäftigt. Der Punkt Dokumentation geht bisher an Gira / Dacom mit HSL 2.0 . Es ist schon recht aufwendig, sich in Deine Überlegungen und Entscheidungen rein zu denken und die Informationen an den verschiedenen Stellen einzusammeln. Dafür hat man mit Dir zum Glück einen ansprechbaren hilfsbereiten Entwickler! Ich werde noch ein bißchen weiter probieren.

            Kommentar


              #7
              Ich habe jetzt ein wenig besser verstanden wo ich Fehler gemacht habe und warum. Jetzt habe ich mit der einfachen Logik von vielleicht weniger als 20 Python-Lines das erreicht was ich zunächst wollte. Das ist schon sehr schön wie ich da quasi übergangslos an eine 5012er Logikzeile Python-Code anhängen kann. Und natürlich auch, wie ich Ergebnisse und auch Fehler direkt an der Konsole sehen kann. Tolle Arbeit, Nils! Es bleiben aber Fragen über Fragen, vor allem dann wenn ich komplexere Probleme angehe.
              • Soll ich den Python-Code immer in eine Klasse einbinden oder nur in bestimmten, welchen Fällen?
              • pItem scheint wichtig zu sein. Welche Attribute, Funktionen, Methoden hat pItem?
              • In einem Beispiel steht "import pht": Ist das eine Homeserver-spezifische Library?
              • Gibt es für die Logikentwicklung und das Debugging weitere Elemente als das LogikGen.py?
              • ...
              Danke im Voraus für die Antworten.

              Kommentar


                #8
                Zitat von Lucien Beitrag anzeigen
                Soll ich den Python-Code immer in eine Klasse einbinden oder nur in bestimmten, welchen Fällen?
                Da muss ich ein bisschen ausholen.
                Das was du innerhalb des Bytecodes innerhalb einer 5012er Zeile machst ist wenn es nicht in einer Funktion oder Klasse mit Funktion ist nur solange gültig solange die Zeile ausgeführt wird. Das ausführen einer Bytecode Zeile ist natürlich von der Performance her erst einmal schlechter als eine normale Funktion, da sie ja erst Base64-dekodiert, dann compiliert und danach mittels Eval ausgeführt werden muss.
                Ich würde daher immer diesen aufwändigen Schritt möglichst selten ausführen. Das geht in dem ich in dem Bytecode-Block einfach eine Funktion definiere, diese ist dann aber als Variable nur LOKAL innerhalb dieser 5012er Zeile verfügbar. Das ließe sich natürlich mittels global funktions_name lösen. Dabei gibt es jedoch das Problem das global dann auch wirklich global ist, also für alle Logiken und auch alle Homeserver Funktionen. Wenn ich in meinem Bytecode also zum Beispiel die Funktion
                Code:
                global time
                def time(somehting):
                   print something
                schreibe, ist das Pythonmodul time ab dem Moment tot. Der Homeserver wäre in diesem Fall (wenn die Logik beim Start ausgeführt wird) brikked und kann nur über seriell wiederbelebt werden.
                Außerdem weißt du ja nicht welche Funktionsnamen von anderen Logiken verwendet werden. Wenn also du und ein anderer Logikbaustein-Entwickler die Funktion def ausgabe(wert) erstellen, dann würde die letztere die vorherige überschreiben.

                Das trifft natürlich auch für Klassennamen zu. Ich benenne die Klassen daher immer 12345_Logikname_klassenname (12345 ist die LogikID) Dadurch ist die Chance einer Kollision ziemlich gering ;-)

                Da kommen wir auch schon zu Punkt 2
                Zitat von Lucien Beitrag anzeigen
                pItem scheint wichtig zu sein. Welche Attribute, Funktionen, Methoden hat pItem?
                pItem.LogikItem ist die Definition des Logikbausteins und pItem ist die Logik wie sie im GLE verbunden ist, also mit den Ausgängen.
                Ein guter Platzt um wieder zu verwendende Klassen oder Funktionen zu plazieren wäre ein idealer Ort.
                pItem.LogikItem.SHARED_MYFUNKTION kann dann aus ALLEN Logiken dieses Logikbausteins aufgerufen werden und der Bytecode muss nur ein einziges Mal ausgeführt werden.

                Ein dir(pItem) oder dir(pItem.LogikItem) im HS-Insight Baustein wird dir näheres Zeigen

                Zitat von Lucien Beitrag anzeigen
                In einem Beispiel steht "import pht": Ist das eine Homeserver-spezifische Library?
                Ja das ist eine interne HS Funktion um den Zeitdrifft auf dem HS auszugeleichen. (Korrektur auf der Debugseite)

                Zitat von Lucien Beitrag anzeigen
                Gibt es für die Logikentwicklung und das Debugging weitere Elemente als das LogikGen.py?
                Falls du auf den fehlenden import von hslx_decrypt verweißt ... der Godmode ist nur für mich xD


                Nils

                aktuelle Bausteine:
                BusAufsicht - ServiceCheck - Pushover - HS-Insight

                Kommentar


                  #9
                  Herzlichen Dank! Werde mich mit HS-Insight auseinandersetzen ...

                  Kommentar


                    #10
                    Verstehe ich das richtig, dass die Zeile "5012|0|"EI and not hasattr(pItem.LogikItem,'SHARED_OWFS')"|"@BYTECODE @"|""|0|0|0|0"
                    dazu dient, die Bytecodezeilen nur einmal nach dem Hochfahren des Homeservers auszuführen?

                    Kommentar


                      #11
                      Ich meine natürlich nur die Bedingung ...

                      Kommentar


                        #12
                        Ja, also das EI ist ja klar nur beim start. Aber das not hasattr sorgt dafür das dieser Part nur einmalig für egal wie viele Instanzen ausgeführt wird.

                        Nils

                        aktuelle Bausteine:
                        BusAufsicht - ServiceCheck - Pushover - HS-Insight

                        Kommentar


                          #13
                          super! Danke.

                          Kommentar


                            #14
                            Hallo Nils, ich habe jetzt ein kleines reales Beispiel, das auf dem Homeserver erfolgreich läuft. Dabei habe ich versucht nur soviel Code wie nötig und so wenig wie möglich von Deinen Beispielen zu übernehmen. Anwendungshintergrund ist bei Gira Tastsensoren 3 und Präsenzmelder, dass das Wohnzimmer zu sehr auskühlt, wenn wir uns zu lange nicht da aufhalten. Meine Frau friert dann .. Deshalb habe ich jetzt Fixzeiten (UniversalZeitschaltuhr) der Präsenz eingeführt. Für Feedback bin ich Dir dankbar.
                            Angehängte Dateien

                            Kommentar


                              #15
                              Das sieht schon gut aus

                              * die """ die von der Mehrzeiligen Description ist noch über geblieben
                              * die Bennennung von nicht globalem also z.B. Funktionen innerhalb der Klasse ist frei und kann egal wie heißen, dort musst du nicht befürchten das du etwas überschreibst.
                              * wenn du eine Klasse schreibst die du generell für alle Instanzen nutzen willst pItem.LogikItem.SHARED_WHATEVER (auch hier ist der Name egal wenn du ein SHARED_ oder etwas ähnliches eindeutiges davor setzt), dann kannst du nicht self.logik = pItem schreiben (ok kannst du schon) aber dann ist es nur die Logikinstanz des ersten Bausteins. Da du ja aber nicht weißt welcher Logik das im GLE ist, ist es schwer da etwas auf einen Ausgang zu schreiben mittels self.logik (machst du in der Logik ja auch nicht) daher lass es da einfach weg. Du brauchst pItem in deinem Fall nicht.

                              * verwende bei übergebenen Parametern wie EN (übergeben bei dir ein) ruhig auch wieder EN dann ist es einfacher zu lesen. Die Variablen innerhalb der Funktionen sind nur lokal - ist am Anfang etwas verwirrend.
                              Nils

                              aktuelle Bausteine:
                              BusAufsicht - ServiceCheck - Pushover - HS-Insight

                              Kommentar

                              Lädt...
                              X