Welche Logikengine (Software)

[mumpf]

Waldemar, könntest du die kommentierte linknx.xsd mal veröffentlichen?

Das klingt spannend/nach einer großen Hilfe. Meinst du, du kannst bei deiner nächsten Logik-Session mal einen Screengrabber mitlaufen lassen? Momentan fällt es mir noch schwer, mir das vorzustellen.

Hi,

beides ist jetzt in den https://knx-user-forum.de/knx-eib-fo...beispiele.html drin.

Gruß, Waldemar

[greentux]

Ja, das haben schon andere so gemacht.

[mumpf]

Hi allerseits,

weiß jemand, wie ich ein ca. 2 MB großes Video (mp4) hier im Forum hochlade? Die Endung .mp4 ist nicht supported, .zip erlaubt nur 976 KB...

Die einzige Möglichkeit, die ich sehe: Die Endung auf .pdf zu ändern (da sind 19 MB erlaubt) und dranschreiben, dass man nach dem Download wieder .mp4 draus machen soll. Ist das das "übliche" Vorgehen?

Gruß, Waldemar

[mumpf]

Na, einmal pro sekunde ist doch nicht schlecht... Da fällt mir nix ein, wo's da eng wird?!

Ein Beispiel, dass mir sofort einfällt: Du hast ein Plugin, dass sich auf mehrere Dim-Status-GA registriert, um immer einen Dimwert hinterherzuschicken. Klappt im Allgemeinen ganz gut, weil ja meist nur eine GA triggert. Triggern aber 2 oder 3 GA's (z.B. per PM, weil gleichzeitig von 3 Personen 3 Räume betreten werden) dann wird der 3. frühstens nach 2 Sek. nachgedimmt - bis dahin sind die Lampen aber bei 100% und werden dann wieder dunkler - es "blitzt".

Hört sich konstruiert an - passiert aber öfter, als man denkt War bei mir WAF-relevant. Mit linknx passiert Dir so was nicht, alle actions werden quasi-parallel (threaded) ausgeführt...

Das klingt spannend/nach einer großen Hilfe. Meinst du, du kannst bei deiner nächsten Logik-Session mal einen Screengrabber mitlaufen lassen? Momentan fällt es mir noch schwer, mir das vorzustellen.

Ist ne gute Idee, muss mal einen Screengrabber suchen. Wird aber noch ein bisschen dauern, bin noch immer am Aufräumen im xsd-File. Stell ich dann auch in die Tipps und Tricks zu linknx.

Gruß, Waldemar

[Chris M.]

Ich hab davon gelesen -ich meine auf SF. Da stand auch, dass geplant ist sich mit SH.py&Co abzustimmen/am gleichen Strang zu arbeiten. Ist das noch aktuell?

Am ehesten unter LogicEngine - Open Automation was eher als Vorläufer zu sehen ist.

Eine Absprache gab's unter https://knx-user-forum.de/wiregate-b...rthome-py.html mit dem Fazit nach 85 Posts und einem späteren Live-Meeting zwischen mir und mknx dass es hier aktuell zu wenig Gemeinsamkeiten gibt.

Zum Warten: Akut habe ich nur ganz wenig Logikbedarf. Ich denke, ein gutes halbes Jahr kann ich sehr gut überbrücken. Ist das ein Zeitrahmen, der dir realistisch scheint?

In dem Zeitraum gibt's sicher was, damit man eine Basis für Diskussionen unter Entwicklern hat.
Ob man damit schon produktiv Logiken laufen lassen sollte? Wenn sehr viele Entwickler mitmachen evtl. schon, aber sonst?

Und da [LinKNX Grafischer Editor] in die Entwicklung einzusteigen ist keine Option? (naja, da du jetzt schon was eigenes gestartet hast wohl nicht...)

Den hatte ich mir extra angeschaut, bevor ich mit dem Code angefangen habe. Ich hatte auch erst mal lange nach Lösungen gesucht das beste der Projekte zusammenzubringen, bevor ich mit dem (aktuellen) Code angefangen habe, vgl. oben geposteten Thread (Beta-Freischaltung notwendig).

Mir war wichtig nicht dem Not-invented-here-Syndrom zu verfallen!

Unterm Strich habe ich mich jetzt für ein flexibles aber Performace und Maintenance optimales Backend entschieden auf das der Logik-Teil aufsetzten wird. Und gerade den Logik-Teil habe ich schon seit viel länger im Kopf, da ist die Heim Automatisierung nur ein willkommener Vorwand den endlich umzusetzen... (Die Idee dazu stammt noch aus Zeiten als ich nicht mal wusste, dass ich bauen werde, geschweige KNX verwenden werde...)

Das führt hier und jetzt aber zu weit und wird hoffentlich möglichst bald Thema eines neuen Threads sein.

Bis dahin kann ich jedem nur empfehlen bei dem Bedarf nach Logiken eine der vielen möglichen Lösungen zu nehmen, die es jetzt schon gibt!

Na, einmal pro sekunde ist doch nicht schlecht... Da fällt mir nix ein, wo's da eng wird?!

Wenn spontan auf Events (z.B. Telegramme auf dem Bus) reagiert werden soll. So im Bereich von 10ms.
(Bei GrAF strebe ich 1ms praktisch nutzbare Auflösung auf leichter Hardware wie einem WG an)

[henfri]

Puh, dann will ich mal antworten.

Genau das wird's geben - weil ich's selber will und z.Zt. da dran bin.

Ich hörte davon.

Ob sich Warten lohnt?
Nun, ich bin noch nicht mal so weit, weitere Entwickler dazu einzuladen, da ich erst mal eine Grundstruktur haben möchte, so dass man sich überhaupt sinnvoll austauschen kann. (Vgl. GrAF - Open Automation und natürlich SourceForge.net Repository - [openautomation] Index of /GrAF)

Oh, da gibt's ja schon Code!
Ich hab davon gelesen -ich meine auf SF. Da stand auch, dass geplant ist sich mit SH.py&Co abzustimmen/am gleichen Strang zu arbeiten. Ist das noch aktuell?

Zum Warten: Akut habe ich nur ganz wenig Logikbedarf. Ich denke, ein gutes halbes Jahr kann ich sehr gut überbrücken. Ist das ein Zeitrahmen, der dir realistisch scheint?

Bei dem grafischen Logik-Editor habe ich ziemlich konkrete Ideen bzw. Anforderungen. (Wer's kennt: es geht stark Richtung Simulink)
Mir ist klar, dass linknx hier inzwischen auch aktiv ist, aber das was ich gehen hab ging nicht in die Richtung, die ich mir vorstelle und war auch noch sehr Buggy.

Und da in die Entwicklung einzusteigen ist keine Option? (naja, da du jetzt schon was eigenes gestartet hast wohl nicht...)

Manuel, Screenshots von einem XML-File?
Linknx ist ein Daemon mit linknx.xml als Konfigurationsfile, welcher direkt mit dem eibd kommuniziert.
Linknx kannst du einfach als autonome Logik Engine laufen lassen. Dazu gibt es mit knxweb und knxweb2 noch zwei Visualisierungen, aber die sind nur optional. knxweb2 dient dabei zusätzlich auch als graphischer Editor für linknx.xml.

Ja, den Editor hätte ich gerne mal gesehen.... Die Demo ist aber scheinbar offline.

Ansonsten geben dir folgende Links hoffentlich genügend Inspiration:
Offizielle Doku: SourceForge.net: linknx
Aktuelle Threads hier im Forum:
https://knx-user-forum.de/knx-eib-fo...beispiele.html
https://knx-user-forum.de/knx-eib-fo...beispiele.html

Der Thread ist super. Danke für deine Mühe. Dennoch -und das gilt für linknx wie für sh.py habe ich momentan noch das Gefühl, dass mir der Einstieg nicht leicht fallen wird, da die Doku noch recht übersichtlich ist :-)

ich habe viel mit WG-Plugins rumprobiert, sie sind sehr mächtig und können alles - aber mich hat die Auflösung (max. 1 mal pro Sekunde) gestört und die Tatsache, dass zeitabhängige Sachen immer vom User non-blocking programmiert werden mussten, das wird man vom Plugin-System nicht direkt unterstützt. Da ist die Logikengine von Fry die richtige Wahl - leider gab es die nicht, als ich rumprobiert habe...

Na, einmal pro sekunde ist doch nicht schlecht... Da fällt mir nix ein, wo's da eng wird?!

Es gibt wohl einen Editor mit knxweb2, den hab ich noch nicht ausprobiert. Ich editiere das xml direkt, mit einem Editor mit xsd-Unterstützung. Habe mir einfach die Mühe gemacht, das linknx.xsd-File zu kommentieren, so dass ich jetzt im Editor die entsprechenden tooltips mit den möglichen Befehlen und deren Bedeutung bekomme - dann ist das easy.

Das klingt spannend/nach einer großen Hilfe. Meinst du, du kannst bei deiner nächsten Logik-Session mal einen Screengrabber mitlaufen lassen? Momentan fällt es mir noch schwer, mir das vorzustellen.

linknx ist schon gut und auch der grafische Editor ist super...was fehlt, und darum habe ich es damals mit linknx sein lassen, ist eine vernünftige und verständliche Doku mit dem aktuellen Entwicklungsstand bzw. eine deutschsprachige Community.

Doku: Den Eindruck habe ich auch.
Community: Hier haben sich doch jetzt schon einige zu Wort gemeldet... Vielleicht wäre auch ein eigener Bereich im Forum sinnvoll?

Mittlerweile ist dies[non-blocking] natürlich nicht mehr so das Problem weil man das rechtzeitig erkennt und jetzt auch weiß wie es trotzdem geht.

Das gilt für Dich. Für mich (noch) nicht... Daher ist der Hinweis durchaus wichtig für mich.

Gruß,
Hendrik

[2ndsky]

beim tcp hat es mich begeistert, dass linknx komplett das reconnect-handling übernimmt, wenn mal ein Gerät abgeschaltet oder rebooted wird. Ich brauche somit keine weiteren Hilfsmittel wie socat oder ähnliches. Aber 3 Protokolle sind nicht die Welt, das stimmt.

Macht smarthome.py aber auch für dich. Auch wenn man Erweiterungen entwickelt muss man sich darum nicht kümmern.

P.S.: Ist schon lustig, wie jeder SEINE Logicengine anpreist...

Das liegt wahrscheinlich in der Natur der Sache. Ich war lange auf der Suche nach einer Möglichkeit Logiken auf dem Wiregate möglichst schmerzfrei umzusetzen. Mit smarthome.py von Marcus habe ich diese Möglichkeit gefunden und seither entwickle ich daran mit und implementiere Plugins, die für meine Anwendungsfälle noch fehlen. Das ist mir so lieber als ständig mit socat versuchen zu müssen, meine Anwendungsfälle in ein Wiregate Perl Plugin zu quetschen (wofür die Plugins einfach nicht gemacht wurden).

[mumpf]

Wie es bei linknx aussieht weiß ich nicht, aber wenn der Fokus hier stark auf KNX liegt (so die Aussage weiter oben) könnte ich mir vorstellen, dass auch hier die Integration anderer Protokolle schwierig ist.

Da hab ich auch schon ein bisschen rumgespielt Und Du hast recht, derzeit ist das recht dünn, es gehen nur serial, tcp und udp. Serial und udp brauchte ich (noch) nicht, beim tcp hat es mich begeistert, dass linknx komplett das reconnect-handling übernimmt, wenn mal ein Gerät abgeschaltet oder rebooted wird. Ich brauche somit keine weiteren Hilfsmittel wie socat oder ähnliches. Aber 3 Protokolle sind nicht die Welt, das stimmt.

Natürlich kann man über LUA (integriert) und Aufrufe von Kommandozeilen-Tools auch hier erweitern und noch mehr machen.

Achja - der Fokus auf KNX hat auch Vorteile. Da man ja meistens in der KNX-Welt ist, ist dieser Teil (meiner Meinung nach) recht einfach hinzuschreiben.

Gruß, Waldemar

P.S.: Ist schon lustig, wie jeder SEINE Logicengine anpreist...

[2ndsky]

Bei Wiregate Plugins (oder zumindest beim Logikprozessor von Fry) ist wichtig, das die DPTs in der eibga.conf korrekt angegeben sind. Da die ETS das bei mir irgendwie nicht automatisch gemacht hat habe ich überall DPT1 und müsste somit auch erstmal alle DPTs korrekt pflegen, um z.B. den Logikprozessor nutzen zu können.

Außerdem kann ich mit smarthome.py mehrere unterschiedliche Protokolle verbinden (siehe z.B. Russound Plugin). Bei Perl Plugins muss zwangsläufig alles über einen dritten Kanal laufen (Socket, KNX Bus etc.). Wie es bei linknx aussieht weiß ich nicht, aber wenn der Fokus hier stark auf KNX liegt (so die Aussage weiter oben) könnte ich mir vorstellen, dass auch hier die Integration anderer Protokolle schwierig ist.

[mumpf]

Hi,

mach ich gerne - allerdings muss ich da noch ein bisschen aufräumen... Ich hab es gerade gestern geschafft, mir die aktuelle CVS-Version zu bauen (0.0.1.31) und hab dann natürlich gleich ins XSD die neuen features reingesetzt, ohne mir die 1.30 Version vorher zu sichern.

Außerdem habe ich einige Typen im XSD verändert, damit sie von meinem Editor als dropdown dargestellt werden. Sollte keine Seiteneffekte haben, aber ich kann es nicht garantieren.

Ich stell das morgen in die Tipps und Tricks rein.

Gruß, Waldemar

[greentux]

Waldemar, könntest du die kommentierte linknx.xsd mal veröffentlichen?

Danke und Gruß

[callidomus]

Hi Henrik,

Da nehme ich dich beim Wort:
https://knx-user-forum.de/knx-eib-fo...tml#post265082

Wie in dem anderen Post beschrieben gibt es eine spezielle DPT dafür.
Hier die Logik für die Umschaltung wenn der Schalter nur zwei unterschiedliche Werte schickt.

Erst einmal die KNX Anbindung über den eibd:

# etc/plugins.conf
[knx]
   class_name = KNX
   class_path = plugins.knx
#   host = 127.0.0.1
#   port = 6720

Dann das Item (das mir primär als Zustandsvariable dient):

# items/ofen.conf
[ofen]
    type = num

(man könnte auch noch den Wert cachen und Ihn über die Visu anzeigen/editierbar machen)

Und die Logik:

# etc/logic.conf
[ofen]
    filename = ofen.py
    knx_dpt = 5
    knx_listen = 3/7/6 # Schalter sendet auf dieser GA Werte und triggert die Logik

# logics/ofen.py
if trigger['value'] == 2: # Es wurde eine 2 an die GA 3/7/6 geschickt
   
    # Code einfügen: Ofen auf Automatik
   
    sh.ofen(2) # Item setzen
    sh.knx.groupwrite('3/7/7',1,'1') # (ga, data, dpt) LED1 ein
    sh.knx.groupwrite('3/7/8',0,'1') # LED2 aus
else: # es wurde ein anderer Wert geschickt
    if sh.ofen() == 1: # toggle off

        # Code einfügen: Ofen aus

        sh.ofen(0)
        sh.knx.groupwrite('3/7/7',0,'1')
        sh.knx.groupwrite('3/7/8',0,'1')
    else: # toggle on bzw. default on  wenn auto deaktiviert wurde

        # Code einfügen: Ofen ein

        sh.ofen(1)
        sh.knx.groupwrite('3/7/7',0,'1')
        sh.knx.groupwrite('3/7/8',1,'1')

Man könnte auch natürlich mehr Items verwenden um z.B. die LEDS mit

sh.ofen.led_auto(1)

zu setzen und die GAs in die Items Config zu 'verbannen'.

Ist das nicht übersichtlich?

Bis bald

Marcus

[JuMi2006]

linknx ist schon gut und auch der grafische Editor ist super...was fehlt, und darum habe ich es damals mit linknx sein lassen, ist eine vernünftige und verständliche Doku mit dem aktuellen Entwicklungsstand bzw. eine deutschsprachige Community.

Der größte Schwachpunkt der WireGate Plugins ist tatsächlich der große Aufwand um Sachen non-blocking zu programmieren ... da gingen schonmal Stunden drauf für eigentlich ganz einfache Sachen weil man sich da irgendwelche Krücken zusammenbasteln musste. Mittlerweile ist dies natürlich nicht mehr so das Problem weil man das rechtzeitig erkennt und jetzt auch weiß wie es trotzdem geht.

[mumpf]

Hi Hendrik,

ich habe viel mit WG-Plugins rumprobiert, sie sind sehr mächtig und können alles - aber mich hat die Auflösung (max. 1 mal pro Sekunde) gestört und die Tatsache, dass zeitabhängige Sachen immer vom User non-blocking programmiert werden mussten, das wird man vom Plugin-System nicht direkt unterstützt. Da ist die Logikengine von Fry die richtige Wahl - leider gab es die nicht, als ich rumprobiert habe...

Inzwischen mache ich zu 95% LinKNX, weil es regelbasiert ist und superschnell, resourcenschonend und zuverlässig agiert. Vor allem zeitbasierte Aktionen (Timer, Verzögerung) sind direkt unterstützt, ich kann nicht einfach so alles blockieren, weil ich irgendwo ein sleep(3600) gemacht habe. Externe Geräte kann man über Portkommunikation einbinden, da macht LinKNX auch nen guten Job bezüglich reconnect etc. Leider gibt es aber hier noch Lücken, die ich dann mit (derzeit noch 3) WG-Plugins löse. 2 der 3 WG-Plugins werde ich aber mit der nächsten LinKNX-Version ablösen können.

Es gibt wohl einen Editor mit knxweb2, den hab ich noch nicht ausprobiert. Ich editiere das xml direkt, mit einem Editor mit xsd-Unterstützung. Habe mir einfach die Mühe gemacht, das linknx.xsd-File zu kommentieren, so dass ich jetzt im Editor die entsprechenden tooltips mit den möglichen Befehlen und deren Bedeutung bekomme - dann ist das easy.

Insofern bin ich mit der Kombi LinKNX (fast alles) + WG-Plugins (für die wenigen Sachen, die in LinKNX nicht gehen) sehr zufrieden.

Gruß, Waldemar

[henfri]

Hi,

vielen Dank für eure Antworten!
Ich muss sie morgen mal in Ruhe abarbeiten. Aber hier juckt es mir in den Fingern:

hmm, ich denke die Logikengines nehmen sich nicht viel was die Basiskonfiguration angeht. Man muss halt einmal einer (KNX) Adresse einen Namen zuweisen.

Na, beim Wiregate/dessen Plugins macht man das nicht.

Nenn mir ein (kleines) Problem und ich schreib Dir die Konfiguration/Logik dazu. Du wirst überrascht sein wie wenig man braucht und wie einfach man die Logik lesen/schreiben kann.

Da nehme ich dich beim Wort:
https://knx-user-forum.de/knx-eib-fo...tml#post265082
(Zumindest, wenn sich keine Möglichkeit ohne Logik findet!) Da kann ich nämlich abschätzen, welcher Aufwand das mit WG-Plugins ist.

Bei SmartHome.py kannst Du Dir auch mal das ETS Import Skript von 2ndsky ansehen.

Das ist lustig, denn hier schließt sich der Kreis. Das Skript stammt m.W. von meiner Idee:
https://knx-user-forum.de/cometvisu/...minuten-2.html
Allerdings hab ich leider nur die ETS3 und das Skript braucht den Export von der ETS4.

Bei weiteren Fragen kannst Du diese auch gerne im Support-Forum stellen. Ich denke Du würdest einen schnellen Einstieg finden.

Danke für das Angebot!

Gruß,
Hendrik