Neues Plugin: Logikprozessor.pl

[Bubo]

Hallo zusammen

Ich bin mir am überlegen, ob man das Logikprozessor modul nicht visuell konfigurieren könnte. Dies würde die Verwendung und die Wartung vereinfachen und einem grösseren Benutzerkreis erschliessen. Eventuell könnte man es in den CometVisu Editor integrieren.

Was denkt ihr darüber?

Gruss, Markus

[Fry]

Grundsätzlich eine gute Idee, nur leider fehlen mir (im Gegensatz zum CometVisu-Team) praktisch alle Kenntnisse, um dies umzusetzen: ich habe nahezu Null Ahnung von Javascript, CSS, XML/HTML usw.

VG
Fry

[Bubo]

Die Grundlagen hätte ich und den Rest könnte ich mir aneignen. Ich frage mich nur wie man die ganze Sache am besten anpackt.

Eventuell würde sich auch ein generischer Ansatz lohnen, welcher für alle Plugins eingesetzt werden könnte. Ich habe mir folgendes überlegt:
- Plugin besteht neu aus einem ParameterFile und dem Plugin.
- Im Cometvisu Editor kann man das Plugin auswählen und anschliessend die Parameter/Config ausfüllen. Beim speichern wird ein PropertyFile geschrieben, welches vom Plugin beim starten gelesen wird.

Beim Logikprozessor könnte man im Cometvisu Editor zum Beispiel zuerst eine OutputGA wählen, dann eine Stufe tiefer 1 ... n logische Operatoren und bei jeder logischen Operation könnte man 1 ... n InputGA hinzufügen. Das ganze würde dann in einem File abgespeichert werden, welches beim Start vom Plugin gelesen wird und dementsprechend ausgeführt wird.

Der Vorschlag ist nur ein Brainstorming. Vielleicht hat jemand einen besseren Ansatz.

Gruss, Markus

[Fry]

Zu starr.

Es gibt Logiken ohne "transmit", und es gibt Logiken ohne "receive". Sogar welche ohne "translate".

Am Ende tut es doch am besten ein Editor, meine ich :-)

[Bubo]

Man müsste zuerst natürlich die genauen Eingaberegeln für den Editor aufnehmen.

Wenn ich dich richtig verstanden habe gibt es vier Arten:
- receive -> translate -> transmit
- receive -> translate
- translate -> transmit
- receive -> transmit

Gibt es noch weitere und gibt es eventuell noch Beispiele dazu, damit man sich darunter mehr vorstellen kann? Um ehrlich zu sein habe ich nicht den ganzen Thread gelesen. Der ist unterdessen riesig geworden :-)

Gruss, Markus

[Fry]

Es gibt auch "translate" ohne receive/transmit. Der Aufruf erfolgt dann durch Timer oder "followup", und die Logik erledigt irgendwas außerhalb des KNX-Busses.

Nach aktuellem Stand gibt es neben receive, translate und transmit auch noch:

fetch=>... um KNX-Adressen abzufragen, ohne dass diese die Logik auslösen

trigger=>... um die Logik auszulösen, ohne dass diese Adressen abgefragt werden

timer=>... für regelmäßig zu bestimmten Tagen/Zeiten Logiken auszuführen

followup=>... sowie die followup()-Funktion, um einen einmaligen Timer auf eine Logik einzurichten (Logik wird dann später zum festgelegten Zeitpunkt ausgeführt)

prowl=>... für Prowl-Nachrichten

state=>... für die Einrichtung Logik-lokaler Variablen (werden in %plugin_info abgelegt)

rrd=>... um den auf transmit... gesendeten Wert zusätzlich in ein RRD aufzuzeichnen

delay=>... verzögert das Senden

cool=>... blockiert die Logik nach dem Senden für eine definierte Zeit

eibd_cache=>... für die Handhabung des eibd-Caches

reply_to_read_requests=>... damit die Logik auf Read-Telegramme (an die transmit-GA) antwortet (mit dem letzten berechneten Wert)

recalc_on_request=>... damit die Logik auf Read-Telegramme (an die transmit-GA) ausgeführt wird

transmit_only_on_request=>... damit die Logik den ausgerechneten Wert nur speichert und später auf ein Read-Telegramm hin sendet

transmit_changes_only=>... Senden nur falls berechneter Wert anders als vorher

execute_on_input_changes_only=>... Logik ausführen nur, falls Input anders als vorher

execute_only_if_input_defined=>... Ausführung nur falls ALLE receive- und fetch-Werte verfügbar und definiert sind

transmit_on_startup=>... Ausführung beim Startup des Logikprozessors

debug=> Debugging an/aus

[johnnychicago]

@Markus --

Meiner Meinung nach kannst Du einen von zwei Ansätzen verfolgen. Du darfst nicht vergessen, dass die Logiken im Wesentlichen Perl-Programme sind - auch wenn viele davon kleine Einzeiler sind, die 'einfach nur' einen Vergleich oder eine Verknüpfung herstellen.

Entweder kannst Du hingehen und 3, 4, 15 oder zwölfunddreissig Standardlogiken abbilden: Alle möglichen and/or/not-Verknüpfungen, Umwandeln eines 1-Bit-Wertes in einen 1-Byte-Wert oder dergleichen mehr. Damit erreichst Du eine Funktionalität, die auch klassische Logik-Bausteine im KNX haben, und hast u.U. eine recht unkomplizierte Definition, die auch vom User angepasst werden kann: man braucht keine ETS dazu.

Das hat meiner Meinung nach durchaus einen Wert.

Oder Du musst halt möglichst viele Eigenheiten der Programmiersprache abbilden: Du musst dem User die Möglichkeit geben, innerhalb der Vorgaben des Logikprozessors Parameter zu setzen, Du musst if-then-else Klauseln erlauben, Schleifen, einen möglichst grossen Subset von Perl-Keywords abbilden etc. Dazu musst Du es dem Nutzer dazu verhelfen, dass er seinen Algorithmus grafisch aufbereitet verstehen kann, damit er nachvollzieht, was er da zusammenklickt.

Keine leichte Aufgabe, das.

[StefanW]

Guten Morgen,

Ich bin wirklich froh, mein Heimsystem auf WG-Basis und nicht mit Homeserver aufgebaut zu haben. Macht viel mehr Spaß.

Danke sehr, freut uns natürlich.

Einziger (momentaner) Kritikpunkt: die großen Update-Intervalle der Software. Aber das ändert sich ja bestimmt zum Besseren demnächst :-)

Ich kann sehr gut nachvollziehen, dass man gerne alle paar Monate eine neue / verbesserte Software hätte. Und seit dem letzten Update dauert es schon zu lang, gerade auch um die Verbesserungen der Community einzubauen - das war anders geplant.

Auf der anderen Seite sehe ich aber auch die Kosten solcher Updates und da frage ich mich, wie das auf zig Jahre zu finanzieren sein soll, gerade bei dem äußerst geringen Verkaufspreis des WG und dem geringen Volumen als Nischenlösung - wir sind ja nicht bei den Verkaufszahlen etwa einer Fritzbox. Man muss hier realistisch sein.

Ich gehe davon aus, dass die größeren Updates / Erweiterungen die wir für die weitere Zukunft planen, nur als kostenpflichtiges Update möglich sein werden.

Soll jetzt aber nicht in eine Diskussion hier ausarten bitte, weil das ist FRY's Thread zum Logikprozessor, aber ich wollte den oben geäußerten Wunsch von Mivola auch nicht ohne Antwort lassen.

lg

Stefan

[mivola]

Hallo,

ich hab mal wieder eine Frage zu einer Logik die ich irgendwie nicht gelöst bekomme. Eigentlich etwas ganz einfaches und auch hier im Thread schon besprochen aber ich bekomme es einfach nicht hin.

Ich habe mehrere "virtuelle" GAs, die zu keinem Gerät gehören sondern eher dem Logikprozessor und der (Comet)Visu. D.h. es gibt kein KNX-Gerät welches auf einen Read-Request antworten kann. Schreiben kann nur die Visu auf diese GA. Das Antworten auf Read-Requests soll nun der Logikprozessor übernehmen. Und zwar bestenfalls so, dass nicht erst versucht wird aus dem eibd zu lesen. Dazu wird immer auf diese Art von Konstrukt verwiesen:

memoryRaffstoreEGFahrsperre => { transmit=>'1/1/11', debug=>1 },

Im eib.log sehe ich jede Menge Read- & Response-Telegramme für diese GA. Aber genau das möchte ich ja vermeiden um schneller zu sein. Muss der Logikprozessor den Wert evtl zyklisch auf den Bus schreiben? Oder muss ich irgendwie mit dem eibd_cache hantieren?

Wie habt ihr das gelöst?

Danke
Micha
PS: ich nutze noch den originalen wiregate.pl

[Fry]

Ja, am besten ist es, solche Werte einmal alle 5min auf den Bus zu schreiben.
VG, Fry

[johnnychicago]

shell Befehle

Hallo --

Ich bin ja dabei, einiges von linknx auf den Logikprozessor zu verschieben, einfach weil er für mich einfacher verständlich ist.

Einige meiner Logiken führen Shell-Befehle oder kleine Bash-Scripte aus. Wie mache ich das denn unter dem Logikprozessor am einfachsten?

[Fry]

Mit dem "system"-Kommando von Perl.
Am besten startest du aber Skripte im Hintergrund, damit sie die weitere Ausführung des Wiregate-Daemons nicht blockieren.

Also zB

system "/bin/bash my_script_name_here &";

[johnnychicago]

Hallo --

Ich habe noch ein kleines Verständnisproblem mit dieser Erhaltungslogik:

ga_cont=>{ receive=>'1/2/3', transmit=>'1/2/3', translate=>sub{$input}, delay=>900 },

Ich habe Rolladenaktoren, die ihren Status zwar einmal nach dem Einstellen senden, das aber dann nicht mehr wiederholen. Wenn ich die GA's mit dieser Logik 'frisch' halte, kann ich sie dann auch in anderen Logiken im Logikprozessor nutzen? Oder geht das nicht, weil die ga_cont-Logik nicht gleichzeitig mit meiner anderen Logik laufen kann?

[Fry]

Du kannst die GA beliebig in anderen Logiken nutzen. Keine Einschränkung.
VG, Fry

[dirk13]

Hallo --

Ich habe noch ein kleines Verständnisproblem mit dieser Erhaltungslogik:

ga_cont=>{ receive=>'1/2/3', transmit=>'1/2/3', translate=>sub{$input}, delay=>900 },

Bezüglich der Erhaltungslogiken habe ich auch noch die Frage, wie es sich den bei
a) Reload des Logik-Plugin
b) Reload der Plugin-Config
c) Restart des Wiregate (z.B. Stromausfall)
verhält.

Gerade in der Urlaubszeit möchte ich vermeiden, dass ein kurzer Stromausfall bestimmte Haus-Zustände (wie Urlaubsmodus o.ä.) vergessen macht.