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

[Gelöst] [V 3.4.5] MQTT mit KNX Subscribe UND Publish

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

[V 3.4.5] MQTT mit KNX Subscribe UND Publish

#1

Beitrag von Zelkin »

Hallo

Die Frage ist ähnlich, aber deutlich vereinfacht und stellt mich immer wieder vor Herausforderungen welche sich nicht lösen lassen!
Wenn Ich ein KNX Objekt (Bool) Sowohl Publishe als auch Subscribe flutet er den Bus mit dem dementsprechenden Wert im Millisekundentakt.
Unabhängig von allem was danach kommt und was man mit den werten aus MQTT anfängt, ist dieses Verhalten doch so nicht gewollt / richtig?

Auch ein versuch auf Integer umzustellen, um die Problematik mit der Umwandlung zu umgehen, hat leider nichts gebracht

Es gibt im KNX (zumindest in meiner Installation mit um die 70 Geräte) mehr als genug werte welche sowohl geschrieben als auch gelesen werden müssen / sollten

Das ist derzeit aber nicht umsetzbar nach meiner Erkenntnis?!

Gruß und danke für die Hilfe
Zuletzt geändert von gbglace am Fr Sep 02, 2022 9:43 pm, insgesamt 1-mal geändert.
Kai
TWS 3500L ID:641 VPN offen, Reboot nach Rücksprache

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#2

Beitrag von Robosoc »

Hallo Kai,

Ich habe Deine Frage irgendwie noch überhaupt nicht verstanden... Warum willst Du alles aus der KNX Welt ins MQTT Universum bringen? Und warum möchtest Du jedes KNX Objekt im MQTT Universum Publishen und Subscriben?
Habe ich das so richtig verstanden?

Was genau beabsichtigst oder willst Du damit umsetzen?
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

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

#3

Beitrag von gbglace »

Ja das ist dann auch ein Zirklbezug, gerade wenn man immer alles durchleitet ohne On-Change Filter.

Beschreibe doch mal den weiteren Zusammenhang zwischen diesen beiden Objekten.
Ergibt das überhaupt Sinn das beides lesend und schreibend gleichzeitig ist? Wenn ich mal so gedanklich das KNX-KO als KO eines KNX-Aktors denke und die MQTT-Komponente im TWS als sowas wie den Aktor selbst, dann ja kann man das KNX-subscriben. Aber einen Status schreibt man als Aktor nicht via dem selben KO auf den Bus dem man seinen Aktionsbefehlt holt. Insofern hätte ich da ein anderes KO im KNX erwartet für das publish vom 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

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

#4

Beitrag von Zelkin »

Hi

Ich will nicht jede knx ga extern weitergeben, aber alleine um eine gute visu hinzubekommen sind doch einige notwendig!
Ein paar Bsp.:
Heizung Sommer winterbetrieb 1ga
Heizung umschalten zwischen Komfort standby und Frostschutz (heißt bei mir wirklich so) 3ga wobei 2 sich sofort auf false schalten wenn man eine auf true setzt - - > muss also alle 3 sowohl lesen als auch schreiben können
Tag nacht Umschaltung
.......

Ich habe es mit auftrennung versucht (Staus und aktor) das wird aber wirklich teilweise unfein wenn man den Status der visu und die Anzeigen innerhalb knx konsistent halten will.... Aber aber hier klappt es wenigstens, da 2 ga's vorhanden sind!

Zirkelbezug...... Aber müssten sich dafür nicht die Werte ändern?
Der gute tws schreibt aber immer den letzten Wert! Es handelt sich also nicht um true / flase / true / false sondern um false / false / false.......

Vlt. kann man am mosqitto noch ansetzen, dass er den Zirkel blockt oder so.....

PS.: vom Handy geschrieben.... Falls irgendwo Kauderwelsch auftaucht 🤣
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

#5

Beitrag von starwarsfan »

Hallo miteinander,

ich würde sogar soweit gehen und das Vorgehen, eine GA sowohl zu lesen als auch zu beschreiben, als "broken by design" zu bezeichnen. IMHO ist es sehr viel sauberer und schlussendlich schmerzfreier, die GAs zum modifizieren und zum abfragen eines Status sauber zu trennen.

Irgendwo im System gibt es eine Stelle, welche den Status von <was-auch-immer> verwaltet resp. kennt (Jalousieaktor, Binäreingang, Logik einer Logik-Engine). Gesetzt wird der Status dann völlig unterschiedlich, je nachdem wer oder was die "zentrale Stelle" ist. Somit also bspw. über entsprechende GAs oder automatisch (bspw. Binäreingang, wenn ein Fenster geöffnet wird). Je nach Gerät u/o Konfiguration wird der Status daraufhin automatisch bei Änderung auf der Status-GA verschickt oder via Read-Request (!) auf der Status-GA erfragt. Damit wird das MQTT-Problem gar nicht erst auftreten und auch in der Visu ist das Handling klar.
Zuletzt geändert von starwarsfan am Mi Aug 31, 2022 7:03 am, insgesamt 1-mal geändert.
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

#6

Beitrag von Zelkin »

@starwarsfan
Es ist nicht so als ob ich dir widersprechen möchte!

Aber es hilft mir jetzt so nicht wirklich weiter!

Und um dein Bsp noch aufzugreifen:
Auch den Status muss ich bei Trennung auf read und write haben!
Bsp. MDT Glastaster
Taste zustand = ga 1
Taste Wert für Umschaltung = ga 2

Wert für Umschaltung wird hierbei immer fremdbestimmt und nicht durch den Zustand des Taster beeinflusst

Den Wert für Umschaltung verwende ich als Status und er wird auch als Referenz zur Darstellung im schalterdisplay genommen!
Nun muss ich in der visu mitbekommen wenn innerhalb von knx der Status verändert wurde UND ich muss den Status beschreiben können wenn ich in der visu was ändere!

Hier muss einfach eine bidirektionaler Datenaustausch möglich sein! Sonst ist das verwenden der knx Daten unnötig kompliziert und umständlich!
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

#7

Beitrag von starwarsfan »

Hi
Zelkin hat geschrieben: Mi Aug 31, 2022 8:08 am Auch den Status muss ich bei Trennung auf read und write haben!
Nein, musst Du nicht.
Zelkin hat geschrieben: Mi Aug 31, 2022 8:08 am Bsp. MDT Glastaster
Taste zustand = ga 1
Taste Wert für Umschaltung = ga 2
Habe ich hier auch so im Einsatz.
Zelkin hat geschrieben: Mi Aug 31, 2022 8:08 am Wert für Umschaltung wird hierbei immer fremdbestimmt und nicht durch den Zustand des Taster beeinflusst

Den Wert für Umschaltung verwende ich als Status und er wird auch als Referenz zur Darstellung im schalterdisplay genommen!
Eben! Genau das ist ja der Punkt!

Zelkin hat geschrieben: Mi Aug 31, 2022 8:08 am Nun muss ich in der visu mitbekommen wenn innerhalb von knx der Status verändert wurde UND ich muss den Status beschreiben können wenn ich in der visu was ändere!
IMHO hast Du hier einen Denkfehler. Der Status wird von dem Gerät oder der Logik auf der Status-GA gemeldet, welche den Status ändert. Er wird aber niemals darüber gesetzt! Sprich, Du drückst auf dem Glastaster eine Taste, welche bspw. das Licht schaltet. In Abhängigkeit des momentanen Zustand der Status-GA wird nun auf die Schalt-GA 0 oder 1 geschickt. Daraufhin verändert der Aktor den Zustand des Lichts und meldet diesen Zustand auf der Status-GA zurück, worauf der Glastaster entsprechend reagiert, indem bspw. die Tasten-LED ein- oder ausgeschaltet wird. Dafür ist keine bidirektionale Kommunikation notwendig (wenn man mal vom Read-Request auf die Status-GA absieht), der Taster liest die Status-GA, er schreibt nicht darauf.

In der Visu funktioniert das auch nicht anders. Der Status eines Buttons auf der Visu orientiert sich an der Status-GA. Abhängig davon schickt der Button bei Betätigung dann entweder 0 oder 1 auf die Schalt-GA. Das Vorgehen ist damit absolut identisch und egal ob Du auf der Visu einen Button betätigst oder den Glastaster benutzt, der Status wird nicht vom jeweiligen Button oder Taster modifiziert sondern vom Aktor! Zudem kennen alle Beteiligten den momentanen Zustand, da sie vom Aktor darüber notifiziert werden.

Zelkin hat geschrieben: Mi Aug 31, 2022 8:08 am Hier muss einfach eine bidirektionaler Datenaustausch möglich sein! Sonst ist das verwenden der knx Daten unnötig kompliziert und umständlich!
Das sehe ich nach wie vor nicht so.
Zuletzt geändert von starwarsfan am Mi Aug 31, 2022 9:04 am, insgesamt 5-mal geändert.
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

#8

Beitrag von Zelkin »

Hi

Ja das funktioniert wenn man innerhalb von knx bleibt recht einfach und logisch, wenn man außerhalb geht muss man bei den scripten extrem auf die richtigen trigger und statussettungen aufpassen!

Als bsp:
Habe einen Taster Kind schlafen im kinderzimmer

Bei Betätigung wird ein Script getriggert hinter mqtt welches die playlist in sonos startet, per zigbee ein sternenlicht einschaltet mit timer in knx den rolledan runterfahrt und sperrt und ne hue Birne schrittweise nach unten dimmt bis nachtlicht bleibt

Im Moment klappt es ganz passabel muss aber extrem mit den stati aufpassen wann was in den Status gesetzt wird um in der visu und im knx alles passend zu haben! Auch das das Script ausgeführt wird wenn der Wert aktualisiert wird anstatt geändert (Taster sendet 2 3 mal true weil status false vorgibt durch Änderung bei der visu)

Aber hier habe ich es auch soweit hinbekommen auch wenn es umständlich iss

Aber noch mal back to topic!
Ich habe ga's welche keinen Status haben, aber dennoch beschrieben und gelesen werden müssen

Z. B. Auch Tag Nacht Modus oder Sommer Winter Heizung oder Modus Heizung........

Hier bleibt das Problem bestehen
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

#9

Beitrag von starwarsfan »

Hi
Zelkin hat geschrieben: Mi Aug 31, 2022 9:15 am Aber noch mal back to topic!
Ich habe ga's welche keinen Status haben, aber dennoch beschrieben und gelesen werden müssen

Z. B. Auch Tag Nacht Modus oder Sommer Winter Heizung oder Modus Heizung........

Hier bleibt das Problem bestehen
Wie ich schon sagte: Broken by design. Insbesondere und gerade weil verschiedene Welten miteinander verbunden werden sollen, ein essentiell wichtiger Punkt. Aber wenn Du meinst, dass das so korrekt ist und sich auch nicht ändern lässt, kann ich auch nicht weiter helfen. :eusa-think:
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) - ... -

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 »

Zelkin hat geschrieben: Mi Aug 31, 2022 9:15 am Ich habe ga's welche keinen Status haben, aber dennoch beschrieben und gelesen werden müssen

Z. B. Auch Tag Nacht Modus oder Sommer Winter Heizung oder Modus Heizung........

Hier bleibt das Problem bestehen
Nee das ist ein Gedankenproblem Deinerseits.

Eine GA ist gänzlich frei von Zuständen, da eine GA kein Objekt ist sondern Teil dessen was bei der Kommunikation auf dem Bus transportiert wird.
In einem Nicht-KNX-Umfeld was diese Telegramme aber irgendwie sehen kann ist man immer dazu geneigt nun eine GA als Objekt mit Zuständen zu begreifen und meint draus etwas lesen und darauf etwas schreiben zu können. Das funktioniert prinzipbedingt nicht, dass muss man einfach akzeptieren. Da muss man dann auch nicht irgendwelche technischen Klimmzüge drumrum bauen.

Du kannst mit dem TWS oder jeder anderen echten KNX-Logikengine, die auf echten KNX-KO basiert, auch für solche Zustände wie Tag/Nacht-Modus quasi einen KNX-Aktor simulieren.

Sprich eine GA wird von verschiedensten Tastern/Logiken/Visus für die Bedienung quasi Definition Soll-Zustand genutzt.

Der TWS bekommt dafür auch ein KNX-KO, um Änderungen des Soll-Zustandes von Seiten KNX entgegen zu nehmen (Taster am Bett).
Dann gibt es z.B. eine kleine Mini-Logik im TWS (UND-Baustein mit Fixwert) die dieses KO/GA als Input erhält. Output ist der IST-Status.

Frage an die Logikspezialisten, kann ich mehre Objekte an einen Input-Knoten einer Logik verbinden? Ich glaube mich zu erinnern, das dies nicht funktioniert. Im KNX-ist es weniger problematisch, da man an der Stelle einfach in der ETS mehrere GA an dieses Eingangs-KO verbindet. Hier brauchst aber nun die Kombination KNX+MQTT. Wenn es geht, dann bleibt es weiterhin bei der einfachen UND-Logik. Wenn nein, braucht es ein Logik-Modul welches das Prinzip der letzte Gewinnt umsetzte. x-Eingänge und ein Ausgang. der Wert vom letzten Eingang zählt. Eingang dann eben KNX-MQTT what ever.

Den Ausgang von diesem Logikobjekt kannst dann mit MQTT subscriben und bist komplett sauber.
Und ebenso kannst den Logik-Ausgang mit einem weiteren KNX-KO des TWS-verbinden und dort auch für alle KNX-Teilnehmer mit L-Flag einen sauberen IST-Zustand Tag/Nacht-Modus zur Verfügung stellen.
Mit den Persistenz Eigenschaften der TWS-Logiken und der KNX-Objekte, sollte das dann auch einem Reboot usw. überstehen.

Im MQTT musst dann aber eben auch getrennte Wege vorhalten schreiben nur an die SOLL-Zustand Strecke KNX-KO und lesen nur von der IST-Zustand Strecke (KNX-KO).

Der TWS-selbst ist dann mit Hilfe einer solchen Logikzelle der Speicher/Master über den Zustand solcher Sachen wie Tag/Nacht usw. wo es sonst keinen geeigneten Aktor für gibt.
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“