Anschluss gesucht: Matter oder KNX IoT - Zukunft KNX im "Smarthome"

[KNXLump]

Ja aber dann müsste die ETS ja etwas über die einzelnen Funktionen des jeweiligen Geräts kennen. Die ETS hat darüber aber keinerlei eingebaute Kenntnisse über die Hersteller-Kataloge hinweg und v.a. nicht wie man was wie sinnvoll verbinden kann. Sie weiß nicht, was ein Heizungsaktor, was ein Taster oder ein Dali GW ist, sie weiß nur, dass es für jenes und dieses Gerät eine Sammlung von Parametern gibt, welche in irgendeiner Hierarchie vorliegen und je nach Parametrierung bestimmte Device-Funktionen "freigeschaltet" werden.

Sie kennt von Haus aus nur die jeweiligen Datentypen, Gruppenadressen, physikalischen Adressen, Topologie und solcherlei Sachen und kann die Parameter-Konfigurationen an die jeweiligen Devices senden.

Die KNX Association hat leider versäumt, Device-Gruppen und Device Profile zu standardisieren an die sich jeder Hersteller halten muss, sodass nun jeder Hersteller sein eigenes Süppchen kocht, welche Art der Funktionalität er wie und wo in den Funktionen anbietet. Das Device kann auch nicht announcen im KNX Netz: "Hey schaut her ! Ich bin ein jungfräulicher Glastaster, programmiere mich !", weil er ja noch nicht mal eine Mac-Addresse hat, die ihn eindeutig identifizieren könnte, falls es mehrere "jungfräuliche" Glastaster im System geben würde.
Die physikalische Adresse entspricht quasi gleichzeitig einer IP- und Mac Adresse im IP Netz, also OSI Schichten 1,2,3.

Es macht übrigens auch keinen Sinn, über TP irgendwelche IP-Pakete, z.B. von Matter zu routen, damit man evtl. solche Geräte in KNX integrieren könnte: bei 9600 Baud Brutto wäre das zu viel Belastung fürs KNX-Netz.

[dreamy1]

Die KNX Association hat leider versäumt, Device-Gruppen und Device Profile zu standardisieren an die sich jeder Hersteller halten muss, sodass nun jeder Hersteller sein eigenes Süppchen kocht, welche Art der Funktionalität er wie und wo in den Funktionen anbietet.

Um Himmels Willen, genau das wäre das KO-Kriterium für jegliche Innovation! Das ist doch aktuell der Hauptgrund, dass Matter nicht in Fahrt kommt, da sich kein Hersteller mehr vom anderen durch Sonderfunktionen abheben kann da dies eben durch Geräteklassen limitiert ist.

Genau das ist doch der Vorteil - dass es z.B. Tastsensoren mit Feuchtemesssung oder Aktoren mit Strommessung gibt. Bei Device-Gruppen gibts dann halt nur noch Standardware oder man muss ständig an den Geräteklassen herumdoktern (und das immer nachziehen, die Hardware ist ja meist früher da). Ich finde das Grundkonzept, nur die Form der Datenpakete zu strukturieren und nicht gerätespezifisch abzubilden, nach wie vor genial. Sieht man ja, auch nach 30 Jahren sind beliebig neue Geräte mit allerlei Innovation problemlos einbindbar.

Ob das nun über eine -komplexe- ETS alles konfigurierbar sein muss und man da nicht Vereinfachungen machen könnte - bin ich dabei. Aber ich schätze im Gegenzug sehr, dass z.B. auch das Backup aller Geräteparameter zentral über die ETS erfolgt, das wird gerne unterschlagen. Wenn ich ein defektes Gerät austausche, drücke ich auf den Programmierknopf des neuen Gerätes und fertig. Über die ETS können halt auch komplexeste Dinge realisiert werden und ist dadurch sehr mächtig - ob das für den normalen Endanwender oft zuviel ist, bin ich auch dabei.

[crewo]

Die KNX Association hat leider versäumt, Device-Gruppen und Device Profile zu standardisieren an die sich jeder Hersteller halten muss, sodass nun jeder Hersteller sein eigenes Süppchen kocht, welche Art der Funktionalität er wie und wo in den Funktionen anbietet.

Deswegen braucht man keinen Standard, das könnte man alles in den Katalogdaten mitgeben. Die ETS kann mich ja fragen, wenn ich einen Glastaster mit einem Aktor verbinde, welche Taste und welche Funktionen ich nutzen möchte. Das ist doch alles keine Raketenwissenschaft mehr

[livingpure]

Dann hat wer auch immer das System eingerichtet hat kein Bauschlüssel verwendet, wobei es hier ja auch nen Tread gibt wie man ihn knackt.

wer macht das freiwillig?

Konnten jetzt mal ein Objekt mit Tiefgarage installieren wo alle 10 Stellplätze eine Ladestation haben... allerdings ein Hersteller, Cloudgebunden (Inbetriebnahme der Ladestation nur per App mit Internetzugang... klar, in ner Tiefgarage..., hatte sie schon in der Firma vorbereitet). Das ganze bekommt jetzt noch nen Internetzugang und dann darf es überhaupt erst ans Netz, weil Lastmanagement will Internet...

OT, welcher Elektriker verbaut denn so einen Mist? Für 300-400€ gibt es Wallboxen mit lokalem dyn LM, wenn gewünscht, dann auch schon halbwegs standardisiertes LM, so dass verschiedene Hersteller möglich sind. Würde mein Elektriker mit einer Cloud für wallboxen kommen, könnte er direkt in diese abziehen

[KNXLump]

Um Himmels Willen, genau das wäre das KO-Kriterium für jegliche Innovation! Das ist doch aktuell der Hauptgrund, dass Matter nicht in Fahrt kommt, da sich kein Hersteller mehr vom anderen durch Sonderfunktionen abheben kann da dies eben durch Geräteklassen limitiert ist.

Wenn Du ein Gerät anbietest, welches sowohl Taster als auch Feuchtesensor beinhaltet, welche sich jeweils an standardisierte Geräteklassen halten, oder wie Du auch erwähnst einen Schaltaktor-Kanal, der Strommessung kann und dann beide Funktionen ebenfalls die Datentypen und Protokolle unterstützen, damit sie von anderen Geräten automatisch eingebunden werden können: wo ist da der Innovations-Hemmschuh ? Das klingt ein bisschen nach dem gleichen Argument wie von Apple, als sie sich weigerten, USB-C im iPhone unterstützen zu wollen, "weil das die Innovation hemmt".

Ich behaupte im Gegenteil: das treibt die Innovation, denn dann ist man nicht mehr darauf angewiesen, dass ein Hersteller alles was man benötigt in ein Gerät einbaut, sondern man kann dann ohne viel Parametrierung beliebige Geräte oder Dienste z.B. in seinem Glastaster einbinden. Beispiel: in meinem MDT Glastaster kann ich den eingebauten Temperatursensor für die Ermittlung der Raumtemperatur einsetzen und/oder optional noch einen externen Temperatursensor. Ich habe bei uns im WoZi aber noch viel mehr Temperatur-Sensoren, die man für die Ermittlung heranziehen könnte. Jetzt muss ich also entscheiden, welcher dieser anderen Sensoren am besten für die Ermittlung der eigentlichen Temperatur-Stellgröße herangezogen werden soll. Aber warum denn nicht einfach alle ? Warum kann mein Glastaster nicht automatisch alle Temp.-Sensoren im Wozi heranziehen oder von mir aus eben alle, die ich aus einer Liste auswählen kann und warum würde das dann z.B. die Innovation hemmen ? Da bei KNX bei 254 KO's pro Gerät Schluss ist (super Innovation!), muss man ja irgendwo einen Deckel bei den Funktionen machen. Aber so 2, 3 Sensoren mehr würden trotzdem nicht schaden.

Und fangen wir mal lieber nicht damit an, was z.B. MDT alles in ihrem Glastastern künstlich beschränkt, weil sie ja noch eine Glas-Bedienzentrale verkaufen wollen. Hör mir uff mit Innovation !

M.M. nach kommt die KNX Assoc. gar nicht drumherum, eine Standardisierungs-Schicht über die bisherigen Funktionen zu legen. wenn KNX und Innovation zusammengehen sollen. Anders kannst Du keine automatische Konfiguration oder Integration bewerkstelligen. Wenn Matter der Standard wird für Heimautomatisierung, _muss_ KNX auf den Zug aufspringen. Das ist keine Frage.

Ich habe nur Bedenkten, dass das so einfach funktionieren kann: KNX setzt auf einem Protokoll auf, wo es auf wenige Bits und einzelne Bytes ankommt. Das ist der Grund dafür, warum es nur soundsoviel KO's, GA's, Haupt- Mittel- und Untergruppen geben darf, etc. Diese Pfennig-Fuchserei ist natürlich den 9600 Baud vom TP geschuldet. Aber wenn Du auf der anderen Seite auf einmal einen Standard hast, der prinzipiell eine unlimitierte Anzahll von Geräten einbinden kann, wirst Du immer Medienbrüche haben. Tunneling über KNX macht auch keinen Sinn, dafür sind weder die 9600 Baud, noch das KNX Protokoll gemacht. Es muss daher darauf hinauslaufen, dass man KNX Geräte woandershin einbinden kann, umgekehrt wird es schwieriger werden.

Macht Euch also darauf gefasst, dass Ihr zwar Eure MDT Schaltaktoren noch einige Zeit benutzen könnt, aber die Glastaster werden irgendwann mit Matter/Thread Entsprechungen ersetzt. Und irgendein findiger Hersteller nimmt die Hersteller-Datenbanken der ETS, trainiert damit ein LLM und macht daraus eine Thread-kompatible KNX/Matter Bridge ... hoffentlich.

[KNXLump]

Deswegen braucht man keinen Standard, das könnte man alles in den Katalogdaten mitgeben. Die ETS kann mich ja fragen, wenn ich einen Glastaster mit einem Aktor verbinde, welche Taste und welche Funktionen ich nutzen möchte. Das ist doch alles keine Raketenwissenschaft mehr

Genau: keine Raktenwissenschaft. Aber damit die ETS weiß, dass hinter dem Glastaster ein "haptives" Schaltelement steckt und nicht z.B. eine Tag/Nacht Umschaltung, muss sie ja das Konzept des Schalters kennen. Genauso wie andererseits das Konzept des Schaltaktors. Und dann sind wir bei Geräteklassen und Standardisierung. D.h. in der Geräte-DB steckt jeder Hersteller von z.B. Tastern eine bestimmte Art von Parmetern ab, z.B. die Anzahl der Tast-Elemente, die von dem jeweiligen Gerät bereitgestellt werden, die unterstützten Datentypen, Rückmeldeobjekte usw. und dann kann die ETS automatisch diese mit Aktoren zuordnen/verbinden, bei der ebenfalls solcherlei Funktionen standardisiert wurden und hinterlegt sind.

Und dazu braucht es ein Mapping anhand von standardisierten Geräteklassen usw.

[dreamy1]

oder wie Du auch erwähnst einen Schaltaktor-Kanal, der Strommessung kann und dann beide Funktionen ebenfalls die Datentypen und Protokolle unterstützen, damit sie von anderen Geräten automatisch eingebunden werden können: wo ist da der Innovations-Hemmschuh ?

Die Antwort steckt bereits in Deinem Satz, Du hast leider nicht verstanden was die Intention war: morgen möchte ein Hersteller einen Aktor verkaufen, der auch gleich den cosphi ausgibt. Dazu müsste dann bei fester Geräteklasse- und Funktion erst der Standard erweitert werden, der noch keinen Aktor mit dieser Funktion kennt. Oder gar ein vollkommen neues Gerät, ich nenne es mal Fluxsensor, wird kein Hersteller entwickeln, da es erst als neue Geräteklasse eingeführt werden muss. Wenn die "Dachorganisation" der Meinung ist, das ist eh nichts für die breite Masse und man möchte nicht tausend neue Schaltaktor-Unterklassen, dann ist jegliche Innovation tot.

Da stellt sich dann auch sofort die Frage, aus welchen Mitteln Weiterentwicklungen des Standards finanziert werden? Wenn ich am Ende eine App habe um das alles zu parametrieren, wer erstellt und pflegt die? Oder gibts von jedem Hersteller eine, mit der sich "seine" Geräte am einfachsten einbinden lassen? Falls auch die "standardisiert" sein muss, wie stellt man die Qualität sicher wenn das alles nix kosten darf da standardisiert...Fragen über Fragen.

Ist ja alles Bullerbü was Du oben schreibst, aber leider halt auch alles blanke Theorie. Warten wir doch mal ab, wie die Praxis aussieht, ich sehe hier immer wieder viele noch völlig ungelegte Eier, aber die schnelle Vorverurteilung von KNX. Wirklich vergleichen kann man aber erst dann, wenn beide Hennen auf dem Feld sind.

Hör mir uff mit Innovation !

Leutchens.

Macht Euch also darauf gefasst, dass Ihr zwar Eure MDT Schaltaktoren noch einige Zeit benutzen könnt

Nunja, ich verkneifs mir hier mehr zu schreiben was die Artikulation angeht, die Drohung mit dem Untergang von KNX sehe ich jedenfalls entspannt.

[KNXLump]

Die Antwort steckt bereits in Deinem Satz, Du hast leider nicht verstanden was die Intention war: morgen möchte ein Hersteller einen Aktor verkaufen, der auch gleich den cosphi ausgibt. Dazu müsste dann bei fester Geräteklasse- und Funktion erst der Standard erweitert werden, der noch keinen Aktor mit dieser Funktion kennt. Oder gar ein vollkommen neues Gerät, ich nenne es mal Fluxsensor, wird kein Hersteller entwickeln, da es erst als neue Geräteklasse eingeführt werden muss. Wenn die "Dachorganisation" der Meinung ist, das ist eh nichts für die breite Masse und man möchte nicht tausend neue Schaltaktor-Unterklassen, dann ist jegliche Innovation tot.

Wenn es um Geräteklassen geht, dann möchte man ja, dass diese Geräte irgendwo automatisch eingebunden werden und ein anderes Gerät mit Deinem Gerät sprechen kann. Wenn Dein Gerät nun einer Standard-Geräteklasse entspricht und zusätzliche Werte herausgibt, wie z.B. CosPhi oder den aktuellen Wert Deines Fluxkompensators und diese Werte noch nicht standardisiert wurden, dann brauchst Du ja nur noch eine Zuordnung zu einer standardisierten Werte Klasse, so wie sie z.B. ja schon bei KNX existiert. Keinen Hersteller muss das davon abhalten, diesen zusätzlich Wert über die Standard-Funktionalität hinaus zu implementieren.

Außerdem:

Matter Standard, Kapitel 7 "Data Model Specification", Abschnitt 7.16:

"This architecture model provides mechanisms for non-standard or manufacturer specific items such
as clusters, commands, events, attributes and attribute data fields. These items MAY be supported
on a certified product. Such vendor specific items SHALL NOT change the standard behavior of the
standard items. The specific function of a vendor specific item cannot be tested as part of
certification. They can only be tested to verify that they do no harm, and conform to proper
behavior with regard to identification, discovery, error processing, etc. A non-standard item
SHOULD NOT take the place of a standard item that provides the same function. ...."

Mit anderen Worten: "Verwässere nicht den Standard mit Deinen proprietären Erweiterungen, aber Du kannst solche Sachen implementieren, wenn Du unbedingt möchtest. Diese fallen nicht unter die Zertifizierung".

[dreamy1]

OT on:

Ich bin seit vielen Jahren in der Prozessautomation unterwegs (Großindustrie, ich betreue mit meinem Team Anlagen mit mehreren tausend Geräten im Sensor- Aktorbereich) - da hat man vor vielen Jahren gedacht, so ein ordinäres 4-20mA Signal aus dem letzten Jahrtausend muss unbedingt durch was "Modernes" ersetzt werden, damals Profibus PA. Die "Innovativen" waren sich sehr schnell einig, dass 4-20mA dem Tod geweiht ist und sich PA schnell als Standard etabliert. Alle Kritiker wurden als Relikte der Vergangenheit diffamiert, die Jungen waren total begeistert (ohne jemals damit aktiv gearbeitet zu haben) und man hat uns mit tollen Folien bombardiert, was mit PA alles möglich ist und warum man dies unbedingt haben muss (z.B. predictive maintenance, mehrere Messwerte auf einmal...). Natürlich war das am Ende auch noch alles teurer als die "alte" Technik.

Dann wurden einige Pilotanlagen mit Profibus PA gebaut, ich habe eine davon betreut. Ich könnte Bücher schreiben was alles nicht funktioniert hat, was alles doch nicht so komfortabel wie angepriesen war, Herstellerversprechen nicht eingehalten wurden, wie Inkompatibilitäten zwischen Treiber und Hardware zu langen Anlagenausfällen geführt haben, wie sich Hersteller der Geräte und Prozessleitsystem gegenseitig die Schuld zugeschoben haben und wie gestandene Ingenieure und Techniker bei der Fehlersuche kurz vom Wahnsinn standen...und wie sich auch die Jungen ganz schnell 4-20mA zurückgewünscht haben.

Um es kurz zu machen: heute wird wieder alles in 4-20mA gebaut.

OT off

[Axel]

Zur Klarstellung.
jeder moderne KNX Teilnehmer hat eine individuelle Seriennummer, ähnlich MAC.

Automatische Verbindung von Aktor und Sensor probiert man auch schon seit vielen Jahren, hat sich nie durchgesetzt.

Device Gruppen gibt es auch innerhalb der ETS und probiert man, geht aber nichts vorwärts und keiner verwendet es.

Mit KNX-IoT kommt dann die semantische Information dazu, dann weiß die ETS mehr über den Raum.

[dreamy1]

Mit anderen Worten: "Verwässere nicht den Standard mit Deinen proprietären Erweiterungen, aber Du kannst solche Sachen implementieren, wenn Du unbedingt möchtest. Diese fallen nicht unter die Zertifizierung".

Interessante Interpretation.

Ich habe ein Wort aus dem zitierten Absatz mal fett gemacht:

non-standard or manufacturer specific items such as clusters, commands, events, attributes and attribute data fields. These items MAY be supported on a certified product.

Mit anderen Worten (mal eine andere Interpretation):

WIR (=Amazon, Google und Co, genauer gesagt die CSA) entscheiden, ob ein neues Gerät mit innovativen Neuerungen (was vielleicht attraktiver ist als die herstellereigenen) letztendlich eine Zertifizierung erhält oder nicht. WIR entscheiden, ob es neue Geräteklassen gibt und ob diese in Konkurrenz zum eigenen Portfolio auftauchen. WIR entscheiden, ob es sich lohnt, für einen kleinen Hersteller von toller Hardware aber noch ohne passender Geräteklasse eine neue zu eröffnen oder nicht.

Das wäre genau das Gegenteil von Innovation, wenn sie nicht aus dem eigenen Haus kommt.

[GLT]

da hat man vor vielen Jahren gedacht, so ein ordinäres 4-20mA Signal aus dem letzten Jahrtausend muss unbedingt durch was "Modernes" ersetzt werden, damals Profibus PA

Diesen Hype habe ich ebenfalls kennengelernt u. auch die eintretende Ernüchterung.
BTW - PA ist aus dem selben Jahrtausend

iAber warum denn nicht einfach alle ? Warum kann mein Glastaster nicht automatisch alle Temp.-Sensoren im Wozi heranziehen oder von mir aus eben alle, die ich aus einer Liste auswählen kann und warum würde das dann z.B. die Innovation hemmen ?

Ergibt keinen Sinn - manuell nicht u. automatisch erst recht nicht.
Und für den <0,0...x%-Satz, die sowas tatsächlich vlt. bräuchten, kann man das tatsächlich auch noch lösen.

Innovationshemmend dürfte indes ein Standard sein, der sowas fordern würde - es bläht die Entwicklung unangemessen auf, ohne wirklichen Nutzen zu generieren u. bezahlen will das schlussendlich auch niemand. Welcher Hersteller würde auf einen Standard setzen, dessen Neukreation erstmal einen Anpassung des gesamten Standards nötig werden lassen würde? Der Markterfolg wäre ziemlich bei Null u in jedem anderen Fall, wäre das Gerät nicht standardkonform - auch blöd.

jm2c - Matter ist für mich einer von vielen Hypes u. vlt. eine Todgeburt - Google ist bekannt dafür, dass sie auch mal schnell was einstampfen, wenn sie darauf keine Lust mehr haben u. Amazon/Apple sind auch nicht gerade für wohltätige Offenheit berühmt.

KNX kenne ich fast seit der Geburt als Instabus u. begleitet mich nun >3 Jahrzehnte. Rate mal, welchem Standard ich eher vertraue, wenn ich mein Geld für Produkte ausgeben muss? Zumal ich in der Zeit schon viele "Innovationen" als EIB-Konkurrenz kommen u. gehen gesehen habe u. was KNX dato also bewiesen hat, sind "Smarthome-Innovationen" (es fehlt ein Kotz-Smiley) erst noch in der Pflicht.

[GLT]

WIR (=Amazon, Google und Co, genauer gesagt die CSA) entscheiden

So stellt es sich, zumindest für mich, ebenfalls dar.

[KNXLump]

Zitat von KNXLump Beitrag anzeigen
non-standard or manufacturer specific items such as clusters, commands, events, attributes and attribute data fields. These items MAY be supported on a certified product.


Mit anderen Worten (mal eine andere Interpretation):

WIR (=Amazon, Google und Co, genauer gesagt die CSA) entscheiden, ob ein neues Gerät mit innovativen Neuerungen (was vielleicht attraktiver ist als die herstellereigenen) letztendlich eine Zertifizierung erhält oder nicht. WIR entscheiden, ob es neue Geräteklassen gibt und ob diese in Konkurrenz zum eigenen Portfolio auftauchen. WIR entscheiden, ob es sich lohnt, für einen kleinen Hersteller von toller Hardware aber noch ohne passender Geräteklasse eine neue zu eröffnen oder nicht.

Also Du musst dann schon mal in den Standard schauen, um zu erfahren was MAY genau bedeutet:

Kap. 1.5 Conformance Levels:

"MAY - A key word that indicates flexibility of choice with no implied preference."

Dazu passendes Beispiel:

Kap. 1.3 Definitions:
...
Node - An addressable entity which supports the Matter protocol stack and (once Commissioned) has its own Operational Node ID and Node Operational credentials. A Device MAY host multiple Nodes.
...

Du wirst mir sicherlich zustimmen, dass das Wort MAY hier nicht von Google oder Apple oder sonstwem abhängt.

Im Falle meines obigen Zitats:

"...These items MAY be supported on a certified product. "

Bedeutet das eben das genaue Gegenteil: dass die Zertifizierung nicht durch die Unterstützung einer proprietären Vendor Erweiterung erlischt oder unmöglich gemacht wird.

[KNXLump]

Zur Klarstellung.
jeder moderne KNX Teilnehmer hat eine individuelle Seriennummer, ähnlich MAC.

Eine Seriennummer hat solange nichts mit einer MAC Adresse in einem IP Netz zu tun, solange es keinen Reverse Lookup im Protokoll wie z.B. bei ARP gibt, der von der Seriennummer auf die Physikalische Adresse schließen lässt. Bei IPv6 wird die MAC adresse quasi automatisch Teil der IP-Adresse eines Interfaces. Wie ist das bei KNX ? Wozu wird die SN hier benötigt ?