Hier ein möglicher Ansatz für die Sonos - Integration:
viewtopic.php?f=25&t=1669&p=17542&hilit ... api#p17596
Über die bereitgestellte API kann dann auch eine Playlist abgespielt werden.
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
Hallo Michael, Hallo Alex
IOBroker Scripte sind in meinem Haus zwingend erforderlich, da Ich doch einige verschiedene Systeme miteinander Verbinde!
Das Beispiel hier ist zwar aus der Praxis aber definitiv nicht das einzige was diesen Punkt im Allgemeinen betrifft!
Hätte Ich nicht diese "Komplexität wäre euer ansatz in jedem Fall zu bevorzugen um das System "Schlank" zu halten
PS.: KO TW meinte Ich das KO vom Timberwolf
Hallo Göran
So in etwa habe Ich mir das auch vorgestellt und bin jetzt schon wieder an eine grenze gestoßen bei der Umsetzung
Ich habe ja mehrere dies betreffende Punkte .... heute musste Ich meinen Keller aufräumen, weil demnächst die Solaranlage kommt ....
jetzt habe Ich gemerkt, dass im Keller ständig ein paar leuchten an sind
Das ist für mich jetzt natürlich akuter als das anschmeißen der Szene meiner Kinder ( das Funktioniert ja zum größten Teil außer aus der Visu) und hier klappt unser "Workaround" leider schon nicht mehr
Ich habe ein Tasterinterface von MDT verbaut
1x drücken kleines Licht an
2 x großes Licht
3 x alle lichter
langer Tastendruck alles aus
zusätzlich schaltet der Tür Sensor noch das kleine Licht ein / aus!
Alles über IOBroker Script
Der Taster hat in dem Fall ein einziges KO, bei Betätigung schickt er "ein" ...... und da bleibt er stehen bis jemand in die ga ein "aus" schreibt
Das aus hat bisher mein script geschrieben wenn, da die leuchten von Shelly 2.5 WLAN Aktoren angesteuert werden
2 Dinge als Workaround gemacht:
KNX Lange Taste auf Wert "aus"
Im TWS Objekt Manager das TWAS KO von Taste lang mit den Ziel KO 1x / 2x / 3x verbunden
Wenn also Taster lang jetzt ein "aus" sendet landet dies auf den einzelnen Tastern
Sterung von aussen möglich Funktion gegeben --> Trotzdem "fühlt" sich die Lösung nicht ganz korrekt an
Den Versuch mit der Szenenschaltung versuche Ich diese Woche noch unterzubringen, gebe dann Rückmeldung
Irgendwie verhagelt mir das Konzept von entweder subscribe ODER Publish mein system schon ziemlich
Bei MQTT V5 soll im übrigen beides möglich sein .....ist die Implementierung hierzu evtl. angedacht? weiß das jemand?
Gruß
Kai
IOBroker Scripte sind in meinem Haus zwingend erforderlich, da Ich doch einige verschiedene Systeme miteinander Verbinde!
Das Beispiel hier ist zwar aus der Praxis aber definitiv nicht das einzige was diesen Punkt im Allgemeinen betrifft!
Hätte Ich nicht diese "Komplexität wäre euer ansatz in jedem Fall zu bevorzugen um das System "Schlank" zu halten
PS.: KO TW meinte Ich das KO vom Timberwolf
Hallo Göran
So in etwa habe Ich mir das auch vorgestellt und bin jetzt schon wieder an eine grenze gestoßen bei der Umsetzung
Ich habe ja mehrere dies betreffende Punkte .... heute musste Ich meinen Keller aufräumen, weil demnächst die Solaranlage kommt ....
jetzt habe Ich gemerkt, dass im Keller ständig ein paar leuchten an sind
Das ist für mich jetzt natürlich akuter als das anschmeißen der Szene meiner Kinder ( das Funktioniert ja zum größten Teil außer aus der Visu) und hier klappt unser "Workaround" leider schon nicht mehr
Ich habe ein Tasterinterface von MDT verbaut
1x drücken kleines Licht an
2 x großes Licht
3 x alle lichter
langer Tastendruck alles aus
zusätzlich schaltet der Tür Sensor noch das kleine Licht ein / aus!
Alles über IOBroker Script
Der Taster hat in dem Fall ein einziges KO, bei Betätigung schickt er "ein" ...... und da bleibt er stehen bis jemand in die ga ein "aus" schreibt
Das aus hat bisher mein script geschrieben wenn, da die leuchten von Shelly 2.5 WLAN Aktoren angesteuert werden
2 Dinge als Workaround gemacht:
KNX Lange Taste auf Wert "aus"
Im TWS Objekt Manager das TWAS KO von Taste lang mit den Ziel KO 1x / 2x / 3x verbunden
Wenn also Taster lang jetzt ein "aus" sendet landet dies auf den einzelnen Tastern
Sterung von aussen möglich Funktion gegeben --> Trotzdem "fühlt" sich die Lösung nicht ganz korrekt an
Den Versuch mit der Szenenschaltung versuche Ich diese Woche noch unterzubringen, gebe dann Rückmeldung
Irgendwie verhagelt mir das Konzept von entweder subscribe ODER Publish mein system schon ziemlich
Bei MQTT V5 soll im übrigen beides möglich sein .....ist die Implementierung hierzu evtl. angedacht? weiß das jemand?
Gruß
Kai
Zuletzt geändert von Zelkin am So Mär 06, 2022 7:03 pm, insgesamt 2-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: 3585
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1253 Mal
- Danksagung erhalten: 1649 Mal
Ehrlich gesagt kann ich diese Bedienkonzepte auch nicht wirklich nachvollziehen. Erklärbar ist es für niemanden der da nicht dauerhaft drinnen wohnt und es sich ausgedacht hat. Intuitiv ist auf jeden Fall anders. Es gibt einige MDT-Taster die das mittlerweile auch so anbieten mit den Tastenfolgen/und zuschaltbarer Beleuchtung. Aber absurd finde ich es grundsätzlich dennoch.
Du hast da halt wohl eine Anlage mit nur KNX Sensorik aber eher Shelly-Aktorik. Naja aus elektrischen Sicherheitsgedanken würde ich persönlich das wohl eher andersrum machen. Aber naja ist halt jetzt wie es ist und KNX-RF Aktoren als Alternative im System sind noch nicht so sehr verbreitet.
Den KNX auch das AUS direkt senden lassen macht auf jeden Fall sinn, dafür haben die ja schonmal entsprechende KO und Funktionen. Bei kurz immer nur EIN senden und das dann irgendwo in einem Skript hochzählen lassen bis max. 4 ist auch OK. Wo dabei dann nun das Problem sein sollte verstehe ich noch nicht. Das sollte auch mit einem KNX-KO am TWS funktionieren. Weil die Tasterschnittstelle sendet eine GA immer EIN vom KO kurzer Tastendruck und eine GA mit immer AUS von dem langen Tastendruck. Am TWS können ja beide GA an ein KO verbunden werden, da kommt dann halt mal EIN mal AUS an. Das kann/muss Dein Skript ja auswerten, EIN muss gezählt werden und AUS geht durch und ist Reset des Zählers. Mehr ist es nicht auf der Befehlsseite bei der KNX-seitigen HW.
Als Rückmeldung für Visu oder LEDs oder sonstigen Abhängigkeiten im KNX könnte aber sein das du dann mehrere KO am TWS braucht weil ja auch unterschiedliche Leuchten/Aktorkanäle einen unterschiedlichen Status haben. Aber an das KO gehört keine der Befehls-GA vom Taster dran, weil das ja nur Rückmeldungen sind. Da quasi Dein Skript der Aktor im KNX ist, können diese 4 KNX-Ko am TWs für andere KNX-Teilnehmer auch entsprechende Befehlsgeber sein. Das ist dann eben so, weil der undefinierte Tasterbefehl erst durch die Logik sinnvoll auf 4 Einzelkomponenten aufgeteilt wird.
ich denke Du hast da noch keine gedankliche Trennung Deiner Konstruktion von Sensor / Aktor im Sinne KNX und im Sinne des Gesamtsystems. Den Datenstrom KNX musst halt vom MQTT und den Shelly trennen. Eine Vermischung hast erst wieder wenn Du statt das Ergebnis der Logik KNX-seitig als Staus eine aktive Rückmeldung der Shellys als Status verwenden willst. Dann musst das halt auch im MQTT aufnehmen und an KNX im TWS durchreichen, dann aber die Blockly-Logik nicht mit den KNX-KO als Status verbinden.
Du hast da halt wohl eine Anlage mit nur KNX Sensorik aber eher Shelly-Aktorik. Naja aus elektrischen Sicherheitsgedanken würde ich persönlich das wohl eher andersrum machen. Aber naja ist halt jetzt wie es ist und KNX-RF Aktoren als Alternative im System sind noch nicht so sehr verbreitet.
Den KNX auch das AUS direkt senden lassen macht auf jeden Fall sinn, dafür haben die ja schonmal entsprechende KO und Funktionen. Bei kurz immer nur EIN senden und das dann irgendwo in einem Skript hochzählen lassen bis max. 4 ist auch OK. Wo dabei dann nun das Problem sein sollte verstehe ich noch nicht. Das sollte auch mit einem KNX-KO am TWS funktionieren. Weil die Tasterschnittstelle sendet eine GA immer EIN vom KO kurzer Tastendruck und eine GA mit immer AUS von dem langen Tastendruck. Am TWS können ja beide GA an ein KO verbunden werden, da kommt dann halt mal EIN mal AUS an. Das kann/muss Dein Skript ja auswerten, EIN muss gezählt werden und AUS geht durch und ist Reset des Zählers. Mehr ist es nicht auf der Befehlsseite bei der KNX-seitigen HW.
Als Rückmeldung für Visu oder LEDs oder sonstigen Abhängigkeiten im KNX könnte aber sein das du dann mehrere KO am TWS braucht weil ja auch unterschiedliche Leuchten/Aktorkanäle einen unterschiedlichen Status haben. Aber an das KO gehört keine der Befehls-GA vom Taster dran, weil das ja nur Rückmeldungen sind. Da quasi Dein Skript der Aktor im KNX ist, können diese 4 KNX-Ko am TWs für andere KNX-Teilnehmer auch entsprechende Befehlsgeber sein. Das ist dann eben so, weil der undefinierte Tasterbefehl erst durch die Logik sinnvoll auf 4 Einzelkomponenten aufgeteilt wird.
ich denke Du hast da noch keine gedankliche Trennung Deiner Konstruktion von Sensor / Aktor im Sinne KNX und im Sinne des Gesamtsystems. Den Datenstrom KNX musst halt vom MQTT und den Shelly trennen. Eine Vermischung hast erst wieder wenn Du statt das Ergebnis der Logik KNX-seitig als Staus eine aktive Rückmeldung der Shellys als Status verwenden willst. Dann musst das halt auch im MQTT aufnehmen und an KNX im TWS durchreichen, dann aber die Blockly-Logik nicht mit den KNX-KO als Status verbinden.
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