[Frage] [V4.8 IP3] Szenenbaustein mit Logik erstellen

[ralftimber]

Hallo Zusammen,

obwohl ich schon einiges im Forum recherchiert habe, komme ich nicht weiter.

Hintergrund:
Viele der neueren KNX-Geräte haben das Objekt "Szene" und lassen sich damit bekanntlich über Szenennummern ansteuern und mittels der Szenenspeichergsfunktion, z.B. über langen Tastendruck, individuell abspeichern (wenn freigegeben).
Nun habe ich verschiedene, ältere Aktoren in meiner KNX, die diese Funktion noch nicht hatten.

Ich möchte bei diesen Aktoren aber auch gerne Szenen benutzen und individuell abspeichern, gerne auch generell die Szenensteuerung als Zusatz nicht in der KNX, sondern auf dem TW laufen haben.

Hat jemand sowas bei sich laufen? Mein Problem ist es vor allem, wie ich den aktuellen Zustand der Aktoren abfrage und im TW speichere.
Wie mache ich das?

[eib-eg]

Hallo @ralftimber

Ich habe auch die lichtszenentaster bei mir vor 27 Jahren verbaut und laufen auch bei mir noch
Die Funktionsweise hast ja beschrieben wie sich der LZ Taster die Zustände der aktoren Speicher
Ich habe es und werde es vermutlich nicht bei mir realisieren dies über den Timberwolf steuern weil ich mit meinem Wolf hauptsächlich Energie steuere und dadurch spare

Bezogen auf dein Vorhaben wie knx Telegramme sich verhalten ist Göran @gbglace sehr gut mit seinen Beschreibungen

Wie würde ich an deiner Situation vorgehen
Der Wolf ist in meinen Augen so zu sehen wie ein zusätzlicher LZ Taster
Auch in der Ets, sprich auf die Einstellungen wird es sehr darauf ankommen der ko‘s
Wenn du den genauen datenpunkttyp sowie subtyp kennst
Zur Kontrollen viewtopic.php?t=217#p59638 ob es freigeschaltet ist
Als Probe könntest ja genau diese GA die der Taster sendet auch vom Wolf senden lassen als Probe

Mit dem busmonitor mal mithorchen was auf dem Bus mit den Tastern geschieht
Anhand dieser Auswertung dann im wolf nachbauen, wie auch immer.

[Parsley]

Hi Ralf

Bitte ergänze zunächst noch den aktuellen Softwarestand deines TWS im Titel.

Zum Thema:
Der TWS kann den aktuellen Zustand der Aktoren nur „herausfinden“, wenn in der ETS am TWS entsprechende KOs konfiguriert werden und diese mit den entsprechenden Status-GAs der Aktoren verbunden werden.
Danach hast du diese Infos innerhalb des TWS im Objektsystem zur Verfügung und kannst sie (z.B. in einer Logik) weiterverarbeiten.

Einen fertigen „Szenen-Logik-Baustein“ gibt es im TWS nicht. Dazu gab es vor Ewigkeiten hier im Forum mal eine Erklärung. Szenen sind ein tolles KNX Feature, solange sie so innerhalb der KNX-Welt umgesetzt werden, wie sie gedacht sind. Ein Negativbeispiel, wo es anders gebaut ist, ist der Gira X1: Wenn Anwender sich innerhalb des X1 eine Szene zusammenklicken ist das etwas ganz anderes also eine KNX-Szene und der X1 agiert als GA-Schleuder. Um diese Unart mit dem TWS gar nicht erst zu hofieren wurde kein „GA-Schleuder-Feature“ eingebaut. (Was nicht heißt, dass man es sucht nicht bauen kann, zumal ich deine Anwendung legitim finde, da du lediglich das Szenen-Feature auf KNX-Geräte erweitern willst, die es eigentlich nicht unterstützen.)

[gbglace]

Gegenüber dem was der X1 da als Szenen macht geht der Wunsch hier noch eine Stufe weiter.

Hier müsste eine Logik nicht nur X Ausgänge bedienen, sondern auch noch x Eingänge mit den ganzen Statuswerten der Aktoren.

Dann muss man in der Logik sich noch je Zustand eine interne Variable bauen, die dem Szenen Sollwert entspricht. Kommt die Sternennummer lernen werden die letzen bekannten Statuswerte als Soll fixiert in der internen Variable. Kommt die Szenenummer auslösen, werden diese Werte auf die Ausgänge gegeben.

Aufwändig wird es solche Bausteine zu initialisieren da der Logik ab Speichern erstmal alle Statuseingänge fehlen.

So einen Baustein auf Level Szenen bauen kann daher recht komplex werden.

Auf Ebene Aktorkanal wird wohl übersichtlicher, weil man bei Dimmaktoren dann auch einfacher zwischen pauschal AN/AUS und einem spezifischen Dimmweet wechseln kann.

[ralftimber]

Danke für die schnellen Antworten!

Tatsächlich ist der Wunsch nach der Funktionalität des X1 gegeben. Als Benutzer klicke ich mir hier einfach die Szene zusammen. Nun ist aber nicht der X1 in der Installation, sondern der TW. Es kann doch nicht sein, das ich dafür den TW nicht nutzen kann?

Eigentlich dachte ich, daß es mit einer Logik relativ einfach zu erstellen sein. Daher habe ich chatgpt gefragt, wie ich daß realisieren kann.

Hier die Antwort mit JSON Vorlage. (Ich weiß allerdings nicht, wie ich das in den Logikeditor als Customlogik bekomme. Einmal als Beispiel angelegt, ist eine Erweiterung um mehr Aktorkänäle dann doch kein Problem mehr):

Perfekt! Dann erstelle ich Ihnen eine Timberwolf-kompatible JSON-Logikvorlage mit:

3 Schaltkreise (1 Bit)
2 Dimmer (1 Byte)
4 Szenen
Szenennummer (1 Byte)
Speichern-Taster (1 Bit)
Abrufen-Taster (1 Bit)
Beispiel-Gruppenadressen
Dimmerwerte springen direkt auf gespeicherte Werte (kein Softstart)
Hier ist die Struktur der Beispielgruppenadressen, die ich verwende:
Gerät Typ GA
Licht1 Schalten 1/1/1
Licht2 Schalten 1/1/2
Licht3 Schalten 1/1/3
Dimmer1 Dimmen 1/1/4
Dimmer2 Dimmen 1/1/5
Szenennummer 1 Byte 1/2/1
Szene speichern 1 Bit 1/2/2
Szene abrufen 1 Bit 1/2/3
JSON-Logik
{
"logic_name": "Szenensteuerung_3L_2D_4S",
"description": "Speichern und Abrufen von 4 Szenen mit 3 Schaltkreisen und 2 Dimmern",
"variables": [
{"name":"Szene1_Licht1","type":"bit"},
{"name":"Szene1_Licht2","type":"bit"},
{"name":"Szene1_Licht3","type":"bit"},
{"name":"Szene1_Dimmer1","type":"byte"},
{"name":"Szene1_Dimmer2","type":"byte"},
{"name":"Szene2_Licht1","type":"bit"},
{"name":"Szene2_Licht2","type":"bit"},
{"name":"Szene2_Licht3","type":"bit"},
{"name":"Szene2_Dimmer1","type":"byte"},
{"name":"Szene2_Dimmer2","type":"byte"},
{"name":"Szene3_Licht1","type":"bit"},
{"name":"Szene3_Licht2","type":"bit"},
{"name":"Szene3_Licht3","type":"bit"},
{"name":"Szene3_Dimmer1","type":"byte"},
{"name":"Szene3_Dimmer2","type":"byte"},
{"name":"Szene4_Licht1","type":"bit"},
{"name":"Szene4_Licht2","type":"bit"},
{"name":"Szene4_Licht3","type":"bit"},
{"name":"Szene4_Dimmer1","type":"byte"},
{"name":"Szene4_Dimmer2","type":"byte"}
],
"inputs": [
{"name":"GA_Licht1","type":"bit","ga":"1/1/1"},
{"name":"GA_Licht2","type":"bit","ga":"1/1/2"},
{"name":"GA_Licht3","type":"bit","ga":"1/1/3"},
{"name":"GA_Dimmer1","type":"byte","ga":"1/1/4"},
{"name":"GA_Dimmer2","type":"byte","ga":"1/1/5"},
{"name":"GA_Szenennummer","type":"byte","ga":"1/2/1"},
{"name":"GA_Speichern","type":"bit","ga":"1/2/2"},
{"name":"GA_Abrufen","type":"bit","ga":"1/2/3"}
],
"logic": [
{
"trigger":"GA_Speichern",
"on_value":1,
"actions":[
{"condition":"GA_Szenennummer==1","set_vars":["Szene1_Licht1=GA_Licht1","Szene1_Licht2=GA_Licht2","Szene1_Licht3=GA_Licht3","Szene1_Dimmer1=GA_Dimmer1","Szene1_Dimmer2=GA_Dimmer2"]},
{"condition":"GA_Szenennummer==2","set_vars":["Szene2_Licht1=GA_Licht1","Szene2_Licht2=GA_Licht2","Szene2_Licht3=GA_Licht3","Szene2_Dimmer1=GA_Dimmer1","Szene2_Dimmer2=GA_Dimmer2"]},
{"condition":"GA_Szenennummer==3","set_vars":["Szene3_Licht1=GA_Licht1","Szene3_Licht2=GA_Licht2","Szene3_Licht3=GA_Licht3","Szene3_Dimmer1=GA_Dimmer1","Szene3_Dimmer2=GA_Dimmer2"]},
{"condition":"GA_Szenennummer==4","set_vars":["Szene4_Licht1=GA_Licht1","Szene4_Licht2=GA_Licht2","Szene4_Licht3=GA_Licht3","Szene4_Dimmer1=GA_Dimmer1","Szene4_Dimmer2=GA_Dimmer2"]}
]
},
{
"trigger":"GA_Abrufen",
"on_value":1,
"actions":[
{"condition":"GA_Szenennummer==1","send_vars":["Szene1_Licht1->GA_Licht1","Szene1_Licht2->GA_Licht2","Szene1_Licht3->GA_Licht3","Szene1_Dimmer1->GA_Dimmer1","Szene1_Dimmer2->GA_Dimmer2"]},
{"condition":"GA_Szenennummer==2","send_vars":["Szene2_Licht1->GA_Licht1","Szene2_Licht2->GA_Licht2","Szene2_Licht3->GA_Licht3","Szene2_Dimmer1->GA_Dimmer1","Szene2_Dimmer2->GA_Dimmer2"]},
{"condition":"GA_Szenennummer==3","send_vars":["Szene3_Licht1->GA_Licht1","Szene3_Licht2->GA_Licht2","Szene3_Licht3->GA_Licht3","Szene3_Dimmer1->GA_Dimmer1","Szene3_Dimmer2->GA_Dimmer2"]},
{"condition":"GA_Szenennummer==4","send_vars":["Szene4_Licht1->GA_Licht1","Szene4_Licht2->GA_Licht2","Szene4_Licht3->GA_Licht3","Szene4_Dimmer1->GA_Dimmer1","Szene4_Dimmer2->GA_Dimmer2"]}
]
}
]
}

So importieren Sie die Logik
Speichern Sie den JSON-Code als Szenensteuerung_3L_2D_4S.json.
Öffnen Sie den Timberwolf-Webserver → Logikverwaltung → Importieren → JSON-Datei auswählen.

Was haltet ihr hiervon und wie bekomme ich das umgesetzt?

VG
Ralf

[eib-eg]

Wenn du mehr Infos geben kannst, dann kann ich meinen Kanon mal „versuchen !“ da mein Kanon sowas noch nicht realisiert hat.
Somit könnte er daraufhin wider gehärtet werden.

Je mehr Infos du geben kannst umso schneller bist an deinem Ziel.
Also keine Angaben wie
Ich will lichtszene 1 Licht auf diese oder jene Helligkeit und fertig

Mein prompt erwartet sehr genaue Angaben
Und wenn es 5 oder mehr Seiten sind die du schreibst
Mein prompt sucht sich es dann schon raus was er braucht bzw. stellt auch Fragen.
Heute habe ich noch Zeit
Stelle dich auf Rückfragen ein das du sie so schnell wie möglich beantwortest.
Denn einmal den promt geschlossen dauert es wider bis er auf dem aktuellen Stand ist.

Gib Rückmeldung ob ich es versuchen soll
Hab heute zwischen 20:00 und 22:00 Zeit

[gbglace]

ChatGPT hat ganz offensichtlich keine Ahnung vom TWS.

Das musst Du doch etwas verbaler formulieren was genau bezweckt werden soll.
Gerne mal halbwegs generisch und für die benötigten Datentypen der Ausgänge je ein Beispiel in einer exemplarischen Szenengruppe zusammengefasst.

Die wesentliche Designfrage bleibt aber noch offen.

Soll der Baustein eher orientiert am Aktorkanal sein oder orientiert an der einen Szene sein.

Bei einer Orientierung an den Aktorkanal ist der Baustein viel leichter zu verwenden und zu bauen, da man hier je benötigten Datentyp genau einen Baustein baut, zwei Eingangs-Objekte denen einmal die Szenen zugeführt werden und einmal der passende Aktorstatus. Und dann eben noch einen Parametereingang über dem man dann im Logik-Manager die Szenennummer auf die der Baustein dann reagieren soll erfasst. Am Ausgang dann ein Ausgangs-KO für die Verbindung an den Aktorkanal.

Für einen Szenenorientierten Baustein würde dieser von jedem User neu designt werden müssen, denn immer wenn man ein Objekt hinzukommt muss der Code erweitert werden oder angepasst werden wenn aus einem Schalt ein Dimkanal wird. Das kann eine KI generieren halte ich aber für einen Community-Fertig-Baustein für ungeeignet.

Für eine komplexe Szene nehme ich mir dann eben 3 Schaltkanal Bausteine, drei Dimmbausteine und 5 RolloBausteine und verapsse denen die notwendigen Aktorverbindungen und allen die selbe Szenen GA und den selben Szenen-Wert. fertig.

Am Ende haben wir dann eine handvoll Converterbausteine für den Standard-Logik Katalog. Die jeweils aus einem Szeneeingang einen klassischen Ausgang bedienen und das lernen beinhalten.

Ergänzender Gedanke. man kann so einen Konverter auch für alle Ziel DPT in einen packen, dann aber wirklich nur je DPT einen Kanal und dessen Auswahl möglichst dynamisch.

Oder in Funktionsgruppen kombiniert.

Denn der Bedarf existiert ja für:

Befehl 1BIT mit Status 1BIT
Befehl 1 byte mit Status 1byte und das in x% und 0-255 getrennt
Dann eigentlich auch für Lichtsteuerung auch in den komplexen DPT für RGB HSV Steuerung usw.
Und Befehl sicher auch gerne 14 Byte Text, damit man Textanzeigen je ausgelöster Szene senden kann.
Insgesamt kann die Liste da beliebig lang werden.

Ganz vergessen kann man dabei Pärchen wo Status und Befehl verschiedene Datentypen sind. Da wäre dann auch noch ein individuelles Mapping notwendig, das lässt sich nicht wirklich per Parameter optionalisieren.

Also dann mal los mehr Futter für die KI-Engine um solch einen / mehrere Basis Konverter zu bauen.

Man kann das in der TWS Logik schon bauen. Nur das Grundprinzip TWS ist halt nicht Gira-Telegrammschleuder, daher muss man sich dann eine solche selber bauen.

[ralftimber]

Eigentlich geht es in der Installation um max 10 Schalt-, 4 Dimm- und 6 Jalou-kanäle, ältere Siemensbausteine aus 1999. Dann gab es ein BJ Panel 6136, das hat einen Szenenbaustein, das Panel ist jetzt defekt. Da auch eine PV (Fronius Gen24) vorhanden ist, habe ich zum TW gergriffen um alles zu überwachen und zum Beispiel lastabhängig zu schalten. Die Visu sieht jetzt auch viel besser aus als vorher, also alles top dank TW. Nur die guten alten Szenen, fehlen..... Das war jetzt mal offtopic zum Hintergrund.
Dann dachte ich, so eine Logik ist einfach und hab chatgpt das Beispiel gegeben. Ich finde die Lösung eigentlich logisch, verstehe halt nur nicht, wie man den Ist-Zustand im TW speichert, als eigentliche eine Art latch mit Wiederabfrage realisiert.

Bei einer Orientierung an den Aktorkanal ist der Baustein viel leichter zu verwenden und zu bauen, da man hier je benötigten Datentyp genau einen Baustein baut, zwei Eingangs-Objekte denen einmal die Szenen zugeführt werden und einmal der passende Aktorstatus. Und dann eben noch einen Parametereingang über dem man dann im Logik-Manager die Szenennummer auf die der Baustein dann reagieren soll erfasst. Am Ausgang dann ein Ausgangs-KO für die Verbindung an den Aktorkanal.

Das würde für den Anfang genügen.

Für einen Szenenorientierten Baustein würde dieser von jedem User neu designt werden müssen, denn immer wenn man ein Objekt hinzukommt muss der Code erweitert werden oder angepasst werden wenn aus einem Schalt ein Dimkanal wird. Das kann eine KI generieren halte ich aber für einen Community-Fertig-Baustein für ungeeignet.

Für eine komplexe Szene nehme ich mir dann eben 3 Schaltkanal Bausteine, drei Dimmbausteine und 5 RolloBausteine und verapsse denen die notwendigen Aktorverbindungen und allen die selbe Szenen GA und den selben Szenen-Wert. fertig.

Am Ende haben wir dann eine handvoll Converterbausteine für den Standard-Logik Katalog. Die jeweils aus einem Szeneeingang einen klassischen Ausgang bedienen und das lernen beinhalten.

Auch eine gute Lösung...

Also, ich werde das Angebot von ein-eg annehmen und berichte über die Ergebnisse

[gbglace]

Die Logik ist dann quasi ab Start ein laufender Prozess. Mit einem Latch machst eine Wertzuweisung an eine Variable zu einem bestimmten Zeitpunkt im Ablauf der Logik. Da so eine Logik dann immer mal wieder den Rechenzyklus durchläuft dabei sich selbst aber als konstanter Prozess versteht steht dem nächsten Zyklus der per Latch zugewiesene Wert im nächsten Zyklus auch für Abgleichen usw. zur Verfügung. Es ist damit quasi ein Speicher innerhalb des laufenden Logikbausteins. Den Wert verliet das nur wenn die Logik editiert und dann halt neu aufgebaut wird.
Ein Neustart des TWS hingegen kann den Wert erhalten, wenn die Persistenz am Logikbaustein dann ausgewählt wird.

[eib-eg]

Hallo zusammen,

kurzes Update zum Stand der Dinge:
Ralf und ich haben uns kurzgeschlossen. Ich habe den Ansatz von Göran (modulare Bauweise statt einem riesigen Monolithen) aufgegriffen und drei spezifische Logik-Bausteine (Schalten, Dimmen, Jalousie) entworfen, die das "Lernen und Abrufen" von Szenen im TWS abbilden.

Technisch setzen wir dabei auf interne Speicher (Latches) und den gezielten Einsatz von Triggern ("Update only"), um Rückkopplungen beim manuellen Schalten sauber abzufangen.

Zum Status:
Ralf hat die Bausteine in einer Nachtschicht implementiert. Die erste Rückmeldung heute Morgen war positiv – die Grundfunktion steht und tut, was sie soll.
Da jetzt Weihnachten vor der Tür steht, wird er die Logik über die Feiertage im "Live-Betrieb" mit der Familie auf Herz und Nieren prüfen.

Wenn dieser "Langzeittest" erfolgreich durchläuft und wir sicher sind, dass keine Seiteneffekte auftreten, werde ich die fertigen JSON-Codes und eine kurze Anleitung hier im Thread posten.

Schöne Feiertage!

mfg
eib-eg