KNX - was geht wirklich?

[bluegaspode]

Ja meine Leuchten real und virtualisiert sind in der Anzahl aber >100 und sauber in der ETS definiert. Das tippe ich da jetzt nicht in solch ein YAML und einen automatischen Converter der mir das aus dem ETS Projekt XML umbaut habe ich nicht. Mein GA Modell und das Namensschema der GA Bezeichnung tät das aber hergeben.

Aber egal welchen Visu-Server du jetzt nutzt.
Du musst jedem Visu-Server 100x beibringen, wie deine GAs sich auf Funktionen mappen.
Das ist doch überall gleichartig aufwändig?

Im HA: musst du 100x eine Light-Entität erstellen. Das geht (bei Light-Entitäten) sogar per GUI, dass du die GAs verknüpft. Willste bei 100 Lichtern aber nicht machen ohne eine Sehnenscheidenentzündig zu bekommen. Also gehst du lieber in die YAML, erstellst ein einzelnes Licht und kopierst es 100x. Weil du eine gute GA Struktur hast, kannst du jede Kopie schnell anpassen. Und weil du ChatGPT hast, geht es noch einfacher (selbst bei doofer GA Struktur), da gibst du einfach ChatGPT den Export deines GA Schemas und lässt dir die YAML generieren.

Dann: erstellt du dir die Visus wie du lustig bist, suchst dir einmal dein Lieblings-Licht Widget raus und packst es hin wo du willst. Es funktioniert in der Regel Out-Of-The Box für die meisten Standardlichter (siehe Screenshot weiter oben sogar richtig cool für LEDs).

Im Timberwolf: klickst du dich auch 100x durch und musst das Licht-Widget mit den GAs verknüpfen, bis deine Finger wund sind?
Und wenn dem Timberwolf Licht Widget irgendeine Sonderfunktion deines Lichts fehlt (das war ja oben deine Kritik an den HA - OutOfTheBoxWidget), bist du auch erstmal aufgeschmissen und machst Workarounds. Die kannste im Homeassistant aber auch machen

In Edomi: ohje - bis da 100x Lichtbuttons angelegt und kopiert sind -> auch 'ne Heidenarbeit. Viel Copy-Paste und dann je Licht mehrere GAs überall einzeln und ohne Fehler zuordnen.


Mein Fazit wäre also: wenn du 100 Lichter hast, ist es in jeder Lösung am Anfang 'ne ordentliche Fleißarbeit?
Überall musst du "GAs mappen", um sie sinnvoll in Visus nutzen zu können.


Ich bin gerade erst in meinen persönlichen Anfangstagen von Homeassistant.
Habe meine PV gut über Modbus integrieren können (im Default dabei), habe meine Energiezähler der aufm Smartmeter sitzt per MQTT integriert (im Default dabei).
Konnte alle MQTT Daten und mir wichtigen Datenpunkte von Homeassistant an die Influx weiterleiten (im Default dabei, ich muss mich jetzt an neue Pfade gewöhnen).
Musste jetzt dem "Energiewidget" (im Default dabei) nur sagen, welches Quellen es benutzen soll und bekomme out-of-the box hübsche Grafiken.

Oh KNX-Frevel: mein Sohn hat eine Ikea Zigbee Leuchte und Nanoleafs. Konnte ich ihm nicht ausreden, KNX hat ihn da nicht überzeugt
Die waren bisher nie eingebunden. Jetzt sind sie es, das war zusammengeklickt und Zack war es da.

Hat Homeassistant mir meine Sonos automatisch erkannt. JA!
Auf einmal habe ich Sonos in meiner Visu drin, die Arbeit habe ich mir mit den älteren Visus (CometVisu, Timberwolf, Edomi) NIEEEE gemacht. Allein wie viele Wochenenden auch aufgewändet hätte, um ein Cover anzuzeigen.

Hat Homeassistant meine älteren Squeezeboxen erkannt? JAAAa ... na wie geil ist das denn. Jetzt habe ich neben den Sonos Geräten auch meine Logitech Squeezeboxen in der Visu drin. Da gab es nichtmal integrationen in anderen Systemen.

Ich bin ebenso begeistert, dass alle Datenpunkte automatisch geloggt werden -> dass ist ähnlich gut wie im Timberwolf und in Edomi war es ein Krampf, ALLES zu loggen.

Ich bin auf meiner Reise noch nicht fertig, das Kapitel "Logiken" habe ich noch nicht aufgemacht, aber was ich bisher an Screenshots gesehen habe (oder "NodeRed" als Fallback) -> holla die Waldfee, da bekomme ich auch alles hin.

Ihr seht - ich bin positiv angetan. Mit ein paar Tagen rumspielen habe ich im Homeassistant schon mehr hinbekommen als je mit meinen Vorgänger-Servern.

[bluegaspode]

sind wohl die WLAN-Lampen-Benutzer die bessere Zielgruppe für HA.

Ich habe immer noch nicht verstanden, wo sich KNX-Lampen von WLAN-Lampen signifikant unterscheiden.
WLAN Lampen können in der Regel deutlich mehr als langweilige KNX-Lampen, was heißt, dass du da kaum in Limits läufst.

Deine gesuchte Lösung mit der Hühnerstallklappe ist doch jetzt auch nix exotisches.
Das was du da als UI und Logik hast, bauen die Homeassistant Jünger doch (von der abgebildeten Logik her) dreimal komplizierter für ihre Rasenmäher und Roombas.

Wenn du willst: bekommst du es hin (und musst dich einarbeiten und drauf einlassen, genauso wie bei jedem anderen System auch).
Und wenn du aus irgendeinem Grund eine Abneigung hast (so wirkt es), wirst du jedesmal einen neuen Grund finden, warum du es nicht magst (was ja voll OK ist, ich könnte auch über andere Systeme meckern, weil jedes System ja irgendwo Nachteile hat).

[henfri]

Super zusammengefasst!
Eine Ergänzung:

In Edomi: ohje - bis da 100x Lichtbuttons angelegt und kopiert sind -> auch 'ne Heidenarbeit. Viel Copy-Paste und dann je Licht mehrere GAs überall einzeln und ohne Fehler zuordnen.

Und wenn du die Männer siehst du dann komplett fertig hast, aber merkst, dass die Buttons bei den lichtern ein bisschen größer sein müssen, dann musst du meines Wissens alle 100 lichtbuttons manuell anpassen.
Bei home assistant geht das mit suchen und ersetzen oder mit chat gpt.
Dafür macht man sich allerdings die Finger mit yaml schmutzig.

Und wenn du aus irgendeinem Grund eine Abneigung hast (so wirkt es), wirst du jedesmal einen neuen Grund finden, warum du es nicht magst (was ja voll OK ist, ich könnte auch über andere Systeme meckern, weil jedes System ja irgendwo Nachteile hat).

Ich sehe das genauso. Du wirst nie mit home assistant warm werden.
Du solltest dir lieber was anderes suchen.

[gbglace]

Du musst jedem Visu-Server 100x beibringen, wie deine GAs sich auf Funktionen mappen.
Das ist doch überall gleichartig aufwändig?

Ja weil die ETS das noch nicht vernünftig beherrscht.

da gibst du einfach ChatGPT den Export deines GA Schemas und lässt dir die YAML generieren.

Ja das Ding als Werkzeug verwenden muss ich mir auch etwas mehr angewöhnen.

[Dampf]

Ja weil die ETS das noch nicht vernünftig beherrscht.

Also sollten wir über die ETS lästern 😁 Wenn es eine einfache Möglichkeit gäbe, hätte sie HA bestimmt längst umgesetzt .

[Springrbua]

Den Ansatz das ETS-Projektfile einzulesen schwups bekomme ich Entitäten und virtuelle Geräte angelegt die dann im HA Universum direkt verwendet werden können wäre das Ziel für eine smoothe KNX-Integration wie man das bei einigen anderen im Rahmen Autodetect kennt.

Wenn das die anderen wirklich können, bitte ich dich das hier aufzuzeigen und das meine ich jetzt nicht Sarkastisch. Es gibt da einiges an Diskussion, wie man die Einrichtung erleichtern (=UI) oder sogar automatisieren kann. Es gab bereits einige Vorschläge (u.a. auch von mir) wie es andere machen, allerdings stützen sich die u.A. auf eine fixe Projektstruktur. Gira scheint es ähnlich zu machen wie die UI in HA, indem einfach die Felder mit einer Auswahl an möglichen GAs angeboten wird.
Allerdings gilt zu beachten, dass eine UI am Ende nahezu immer langsamer als Text (also in dem Fall YAML) ist.
Ich selbst verstehe ehrlichgesagt immer noch nicht warum sich die Profis mit dem Drag And Drop der ETS zufrieden geben, das war mir bereits für mein kleines Haus-Projekt zu langsam. Da schreibe ich wirklich lieber die paar Zeilen YAML.

Das wesentliche Problem ist eben das die HA Vorlage was ein light ist einfach zu wenige Datenpunkttypen/Funktionen bereitstellt.

Da würde ich jetzt echt gerne Wissen, was speziell der Light-Entity noch fehlt, die kommt mir persönlich recht vollständig vor.

Und wie bereits gesagt wurde können Zusatzfunktionen auch als eigene Entity eingefügt werden, sind dann zwar nicht mit der Licht-Entity verbunden, in der ETS hängen sie aber auch nicht zusammen.

Die in Beitrag #53 angesprochenen (für mich und andere unnützen) Funktionen lassen sich nicht mal einfach standardmäßig "wegkonfigurieren".

Kannst du ja, musst halt etwas tiefer in YAML einsteigen. In einer (komplexen) Software hat man zwei Möglichkeiten:
- Man macht alle Einstellungen leicht zugänglich und verkompliziert dadurch die Standardverwendung oder
- Man reduziert die "normalen" Einstellungen auf ein Minimum und versteckt alles weitere
HA hat sich (zum Glück) für die zweite Möglichkeit entschieden, dass der Großteil der User mit der Default-Einstellung als Basis starten können.
Wem die Default-Einstellung nicht gefällt, der kann sie im YAML deaktivieren und das gewünschte reaktivieren.

Solange KNX in dem System der Exot ist

KNX ist international gesehen (leider) ein Exot. Nicht umsonst ist das größte Forum deutschsprachig und die meisten namenhaften Hersteller kommen aus (Zentral-)Europa.

sind wohl die WLAN-Lampen-Benutzer die bessere Zielgruppe für HA

Ich benutze keine WLAN-Lampen, sehe mich aber durchaus als Zielgruppe für HA.
Ich sehe das Problem daher ehrlich gesagt eher bei dir als bei HA aber wenn dir das System nicht zusagt, musst du es ja nicht verwenden.
Man kann es nicht allen Recht machen.

Also sollten wir über die ETS lästern

Da in ich sofort dabei

[mfd]

Ich habe immer noch nicht verstanden, wo sich KNX-Lampen von WLAN-Lampen signifikant unterscheiden.

KNX-Lampen oder auch KNX-Leuchten existieren IMO nicht. Das ist wohl der signifikanteste Unterschied.

Bei einem KNX-System verbindet man i.d.R. Sensorik und Aktorik miteinander über ein Buskabel. Bei sorgfältiger Abstimmung der Komponenten aufeinander läuft dieses System dann weitestgehend autark.
Lediglich für Zusatzfunktionen werden Logikmaschinen und ggf. Visualisierungen eingesetzt.
Ein Aktor steuert normalerweise deutlich mehr als nur eine Lampe/Leuchte, Rolladen etc. und übernimmt dabei noch zusätzliche Funktionen. Das KNX-System kann dadurch sparsamer sein (je Busgerät <= 0,125W im Betrieb), sofern es ordentlich geplant wird.

[bluegaspode]

Ja - das ist ja klar.
Wir haben ja aber aus der Perspektive des Visu-Servers geredet.

Und da ist eine Leuchte in der Regel ein irgendwo platzierter Button, der den Status wechseln kann und den Status überwachen kann.
Der Visu ist es dabei egal, ob es eine WLAN Leuchte mit dedizierter MQTT Schnittstelle ist, oder Signale an mehrere GAs geschickt werden.

Das Konzept "Leuchte" (für eine Visu) ist ja trotzdem valide, egal ob es später auf Schaltaktor, Dimmaktor oder LED-Controller geht.

Und genau das verlangt Homeassistant von dir, dass du die sehr generischen GAs abstrakt auf ein höheres Konzeptniveau wie "Leuchte", "Sensor", "Rolladen" hebst, als es derzeit von KNX / ETS vorgesehen ist.

Und in dem Moment, wo du es (einmalig) auf diese höhere abstrakte Konzept gemappt wird, wird dir eine Menge geschenkt (= lauter Elemente die Daten tracken und alles steuern können, beliebig in der Visu anordbar).

Und wenn du das Geschenk nicht magst / annehmen willst ist ja auch alles gut. Dann bauste dir halt ein eigenes Element in Homeassistant, musst dich dann natürlich (ähnlich wie beim Homeserver oder Edomi) halt ein bißchen mehr mit den Optionen beschäftigen.

[mfd]

Das Konzept "Leuchte" (für eine Visu) ist ja trotzdem valide, egal ob es später auf Schaltaktor, Dimmaktor oder LED-Controller geht.

Jein.
Bei KNX "gehört" ja seltenst ein Busgerät einer einzelnen "Funktionseinheit". Was gewinne ich dadurch, dass ich einen Präsenzmelder als "Sensor" definiere?
Der PM liefert im Idealfall für eine Logik die Information der Anwesenheit. Ggf. Für eine Beleuchtungssituation den Befehl wann mit welcher Helligkeit Licht erforderlich ist. Der Heizung einen Temperatur-Istwert usw.

[mfd]

In einer (komplexen) Software hat man zwei Möglichkeiten:
- Man macht alle Einstellungen leicht zugänglich und verkompliziert dadurch die Standardverwendung oder
- Man reduziert die "normalen" Einstellungen auf ein Minimum und versteckt alles weitere
HA hat sich (zum Glück) für die zweite Möglichkeit entschieden, dass der Großteil der User mit der Default-Einstellung als Basis starten können.

Denn Sinn dahinter verstehe ich nicht. Was ist so schwierig unwichtige oder "kritische" Funktionen die z.B. Internetzugang erfordern erst mit einem Haken im Backend aktivierbar zu machen.
Wenn die Default-Oberfläche das ist was der Großteil der Nutzer heute möchte bin ich hier wirklich falsch.
Ich gehe erst mal mein Haus auf der Karte suchen...

[henfri]

bin ich hier wirklich falsch

Ja, das haben dir jetzt schon mehrere mehrfach gesagt.
Gut, dass du das auch jetzt so siehst.

[mfd]

Dann bitte ich aber auch die hier versammelte Mannschaft in Zukunft alle Missionierungsversuche in den anderen Unterforen in Richtung HomeAssistant zu unterlassen!

[herr2d2]

Was ist so schwierig unwichtige oder "kritische" Funktionen die z.B. Internetzugang erfordern erst mit einem Haken im Backend aktivierbar zu mache.
….
Ich gehe erst mal mein Haus auf der Karte suchen...

Der Aufwand, unwichtige oder kritische Dinge nicht zu aktivieren, ist doch ziemlich gering. HA schlägt dir in der GUI vor, ein gefundenes System zu integrieren. Wenn du dies nicht möchtest, dann genügt ein Klick auf „ignorieren“ und schon belästigt dich HA mit dem entsprechenden Thema erstmal nicht mehr.

Auch die Karte kann man in wenigen Sekunden ausblenden und dafür vielleicht andere Dinge nach vorne holen.

In der dafür erforderlichen Zeit schaffe ich es nicht mal, einen Kaffee zu trinken.

[gbglace]

Bei KNX "gehört" ja seltenst ein Busgerät einer einzelnen "Funktionseinheit". Was gewinne ich dadurch, dass ich einen Präsenzmelder als "Sensor" definiere?

Ja ein PM ist gut ausgenutzt schon ein ganz spezielles KNX-Gerät. Bezogen auf die virtuelle Geräte-Schicht ist dann aber das ein oder andere KO Bestandteil eines solchen virtuellen Geräts, dadurch das dort eine GA dran verknüpft ist, welche ja eben eine Teilfunktion eines solchen virtuellen Gerätes repräsentiert.
Aber Am Ende muss ein physisches KNX Gerät, bzw. seine Kanäle gar nicht einem solchen virtuellen Gerät zugeordnet werden, sondern nur GAs.
Denn dies sind die Repräsentanzen der Funktionen.

Für ein Softwareupgrade der ETS, macht es aber dann schon Sinn, das die Hersteller in ihren Applikationen mehr Metadaten zu den KOs bereitstellen, um eben einfacher ganze solche virtuellen Geräte als ETS-Objekt mit einem Aktorkanal und Taster Kanal und PM Kanal und ggf noch weiteren Aktorkanälen zu verbinden und dann automatisch auch die passenden GAs sich finden.
Aber auch da werden die PM's die größte Herausforderung abbilden das zu automatisieren.

IM HA ist quasi immer nur eine Sammlung von Identifiern eines Datentelegramms egal auf welchem medium Bauteil eines virtuellen Gerätes. da ist man relativ schnell komplett losgelöst vom eigentlichen physischen Gerät (Shelly-aktor).

Denn Sinn dahinter verstehe ich nicht.

Typischer Aufbau schneller 80/20 Lösungen. Der YT influencer baut Dir nen Smarthome-Raum in 5 Minuten fertig. Und aus der IoT Welt kennt man es eben einschalten, mit Handy verbinden Wisch Wasch läuft.
Meta startet auch erstmal so. Basisfunktionen eines Gewerkes haben erstmal alle. aber jeder Hersteller hat noch ne Spezialität dabei, die aber noch nicht im Matter. Ist im KNX ja auch nicht viel anders. PMs vor MDT hatten AN/AUS Sperre/Zwangsführung, jetzt hast unterschiedlichste manuelle Beeinflussungsoptionen usw. Das passt erstmal alles nicht in ein einfaches schnelle Template, da muss man dann unter die Oberfläche einsteigen im HA. IM KNX muss man die verschiedenen Konzepte (Gira vs BJ vs MDT) auch erstmal lesen, verstehen, anwenden lernen.
Und manche Hersteller haben sowas immer noch nicht und dann muss externe Logiken bauen und für Tagesphasen nach dem EIN noch umständlich passende Dimmwerte hinterherfeuern.

Eine Vereinheitlichung solcher Semantiken abseits vom simplen AN/AUS sind die großen Herausforderungen für den KNX um im IoT Umfeld bestehen zu können und das die ETS weiterhin DAS Tool dafür bleibt.

[mfd]

Auch die Karte kann man in wenigen Sekunden ausblenden und dafür vielleicht andere Dinge nach vorne holen.

Ich werde es in einer ruhigen Minute mal ausprobieren.
Finde es aber trotzdem schade, dass solche Dinge wohl nicht von den Entwicklern berücksichtigt werden. Wenn ich das richtig verstehe muss man zunächst eine Default Config erstellen und darin alles einfügen was benötigt wird (außer map bspw.).