Logikbaustein 12242_HostCheck (ByteCodeLogic)

[NilsS]

Das läuft natürlich auch mit dem LogikGenerator Template auf nem PC und Python.

[Dundi]

Ohje...da kommen ja ungeahnte Möglichkeiten auf UNS zu.

[MatthiasS]

[WARNUNG]Die Nutzung dieser Möglichkeit kann bei unsachgemäßer Anwendung euren HS/FS komplett lahmlegen!

Ich rate dringend davon ab, das auf produktiven HS/FS einzusetzen und/oder zeitkritische bzw. umfangreiche Aktionen in den Code zu packen!

Die Behandlung dieses Codes weicht vom HS-internen Standard erheblich ab!
[/WARNUNG]

Richtig, ungeahnte Möglichkeiten - aber eben nur fast, denn die Warnung oben ist ernst.

Die Bausteine, die quasi externen Code enthalten, werden vom eigentlichen HS-Prozess natürlich nicht überwacht - der kennt sie gar nicht. D.h., während die normale HS-Logik so getimed ist, dass immer Zeit für andere "nebensächliche" Dinge wie Telegrammversand und Empfang ist, laufen diese Prozesse ungehindert mit Priorität. Während der Abarbeitung ist für den Rest des HS Schicht im Schacht. Muss man beachten, ansonsten gilt natürlich:

Ungeahnte Möglichkeiten

[NilsS]

Wo liegt denn der Unterschied/Vor-/Nachteil von ByteCode gegenüber base64 Codierung?

Der Bytecode ist nicht mit unterschiedlichen Python versionen kompatibel.
Die Betatester haben mitgeteilt das die 2.4er Firmware die Python Version 2.4 gegenüber der bisherigen Version 2.2 hat.
Man kann natürlich auch parallel das Python 2.4 installieren und den Baustein für beide Versionen kompilieren, jedoch macht dieser Mehraufwand wohl nur bei kommerziellen closed-source Bausteinen sinn.

[tbi]

echt Stark !!!!

Nils,

Super !!!

Ich glaube hier hast Du was ganz Tooles gemacht.

Ich habe nämlich das Problem beim ECO-BUS von Buderus eine Serielle Schnittstelle (über Moxa) abfragen zu müssen, die noch einen Handshake drumrum hat (3964R).

Mit IP Telegrammen geht das nicht, selbst mit geschachtelten Abfragen bzw. Senden ist das nur schwer möglich. Zumindest kriegt man einen Knoten im Kopf und es würde nie wieder einer verstehen. Von fehlern und Testbarkeit mal ganz abgesehen.

Mit den Möglichkeiten hier bin ich aber sicher, werde ich da nun eine gute und auch saubere Lösung finden.

Wichtig wird aber ein sauberes Austesten sein, etc.

Warscheinlich ist es am besten den Code auf dem PC direkt zu testen und dann erst auf den HS zu portieren?

Nils wie bist Du vorgegangen, welche Test- bzw. Entwicklungsumgebung hast Du dir aufgebaut?

Gruß Tbi

[NilsS]

Hi,
zum Testen kannst du in dem anderen Thread https://knx-user-forum.de/knx-eib-fo...zpruefung.html das Template raus kopieren, ich bin da bereits wieder an einer neuen Version, werd die gegebenenfalls in den DL Bereich wechseln wenn sich das nicht mehr stündlich/täglich ändert

Bei TCP Verbindungen kann aber das Problem was Michel und Matthias erwähnten auftreten, dass ein zu langer Aufenthalt (for/while oder select) die gesamte Logik ausbremsen können.

Gedanklich ist mir da schon einiges mittels eines xml sub-bus durch den Kopf gegangen.
Ich mach mal nen kurzen DUMP
Prozess mit fork eigenständig machen und die Kommunikation mit (Daemon) erfolgt mittels (direkter Steuerung egal welchen Protokolles -- senden) sowie alles was der Daemon empfängt, sendet er er schön in XML verpackt an einen event-empfangen des HS.
Ein Packet dahin könnte z.B. so aussehen

<xml>
<buderus>
<druck>15</druck>
<kesseltemp>77.2</kesseltemp>
</buderus>
</xml>
 
oder auch so
 
<xml>
<mpd>
<bad><title>Was ein tolles Lied</title><status>play</status></bad>
<kueche><title>Was ein tolles Lied</title><status>play</status></kueche>
</mpd>
</xml>
 
.....

alles was dann auf diesem einen Event-Empfagen Port ankommt kann mittels XML2Text Logik in die richtigen Gewerke verteilt werden

[Michel]

Wahrscheinlich ist es am besten den Code auf dem PC direkt zu testen und dann erst auf den HS zu portieren?

So testest du "nur", ob dein Python-Code syntaktisch richtig ist und korrekt arbeitet, wovon ich ausgehe, bevor du den Code in den HS schiebst.

Was du so nicht testen kannst, ist die Auswirkung auf die "Nebentätigkeiten" des HS, wie z.B. dafür zu sorgen, daß das KNX-Prozessabbild "sauber" ist, alle anderen Logiken weiterhin abgearbeitet werden etc.

Gerade Verbindungen in die "Aussenwelt" könnten deinen HS/FS lahmlegen; evtl. auch parallele Aufrufe des Bausteins.

Ich teste gerade auf einem meiner Beta-HS diverse Sachen. Mal sehen, ob daraus eine Art "how-to" / "don´t do" Liste wird.

[WARNUNG]Legt ihr den HS/FS auf diese Weise lahm und laßt die auslösende Logik auch noch beim Start berechnen, kann es dazu kommen, daß ihr nur noch per serieller Schnittstelle an den HS kommt!
[/WARNUNG]
Du solltest also wissen, was du tust!

[NilsS]

Ich bin gerade dabei dem Logik Template eine Art Live-Schnittstelle zu basteln

Das wird dann einen Baustein erstellen der zusätlich zu den definierten noch jeweils einen Eingang und Ausgang hinzufügt.

Diese werden mittels Event-Empfangen/Senden verbunden.

Der Logikbaustein wird nicht die eigentliche Logik enthalten sondern eine ebenfalls codierte Logik die die Logik die über den (Live-Eingang) erhalten wird ausführt.

Bin im Moment noch in der Theorie aber man sollte dann von der Commandozeile das Pythonscript aufrufen können und auch alle Variablen von dort ändern. Ausgeführt wird im HS, und wenns dann wirklich mal den HS schießt, macht nix, da nix remanent im Speicher ist reicht ein Neustart des HS und alles is wieder wech

[tbi]

Hi,

@Michel:

So testest du "nur", ob dein Python-Code syntaktisch richtig ist und korrekt arbeitet, wovon ich ausgehe, bevor du den Code in den HS schiebst.

Ja, aber damit sind die PHP Fehler erstmal schon weg. Ziel Schrittweise testen und inbetrieb nehmen.

Was du so nicht testen kannst, ist die Auswirkung auf die "Nebentätigkeiten" des HS, wie z.B. dafür zu sorgen, daß das KNX-Prozessabbild "sauber" ist, alle anderen Logiken weiterhin abgearbeitet werden etc.

Vollkommen richtig, mein Code hat eh Timer. Er muß eh immer wieder die Kontrolle zurückgeben. Hier muß ich die richtige Granularität dann finden.

Gerade Verbindungen in die "Aussenwelt" könnten deinen HS/FS lahmlegen; evtl. auch parallele Aufrufe des Bausteins.

Ja, deshalb ist es wichtig zu verstehen was blockiert und was nicht. Ggf. helfen Semaphoren, etc.

Du solltest also wissen, was du tust!

Ich weiß es . Oder besser bin mir bewußt und werde mich darauf gut vorbereiten. Also wie geht dann ein Wiederbelebungsversuch eines HS über Seriell?

@Nils:

Gedanklich ist mir da schon einiges mittels eines xml sub-bus durch den Kopf gegangen.
Ich mach mal nen kurzen DUMP
Prozess mit fork eigenständig machen und die Kommunikation mit (Daemon) erfolgt mittels (direkter Steuerung egal welchen Protokolles -- senden) sowie alles was der Daemon empfängt, sendet er er schön in XML verpackt an einen event-empfangen des HS.

Es gibt da dann einen ganzen Sack voll an Datenpunkten, die dann erst ausgewertet werden müssen.

Mit der Lösung, die Du vorschlägst, würde der HS komplett nicht blockiert, so wie ich Dich verstehe ?

Wo würdest Du dann die Events fangen ? Da hast Du das Problem doch dann wieder ?

Gruß Tbi

[NilsS]

Wo würdest Du dann die Events fangen ? Da hast Du das Problem doch dann wieder ?

nope ich verwende dann zum Empfang ja den "offiziellen" Weg über einen Kommunikation -> Event-Empfang(IP/EIB-Telegramme (Empfang)
Das nutz ich jetzt auch schon um das besagte mit dem MPD zu machen, allerdings sende ich das von einem anderen Rechner auf dem auch die MPD's (MusicPlayerDaemon) laufen und hab da einfach nur einen loop der alle statis sammelt und dann komplet per netcat an den HS schickt.

[tbi]

das Konzept

Hallo Nils,

ich fassen nochmal zusammen, wie ich Dein Konzept verstehe:

1. Über eine Logik wird ein PHP Prozess hochgezogen und abgetrennt, der dann die Schnittstellen Logik im Bauch hat. Der läuft dann selbstständig und blockiert den HS nicht mehr. Er wird vom Kernel so mit CPU Zeit versorgt, wie es eben geht.
2. Seine Ergebnisse verschickt er über IP-Telegramme und werden von HS wie gewohnt verarbeitet.
3. Befehle empfängt er über IP-Telegramme, verarbeitet die und schickt sie dann an die externe (bei mir die spez. Serielle) Schnittstelle weiter.
4. Remanente Daten sind nicht notwendig, das wäre ok. Der Prozess würde nach einem Neustart erst wieder durch eine Logik gestartet. Die sollte dann nicht an "System start" gebunden sein . Zumindest nicht am Anfang.

Nils, ich glaube Du bis genial . So könnte das gehen. Da gäbe es eine Menge Schnittstellen, die man so kapseln und auf dem HS anbieten könnte.

Tbi

[NilsS]

Über eine Logik wird ein PHP Prozess hochgezogen und abgetrennt, der dann die Schnittstellen Logik im Bauch hat. Der läuft dann selbstständig und blockiert den HS nicht mehr. Er wird vom Kernel so mit CPU Zeit versorgt, wie es eben geht.

Eigentlich alles OK nur ..... Es ist Python und kein PHP

[tbi]

Naja, ich habe so viele Programmiersprachen schon gesehen, da nehme ich das nicht mehr so genau. Ja, das ist dann wieder eine neue die dazu kommt.

Wichtig ist, dass ich dann das richtige installiere .

Gruß Tbi

[Michel]

Aber schön darauf achten, daß du die richtige Python Version verwendest:

Benötigt wird, um den ByteCode zu erstellen, ein Python gleicher Version wie der HS, also Python 2.2.3

[NilsS]

Es muss ja kein Bytecode sein, der code kann ja auch base64codiert sein und auf dem HS compiliert werden.

 
compile(__import__('base64').decodestring('xxx34sda.....'),"/tmp/mydaemon.pyc","exec")