Sinnvoll? Raspi mit KBerry für knxd und Node-RED im Schaltschrank

[tobo]

Das liest sich so als wäre da noch etwas konzeptionelle Vorarbeit erforderlich: Gefühlt hast Du hier erst mal alle Eingangsgrößen aufgeführt die man sich so vorstellen kann. Das macht es nicht unbedingt einfacher eine wohldefinierte und noch nachvollziehbare Verhaltensdefinition zu erstellen, vor allem ohne eine gewisse Formalisierung.

Ich habe die Vermutung, dass sich Dein Vorhaben nicht vollständig zustandslos umsetzen lassen wird (z.B. zeitlich beschränkte Sperren). Ggf. noch durch eine Kette von Bedingungen, was sich mit OpenKNX-Logikmodul-Kanälen und den bedingten Übergängen der Zustandsautomaten lösen lassen könnte...

Ich denke Du liegst mit Deiner Einschätzung komplett richtig. In meiner beruflichen Welt denke ich durchaus in Schichten (, aber ich bin kein Entwickler, weshalb ich mir manche Konzepte recht mühselig erarbeiten muss): Unten eine Integrationsschicht (KNX Verbindung), darüber eine grundlegende Schicht die eine „Intention“ ableitet: Ist es Dämmerung und Bewegung etc, dann Intention X? Darauf dann dann das zu steuernde Element, welches aufgrund der Intention einen Zustand annimmt, aber dessen Ausführung übergeordneten Bedingungen unterwirft. Dafür war die virtuelle Leuchte in Edomi genial, und das hat gut dazu gepasst dass ich eher visuell unterwegs bin und theoretisches Nachvollziehen verteilter Elemente als herausfordernd empfinde.

Vielleicht ist meine Vorstellung davon, so mein obiges Ziel zu erreichen aber auch komplett übertrieben - ein Grund warum ich das seit langem vor mir herschiebe.

Ich freue mich über weitere Antworten, aber das OpenKNX Modul werde ich mal bestellen wenn ich aus dem Urlaub zurück bin.

[tobo]

Warum das kBerry Modul und nicht ein Tunnel zum KNX IP Interface? Für mich hat das LAN eine höhere „Zuverlässigkeit“ und kann viel leichter ersetzt werden. Meiner Erfahrung nach hat das RPi CM4 eine sehr hohe Verfügbarkeit.

Das habe ich ja jetzt schon mit IP Interface und Node-Red in der VM. Meine Überlegung war hier, das möglichst nah zusammenzubringen, und in den Schaltschrank. Ein Raspi mit knxd und lokaler Anbindung ist ja schon fast ein echtes KNX-Gerät, wenn man das mit einem X1 oder dem BAB-Tec, Timberwolf und Kollegen vergleicht. Die interessiert es auch nicht wenn das LAN ausfällt (ja ich weiß, unwahrscheinlich) oder die Gattin den Server ausschaltet „weil das WLAN grad nicht geht und hast Du nicht gesagt neustarten?“

[willisurf]

Würde mir jemand freundlicherweise ein paar Screenshots von der Logik Konfiguration erstellen damit ich mir das besser vorstellen kann?

Die Logik entscheidet, ob die Szene Essen bei hoher Helligkeit durch eine andere Szene ersetzt wird.
Die Logik hat zwei Eingänge (wie alle 99 Logikkanäle), Eingang1 Szene und Eingang2 Helligkeit
Logikverknüpfung ist richtige Szene (12) UND Helligkeit hoch,
dann wird Szene 10 gesendet
sonst wird die Szene vom Eingang1 einfach durchgereicht.
Szene Eingang und Ausgang sind unterschiedliche GAs
Das wars

image.png
image.png

image.png
image.png
Der Vollständigkeit halber anbei der Konfigstríng

OpenKNX,cv1,0xA012:0x51/LOG:0x37/35§f~Name=EZ%20Szene%20Essen%20hell%2Fdunkel§f~ChannelDelayTime=5§f~Logic=1§f~Calculate=1§f~Trigger=1§f~TriggerE1=1§f~NameInput1=EZ%20Szene%20§f~E1=1§f~E1Dpt=9§f~E1Default=1§f~E1Low0Dpt17=12§f~NameInput2=Aussenhelligkeit§f~E2ConvertFloat=2§f~E2=1§f~E2Dpt=7§f~E2Default=1§f~E2LowDpt9:2=2200§f~E2HighDpt9:2=2500§f~NameOutput=EZ%20Szene%20inkl.%20Essen%20hell%2Fdunkel%20§f~ODpt=9§f~OOnDpt17=10§f~OOffBuzzer=2§f~OOffAll=2§;OpenKNX

[coko]

Dafür war die virtuelle Leuchte in Edomi genial, und das hat gut dazu gepasst dass ich eher visuell unterwegs bin und theoretisches Nachvollziehen verteilter Elemente als herausfordernd empfinde.

Die virtuelle Leuchte von Edomi kenne ich nicht. Visualisierung von Logiken stößt allerdings an Grenzen, wenn die Komplexität steigt. KV-Diagramme werden bei >4 Eingangswerten unpraktikabel, Graphen von Zustandsautomaten bei sehr vielen Übergängen.

Unten eine Integrationsschicht (KNX Verbindung), darüber eine grundlegende Schicht die eine „Intention“ ableitet: Ist es Dämmerung und Bewegung etc, dann Intention X? Darauf dann dann das zu steuernde Element, welches aufgrund der Intention einen Zustand annimmt, aber dessen Ausführung übergeordneten Bedingungen unterwirft.

Ich finde die Verwendung der Bergriffe hier nicht so intuitiv und würde eher das was Du als "Intention"/Szenen bezeichnest als Zustand bezeichnen (wobei diese in der nachfolgenden Auflisttung ggf. noch mal aufgetrennt werden müssen in verschiedende Zustände):

verschiedene Szenen wie Hell, Dunkel, einschlafen schlafen, aufwachen, möglichst basierend auf Regeln (Helligkeit drinnen und draußen, ggfs. Rollladenposition) aber auch übersteuerbar, zeitgesteuert etc. Zwangsführung bei Alarm, Regeln für dauerhaftes überschreiben bis oder für Zeit X

Meine Begriffsdefinition findet sich so auch in den OpenKNX Zustandsautomaten wieder, bei denen dann mehreren Ausgängen jeweils zustandsabhängige Werte zugeordnet sind, mit denen Du die "steuernden Elemente" indidivuell beeinflussen kannst. Ein Wechsel zwischen den Zuständen (wie gut das hier passt kann ich auf Basis Deiner bisherigen Beschreibung noch nicht klar sagen) kann dann z.B. durch Erreichen von Helligkeitsschwellwerten, Tageszeiten oder Präsenz erfolgen. Verweise da zum besseren Verständnis noch auf den ursprünglich verlinkten Thread, inkl. der dort mit aufgeführten Beispiele zur Nutzung der StateEngine/Zustandsautomaten.

Vielleicht ist meine Vorstellung davon, so mein obiges Ziel zu erreichen aber auch komplett übertrieben - ein Grund warum ich das seit langem vor mir herschiebe.

Es könnte eine gute Idee sein, erst mal mit kleineren Beispielen (weniger Einflussgrößen) zu beginnen.