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

[Beantwortet] [V3.1] Verständnisfrage zur Funktion KNX und MQTT

Wissen, Planung & Diskussion zur MQTT Unterstützung im Timberwolf Server.
Stellt uns hier Eure MQTT Projekte und Ideen vor.
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

Ersteller
Zelkin
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

#1

Beitrag von Zelkin »

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
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
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#2

Beitrag von starwarsfan »

Hi
Zelkin hat geschrieben: Mo Feb 28, 2022 9:40 am Meine MDT Taster unterstützen keine eigene GA für den Status des Schalters .... zumindest hab Ich es nicht gefunden
Zu MQTT kann ich Dir leider nicht helfen. Aber was sind das denn für Taster?
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -

Ersteller
Zelkin
Reactions:
Beiträge: 38
Registriert: Fr Jan 07, 2022 2:02 pm
Hat sich bedankt: 23 Mal
Danksagung erhalten: 10 Mal

#3

Beitrag von Zelkin »

MDT smart Glastaster..... Glaub gen1

Die mit dem Display in der Mitte und den 6 sensorflächen aussen
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#4

Beitrag von starwarsfan »

Hi
Zelkin hat geschrieben: Mo Feb 28, 2022 1:08 pm MDT smart Glastaster..... Glaub gen1

Die mit dem Display in der Mitte und den 6 sensorflächen aussen
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...
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -

Ersteller
Zelkin
Reactions:
Beiträge: 38
Registriert: Fr Jan 07, 2022 2:02 pm
Hat sich bedankt: 23 Mal
Danksagung erhalten: 10 Mal

#5

Beitrag von Zelkin »

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
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#6

Beitrag von gbglace »

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!
ersteres ist genau das einzig sinnvolle Anwendungsszenario.

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

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#7

Beitrag von Sun1453 »

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.
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 |

Ersteller
Zelkin
Reactions:
Beiträge: 38
Registriert: Fr Jan 07, 2022 2:02 pm
Hat sich bedankt: 23 Mal
Danksagung erhalten: 10 Mal

#8

Beitrag von Zelkin »

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
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#9

Beitrag von Sun1453 »

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.
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 |

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#10

Beitrag von gbglace »

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.
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
Antworten

Zurück zu „MQTT“