UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ
NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ
NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074
[Beantwortet] [V3.1] Verständnisfrage zur Funktion KNX und MQTT
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
- Reactions:
- Beiträge: 38
- Registriert: Fr Jan 07, 2022 2:02 pm
- Hat sich bedankt: 23 Mal
- Danksagung erhalten: 10 Mal
[V3.1] Verständnisfrage zur Funktion KNX und MQTT
Hallo zusammen
Ich habe meinen Mqtt Server vom IOBroker auf Mosquitto umgestellt und habe dabei ein Problem mit dem Ich nicht so ganz klar komme!
In dem Moment als Ich den Timberwolf umgeschaltet habe, ist mein KNX-Bus geflutet worden mit Meldungen im Millisekunden Takt.
Hab jetzt ein bisschen gebraucht um das Problem einzukreisen!
Zur Info meiner Situation:
Meine Publish / Subscribes sind alle QOS2
Es lief zu testzwecken NUR der Timberwolf am Mosquitto
Probleme vorher beim IOBroker nicht vorhanden --> Vermutlich weil dieser kein QOS2 kann!
Durch den Busmonitor konnte Ich feststellen, dass es sich bei den Meldungen um Topics handelte, welche Ich sowohl Publish als auch Subscribe hatte
--> dies hat also zu Schleifen geführt
Das habe Ich nun geändert indem Ich alle Topics durchgegangen bin und mich für Publish ODER Subscribe entschieden habe
--> Im anschluss lief das System erwartungsgemäß und es gab keine Schleifen mehr!
Soweit so gut!
Hier erst mal die Frage ob das so passt oder ob Ich einen anderen Denkfehler habe?
Zu meiner Verständnis Frage:
Wie gestalte Ich nun die Anbindung von Topics bei denen Ich eben beides benötige??
Z.B. Ich habe einen Schalter im Kinderzimmer mit der Funktion eine Schlafszene zu starten.
Wenn Ich den Schalter betätige wird auf MQTT ein Publish durchgeführt --> IOBroker lässt sein script ablaufen ...... alles gut
Nun möchte Ich den Schalter aber auch per Visu betätigen und dies auch als Zustand für den Schalter auf KNX Senden
Dazu müsste Ich das Topic aber gleichzeitig Subscriben was wieder zu einer schleife führt
Meine MDT Taster unterstützen keine eigene GA für den Status des Schalters .... zumindest hab Ich es nicht gefunden
Wie könnte hierfür ein Lösung Ansatz aussehen?
Danke für die Hilfe Gruß
Kai
Ich habe meinen Mqtt Server vom IOBroker auf Mosquitto umgestellt und habe dabei ein Problem mit dem Ich nicht so ganz klar komme!
In dem Moment als Ich den Timberwolf umgeschaltet habe, ist mein KNX-Bus geflutet worden mit Meldungen im Millisekunden Takt.
Hab jetzt ein bisschen gebraucht um das Problem einzukreisen!
Zur Info meiner Situation:
Meine Publish / Subscribes sind alle QOS2
Es lief zu testzwecken NUR der Timberwolf am Mosquitto
Probleme vorher beim IOBroker nicht vorhanden --> Vermutlich weil dieser kein QOS2 kann!
Durch den Busmonitor konnte Ich feststellen, dass es sich bei den Meldungen um Topics handelte, welche Ich sowohl Publish als auch Subscribe hatte
--> dies hat also zu Schleifen geführt
Das habe Ich nun geändert indem Ich alle Topics durchgegangen bin und mich für Publish ODER Subscribe entschieden habe
--> Im anschluss lief das System erwartungsgemäß und es gab keine Schleifen mehr!
Soweit so gut!
Hier erst mal die Frage ob das so passt oder ob Ich einen anderen Denkfehler habe?
Zu meiner Verständnis Frage:
Wie gestalte Ich nun die Anbindung von Topics bei denen Ich eben beides benötige??
Z.B. Ich habe einen Schalter im Kinderzimmer mit der Funktion eine Schlafszene zu starten.
Wenn Ich den Schalter betätige wird auf MQTT ein Publish durchgeführt --> IOBroker lässt sein script ablaufen ...... alles gut
Nun möchte Ich den Schalter aber auch per Visu betätigen und dies auch als Zustand für den Schalter auf KNX Senden
Dazu müsste Ich das Topic aber gleichzeitig Subscriben was wieder zu einer schleife führt
Meine MDT Taster unterstützen keine eigene GA für den Status des Schalters .... zumindest hab Ich es nicht gefunden
Wie könnte hierfür ein Lösung Ansatz aussehen?
Danke für die Hilfe Gruß
Kai
Zuletzt geändert von Parsley am Fr Nov 10, 2023 12:54 am, insgesamt 1-mal geändert.
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache
-
- Reactions:
- Beiträge: 1152
- Registriert: Mi Okt 10, 2018 2:39 pm
- Hat sich bedankt: 744 Mal
- Danksagung erhalten: 923 Mal
Hi
Zu MQTT kann ich Dir leider nicht helfen. Aber was sind das denn für Taster?
-
- Reactions:
- Beiträge: 1152
- Registriert: Mi Okt 10, 2018 2:39 pm
- Hat sich bedankt: 744 Mal
- Danksagung erhalten: 923 Mal
Hi
Bei "Zweitastenfunktion" wär's dann KO3 usw. usf. Das ist eine essentielle Funktionalität, würde mich schwer wundern, wenn's das nicht gäbe...
Ok, hab' ich zwar nicht im Einsatz aber wenn ich da einen Blick in die Applikation werfe, dann sollte das doch bei Einzeltastenfunktion für Taste 1/2 KO1 und KO6 sein!? Also in der Applikation "Bedienen / Anzeige" > "Tastenfunktion" > "Tasten 1/2 (links, rechts)" und dann "Einzeltastenfunktion". Dann werden die KOs aktiviert und sichtbar.
Bei "Zweitastenfunktion" wär's dann KO3 usw. usf. Das ist eine essentielle Funktionalität, würde mich schwer wundern, wenn's das nicht gäbe...
-
- Reactions:
- Beiträge: 38
- Registriert: Fr Jan 07, 2022 2:02 pm
- Hat sich bedankt: 23 Mal
- Danksagung erhalten: 10 Mal
Hi
Ich benutze die Unterfunktion umschalten, hierbei werden mir 2 KO´s zur verfügung gestellt:
Schalten und Wert für Umschaltung
Den Wert für Umschaltung muss Ich entweder dem Status eines Aktors zuordnen (damit er immer invertiert den anderen Status wählt) oder dem gleichen KO wie Schalten (Verweist dann sozusagen auf sich selbst)
Einen Status des Schalters an sich gibt es so nicht!
Ein Workaround wäre über eine Logik ein extra GA beschreiben zu lassen vom TW .... finde es halt keine brauchbare Lösung da umständlich und unnötig Daten generiert
Ich könnte noch prüfen, ob Ich über andere Tasterfunktionen das ganze abfangen kann
Ich benutze die Unterfunktion umschalten, hierbei werden mir 2 KO´s zur verfügung gestellt:
Schalten und Wert für Umschaltung
Den Wert für Umschaltung muss Ich entweder dem Status eines Aktors zuordnen (damit er immer invertiert den anderen Status wählt) oder dem gleichen KO wie Schalten (Verweist dann sozusagen auf sich selbst)
Einen Status des Schalters an sich gibt es so nicht!
Ein Workaround wäre über eine Logik ein extra GA beschreiben zu lassen vom TW .... finde es halt keine brauchbare Lösung da umständlich und unnötig Daten generiert
Ich könnte noch prüfen, ob Ich über andere Tasterfunktionen das ganze abfangen kann
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache
-
- Reactions:
- Beiträge: 3585
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1253 Mal
- Danksagung erhalten: 1649 Mal
ersteres ist genau das einzig sinnvolle Anwendungsszenario.Zelkin hat geschrieben: ↑Mo Feb 28, 2022 4:55 pm Den Wert für Umschaltung muss Ich entweder dem Status eines Aktors zuordnen (damit er immer invertiert den anderen Status wählt) oder dem gleichen KO wie Schalten (Verweist dann sozusagen auf sich selbst)
Einen Status des Schalters an sich gibt es so nicht!
Der Taster soll halt im Wechsel mal AN und mal AUS schalten und zwar genau nicht in Abhängigkeit dessen was an dem Schalter zuletzt bedient wurde sondern was aktuell am Aktor anliegt. Damit eben multiple Bedienquellen die auf den Aktor wirken nicht unberücksichtigt bleiben.
Einen Status des Tasters haben zu wollen ergibt da irgendwie gar keinen Sinn.
Ich kann Deiner ganzen Konstruktion da allerdings auch noch nicht folgen.
Du hast einen MDT KNX-Taster der sich komplett so verhält wie man das im KNX so tut.
Du hast einen IO-Broker wo irgendwelche Skripte laufen.
Du hast eine Visu die worauf basiert und wie mit dem Gesamtsystem verbunden ist?
Und es gibt irgendwelche Lampen, die auf welcher Basis laufen also was ist da der "Aktor"?
Es fehlt mir hier grundsätzlich der Zusammenhang für den Bedarf des Weges via MQTT.
Grüße
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
-
- Reactions:
- Beiträge: 1849
- Registriert: Do Feb 07, 2019 8:08 am
- Hat sich bedankt: 1541 Mal
- Danksagung erhalten: 788 Mal
Guten Morgen Kai, @Zelkin
also ich kann den Göran nur zustimmen. Für mich ist die Sache auch bisschen unklar und könnte durch eine Skizze finde ich besser veranschaulicht werden.
Wert für Umschaltung -> Dieses Objekt bei den Tastern egal welcher Hersteller ist immer ein Empfangendes Objekt welches von einem Aktor oder hier beim TWS auch durch eine Logik oder anderes Objekt aus dem weiten System gesetzt werden kann. Es wird nie senden. Beim Aktor gibt es das Status Objekt was z.B. bei kleinen Räumen mit 2 Schaltern oder gar großen Räumen mit 4 oder mehr schaltern sicher stellt das alle Taster den gleichen Status des Aktor Ausgangs kennen und dann sofort richtig ein bzw. aussschalten. Ist auch ein sehr bekannter Anfängerfehler den viele vergessen und mir beim ersten programmieren auch passiert ist. Ich würde das zum Dopplertouch Fehler ernennen.
So aber nun zu deinen Problem. Wir müssen 1. alle Aktoren / Taster und beteiligen Systeme wissen und wie diese nach deiner Idee miteinander kommunizieren sollen. Welche Wege und welche Protokolle. Das müsstest du uns bitte in einer Skizze mal deutlich machen. Danke.
also ich kann den Göran nur zustimmen. Für mich ist die Sache auch bisschen unklar und könnte durch eine Skizze finde ich besser veranschaulicht werden.
Wert für Umschaltung -> Dieses Objekt bei den Tastern egal welcher Hersteller ist immer ein Empfangendes Objekt welches von einem Aktor oder hier beim TWS auch durch eine Logik oder anderes Objekt aus dem weiten System gesetzt werden kann. Es wird nie senden. Beim Aktor gibt es das Status Objekt was z.B. bei kleinen Räumen mit 2 Schaltern oder gar großen Räumen mit 4 oder mehr schaltern sicher stellt das alle Taster den gleichen Status des Aktor Ausgangs kennen und dann sofort richtig ein bzw. aussschalten. Ist auch ein sehr bekannter Anfängerfehler den viele vergessen und mir beim ersten programmieren auch passiert ist. Ich würde das zum Dopplertouch Fehler ernennen.
So aber nun zu deinen Problem. Wir müssen 1. alle Aktoren / Taster und beteiligen Systeme wissen und wie diese nach deiner Idee miteinander kommunizieren sollen. Welche Wege und welche Protokolle. Das müsstest du uns bitte in einer Skizze mal deutlich machen. Danke.
Gruß Michael
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
-
- Reactions:
- Beiträge: 38
- Registriert: Fr Jan 07, 2022 2:02 pm
- Hat sich bedankt: 23 Mal
- Danksagung erhalten: 10 Mal
Guten Morgen
Ich versuche mal den Weg mit Worten zu skizzieren welchen Ich im Moment benutzen will:
MDT Glastaster Programmiert mit umschalten --> es steckt hier hinter kein Aktor innerhalb von KNX
In der GA "Kind Schlafen" gibt es dann 3 KO´s: Schalter / Wert für Umschaltung / TW
dieser Taster wird von mir nur dafür verwendet den Status Ob die Kinder im Bett sind oder nicht nach Aussen zu leiten
Ich drücke jetzt auf die Sensorfläche --> Das angezeigte Bild auf meinem Taster wird blau damit am am Taster sieht welchen zustand er nun hat
TW gibt über sein KO den wert weiter an den MQTT Broker (jetzt Mosquitto)
Mein IOBroker hat den Topic als Abo und bekommt jetzt den zustand Kind Schläft mitgeteilt
Dies löst ein script im iobroker aus welches dann:
- Rolladen runterfährt --> geht an KNX über MQTT
- Playlist auf Sonsos Startet --> geht an Sonos adapter in IObroker
- meine Hue Beleuchtung anschaltet und schrittweise bis 0 runterdimmt --> geht an Hue adapter in IObroker
- Rolladen Sperrt wenn er unten ist --> geht an KNX über MQTT
Gegenpart dann wenn der Taster mitteilt, dass das Kind wach iss
bis hierher läuft alles, da der Taster seinen zustand einzig und alleine mitteilt
Auf dem IOBroker läuft die eigene Visu vom IOBroker
bisher konnte Ich darin einfach Kind schlafen aktivieren und der Befehl wurde über MQTT in die GA geschrieben
folge: der Taster hat den zustand verändert, das Script wurde ausgeführt --> Ich habe also in der Visu den Taster betätigt
Dieser weg ist auf dem Mosquitto so nicht mehr möglich, da ich dafür den Taster sowohl Publishen als auch Subscriben müsste um die GA von Außen zu betätigen als auch aus dem knx Heraus
Dies führt dann aber zu schleifen
Wenn Ich es jetzt so betrachte ist im Prinzip mein Script mein "Aktor"
Wenn Ich das aus dieser Sicht heraus sehe, müsste Ich eine neue GA machen (Status) hier die KO´s
Wert für Umschaltung / (neues)TW
reinnehmen und im script innerhalb der Ausführung den Status setzen
So hätte Ich dann wieder eine saubere schleife .... muss nur testen ob sich dann auch das anzeige Bild auf dem Taster ändert bzw. ob das am zustand von "Wert für Umschaltung" oder des Taster selbst hängt
Ich hoffe Ich hab es einigermaßen verständlich rüber gebracht
Aufgrund meines immer weiter erweiterten und gewachsenem System, schleppe Ich halt doch noch einige Altlasten mit. Das führt dann doch das eine oder andere mal zu sehr seltsamen Fehlern
So wie 2 MQTT Broker (vorher eben der in IOBroker und jetzt Mosquitto) so unterschiedlich reagieren auf die selbe Programmierung
Ich versuche mal den Weg mit Worten zu skizzieren welchen Ich im Moment benutzen will:
MDT Glastaster Programmiert mit umschalten --> es steckt hier hinter kein Aktor innerhalb von KNX
In der GA "Kind Schlafen" gibt es dann 3 KO´s: Schalter / Wert für Umschaltung / TW
dieser Taster wird von mir nur dafür verwendet den Status Ob die Kinder im Bett sind oder nicht nach Aussen zu leiten
Ich drücke jetzt auf die Sensorfläche --> Das angezeigte Bild auf meinem Taster wird blau damit am am Taster sieht welchen zustand er nun hat
TW gibt über sein KO den wert weiter an den MQTT Broker (jetzt Mosquitto)
Mein IOBroker hat den Topic als Abo und bekommt jetzt den zustand Kind Schläft mitgeteilt
Dies löst ein script im iobroker aus welches dann:
- Rolladen runterfährt --> geht an KNX über MQTT
- Playlist auf Sonsos Startet --> geht an Sonos adapter in IObroker
- meine Hue Beleuchtung anschaltet und schrittweise bis 0 runterdimmt --> geht an Hue adapter in IObroker
- Rolladen Sperrt wenn er unten ist --> geht an KNX über MQTT
Gegenpart dann wenn der Taster mitteilt, dass das Kind wach iss
bis hierher läuft alles, da der Taster seinen zustand einzig und alleine mitteilt
Auf dem IOBroker läuft die eigene Visu vom IOBroker
bisher konnte Ich darin einfach Kind schlafen aktivieren und der Befehl wurde über MQTT in die GA geschrieben
folge: der Taster hat den zustand verändert, das Script wurde ausgeführt --> Ich habe also in der Visu den Taster betätigt
Dieser weg ist auf dem Mosquitto so nicht mehr möglich, da ich dafür den Taster sowohl Publishen als auch Subscriben müsste um die GA von Außen zu betätigen als auch aus dem knx Heraus
Dies führt dann aber zu schleifen
Wenn Ich es jetzt so betrachte ist im Prinzip mein Script mein "Aktor"
Wenn Ich das aus dieser Sicht heraus sehe, müsste Ich eine neue GA machen (Status) hier die KO´s
Wert für Umschaltung / (neues)TW
reinnehmen und im script innerhalb der Ausführung den Status setzen
So hätte Ich dann wieder eine saubere schleife .... muss nur testen ob sich dann auch das anzeige Bild auf dem Taster ändert bzw. ob das am zustand von "Wert für Umschaltung" oder des Taster selbst hängt
Ich hoffe Ich hab es einigermaßen verständlich rüber gebracht
Aufgrund meines immer weiter erweiterten und gewachsenem System, schleppe Ich halt doch noch einige Altlasten mit. Das führt dann doch das eine oder andere mal zu sehr seltsamen Fehlern
So wie 2 MQTT Broker (vorher eben der in IOBroker und jetzt Mosquitto) so unterschiedlich reagieren auf die selbe Programmierung
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache
-
- Reactions:
- Beiträge: 1849
- Registriert: Do Feb 07, 2019 8:08 am
- Hat sich bedankt: 1541 Mal
- Danksagung erhalten: 788 Mal
Hallo Kai,
also ich denke du musst dich hier vom IO Broker Script verabschieden und diese in der Logik Engine des TWS umsetzten, damit du hier keine Doppelungen usw. mehr hast.
Also dein KNX Taster braucht auf jedenfall eine KO mit GA für das Umschalten und eine GA für den Wert Umschalten. Keine Ahnung was du hier mit KO TW meinst.
Diese Werte kommen an den TWS per KNX ran ohne Umwege.
Der Umschalt Wert vom Taster wenn du ihn betätigt hast muss dann auf die Logik im TWS.
Rolladen runterfahren geht direkt von der Logik auf die entsprechende KNX Adresse des Jal Aktors. Das mit der Sperre kann man auch denke ich in der Logik mit verankern. Aber da sind andere fitter drin wie @Robert_Mini usw.
Playlist Sonos kann ich nichts sagen. Phillips HUE habe ich gerade mit der HTTP API eingebunden. Hier muss man nur schauen was man da braucht für den Dimmslide.
Muss ich heute abend mal schauen wegen Phillips. Hab nur kurz mal was dazu geschrieben.
also ich denke du musst dich hier vom IO Broker Script verabschieden und diese in der Logik Engine des TWS umsetzten, damit du hier keine Doppelungen usw. mehr hast.
Also dein KNX Taster braucht auf jedenfall eine KO mit GA für das Umschalten und eine GA für den Wert Umschalten. Keine Ahnung was du hier mit KO TW meinst.
Diese Werte kommen an den TWS per KNX ran ohne Umwege.
Der Umschalt Wert vom Taster wenn du ihn betätigt hast muss dann auf die Logik im TWS.
Rolladen runterfahren geht direkt von der Logik auf die entsprechende KNX Adresse des Jal Aktors. Das mit der Sperre kann man auch denke ich in der Logik mit verankern. Aber da sind andere fitter drin wie @Robert_Mini usw.
Playlist Sonos kann ich nichts sagen. Phillips HUE habe ich gerade mit der HTTP API eingebunden. Hier muss man nur schauen was man da braucht für den Dimmslide.
Muss ich heute abend mal schauen wegen Phillips. Hab nur kurz mal was dazu geschrieben.
Zuletzt geändert von Sun1453 am Mi Mär 02, 2022 12:14 pm, insgesamt 1-mal geändert.
Gruß Michael
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
-
- Reactions:
- Beiträge: 3585
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1253 Mal
- Danksagung erhalten: 1649 Mal
Das IO-Broker Script kann/sollte in dem Falle schon der Aktor sein.
Dann würde der Taster nur noch die GA "wechsle den Status" 1/1/1 senden und das Script (via MQTT und TWS) würde dann entsprechend mit der GA " Zustand xy ist bearbeitet" 1/2/1 antworten.
beide GA hätten je zwei Verbindungen im KNX
1/1/1 Ausgang-Taster Taste x und TWS-KO nn
1/2/1 Eingang-Umschaltwert Taste x und TWS-KO nn+1
Die Visu im IO-Broker konsumiert dann auch nur noch den Script-Trigger als Status um Dir dort die Knöpfe richtig abzubilden Und schickt auch nur einen Trigger in das Script. Die Visu für den Knopf braucht da also keine direkte Verbindung mehr an MQTT und/oder KNX, die arbeitet da dann rein IO-Broker intern (sofern das so rein intern geht).
Mittelfristig kann man natürlich auch versuchen das Script vom IO-Broker in eine TWS-Logik zu packen.
Derzeit würde das aber nur für den Rollo Sinn ergeben. Denn solch eine Dimmsequenz am HUE finde ich derzeit noch unnötig aufwändig im TWS-LE zu bauen. Da würde ich erstmal warten bis die Lichtengine im TWS fertig ist. Dann kommt da das passende raus was man dann direkt an HUE schicken kann.
HUE direktanzusprechen wäre natürlich immer gut, kommt aber drauf an wie man HUE im System integriert hat. Ich habe bei mir 2 HUE Birnen im haus und dazu natürlich keine HUE-Bridge sondern einfach einen Alexa-ECHO im EG. Ich glaube nicht das so eine HUE-API dann direkt mit einem ECHO spricht. Daher übersetzt bei mir auch noch Node-Red die KNX-Befehle für Alexa.
Sonos habe ich nicht im Haus. habe hier aber auch noch von keiner API-Umsetzung zu Sonos im Forum gelesen, insofern bist mit den beiden Systemen im IO-Broker erstmal noch gut aufgehoben. Wobei ich wegen der schlankeren Architektur der Container dafür NodeRed bevorzuge.
Dann würde der Taster nur noch die GA "wechsle den Status" 1/1/1 senden und das Script (via MQTT und TWS) würde dann entsprechend mit der GA " Zustand xy ist bearbeitet" 1/2/1 antworten.
beide GA hätten je zwei Verbindungen im KNX
1/1/1 Ausgang-Taster Taste x und TWS-KO nn
1/2/1 Eingang-Umschaltwert Taste x und TWS-KO nn+1
Die Visu im IO-Broker konsumiert dann auch nur noch den Script-Trigger als Status um Dir dort die Knöpfe richtig abzubilden Und schickt auch nur einen Trigger in das Script. Die Visu für den Knopf braucht da also keine direkte Verbindung mehr an MQTT und/oder KNX, die arbeitet da dann rein IO-Broker intern (sofern das so rein intern geht).
Mittelfristig kann man natürlich auch versuchen das Script vom IO-Broker in eine TWS-Logik zu packen.
Derzeit würde das aber nur für den Rollo Sinn ergeben. Denn solch eine Dimmsequenz am HUE finde ich derzeit noch unnötig aufwändig im TWS-LE zu bauen. Da würde ich erstmal warten bis die Lichtengine im TWS fertig ist. Dann kommt da das passende raus was man dann direkt an HUE schicken kann.
HUE direktanzusprechen wäre natürlich immer gut, kommt aber drauf an wie man HUE im System integriert hat. Ich habe bei mir 2 HUE Birnen im haus und dazu natürlich keine HUE-Bridge sondern einfach einen Alexa-ECHO im EG. Ich glaube nicht das so eine HUE-API dann direkt mit einem ECHO spricht. Daher übersetzt bei mir auch noch Node-Red die KNX-Befehle für Alexa.
Sonos habe ich nicht im Haus. habe hier aber auch noch von keiner API-Umsetzung zu Sonos im Forum gelesen, insofern bist mit den beiden Systemen im IO-Broker erstmal noch gut aufgehoben. Wobei ich wegen der schlankeren Architektur der Container dafür NodeRed bevorzuge.
Grüße
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension