Erste Erfahrung mit HSL 2.0-Framework

[Lucien]

Das ist ja nett! Vielen Dank.

[NilsS]

# -*- coding: iso-8859-1 -*-
LOGIKCATEGORY="#lucien\hsb"
LOGIKNAME="reg_wohnen"
LOGIKID="10310"
LOGIKVERSION="2.0b"
LOGIKCOMPILEMODE=1
LOGIKDEBUG=1
LOGIKDESCRIPTION="""
Raumregelung (Betriebsmodus und Präsenzobjekt) bei Scharf, Urlaub, Tag und Nacht sowie Zeit, Präsenz
"""

#5000|"Text"|Remanent(1/0)|Anz.Eingänge|.n.|Anzahl Ausgänge|.n.|.n.
#5001|Anzahl Eingänge|Ausgänge|Offset|Speicher|Berechnung bei Start
#5002|Index Eingang|Default Wert|0=numerisch 1=alphanummerisch
#5003|Speicher|Initwert|Remanent
#5004|ausgang|Initwert|runden binär (0/1)|typ (1-send/2-sbc)|0=numerisch 1=alphanummerisch
#5012|abbruch bei bed. (0/1)|bedingung|formel|zeit|pin-ausgang|pin-offset|pin-speicher|pin-neg.ausgang

5000|"@LOGIKCATEGORY@\\@LOGIKNAME@"|0|7|"Nacht"|"Urlaub"|"Scharf"|"Pr_Zeit"|"Pr_Bew"|"HVAC_Tag"|"HVAC_Nacht"|2|"Betr_Modus"|"Prsenz"|"@LOGIKID@ - V@LOGIKVERSION@"

5001|7|2|0|0|1

5002|1|0|0 # Nacht
5002|2|0|0 # Urlaub
5002|3|0|0 # Scharf
5002|4|0|0 # Präsenz gemäß Zeit
5002|5|0|0 # Präsenz gemäß Bewegungsmelder
5002|6|2|0 # HVAC Code Tag
5002|7|3|0 # HVAC Code Nacht

5004|1|0|0|2|0 # Betriebsmodus
5004|2|0|0|2|0 # Präsenz für Heizung

## nur beim ersten Mal initialisieren
5012|0|"EI and not hasattr(pItem.LogikItem,'SHARED_REG_WOHNEN')"|"@BYTECODE@"|""|0|0|0|0
@BYTECODESTART@
## Name bisschen angepasst
class C10310_regwohnen(object):
    def __init__(self,pItem):
        ## reicht ... rest brauchen wir nicht und dann bauen wir es auch nicht ein
        pItem.LogikItem.SHARED_REG_WOHNEN = self  

    def check(self,EN,AN):
        ## ist automatisch wahr ... brauchst du nicht mit True vergleichen
        if EN[1] or EN[2]: # Nacht oder Urlaub
            AN[1]=EN[7]
            AN[2]=0
        elif not EN[1] and not EN[3]: # weder Nacht noch Scharf
            AN[1]=EN[6]
            AN[2]=(ein[4] or ein[5]) # Präsenz gemäß Zeit oder Präsenzmelder
        else:
            AN[1]=EN[6]
            AN[2]=0
  
C10310_regwohnen(pItem)
@BYTECODEEND@

## reicht einmal und dann direkt auf AN schreiben, hier muss dann Ausgang auf 0 sonst würde es wieder überschrieben
5012|0|""|"pItem.LogikItem.SHARED_REG_WOHNEN.check(EN,AN)"|""|0|0|0|0

[Lucien]

Danke. Werde über das Eine oder Andere noch ein wenig grübeln müssen ... Schönen Abend.

[NilsS]

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.

[Lucien]

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.

[Lucien]

super! Danke.

[NilsS]

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.

[Lucien]

Ich meine natürlich nur die Bedingung ...

[Lucien]

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?

[Lucien]

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

[NilsS]

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

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

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

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)

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

[Lucien]

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.

[Lucien]

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.

[Lucien]

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.

[NilsS]

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