Idee: Logikbausteine

[henfri]

Hallo,

das folgende könnte ich mir sowohl für den Zustandsautomaten als auch für das Logikmodul vorstellen, wobei ich selbst bisher nur letzteres verwendet habe:

Für viele Server gibt es ja Logikbausteine, damit das Rad nicht immer wieder neu erfunden werden muss.
Da für einen bestimmten Zweck oft mehrere Logikkanäle nötig sind, ist es das Teilen ja oft etwas schwieriger.
Das LM ja interne, relative Verknüpfungen zulässt, ist es ja durchaus möglich, Bausteine zu erstellen (sprich mehrere miteinander intern verknüpfte Kanäle, die eine Aufgabe haben). Schwierig wird es natürlich, wenn die Logik einen VPM nutzt, denn die Logikkanäle wären ja en-block, so dass man die Kanalnummer weiß, die VPM aber nicht.

Was haltet ihr davon? Oder sind die Logiken so speziell, das es hierfür gar keinen Bedarf gäbe?

Ich spreche hier (noch) nicht über irgendwelche Änderungen am LM, sondern nur davon, ob wir eine Umgebung (Thread, Downloadbereich,...) schaffen, um Bausteine zu teilen. Wenn das Ganze Anklang findet, wäre es natürlich toll - bin aber nicht sicher ob möglich - solche Bausteine auch "Gruppiert" in der ETS darzustellen. Aber das wäre nur ein Sahnehäubchen und nicht wirklich nötig.

Viele Grüße,
Hendrik

[thewhobox]

Ich habe noch nicht ganz verstanden, was du nun als Logikbaustein definierst.
Meinst du damit die Einstellungen der Logikkanäle um Beispiel Rollos Zeitgesteuert zu fahren?

Sowas ähnliches gibt es ja bereits, wo waldemar Beispiele vorstellt: https://knx-user-forum.de/forum/proj...knx-logikmodul

Ich glaube aber vieles davon ist einfach zu speziell für jeden selbst.

[henfri]

Hallo,

ja, die Beispiele von Waldemar würden darunter fallen.
Ein anderes - recht triviales - Beispiel was mir von mir einfällt ist ein Baustein der mehrere Und-Eingänge hat. Ist trivial, ist hier im Forum irgendwo dokumentiert, aber der Kniff mit relativen Verknüpfungen zu arbeiten kommt einem Anfänger vielleicht nicht.

Vielleicht ist der Thread auch genau das, was wir brauchen... Nur mental habe ich da eine Hürde Lösungen zu posten, da ich nicht an die Beschreibungen und Komplexität der Beispiele von Waldemar heran komme.

Gruß,
Hendrik

[willisurf]

Die relativen Verknüpfungen sind bereits ein Teil, um strukturiert Blöcke zu bilden. Kommentare bei den Logikblöcken können helfen die notwendigen Kanäle auch fremder Module zu dokumentieren.
Und der Konfigtransfer wird sich auch noch weiterentwickeln.
Um die intensive Auseinandersetzung mit den Möglichkeiten kommt man aber nicht herum.

[mumpf]

Klar, wir können auch weitere Sachen veröffentlichen. Das grundsätzliche Problem liegt darin, dass viele komplexere Logiken von der Telegrammreihenfolge und Timing auf dem Bus abhängen. Die ganzen Zeitkomponenten bei den Eingangs- und Ausgangs-Signalverarbeitung dienen ja gerade dazu, das zu kompensieren. Aber genau das macht es komplex und notwendig, sich mit der Materie auseinanderzusetzen.
Ein Logikbaustein impliziert ein "ich nehme das und dann läuft es". Der wird aber über mehrere Logikkanäle gehen und potentiell bei jedem User angepasst werden müssen. Ich frage mich, ob das nicht ein Bumerang wird, in dem Sinne dass es dann heißt "Die Logikbausteine kannst Du vergessen, die funktionieren sowieso nicht". Das war auch mit der Grund, warum ich erstmal nur einfach Beispiele gezeigt habe, die eher grundsätzliche Konzepte aufzeigen.

Gruß, Waldemar

[henfri]

Hallo,

ich verstehe das Feedback, frage mich aber, warum diese Hindernisse für OpenKNX/das LM gelten, nicht aber für EDOMI oder einen HS?

Gruß,
Hendrik

[gbglace]

Das sind in dem.Sinne keine vollnativen KNX Geräte mit echten KOs und deren Implikationen der Buskommunikation. Die hören im wesentlichen auf dem Multicastdatenstrom und wenn da ein Telegramm mit einer GA vorbeikommt dann nehmen die sich das und packen das in ihren Baustein, und der arbeitet da in sich als PHP Code Module (Edomi) alles ab.

Hier sind es mehrere einzelne Logikzellen die dann teilweise auch nochmal über den KNX Stack und den KOs sich untereinander Signale zu schicken.

Und das ganze auf komplett unterschiedlichen HW Größenordnungen mit entsprechenden Kapazitäten.

[henfri]

Das ist mir bekannt, aber ich sehe nicht, wie sich das auf die Sinnhaftigkeit von LBS auswirkt?

[gbglace]

Naja das was alles in echten Skriptsprachen in Python Module (HS, wohl auch HA) oder Edmoni in PHP gepackt ist, müsstest da jetzt auch in die Firmware der OpenKNX-Module bringen und da dann einen Rahmen drum rum basteln der dann wiederum einige Verhaltensparameter und die KOs per ETS bedienbar macht.

Das ist dann doch wieder etwas ganz anderes als was derzeit auf den OpenKNX Geräten passiert.

Klar kann man mit einem OpenKNX HW Modul und der Nutzung entsprechend vieler Kanäle sich da auch recht komplexe Logik-Strukturelemente als quasi einen LBS bauen aber derzeit sind das erstmal alles einzelne kleine separate Komponenten.

Das bietet erstmal den großen Vorteil sich sehr individuelle eigene Konstruktionen zu bauen.

Und ja wenn der Konfigtransfer sowas noch geklammert er als ein Paket ex und importieren können wird dann hat man da auch die Option sich quasi fertige komplexe Bausteine auszutauschen aber da wird man dann bei einzelnen zu individualisieren den Verhalten immer in die einzelnen Teilkomponenten gehen müssen und dort die Parameter anpassen. Und da kann man sich dann schon etwas kaputt bauen.

Einfacher zu bedienende große LBS-Module mit einer Konfigseite und die zugehörigen KOs. Sind dann aber eben eine komplett andere Softwarearchitektur. Inwieweit das auf der HW von den Ressourcen passt keine Ahnung.

Mal darüber sinnieren ist ja immer erlaubt.

[willisurf]

Inwieweit das auf der HW von den Ressourcen passt keine Ahnung.

und es müsste ja noch jemand entwickeln....

[henfri]

Ich glaube nicht, dass meine Idee hier rüber gekommen ist.

[coko]

Hardware-Ressourcen sind zwar limitiert, aber nach meinem Eindruck bislang aber nicht der begrenzende Faktor. Den sehe ich eher in den Möglichkeiten der ETS und in bestimmten Fällen auch der Parameter-Größe zum Programmieren über den Bus.

Und ja wenn der Konfigtransfer sowas noch geklammert er als ein Paket ex und importieren können wird dann hat man da auch die Option sich quasi fertige komplexe Bausteine auszutauschen

Den Konfigurationstransfer wird längerfristig eine Möglichkeit zum Multi-Kanal-Transfer bekommen. Was ich hier schon mal entspannt "versprechen" kann: Im nächsten Release wird diese Möglichkeit eher noch nicht integriert sein ;-) Was genau wäre denn Deine Vorstellung von "geklammert er als ein Paket"? (... habe schon einige Pläne/Ideen die in diese Richtung gehen könnten, Input von Anwenderseite ist aber auch immer nützlich!)

Es gibt ansonsten auch noch Vorbereitungen für ein, bislang nicht in PROD-Releases enthaltenes, OpenKNX-Modul mit einer Sammlung von Bausteinen für häufige Standardprobleme wie z.B. Logische Verknüpfungen mit mehr als 2 Eingängen...

[gbglace]

Ich komme mit den IST featuren gut zurecht. es wäre ja interessant was sich Hendrik da so unter LBS und vereinfachten Austausch sich vorstellt.

Das ist mir halt aus seiner Beschreibung und vergleich zu EDOMI und HS Modulen nicht klar geworden.

Soll es nur einfacher sein sich einen 8-fach ODER zu bauen oder doch einen kompletten Beschattungslogikbaustein?

[henfri]

Hi,

es wäre ja interessant was sich Hendrik da so unter LBS und vereinfachten Austausch sich vorstellt.

Jedenfalls meine ich keine neuen Features.

Wie thewhobox erkannt hat, ist diese Sammlung schon ein guter Anfang: Alltagsprobleme und deren Lösungen mit dem OpenKNX-Logikmodul - KNX-User-Forum

Wenn jemand einen kompletten Beschattungslogkikbaustein im LM gebaut hat, wäre das auch ein Kandidat. Ich bezweifle es.
Aber Lösungen, die zwischen einem 8-fach ODER und einer Beschattungslogik sind wird es doch viele geben, von denen einige wohl auch allgemein genug sind.

Wenn man dann noch einen Ort hat, wo die mit einer kurzen Zusammenfassung ohne Hürden - und ohne Diskussion - hochladen kann, wäre der erste Schritt doch gemacht.

Gruß,
Hendrik

[gbglace]

Das Problem ist das Hochladen, dazu muss man es ja auch erstmal als ein objekt aus dem LM extrahieren können. Und dazu stellt sich die Frage wie dieses Feature auszugestalten sein soll und welche Erwartungen hat man dazu.

Ein Konfigextrakt aus 10 einzelnen Kanälen mit jeweils 2 Seiten ETS Parameter ist ein Ansatz aber nicht unbedingt eine komfortable Lösung, um Einsteigern eine komplexere logik, mit aber eigentlich nur noch 3 Parametern, die man aber nur schwer identifizieren kann, vorgefertigt anzubieten.

Insofern ist der Thread Alltagsprobleme mit generischen Beschreibungen der Umsetzung derzeit schon das richtige Medium denke ich. Wenn es dann einen Extrakt komlexerer Strukturen an Logikkanälen in ein extraktfile gibt, dann kann man ja quasi schon von LBS sprechen udn dafür auch eine echte Katalogisierung und Downloadquelle vorsehen. sei es hier im Forum oder im Wiki-Bereich.