Topologie ändern "Stern" zu "Linie/Baum"

[Dkfiwa]

Hallo zusammen,

ich bin ein klein wenig "verzweifelt". Wir bauen gerade unser neues Haus und vom Elektriker wurden an diversen Stellen (auf Wunsch) "Datenkabel" (EIB, KNX-fähig) verlegt.
Hintergrund war an dieser Stellen per Taster gewisse Lampen steuern zu können, die auch über Smart Home (zB App) steuerbar sind.

Die Taster/Kabel sollen also nur das Signal des Schaltens an einen Controller senden, der dann das Licht schaltet. Der Controller wandelt das Signal bzw. den Impuls per Applikation um und speist ihn zB in das MQTT Protokoll ein. Ein anderes Programm kann dabei die MQTT Topics abonnieren und per Relais die entsprechende Lampe schalten. (Hier soll zB die Schaltung im Treppenhaus per oberen/unteren Taster sowie per Applikation/Automatisierung möglicht sein)

Jetzt kommen wir zum Problem:

Die Kabel wurden nicht als Linie oder Baum verlegt, sondern sternförmig aufgebaut. Ich habe für alle 14 Taster also 14 Enden im Schaltschrank. Als ich nun auf der Such nach entsprechenden Controllern war, bin ich fast vom Stuhl gekippt als ich erstmal gesehen habe, dass ich ja für jeden einen separaten KNX Controller benötige. Da es ja 14 Bus'e mit je einem Teilnehmer sind und nicht ein Bus mit 14 Teilnehmern.

Nun zu meiner Frage: kann man die Sterntopologie in Baum/Linie ändern? So wie ich es gesehen habe, macht man dies ja direkt an der Abzweigung vom jeweiligen Taster. In meinem Fall ist dies nicht mehr möglich. Lediglich im Schaltschrank könnte man die jetzt auf "Reihe schalten"? Dann ist der Zuweg von der "Kopplung" natürlich extrem weit bis zum jeweiligen Taster, aber das könnte man doch machen, oder? Gibt es da gewisse Einschränkungen?

Ziel wäre es halt, dass es am Ende dann doch nur einen Aktor bzw. eine Baugruppe benötigt, die auf den Bus lauscht.

Zu meinem Hintergrund: ich bin Anwendungsentwickler/Programmierer. Ich habe also einige Erfahrung und Kenntnisse im Bereich der Datenverarbeitung und Steuerung von Prozessen. Mit der Elektrotechnik, dem Senden und Empfangen von Signalen allerdings nicht allzu viel am Hut...



Bussystem.png

Wenn das geklärt ist, könnte ich die nächsten Schritte angehen, die da wären: Aktor/Controller suchen und die Signale abfassen und ins MQTT schieben zur Visualisierung. Das Schalten der Verbraucher würde dann per MQTT subscribe und einer Relais-Schaltung realisiert werden (so mein erster Gedanke).

Vielen Dank für eure Hilfe

[tsb2001]

Wenn du KNX-Taster verwenden möchtest, klemmst du alle 14 Kabel mit rot/schwarz einfach zusammen, packst im Schaltschrank als Nummer 15 noch eine Spannungsversorgung bei; und Nummer 16 wird der Adapter zu MQTT, z.B. irgendein fertiges Modul; oder aber eine IP-Schnittstelle, woran auf der IP-Seite ein Raspberry mit Smarthome-NG läuft. Dieses kann dir entweder direkt als Broker dienen; oder aber als einfacher Client.
Fertig!
Bei KNX kannst du immer alles munter zusammenklemmen; es sollte nur keinen Ring ergeben.
Was du mit einem KNX-Controller pro Linie meinst, verstehe ich jedoch nicht.

[DirkN]

Irgendwie steh ich auf dem Schlauch was du meinst...deine rechte Skizze ist doch ein Stern.
Wenn du 14 NICHT-KNX-Taster hat, dann bräuchtest du 14 Binäreingänge im Aktor. Dann solltest du aber hoffen, dass es sternförmig ist ;-)
Liegen denn die Stromleitungen für die Lampen sternförmig im Schaltschrank?

Falls es doch KNX werden soll.... es ist egal ob 1 oder 14 grüne KNX-Leitungen ankommen. Entscheidet ist wieviele Kanäle du schalten willst. D.h. du bräuchtest ein Aktor mit z.B. 16 Schaltkanälen - fertig.

[gbglace]

Ich verstehe auch nicht wozu man da MQTT braucht um ne Lampe an/aus zu machen.

[blacksheep587]

Wie es die Vorredner schon gesagt haben: Im Schaltschrank alle 14 Leitungen auf Reihenklemmen gelegt und fertig. Wenn du dann nur 0/1 abfragen willst, dann kannst auch nen 16er-Binäreingang dranhängen und deine 14 KNX-Leitungen dafür "mißbrauchen". KNX startet dann erst im Schaltschrank mit Spannungsversorgung, IP-Interface und angesprochenem Binäreingang.

Wenn nicht so, dann brauchst hald 14 Geräte an den Enden. So wie Sensoren normal angebunden sind. In der Verteilung dann wieder alle sauber verbunden.

[TheOlli]

Ich verstehe was der TE vor hat. Da seine Welt die SW-Entwicklung ist, versucht er die Taster möglichst blöd zu halten und die Intelligenz in „seiner Welt“ abzubilden.

Ich würde das Thema KNX dann bleiben oder vom Eli machen lassen. Finger weg vom Schaltschrank wenn man keine Ahnung hat!

Normale 0815-Taster an die Leitungen anschließen und über einen Arduino auswerten. Der kann MQTT.

Ob das so sinnvoll ist oder nicht muss jeder für sich entscheiden. Im KNX-Forum wird die Meinung eindeutig ausfallen. Stell die selbe Frage im Arduino-Forum und schau was passiert.

Aber Strom macht Aua. Finger weg!

[mumpf]

Hi,

auch ein paar Anmerkungen von mir:

Die Kabel wurden nicht als Linie oder Baum verlegt, sondern sternförmig aufgebaut.

Ein Stern ist ein Baum mit nur einem Root und n (in Deinem Fall 14) Blättern. Also hast Du einen Baum

Da es ja 14 Bus'e mit je einem Teilnehmer sind und nicht ein Bus mit 14 Teilnehmern.

Nein, Du hast 14 Leitungen. Ob es ein oder mehrere Busse werden, entscheidet die Beschaltung der Leitungen. Wenn Du im Schaltschrank jeweils die 14 roten Adern miteinander verbindest und die 14 schwarzen auch (aber nicht rot und schwarz zusammen!), dann hast Du einen Bus (zumindest im KNX-Sinne).

Aber: Nur weil Du KNX-Leitungen verlegt hast, hast Du noch lange kein KNX-System. Und wenn der einzige Zweck für ein KNX-System sein soll, gleich einen Medienwechsel auf MQTT zu machen, dann lasse es sein! Es ist zu teuer und geht komplett an der Idee von KNX vorbei! KNX hat dezentrale intelligente Geräte, die über einen Bus verbunden sind. Ein jeder Taster (genauer: Jeder Busteilnehmer) ist quasi ein Arduino, also ein Mini-Computer mit einem darauf laufenden Programm.

Ich glaube nicht, dass Du das im Sinn hast. Aber Du solltest Dich mit KNX beschäftigen, weil:

Der Controller wandelt das Signal bzw. den Impuls per Applikation um und speist ihn zB in das MQTT Protokoll ein.

Natürlich macht das der KNX-Taster nativ, nur eben als KNX-Telegramm und nicht als MQTT-Telegramm.

Ein anderes Programm kann dabei die MQTT Topics abonnieren und per Relais die entsprechende Lampe schalten.

Das heißt im KNX Schaltaktor, der hört nativ auf KNX-Telegramme und führt entsprechende Aktionen aus.

(Hier soll zB die Schaltung im Treppenhaus per oberen/unteren Taster sowie per Applikation/Automatisierung möglicht sein)

Das ist im KNX eine Standardfunktion (Treppenlichtfunktion) ohne jegliche externe Applikation oder Steuerung, kein MQTT notwendig und auch kein weiterer Rechner, der das steuert.

Du musst bedenken, es geht um ein Gebäude. Ein KNX-System wird in 20 Jahren noch laufen. Ob Deine MQTT-Infrastruktur (verschiedene Übertragungsmedien wie LAN, WLAN, serverbasierte Steuerung wie RasPi, Softwareabhängigkeiten etc.) dann noch läuft, stelle ich in Frage, zumindest nicht ohne intensive Wartung.

Gruß, Waldemar

[GLT]

Taster/Kabel sollen also nur das Signal des Schaltens an einen Controller senden...
Der Controller wandelt das Signal bzw. den Impuls per Applikation um und speist ihn zB in das MQTT Protokoll ein.

Und welcher wäre das dann - Hersteller/Typ?

Jetzt kommen wir zum Problem:
Die Kabel wurden nicht als Linie oder Baum verlegt, sondern sternförmig aufgebaut.

Bei KNX gibt es hier überhaupt kein Problem - dein "geplantes System" ist dato noch nicht bennant.

für jeden einen separaten KNX Controller benötige

Für KXN - definitiv Nein!
Entweder Du nimmst echte KNX-Taster (davon bräuchtest Du zwar 14St., dafür haben die alles an Board und sogar noch mehr) oder Du klöppelst Kuhstallelektroniktaster in die Wand u. schliesst die allesamt auf einen Binäreingang (schlechteste Wahl, da unflexibel).

Die techn. Umsetzung komplett in KNX ist simpelst - 14 KNX-Taster, 1 Schaltaktor mit entsprechenden Kanälen, 1 Spg.-Versorgung - fertisch!

Die MQTT-Spielerei kannst dann dazuklöppeln.

[Dkfiwa]

So, erstmal vielen lieben Dank für das Feedback!

Ich versuche das mal eben aufzugreifen und hoffe, nichts zu vergessen.

Was du mit einem KNX-Controller pro Linie meinst, verstehe ich jedoch nicht.

Habe noch Probleme mit der Terminologie. Ich meine damit den Aktor.

Liegen denn die Stromleitungen für die Lampen sternförmig im Schaltschrank?

Ja, die Verbraucher liegen sternförmig an, damit sie direkt ansprechbar sind.

Ich verstehe auch nicht wozu man da MQTT braucht um ne Lampe an/aus zu machen.

Ich möchte es gerne a) visualisiern in zB iobroker oder Home Assistant und b) auch über diese Applikationen per App/Tablet oder Regel steuerbar machen.

Ich verstehe was der TE vor hat. Da seine Welt die SW-Entwicklung ist, versucht er die Taster möglichst blöd zu halten und die Intelligenz in „seiner Welt“ abzubilden.

Ja, danke. So ist es. Als Software-Enwitckler hat man eine andere Sicht auf die Dinge.
Ich habe nach einer einfachen Lösung gesucht, Verbraucher über konventionelle Wege (Taster) und digital (App, Heimsteuerung) verwalten zu können. Aber da wird es wohl auf KNX hinauslaufen. Wenn ich es nur per Arduino auswerten lasse, dann bin ich von der Zuverlässigkeit dieser abhängig. Die Heimsteuerung per ioBroker oder HA soll das Topping sein. Auch ohne diese sollte es bestmöglich laufen.

Ein Stern ist ein Baum mit nur einem Root und n (in Deinem Fall 14) Blättern. Also hast Du einen Baum.

Naja, aktuell habe ich nicht mal den Baum sondern nur die blanken Kabel!

Wenn ich die Leitungen dann zusammengefasst habe, so wie oben die Eingangsfrage gemeint war, habe ich meinen Bus.

Und wenn der einzige Zweck für ein KNX-System sein soll, gleich einen Medienwechsel auf MQTT zu machen, dann lasse es sein! Es ist zu teuer und geht komplett an der Idee von KNX vorbei! KNX hat dezentrale intelligente Geräte, die über einen Bus verbunden sind.

Genau davon möchte ich profitieren. Es soll primär über das Bus-System laufen. MQTT dient der Visualisierung und möglichst als sekundäre Schaltquelle via App.

Die techn. Umsetzung komplett in KNX ist simpelst - 14 KNX-Taster, 1 Schaltaktor mit entsprechenden Kanälen, 1 Spg.-Versorgung - fertisch!

Die MQTT-Spielerei kannst dann dazuklöppeln.

Genauso werde ich es dann wohl machen!


Fazit


Erstmal nochmal Danke!
Meine Eingangsfrage hat sich wohl damit bestätigt, dass es kein Problem ist, dass keine Busklemmen im Haus verteilt verwendet worden sind, sondern ich dies im Verteilerschrank setzen kann um alle Kabel "auf einen Bus zu bringen".

Wenn ich die 14 losen Kabel dann zu einem Bus zusammengefasst habe (Busklemmen) + Spannungsversorgung und dem notwendigen Aktor, kann ich über diesen die Konfiguration vornehmen. (Damit ist ein Schalten der Verbraucher unabhängig von jeglicher Automatisierung, die aus einem Raspi oder Arduino stammt.)

Kann ein gängiger Aktor die Informationen dann auch in das MQTT einspeisen? Ich weiß es gibt da massig am Markt, aber ist das eher eine Standardfunktion oder sollte man dafür eine extra Baugruppe wie oben vorgeschlagen, in Betracht ziehen?
Oder gibt es anders herum die Möglichkeit den Zustand aus dem Aktor auszulesen um ihn darzustellen? Und anders herum natürlich auch zu setzen per TCP/IP Verbindung oder ähnliches?


Mein grobes Setup würde dann in etwa so aussehen:
- 14 Buskabel mit je einem Schalter/Taster (manche werde ich wohl zusammenfassen, da 1 Schalter mit 4 Bereichen besser ist als 4 einzelne Schalter)
- Stromversorung im Verteilerschrank für den Bus
- Busklemmen im Verteilerschrank um die Telegramme gesammelt im Aktor verarbeiten zu können
- ggf. separater Aktor um Telegramme in MQTT umzuwandeln
- RasPi o.ä. um MQTT auszuwerten und Visualisierung zu ermöglichen (oder Pull des Zustandes direkt vom primären Aktor)
- Ändern von Zuständen über Visualisierung -> Ändern MQTT -> Verarbeitung/triggern im Aktor um Verbraucherzustand zu ändern


Ich weiß da sind sicher noch viele Fragezeichen und Stolpersteine, aber so in etwas stelle ich es mir vor. Wie erwähnt, Software-Entwickler, kein Elektrotechniker!

Schönen Abend!

[TheOlli]

Also 14 KNX-Taster die im Schaltschrank auf KNX-Reihenklemmen gehen
Eine Spannungsversorgung, eine Schnittstelle (evtl. in Form eines KNX-Routers)
Einen Schaltaktor (z.B. 20-fach)

Damit hast du schon mal ein KNX-System das die Lampen schalten kann.
Wenn du jetzt mit dem RasPi und einem der üblichen Verdächtigen (NodeRed, io-broken, openhab..) auf den Bus zugreifst hast du es.

[Dkfiwa]

Also 14 KNX-Taster die im Schaltschrank auf KNX-Reihenklemmen gehen
Eine Spannungsversorgung, eine Schnittstelle (evtl. in Form eines KNX-Routers)
Einen Schaltaktor (z.B. 20-fach)

Damit hast du schon mal ein KNX-System das die Lampen schalten kann.
Wenn du jetzt mit dem RasPi und einem der üblichen Verdächtigen (NodeRed, io-broken, openhab..) auf den Bus zugreifst hast du es.

Danke, das klingt nach einem Plan. Mit den Infos aus den vorigen Kommentaren habe ich mich jetzt auch nochmal ein wenig aufgeschlaut. (ist halt schwierig, wenn man keinen Anfang findet. Aber mit solchen Brocken setzt sich dann doch ein Bild zusammen).

Ich würde es dann jetzt so planen, dass ich einen Aktor (16, 20-fach) einsetze, sowie ein IP Interface (+ ggf. Spannungsversorgung in Abhängigkeit von den Baugruppen). Das IP Interface sollte ja genauso wie ein Teilnehmer auf dem Bus funktionieren.
Die Taster im Haus werden per Aktor konfiguriert und verwaltet. Zusätzlich sind die Informationen/Zustände über das IP Interface abrufbar und so zB in ioBroker und Co darstellbar. Genauso können sie dort auch geändert und über das IP Interface zurück an den Bus gesendet werden und somit im Schaltaktor dann den Zustand ändern.

(Weiß Gott keine Kaufberatung, aber sowas habe ich mir auf die Schnelle ins Auge gefasst. Bzw um diese Art der Komponenten wird es sich wohl drehen):

https://www.voltus.de/?cl=details&an...BoCyqwQAvD_BwE

https://www.voltus.de/?cl=details&an...BoCN2MQAvD_BwE

https://www.eibabo.de/eibmarkt/eib-k...0402-ebn000402

https://www.voltus.de/hausautomation...r-20-fach.html

https://www.voltus.de/?cl=details&an...hoCQ4YQAvD_BwE

Wobei man sich bei den IP Interfaces fragt warum die so einen Preisunterschied haben

Das gute mit dem IP Interface ist eben, dass die Visualisierung und Steuerung per App nur ein nice-to-have ist und das System auch bei einer Downtime vom RasPi o.ä. noch funktionsfähig bleibt.

Dazu kommen dann die verschiedenen Taster und das wars - ganz salopp gesagt.

[wknx]

- ggf. separater Aktor um Telegramme in MQTT umzuwandeln
- RasPi o.ä. um MQTT auszuwerten und Visualisierung zu ermöglichen (oder Pull des Zustandes direkt vom primären Aktor)
- Ändern von Zuständen über Visualisierung -> Ändern MQTT -> Verarbeitung/triggern im Aktor um Verbraucherzustand zu ändern

Kann ein gängiger Aktor die Informationen dann auch in das MQTT einspeisen? Ich weiß es gibt da massig am Markt, aber ist das eher eine Standardfunktion oder sollte man dafür eine extra Baugruppe wie oben vorgeschlagen, in Betracht ziehen?
Oder gibt es anders herum die Möglichkeit den Zustand aus dem Aktor auszulesen um ihn darzustellen? Und anders herum natürlich auch zu setzen per TCP/IP Verbindung oder ähnliches?

Warum willst Du da immer wieder MQTT als zusätzliches Protokoll mit rein nehmen? Das was Du vorhast lässt sich alles direkt über KNX lösen und die gängigen Softwarelösungen können auch per IP-Interface mit KNX kommunizieren.

Die Taster im Haus werden per Aktor konfiguriert und verwaltet. Zusätzlich sind die Informationen/Zustände über das IP Interface abrufbar und so zB in ioBroker und Co darstellbar.

Da fehlt es Dir ganz offensichtlich noch an grundlegendem Verständnis von den Konzepten von KNX. Jedes KNX-Gerät wird direkt und komplett für sich allein konfiguriert. Das Zusammenspiel erfolgt durch gemeinsam genutzte Gruppenadressen über die per Broadcast (innerhalb einer Linie) kommuniziert wird…

Wobei man sich bei den IP Interfaces fragt warum die so einen Preisunterschied haben

Das sind komplett unterschiedliche Geräte.

• Ein IP-Interface
• Ein IP-Interface mit einer herstellereigenen Lösung für Bus-Zugriff über Webservices
• Ein IP-Router

Zum Aktor könnte man auch noch mal ausführlicher diskutieren, bzw. sollte auf Basis Deiner Anforderungen schauen welche Funktionen der mitbringt.

[gbglace]

Zieh dir Mal die ETS und KNX virtual auf den PC damit du Mal ne Vorstellung bekommst was KNX ist und wie das funktioniert.

Bei den Tastern durchdenken ob das entsprechend schlaue native KNX werden sollen oder Mehrwerttaster wie ein MDT GT2 smart. Das kommt hier auch noch nicht raus was da für Vorstellungen zum Bedienkonzept herrschen.

Wie erwähnt braucht es hier kein MQTT. Die notwendige Visu Logiksoftware spricht schon von allein KNX. MQTT kommt erst ins Spiel wenn Du vollkommen KNX fremde Sachen in die Logik /Visu einbauen willst. (Rasenmäher, Cloud-Gedöns).

In KNX ist alles meist Recht modular. Somit hat jedes KNX Gerät eine spezielle Aufgabe dafür auch die dezentrale Intelligenz.

Die KNX Spannungsversorgung ist nicht vielleicht oder so sondern das absolute Basisgerät im Bus. Und auch immer eine KNX Spannungsversorgung kaufen nicht einfach nen 30V Netzteil aus der Grabbelkiste. Und besser auch keine Museumsangebote aus eBay.

[jcd]

Mein Tipp an Dkfiwa: Schau dir mal den Grundkurs beim ETS Campus an. (https://wbt5.knx.org/). Das hilft ein grundlegendes Verständnis zu bekommen. Kostet nix und als Bonus gibts einen Rabattgutschein für eine kleine ETS Version. (die dir vermtl. aber nicht reichen wird).

[Dkfiwa]

ETS werde ich mir am Wochenende mal anschauen. Habe dazu bereits mal die Lizenzmodelle angeschaut. Die "lite" version mit 5 Geräten reicht nicht. Es gibt aber ja auch diese ETS Inside. Wenn ich es richtig verstehe, sollte die genau das richtige sein.

Vlt sollte ich mal mein Setup erklären damit ersichtlich wird welche Komponenten es benötigt. Ich kürze es mal als Stichpunkte ab, damit es kürzer ist:

- EFH mit 2 Etagen
- (14 Buskabel über beide Etagen verteilt, lose im Verteilerschrank)
- Wandtablets zur Visualisierung/Steuerung (Home Assistant, aktuell für Zigbee genutzt sowie Nachrichten etc.)
- elektr. Jalousien im EG mit verbauten Shelly's in den UP Dosen
- diverse Zigbee-fähige Sensoren und Leuchten, Fenster-/Türkontakte, Präsenzmelder, WLAN-Steckdosen (Tasmota)
- RasPi 4 mit Conbee 2 und Home Assistant (bestehende Infrastruktur, die läuft)
- Weitere RasPi für Reverse-Proxy, DNS, Git-Server, Backup-System
- 3D-Drucker, die per RasPi und Octoprint monitored und gesteuert werden können
- LED-Stripes/Leuchten, die per WLED gesteuert werden
- Arlo-System

- die Anzahl der Verbraucher muss ich nochmal durchzählen. Danach richtet sich ja dann der Aktor mit seinen Ausgängen

Aufgrund der Zigbee Geräte und dem darauf genutzten MQTT Protokoll, bin ich eingangs auch in die Richtung MQTT gegangen. Da war mir noch nicht ganz bewusst, dass das IP Interface als Busteilnehmer eigentlich genau derjenige ist, über den man die Zustände lesen und auch setzen kann. Von daher ist MQTT eigentlich nebensächlich.

Die KNX Spannungsversorgung ist nicht vielleicht oder so sondern das absolute Basisgerät im Bus. Und auch immer eine KNX Spannungsversorgung kaufen nicht einfach nen 30V Netzteil aus der Grabbelkiste. Und besser auch keine Museumsangebote aus eBay.

Danke. Das war auch eher auf das IP Interface bezogen. Das gibts ja auch mit PoE.

Bei den Tastern durchdenken ob das entsprechend schlaue native KNX werden sollen oder Mehrwerttaster wie ein MDT GT2 smart. Das kommt hier auch noch nicht raus was da für Vorstellungen zum Bedienkonzept herrschen.

Sorry, aber worin besteht denn kurz gesagt der Unterschied zwischen "nativ KNX" und "Mehrwarttaster"? Ok, sie sind "bunt" und haben tolle Features, aber was ist am nativen KNX dann abgespeckt? Können die nur 0/1 oder wie kann man sich das vorstellen?

Jedes KNX-Gerät wird direkt und komplett für sich allein konfiguriert. Das Zusammenspiel erfolgt durch gemeinsam genutzte Gruppenadressen über die per Broadcast (innerhalb einer Linie) kommuniziert wird…

Das was die Geräte bei entsprechenden Tastendruck senden sollen, für diese konfiguriert werden muss ist klar. Verstehe ich das richtig, dass man dies auf dem Taster direkt durchführt? Also physisch an diesem konfiguriert (per Kabel)?
Ich bin davon ausgegangen, dass man mit der ETS in der Zentrale konfiguriert und über den Aktor, der am Bus hängt die entsprechenden Teilnehmer somit aus der Ferne konfiguriert. Würde ja bedeuten, dass man sonst bei Änderungen immer an den Taster ran muss.

Nochmal zum Thema, was eigentlich passieren soll/gesteuert wird...

Ganz klassisch per Taster entsprechende Verbraucher schalten. Aktuell ist es so, dass an einem Taster nur eine Aktion auszuführen wäre. Das wäre natürlich eine Verschwendung von Ressourcen wenn dort mehr als nur ein Taster umgesetzt werden könnten. Daher wäre es gut wenn dort zusätzlich auch die Temperatur und Luftfeuchtigkeit ermittelt wird. Dann braucht es keine WLAN oder Zigbee fähigen Sensoren, die man auch erst wieder kaufen muss und die nicht so stabil laufen wie per Kabel.
In diesem Zusammenhang würde es ja auch Sinn machen dort z.B. die Temperatur mit anzeigen zu lassen. In Verbindung mit den Fensterkontakten wäre es auch eine Idee per LED darzustellen ob alle verschlossen sind oder nicht.
Aus dem OG sollte es z.B. möglich sein, die Jalousien im EG zu öffnen oder zu schließen. (hierfür müsste man dann per IP Interface das Signal erhalten und über eine gesonderte Routine die Shellys ansprechen)

Die Taster dürfen also auch gerne Zustände anzeigen. Ich denke das war auch mit "nativ KNX" und "Mehrwerttaster" gemeint.