Nachträgliche Funktionseinschränkungen von Loxone - das betrifft ALLE Loxone-Kunden

[Jan W.]

Mal ehrlich, wer um Gotteswillen, baut bitte ein SmartHome bei seinen Kunden ein, welches weder zertifiziert geschweige denn zu 100% kompatibel zu anderen Herstellern ist?

Eine Zertifizierung hilft vielleicht, eine gute Kompatibilität mit einem Standard werbewirksam darzustellen und dem Käufer eine gewisse Sicherheit dafür zu geben, aber garantieren kann sie nicht, dass es mit jedem anderen Hersteller auch funktioniert. Auch wenn Loxone nicht für KNX zertifiziert ist, so werben sie mit der Schnittstelle und das nicht nur im Nebensatz, sondern sogar mit einem prämierten Referenzprojekt, siehe http://www.loxone.com/dede/smart-hom...brown-box.html Ganz unten bei "unsere Haustechnik:" steht "Sensorik auf KNX Basis - Tasten, Bewegungsmelder, Wetterstation". Sollen Partner nur noch Komponenten einbinden, die von Loxone kommen? Sind DMX Dimmer von anderen Herstellern damit auch gemeint? Es ist doch dreist von Kunden hier nicht die Dimmer von Loxone zu kaufen! Dann haben Kunden, die billige DMX Dimmer kaufen, auch selbst schuld, wenn solche Dimmer nach einem Update nicht mehr funktionieren. Nein, so kann man nicht argumentieren, auch wenn ich den eigentlichen Grund von Loxone für die Einführung der Beschränkung, nämlich den Ausschluss billiger I/O Module durchaus verstehen kann.

Ich gehe auch davon aus, dass bei Loxone z.B. die EIB-Schnittstelle verschwinden wird.

Vor einigen Jahren gab es noch gar kein Tree und die Alternative zu KNX waren altmodische "normale" Taster. Aus genau diesem Grund habe ich mich für KNX Taster entschieden. Eine Hausautomation, die KNX unterstützt, war damals für mich kaufentscheidend und die Anbindung funktionierte problemlos und das bis heute. Damals war mir allerdings gar nicht bewußt, dass die KNX Schnittstelle von Loxone nicht zertifiziert ist. Ich gehe davon aus, dass das alles so bleibt - sowohl die fehlende Zertifizierung, als auch die vorhandenen Mängel mit KNX, aber auch dass diese Schnittstelle nicht durch ein Update von Loxone bewusst beschnitten wird. Genau das ist bei Modbus passiert und daher der große Aufschrei auch von nicht betroffenen Kunden oder Partnern. Weil Loxone die Beschränkung so schlecht implementiert hat, kann ich die Argumentation mit der Stabilität nicht nachvollziehen. Hätte man nicht pauschal für alle Geräte das Abfrageintervall geändert sondern z.B. bei mehr als X Abfragen pro Sekunde eine Warnung und eine Verzögerung, dann könnte man das Argument ja nachvollziehen.

Funktionen die Mißbraucht werden müssen leider auch wieder reduziert werden, welches wir als Loxone schade finden, aber diese Schritte sind nötig um stabile Systeme bei den Kunden gewährleisten zu können.

Mit solche Statements (von Loxone bei Facebook) braucht sich Loxone nicht wundern, wenn bei neuen Installationen der MS nicht mehr in Frage kommt, weil die langfristige Planungssicherheit fehlt, dass eine getestete und funktionierende Lösung, die virtuelle Schnittstellen nutzt, zukünftig mit Updates versorgt werden kann. Wenn Du dann auch noch Partner und Kunden deswegen als blöd darstellst, dann kann man Loxone nur noch einsetzen, wenn Kunden wenig Ansprüche und Anforderungen haben und man zu 100% alles mit Loxone Komponenten abdecken kann.

Sollen Loxone Partner jetzt wirklich ihren (zukünftigen) Kunden sagen, dass nur noch Tree Taster mit einem Einheitsdesign für Alle in Frage kommen? Oder doch lieber nur herkömmliche Taster nehmen? Von einer KNX Anbindung an eine bestimmte vom Kunden vorgegebene oder geplante Anlage oder KNX Sensoren / -Taster sollte der Partner nach Deiner Meinung auch lieber die Finger lassen und die dann gar nicht mehr einbinden? Soll Loxone das o.a. prämierte Referenzobjekt mit dem Hinweis auf Geschwätz von gestern und das es jetzt Tree gibt wieder löschen?

Was ist mit einer modernen Anlage bzw. einem Steuerungsmodul, welche(s) eine Anbindung per Modbus/TCP, TCP, UDP oder HTTP bereits im Standard mitbringt? Soll der Partner dem Kunden sagen, dass er lieber das veraltete Modell mit analogen oder digitalen Eingängen (wen es so etwas gibt) wählen soll, weil ansonsten eine Einbindung mit Loxone langfristig nicht gewährleistet werden kann? Oder lieber gar nicht einbinden, weil die Komponente nicht von Loxone kommt?

Jedoch war ich nicht so blöd und vertraue auf ein Netzwerk, dies kann schließlich auch ausfallen und dann?

Ja, ein Netzwerk kann ausfallen, aber es gibt diverse Möglichkeiten Redundanz einzubauen. Ich weiß nicht, ob man in Kollerschlag oder bei Dir hinter dem Mond lebt, aber bei mir im beruflichen Umfeld ist IoT / Industrie v4.0 bereits angekommen. Seit Jahren gehen alle Hersteller von Telefonanlagen auf IP und telefonieren ist für eine Firma schon ziemlich wichtig. Das gleiche passiert bei privaten Telefonanschlüssen auch - Stichwort "IP-basierter Telefonanschluss der Telekom. IP-basierte Lösungen für Haustechnik unter dem schwammigen Oberbegriff "IoT" kommen immer mehr und der Anteil wird in den nächsten Jahren noch deutlich wachsen. Egal, ob es eine Lüftungsanlage ist (Beispiel: Helios mit easyControls), eine Waschmaschine, PV-Steuerung oder ein anderes Gerät ist. Ich finde daher den eingeschlagenen Weg der Beschränkung von virtuellen Schnittstellen (Modbus/TCP ist auch IP-basierend) ziemlich kurzsichtig von Loxone. Eine Alternative wäre nach meiner Ansicht eine Lizenzierung virtueller Schnittstellen. Und die Gegenfrage musst Du Dir dann auch gefallen lassen: Wer ist so blöd und vertraut auf einen zentralen, nicht redundanten MS für die Steuerung wichtiger Komponenten wie Licht? - der kann auch ausfallen oder stehenbleiben weil z.B. die SD-Karte kaputt ist.

In dem Punkt der Nörgelei stimme ich Dir aber zu. Forderungen nach I/O Modulen für 1-Wire sind nach meiner Ansicht völlig unrealistisch und ebenso sinnlos, wie Androhung eines Wechsels oder die Forderung an Loxone, dass sie irgendeine Garantie für eine Schnittstelle geben sollen. Die Zukunft wird zeigen, ob Loxone den Weg weitergeht und als nächstes UDP, TCP und HTTP einschränkt, weil billige I/O Module auch diese Schnittstellen verwenden. Vielleicht kommt auch noch KNX, weil die Verkäufe bei Tree hinter den Erwartungen von Loxone liegen? Ändern kann ich es nicht, finde es aber Schade, wie Loxone sich durch eine ziemlich schlechte Strategie selbst auf das Abstellgleis schiebt.

Einen Ausweg sehe ich in einer Lizenzierung von offenen Schnittstellen und so etwas könnte nach meiner Ansicht gut funktionieren, wenn bestehende Anwender großzügig von Loxone behandelt werden, denn sie haben den MS ja vor der Einführung einer solchen Lizenz gekauft. Auf der anderen Seite könnte Loxone bei Neuinstallationen, die z.B. KNX verwenden, anteilig mitverdienen. Auf diese Weise würde Loxone nicht nur an eigenen proprietären Protokollen bzw. Modulen wie Tree und Air verdienen, sondern wäre in der Lage und hätte ein Interesse daran, weiterhin viele offene Schnittstellen anbieten und weiterentwickeln zu können.

[BSiege]

Einen Ausweg sehe ich in einer Lizenzierung von offenen Schnittstellen und so etwas könnte nach meiner Ansicht gut funktionieren, wenn bestehende Anwender großzügig von Loxone behandelt werden, denn sie haben den MS ja vor der Einführung einer solchen Lizenz gekauft. Auf der anderen Seite könnte Loxone bei Neuinstallationen, die z.B. KNX verwenden, anteilig mitverdienen. Auf diese Weise würde Loxone nicht nur an eigenen proprietären Protokollen bzw. Modulen wie Tree und Air verdienen, sondern wäre in der Lage und hätte ein Interesse daran, weiterhin viele offene Schnittstellen anbieten und weiterentwickeln zu können.

Das kann ich nicht im geringsten Nachvollziehen. In welchem Bereich der Technik funktioniert das noch? Alles dreht sich um offene Schnittstellen und Interoperabilität. Man hat ein Alleinstellungsmerkmal und probiert das so gut wie möglich zu Vermarkten. Bei Loxone offensichtlich die Visu und die Programmierunterstützung. Dafür ist man bereit zu zahlen.
Es ist ja kein Geheimnis, dass sich SmartHome am ehesten den Gesetzen der Unterhaltungselektronik unterordnen muss. Wenn man es etwas professioneller nimmt, vielleicht auch der ICT-Branche. Beide sind knallhart. Der Kunde lässt sich gerne Überzeugen. Vorschreiben lässt er sich aber gar nichts. Und Beschimpfen schon gar nicht.

[Jan W.]

@BSiege: Und wie sieht Dein Vorschlag aus? Das Vertriebsmodell bei Loxone hatte in der Vergangenheit funktioniert, solange viele Extensions mit jedem MS verkauft wurden. Die Entwicklung der kostenlosen Software und des Supports wurden damit querfinanziert. Wenn jemand nur einen MS kauft und den Rest mit Fremd-IOs dann kann ich verstehen, dass Loxone ein Problem bekommt. Ohne Grund hätte Loxone die Beschränkung sicherlich nicht implementiert.

In der Unterhaltungselektronik gibt es kaum Bedarf für Support und auch keine nennenswerten Updates. Wer braucht Support für einen Fernseher? Wenn Produkte übereilt auf den Markt geworfen werden, dann kann der Hersteller durch die Möglichkeit von nachträglichen "Updates" die Fehler kostengünstig beheben ohne Geräte austauschen zu müssen. Das ist nicht mit den Updates bei Loxone zu vergleichen, auch wenn in der letzten Zeit viele Features eher wg. neuer HW wie Tree und Air ergänzt wurden. Andere Geräte wie Spielekonsolen werden über die Spiele querfinanziert. Die HW ist günstig, aber der Hersteller verdient an jedem Spiel mit.

Im Bereich ICT, also z.B: einem Windows PC war es üblich, dass man für die Software z.B. Windows oder einem Anwendungsprogramm bezahlt hat und gerade der kostenintensive Support eben nicht kostenlos war und ist. Die Kostenkalkulation bei einem weltweit vertriebenen Betriebssystem sieht sicherlich auch anders aus, als bei dem MS. Der Hersteller der Hardware, z.B. eines PCs liefert nicht den kostenlosen Support für ein individuelles Anwenderproblem mit der Software. Nimmt man Smartphones oder Tablets, sind Software Updates kostenlos, aber werden üblicherweise nur wenige Jahre bereitgestellt. Gut, Apple liefert sein OS-X kostenlos, aber dafür verdient der Hersteller über AppStore an der Software indirekt mit.

[BSiege]

Ich habe keinen Vorschlag. Ich kann die auch nicht retten. Wie ich Sinclair, Atari und Commodore nicht retten konnte. Oder Nokia.

Und zum kostenlosen Support: Ich hatte drei oder vier Anfragen. Eine der Anfragen wurde annähernd brauchbar beantwortet. Beispiele:

• F: Frühling 14: Ich möchte LOXONE Komponenten bestellen, aber nicht über einen ungesicherten Webshop. Ist immer noch so. Habe halt per Mail bestellt.
• F: Sept 14: SIEMENS-KNX Schalter können nur "Ein" "Aus" wie wird so etwas eingebunden? A: Kein Produkt von uns. Lösung war natürlich trivial. Typisches können aber nicht wollen. Ich mache so etwas mittlerweile in 2-3 Minuten mit dem Screenshot einer möglichen Lösung im Forum.
• F: Juli 2014: Unterstützt die Enocean-Extension die Verschlüsselung? A: Ja, Wir unterstützen die Standard-Verschlüsselung. Was eine glatte Lüge war. Richtig ist: Keine Verschlüsselung. Habe ich natürlich erst nach dem Kauf herausgefunden. Während die eingesetzten ELTAKO-Aktoren das schon längstens beherrschten.

Deswegen muss man sich ja auch die guten Lösungen in einem Forum zusammensuchen. Ich habe mein Urteil schon vor zwei Jahren gemacht. Und bis jetzt habe ich mich leider nicht geirrt. Aber als early Adopter muss man sowas in Kauf nehmen. Investition gemacht und abgeschrieben. Angefixt und wenn etwas Überzeugenders kommt, wird es ausgetauscht. Das geht sicher noch ein paar Jahre. Vielleicht ist bis dann die LOXONE-Banane soweit gereift, dass sie eine zweite Chance kriegt.

[Gast]

Dazu kommt ja auch noch die einseitige Änderung der Partnerverträge bzw. deren Provisionen vor einem Monat. Wer bislang Loxone lediglich als Logikmaschine/Visu in KNX-Installationen verwendet hat, für den ist das Teil jetzt uninteressant, weil er die diktierten jährlichen Umsätze nie erreichen wird, um angemessene Provisionen für die immensen Supportleistungen zu erzielen.
Auch ich habe mich bereits vor 2 Jahren gegen Loxone-Komplettplanungen beim Kunden entschieden, weil ich kein gutes Bauchgefühl bzgl. der Investitionssicherheit hatte, das hat sich inzwischen ja wohl bewahrheitet. Die vielen privaten Enthusiasten, die viel Geld in ihre Installationen gesteckt haben, tun mir ehrlich leid, das ist eine Geschäftspolitik, welche völlig am Kunden vorbei geht.

[jensmh]

Ich verstehe das Loxone Gewinn erzielen muss. Die KNX Schnittstelle ist für mich die wichtigste - ich würde auch eine "KNX-Extension" bezahlen - 100 Euro rauf und runter sind nicht kriegsentscheidend bei den Investitionssummen.

In meiner Installation (Hardware von Elektro-Fachbetrieb verbaut, Programmierung von mir (als Dip.-Ing. E-Technik sicher nicht unqualifiziert) ist KNX für die Logik und die Visu zuständig, alles wichtige läuft einfach per KNX - eben weil ich keinen Vendor-Lock-In wollte und dem damals "Newcomer" Loxone nicht "lebenswichtige" Funktionen anvertrauen wollte.

Deshalb habe ich mir auch für viele 100 Euro die ETS Professional gekauft - damit ich flexibel bin. "Fertig" ist kein Zustand den ich jemals erreichen will.

Dann gibt es auch den Häuslebauer, der alles seinen Loxone-Partner machen lässt und selbst nicht anfangen wird zu programmieren, für den ist die Programmiersoftware egal.

Wenn ich Loxone Betriebswirtschaft beraten würde, könnte ich mir vorstellen, dass es einen

-Loxone Home Edition ohne KNX und andere Fremd-Schnittstellen

Loxone Professional mit voller KNX und ModBus Unterstützung

gibt.

Für die Progammiersoftware würde ich einen kleinen Betrag von 100-200 Euro nehmen, für Updates nach 2 Jahren eine Gebühr wie in der IT Welt üblich nehmen (so 10-20 Euro/Jahr), die dann auch den Zugang zu einer KnowledgeBase und Zugriff auf Betas beinhaltet.

So kann dann aus dem "MS Verkauft und kostet danach nur noch Geld" ein Dauer-Revenue-Stream gemacht werden.

Leistungen abzuschrauben um Support-Aufwände runter zu bringen und langsam aber sicher auf Vendor-Lock-In zu kommen ist m.E. der steinigere Weg der mehr Endkunden frustrieren wird - und enttäuschte Kunden sind die schlimmsten - sie erzählen es nämlich weiter und verhindern Neugeschäft.

Das mit den Editionen ist ja mal ne Klasse Idee!

[Gast]

Hoffentlich tragen die hier mitlesenden Loxone Leute diese wirklich guten Ideen auch an die richtige Adresse in ihrem Haus, damit die Entscheider darüber auch nachdenken können. Ein hochkarätiger kostenloser Ideenpool kann ja so verkehrt nicht sein...

Das würde Loxone für professionelle SIs auch wieder interessanter machen, denn die können Ihren Kunden guten Gewissens sicher nichts empfehlen, wenn sie von der Investitionssicherheit für den Kunden nicht überzeugt sind, geschweige denn selbst die entstehenden Wartungs-/Änderungskosten tragen wollen.

Das wäre auch eine Möglichkeit für Eure "Petitions-Idee" oder was ihr da vorhabt:
Solche konstruktiven Vorschläge unterbreiten mit der Bitte, dass die GFs sich das wenigstens anschauen, bessere Ideengeber als die Enthusiasten aus diesem Forum, die teilweise schon jahrelang mit dem System arbeiten, können sie ja eigentlich nicht kriegen...

[Benjamin Jobst]

Loxone ist ja offiziell sehr stolz auf ihre Preispolitik - lebenslang kostenlose Updates, kostenlose Programmiersoftware etc. Da kann ich mir schwer vorstellen, dass man stattdessen derart die Politik ändert und alles als "Abo-Modell" verkauft - auch wenn das heutzutage ja ganz beliebt ist.
Ich bin da auch eher vom alten Schlag und sage, was ich einmal gekauft habe, ist meins - ich hasse solche Wartungsverträge. Aber ich gebe zu, in manchen Fällen kommt man nicht drum rum - und das nicht nur, weil die Anbieter einem keine andere Wahl mehr lassen...

Der kostenlose Ideenpool ist wohl nicht erwünscht, sonst würde man nicht so mit dem Forum fremdeln... und wie viel man hier tatsächlich mitliest, bezweifle ich mittlerweile generell...

[Gast]

Heute per Mail an Loxone. Damit man nicht sagen kann, unsere (Firma) Probleme werden nicht eindeutig kommuniziert...

Da Du wohl Loxone "Partner" bist, gab es denn da für Euch eine konstruktive Antwort von Loxone?
Wenn ja, könntest Du etwas dazu berichten?

Danke

[Benjamin Jobst]

Ja, wir sind Partner, wenn auch aufgrund unserer Politik nur auf der unteren Umsatzschiene von Loxone...
Ich habe bisher einen Vorschlag zur telefonischen Klärung bekommen, terminlich wird das aber erst am Freitag sein, mal sehen, was da raus kommt.

Danke für die Zwischeninfo.

[tholle]

Bin gespannt...

[Benjamin Jobst]

So, kurz ein Update zum Telefonat am Freitag:
An sich war des Telefonat ruhig und sachlich, allerdings nur bedingt produktiv.
Die meisten meiner Anmerkungen wurden quasi zur Kenntnis genommen und einige Punkte an die Entwicklung weitergeleitet - was immer damit dann passiert.
Zu den einzelnen Punkten (so wie ich sie aufgefasst habe, ein Gesprächsprotokoll kann und will ich hier nicht liefern ;-)

1. Bei Modbus ist in den nächsten Config-Versionen keine Besserung in Sicht, die Abfragezeit wird bei 5s bleiben. Das wurde so beschlossen und das wird jetzt auch so durchgezogen. Dass es da Ärger gibt und wir im Zweifelsfall für entsprechend kritische Anwendungen eine andere Steuerung verwenden werden, ist dann eben so.

2. KNX ist nicht mehr im Fokus von Loxone, dafür gibt es ja jetzt Tree. Früher hat man sich auf KNX gestützt, als man aber festgestellt hat, dass KNX in vielen Dingen einfach unzureichend ist, hat man die Entwicklung auf Priorität Z herabgestuft. Es wird zwar hin und wieder etwas daran entwickelt, aber eben nichts nennenswertes. Unsere Wünsche bzgl. Kompatibilität mit den neuen, großen Bausteinen wurde fast stillschweigend zur Kenntnis genommen.

3. Am Thema mit den SD-Karten wird intensiv gearbeitet, das wird sich jetzt wohl nochmal deutlich verbessern.

4. Am Thema Sicherheit wurde auch einiges gearbeitet, der MS sollte jetzt bei DDoS bzw. SYNFlood nicht mehr komplett aussteigen, da wurde die Firewall überarbeitet. In-App-VPN wird wohl aufgrund der Art, wie die App aufgebaut ist (Kerberos) nicht möglich sein. Port 80 ist nur der Standardport, über den der MS kommuniziert, es wird ja empfohlen, auf einen hohen Port auszuweichen (siehe Doku Freigaben).

5. Das Thema Dokumentation ist zwar mittlerweile durch die neue Website überholt, eine Offline-Version bzw. eine Version für den Endkunden gibt es bisher aber ja immer noch nicht. Ich habe das Thema noch einmal angeregt. Lustigerweise ist die neue Website ja hauptsächlich für Endkunden ausgelegt, obwohl ja der Installateur der gewünschte Partner sein soll - dem wird aber nicht wirklich was brauchbares an die Hand gegeben...

6. PicoC läuft halt so irgendwie. Da der Code erst im MS kompiliert wird, ist eine Überprüfung bzw. Simulation in der Config wohl nicht ohne größeren Aufwand seitens Loxone machbar. Aber das wird einmal an die Entwicklung gegeben, ob sich da etwas machen lässt (z.B. ein Vorschlag von mir: Syntax-Überprüfung im Editor...)

7. Die Anwesenheitssimulation wird von den neuen Bausteinen unterstützt. Verblüffend, dass überhaupt der EIB-Dimmer die Simulation kann. Aber warum der EIB-Taster sie z.B. nicht beherrscht, ist auch nicht ganz klar. Das wird in der Entwicklung noch mal geprüft...

8. Die geforderten Aktionen der Schaltuhr, verschiedene "Auslöser" zu definieren, kann der Kunde ja über den Autopilot-Designer in der App gestalten. Das müssen/können wir als Programmierer dann eben nicht vorbereiten (schön bei einem Gebäude mit 10 Räumen, den Autopilot-Designer für jeden Raum einzeln durchzuziehen...). Aber vielleicht ist da ja etwas in der Entwicklung, man weiß es nicht...

HINWEIS: Das Telefonat mit Loxone wurde nicht explizit als vertraulich behandelt, deshalb sehe ich mich hier in der Lage, diese abgearbeiteten Punkte grob zusammenzufassen. Was ich hier geschrieben habe, ist nicht O-Ton Loxone sondern das, was ich aus dem Telefonat mitgenommen habe. Darauf möchte ich noch einmal explizit hinweisen.

[Muto]

Danke für deine Zusammenfassung. Hast du denn mal die Zukunft anderer Schnittstellen (vor allem http) angesprochen? Gab es hierzu bezüglich der Aufrechterhaltung der derzeitigen Spezifikation eine Aussage?

[Benjamin Jobst]

Nein, das habe ich nicht angesprochen, am Ende wurde unser Telefonat abrupt unterbrochen, weil irgendwie die Leitung zusammengebrochen ist. Deshalb haben wir es erst einmal dabei belassen...

[Squarry]

Dass Loxone ihr Tree als KNX-Ersatz sieht, hatte ich schon fast befürchtet. In Sachen KNX dürfte es somit nun tatsächlich eher düster aussehen. Ich hoffe das merken nun viele Installateure, welche heute noch auf KNX/Loxone-Mix setzen. Ich habe den Mix nun im Haus und werde mir wohl in Sachen Programmierung/weiterem Ausbau überlegen wie ich mein System möglichst zukunftssicher gestalten kann (künftig eher ohne Loxone). Für mich ist nun klar, dass ich Loxone niemandem mehr empfehlen werde.

[Benjamin Jobst]

Wie schon gesagt, meine Zusammenfassung entspricht meiner Auffassung, nicht der offiziellen Aussage des Loxone-Mitarbeiters.
Dass Loxone den Tree als KNX-Alternative eingeführt hat, ist aber ja offensichtlich. Diesen Schluss habe ich deshalb jetzt einfach mal so gezogen...

[Matti]

Sehe ich auch so... habe auch auf den Mix gesetzt, da mir das am besten erschien damals... Aber was da die letzten beiden Jahre passierte ist ein Dilemma. Schau mir gerade edomi an... Vielleicht kann man hier was draus machen, noch im Zusammenspiel mit Loxone wg. 1Wire und DMX sowie Modbus...

[Robert L.]

das mit dem TREE und KNX wird noch interessant, vor allem für die Partner:
die ja keine Produkte mehr mit loxone verbauen dürfen, von denen Loxone ein "ähnliches" im Sortiment hat
ob ein tree-taster und ein KNX taster jetzt "ähnlich" sind, ??