ByteCode Logikbaustein (opt. Lizenzprüfung)

[NilsS]

Benchmarks

So ich hab mal ein paar Benchmarkbausteine erstellt.

Simple raufzählen bis 110 aber nur akzeptieren bis 100

Original Logik: 0.52 - 1.2 ms
Base64Code Logik: 0.55 - 2.1 ms
Base64Code Logik cached: 0.26 - 0.32 ms
ByteCode 0.18 -0.20 (erste aufruf 0.52) ms

Bei der Base64 Variante geht bei der ungecachten Version dir meiste Zeit beim decode und compile drauf, das ist deutlich bei der gecachten Variante zu sehen.

Wer langeweile hat kann das ja gerne noch erweitern

Die angehängten Logikbausteine befinden sich im PRIVATE Nummernbereich, ich wollte keine Nummern verschwenden mit Dingen die sowieso keiner auf nem Produktivsystem einsetzt.
E1: Ist der Trigger zum Starten
A1: Ist die Zeit in MS die die Logik benötigt
A2: Der Wert von SN[2] muss 100 sein.

[NilsS]

LogicGenerator mit Live-Extension

So ich hau das mal raus obwohl da sicher noch mehr kommt, hab da die ganze Zeit an so nem sau blöden Fehler rumgedockert und den ganzen Tag verschwendet.

also:

python.exe LogikGeneratorTemplate.py --live=192.168.178.11:9011
erstellt automatisch einen Debugbaustein von der gewünschten Logik (der enthällt keine echte Logik aus dem Script sondern nur einen Loader)
den in den Experten-Logikordner rein, im Experten so verbinden wie er sein soll + Den automatisch erstellten Debugeingang mit einem Event-Empfang (UDP) verbinden (gesamten Empfangen auf ein iKO und an den Debugeingang--- dieser DEBUGPPORT kann für alle Logiken verwendet werden da der DEBUGbaustein die LOGIKID im XML erwartet--- ist also kein Problem mehrere Bausteine gleichzeitig zu testen)

Wenn der Debuggerbaustein installiert ist kann mit dem gleichen Befehl
python.exe LogikGeneratorTemplate.py --live=192.168.178.11:9011
der aktuelle Codeblock übertragen werden.

wenn der Baustein geht einfach ohne --live= ausführen und der "echte" Baustein wird erstellt.



:::coming soon:::
Live Variablen ändern
konventionelle Logiken --- Live testen und umwandeln

[Andreas]

So ich hau das mal raus obwohl da sicher noch mehr kommt, hab da die ganze Zeit an so nem sau blöden Fehler rumgedockert und den ganzen Tag verschwendet.

An dieser Stelle, einfach nur mal Danke für Dein Engagement.
Hab zwar noch keinen HS, kommt aber bald. Auch durch Deine Features wird der HS umso interessanter.

Andy

[ChristianB]

Hi Nils,

...........man soll ja immer alles schön machen, aber Du hast ja sogar an die i-Tüpfelchen gedacht
- als ich eben gesehen habe, dass der Generator soger automatisch den GLE-Hilfetext mit auswirft bin ich fast auf den Rücken gefallen!

RESPEKT!

[NilsS]

- als ich eben gesehen habe, dass der Generator soger automatisch den GLE-Hilfetext mit auswirft bin ich fast auf den Rücken gefallen!

Das kann man aber zur NOT abschalten, damit du nicht auf dem Rücken liegend arbeiten must.
standardmäßig ist doDoku=True und doCache=True
doByteCode=False

[Gaston]

Hi,

Nachdems ich mich vom Schock erholt habe dass ich nicht selbst drauf gekommen bin nachdem ich schon mit lambda funktionen expirimentiert hatte, habe ich nun etwas mit dem Template rumgespielt: Tolles Teil

Zwei ErweiterungsVorschläge haben Sich während meines rumgespiels (soweit hab ich das Resultat noch nicht getestet) ergeben:

1) POSTLOGIK

Sprich, zusätzlich zur LOGIK noch eione POSTLOGIK variable die 5012er Logikzeilen enthält die nach dem aufruf des Pythoncodes ausgeführt werden sollen. Z.B. zum Starten von Timern. Alternativ eine spezielle Zeile in LOGIK die Als Platzhalter für die Pythoncode Zeile dient.

2) Bei eingeschaltetem doCache wird der "Cache" bei der Initialisierung (EI!=0) ausgeführt. Das Template sollte darauf achten dass diese Zeile die erste 5012er Zeile in der HSL Datei ist um zu verhindern dass durch ein Bedingung dies Kompileirung nicht ausgeführt wird.

Da LOGIK eh gesplittet und analisiert wird, ist das kein Problem.

Gruss,
Gaston

[Gaston]

Vorsicht Falle

Ein kleine Warnung für diejenigen die mit diesem Template rumexpirimentieren:

Es ist zu beachten dass der compilierte code im Kontext der HS Logik läuft und somit auf alle Variablen davon zugriff hat.

Man muss also tunlichst darauf achten dass man nur die erlaubten Variabeln benutzt da es sonst zu unerklärlichen Phänomenen kommen kann.

Braucht man also z.B. eine Temporäre Variable zum Zwischenspeichern eines resultats muss man dafür wie gewohnt eine Speichervariable SN[x] anlegen, und nicht soetwas schreiben wie "TEMP=EN[2]*4", denn auch der HS könnte TEMP benuztzen.

Die Probleme die hierdurch enstehen können, wären nicht unbedingt auf den Baustein der mit dem Template erstellt wurde begrenzt sondern könnte sich in einem ganz anderen Baustein (oder zufällig in Mehreren) bemerkbar machen.

Eine Andere möglichkeit wäre die Verwendung von Funktionen mit lokalen Variabeln. Hierfür müssen sich ungeübte Phytonentwickler allerdings mit der etwas speziellen behandlung von lokalen und globalen Variabeln von Python auseinandersetzen.

Frohes Schaffen,
Gaston

[NilsS]

nope.

keine Sorge da sich das in einer Funktion befindet kann mann "lokale" Variablen ruhig verwenden. Es gibts da auch außnahmen aber .....

...vielleicht später mal mehr

[NilsS]

So nochmal eine neue Version (1.4)

Neuerungen:
Senden von EN,EI,EC... überarbeitet
Livecode erneuert
+ langen Quellcode splitten
+ Fehler abfangen
+ Debug auf die HS Konsole

Kommetar Remover -- Gaston
Logik Stop beim Cachen wenn kein EI bei Live -- Gaston

[NilsS]

nochmal ein kleines addon kommt in die nächste Version,
ist aber ganz praktisch also schonmal vorab

## aktiviere Debug Lines
if debug or livedebug:
    code=re.sub("###DEBUG###","",code)

kurz vor den Komentar Remover.

Dann kann man einfach Debug lines in den Code schreiben.

z.B.
###DEBUG###print "Debug: EN[1] = "+ str(EN[1])

wenn der Baustein mit debug oder livedebug ausgeführt wird werden die Zeilen auf der Konsole ausgegeben. bei der endgültigen Fassung werden sie dann aber vom Komentar Remover entfernt.

[NilsS]

Update Version 1.9

So damit auch andere ein bischen spielen können.

###Changelog###
#############
* kompiliert für 2.2er und 2.3er FW als auch für 2.4er Firmware
* Symbolize ( um den Variablen SN[2]/EN[3]... Namen ala @@Temperatur zu geben)
* base64 oder zlib komprimierter Bytecode zur Formelerstellung
* Quelltext kann direkt mit angehängt werden
* mehrere Codeblöcke mit auch unterschiedlichen kodierungen (base64/bytecode)
* Zipfile support (--zip)
* ausgabe des generierten Codes (--list)
* Debug Komentare die in der entgültigen Version entfernt sind (###DEBUG###print "Debug: EN[1] = "+ str(EN[1]) (nur bei --debug oder --live)



Um jetzt damit einen neuen Baustein zu erstellen
python LogikGeneratorTemplate.py --new=10555:MeinLogikName
damit wird eine Datei mit dem Namen "10555_MeinLogikName.py" erstellt.
Diese enthällt automatisch das Template mit bereits angepasster ID und Namen

dort kann dann der Code im Codebereich erstellt werden.

(HS im Bsp: IP 10.10.10.10 mit Debugport 9011)
Um den Code LIVE zu testen, muss der Baustein dann einmal mit
python 10555_MeinLogikName.py --live=10.10.10.10:9011

dadurch wird eine hsl mit dem Namen 10555_MeinLogiName_V0.1_DEBUG.hsl

Diese hsl wird dann in den Logikordner des Experten kopiert.
Die Logik die dann im GLE zu sehen ist, hat einen Eingang mehr als definiert wurde (DEBUG) dieser wird einfach mit einer "IP/EIB-Telegramm empfangen" verbunden (Empfangen enthällt nur ein WERT-als Klartext 14Byte iKO). Alle weiteren zu testenden Logiken können ebenfalls mit diesem gleichen IP Empfang verbunden werden, da jeder Baustein nur den Code an nimmt, der von seinem Template mit der gleichen LogikID verschickt wird.

Nach dem Upload auf den HS, führt ein weiterer
python 10555_MeinLogikName.py --live=10.10.10.10:9011
dazu, das der im Template angezeigte Code in den HS geladen wird.
(auf der Konsole des HS kann das auch mitverfolgt werden, ebenso wie im Quelltext angegebene "print" Befehle ihre Ausgabe auf den am HS angeschlossenen Monitor ausgeben.

Zum testen, oder zum Auslösen de Bausteins
python 10555_MeinLogikName.py --send=10.10.10.10:9011 --ei=1 --run
führt die Initialisierung des Bausteins durch
python 10555_MeinLogikName.py --send=10.10.10.10:9011 --en1=NeuerWert
setzt Eingang 1 auf den Wert "NeuerWert", es können auch die Werte EA,SN,SA,AA,AN geändert werden ebenso kann das ändern von EC/SC/AC (--ec1=1) dazu genutz werden um Änderungen zu simulieren.

[SebastianFey]

ich habe eben versucht deinen ColorConvert-baustein zu nutzen.
Der Experte sagt aber:

"Die Definition für den Logikbaustein ist fehlerhaft"

muss ich etwas besonderes beachten wenn ich diese bausteine nutzen will?
ist die neueste version des experten.

danke

[NilsS]

ich habe eben versucht deinen ColorConvert-baustein zu nutzen.

welchen ? den https://knx-user-forum.de/downloads.php?do=file&id=310 ?

oder selber mit dem LGT erstellt.

Der Experte sagt aber:

"Die Definition für den Logikbaustein ist fehlerhaft"

eigentlich nicht \n müssen escaped werden oder der " Block muss mit r" kommentiert werden.

[SebastianFey]

deinen, also nicht selbst erstellt.

irgendeine idee wie ich eine aufschlussreichere fehlermeldung bekomme?
der experte meckert übrigens erst beim hochladen nicht schon beim prüfen.

[NilsS]

Hmmm, das ist der mit dem Header ?

# -*- coding: iso8859-1 -*-
## -----------------------------------------------------
## ColorConvert   ### V0.8
##
## erstellt am: 2010-03-11 22:15
## -----------------------------------------------------
## Copyright © 2010, knx-user-forum e.V, All rights reserved.

Ich hab ihn gerade in Experte 2.32 geladen und auch beim übertragen kein Problem.

Lad doch nochmal die aktuelle Version runter, vielleicht ist beim entpacken was schiefgegangen.