KNX - was geht wirklich?

[Sven1973]

Ich verstehe die ganze Diskussion nicht so recht. Home Assistant ist, wie der name schon sagt, eine Haushaltshilfe. Und mein persönlicher Haushalt umfasst halt deutlich mehr als nur KNX. Ich habe in meinem NEubau KNX eingesetzt, weil das ganze system auch ohne Server und ohne Internet funktioniert. Zwischen Sensor und Aktor findet eine direkte kommunikation statt. Das ist für mich Ausfallsicherheit! Ich kann das ganze System wenn ich möchte auch per Visu-Server visualisieren.
Nun bringt aber fast jedes kleine Haushaltsgerät seine ganz eigene Kommunikatioin mit. möchte ich Die auch in die Visualisierung einbinden wird es mit der KNX-Visu schon schwierig oder aber ich benutze wieder Plugins die mir dies ermöglichen.

Die Frage ist also, und das kann nur jeder für sich allein beantworten, wo möchte ich mit der integration ansetzen KNX in ein "fremdes" System übersetzen oder ein "fremdes" System in KNX integrieren..?

Ohne Integration wird es nicht möglich sein... Daher sehe ich keines Variante als "besser" oder "schlechter" an. Beide Wege führen letz endlich zum Ziel.

Sven

[henfri]

Hallo,

Man hat nur jene Funktionen die der Visu-Knopfersteller da als Funktionen sich gedacht hat. Wenn Du nun eine Lampe / Aktor hast der eine Funktion mehr hat als was der Knopf da bietet dann hast zwar GA's und irgendwo Entitäten aber doch keine Entsprechung in dem "fixen" Gerätetemplate vom HA.

Ich verstehe die Sorge. Aber wie Tom gesagt hat, ist das nicht so.
Man kann eine "light" entität nutzen. Man kann aber auch eine DPT5-Entität erzeugen, die dann als Slider dargestellt werden kann (sicher auch als Anderes).

Ein Riesenvorteil ist halt, dass ich ganz fix auch verschiedene Visu-Elemente ausprobieren und vergleichen kann, die z.B. ein Licht oder einen RTR darstellen, da sie nur die climate oder light Entität (und nicht 10 GAs und 15 Visu-Elemente) brauchen.

Ich komme ja auch von KNX und von Smarthome-NG, wo ich auch ein Objekt pro (zwei) GAs hatte. Aber ich sehe wirklich fast ausschließlich Vorteile (wenn man den Phantomschmerz erst überwunden hat).

Gruß,
Hendrik

[gbglace]

Ein Riesenvorteil ist halt, dass ich ganz fix auch verschiedene Visu-Elemente ausprobieren und vergleichen kann,

Da sehe ich jetzt nicht den USP von HA, das kann ich auch mit verschiedenen anderen.

Und wenn ich den Visu thread so verfolge gibt es da auch immer bei den Visu Elementen so fragen was gehört denn da nun im yaml an den einen Punkt dran verknüpft das es dann so tut wie gewollt.

Also so toll und simple scheint es auch nicht alles zu sein das ich alles mögliche an Funktionsdatenpunkten irgendwie einem "virtuellen" Geräteknoten zuordne und dann ein Visu element welches drei der 15 möglichen Funktionen für das virtuelle Geräte Lampe abbilden kann dann auch automatisch sich zieht.

Das wesentliche Problem ist eben das die HA Vorlage was ein light ist einfach zu wenige Datenpunkttypen/Funktionen bereitstellt. Und man sich eben eigene Entitäten erstellen muss und dem virtuellen Gerät Lampe zuordnen muss. Dass das geht ist ja gut.
Aber bei vielem muss man es eben noch so tun, weil der geneigte HA Entwickler nur den teilweise begrenzten Funktionsumfang der IoT Welt wie Homekit kennt.

Und nix anderes ist der aktuelle Zustand der ETS Funktionen, da sind auch zu wenige Funktionen per Standard möglich und man muss sich da erst eigene "Funktionen"/virtuelle Geräte bauen mit effektiv mehr Funktionen also GAs.

Es kommt also immer darauf an welche Datenpunkte je Gerätetyp maximal im Template erdacht wurden. Und da sind die Leute die aus der IoT-Welt kommen in den klassischen KNX basierten Gewerken deutlich weniger detailliert unterwegs, als das was die KNX-Welt an den Geräteklassen zur Verfügung stellt und der KNX-Welt fehlt die Strukturebene "virtuelles Gerät" noch vollständig.

Und das ist es was eben KNX und HA noch nicht so flüssig macht wie anderes was an HA angebunden werden kann und eh aus der IoT Welt kommt.

Insofern ist HA toll und hat seine Daseinsberechtigung aber bevor ich mit meinem ganzen KNX-Universum da einsteige brauche ich mehr Vereinfachung, weil das derzeit alles zu sehr in manuelles "geyammel" münden würde und darauf habe ich persönlich nicht die Lust mir das anzutun.

Und den aktuelle Status kann da jetzt keiner ernsthaft als tiptop bezeichnen.

[henfri]

Ich bin kein Jünger und werde nicht versuchen, dich zu überzeugen.
In dem, was ich gesagt habe geht es mir nicht darum, ob HA gut oder schlecht ist, sondern darum, dass das Arbeiten auf einer höheren Ebene gut ist. Und ich finde gut, dass das andere Systeme auch so machen.

Dass im Forum viel YAML gepostet wird, liegt daran dass man damit schnell und sicher Informationen übertragen kann, die sonst viele Screenshots benötigen würden. Wenn ich nicht-Standard-Cards verwende, achte ich darauf, dass man sie per UI konfigurieren kann.

Also so toll und simple scheint es auch nicht alles zu sein das ich alles mögliche an Funktionsdatenpunkten irgendwie einem "virtuellen" Geräteknoten zuordne und dann ein Visu element welches drei der 15 möglichen Funktionen für das virtuelle Geräte Lampe abbilden kann dann auch automatisch sich zieht.

Nutzt du HA? Ich kann nicht nachvollziehen, was du meinst.

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

Was genau fehlt denn?

Und man sich eben eigene Entitäten erstellen muss und dem virtuellen Gerät Lampe zuordnen muss. Dass das geht ist ja gut.

Muss ich bisher nicht einmal. Wie gesagt: Ein Beispiel würde helfen.

Gruß,
Hendrik

[Tom Bombadil]

Da sehe ich jetzt nicht den USP von HA, das kann ich auch mit verschiedenen anderen.

Nun, soweit ich das verstanden habe, ist das hier KNXUF > Projektforen > Home Assistant.

Sofern Du bei 'verschiedenen anderen' eine für Dich bessere Lösung gefunden hast - Glückwunsch, und immer her damit, lass uns daran teilhaben. Danke!

/tom

p.s. / Nachtrag:

Aber bei vielem muss man es eben noch so tun, weil der geneigte HA Entwickler nur den teilweise begrenzten Funktionsumfang der IoT Welt wie Homekit kennt.

Es ist Dir aber schon klar, dass HA als OpenSource mittlerweile 21.000 'Contributors' aller Art hat, und damit das zweitgrößte Projekt auf Github ist (also: 21.000 gezählt auf HA Core, ohne die ganzen Entwickler auf HACS, mit privaten Repositories usw)? Hier auf geistig beschränkte 'HA Entwickler' zu verweisen, die 'nur' Homekit kennen, finde ich schon derb arrogant. 21.000 Volldeppen wahrscheinlich ...

[gbglace]

Die große Menge an Entwickler ist ja auch das was HA so interessant macht, bestreite ich ja auch gar nicht.
Aber im Vergleich der Einfachheit anderer Integrationen ist das mit KNX eben noch anders und wenn ich HA einsetzen will, dann messe ich HA eben daran wie gut das mit KNX funktioniert, das ist ja in etwas ziemlich der Kern der Überschrift dieses Threads.

Und das bei mir solch ein TWS werkelt ist vielen bekannt und im KNX tut er das was ich da so benötige und im Zusammenspiel mit anderen Systemen geht er mir da einfacher von der Hand. Aber den hier jetzt auszubreiten ist dann wahrlich der falsche Thread.


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.

Bis dahin muss noch was in der ETS und im HA passieren.

Das bisherige Vorgehen via YAML sehe ich dann erstmal als temporären Workaround und hoffe, dass das nicht mehr zu lange dauert.

Bis dahin bleibt HA für mich ein Zuspieler, wo ich halt Integrationen damit nutze, diese 1:1 direkt nach MQTT weiterreiche, um sie dann in meinem System zu verarbeiten, nicht schön aber für mich mit hoher KNX-Lastigkeit im Bestand eben das einfachere Verfahren.

Wer bei 0 startet kann auch mit dem aktuellen Stand der Dinge in HA starten.


Ansonsten ist das Konzept ein Gerät zu virtualisieren und die Datenpunkte/Entitäten aus verschiedenen Integrationen dazu zusammenzuführen der komplett richtige Ansatz und finde ich gut und fehlt noch im KNX/ETS.

Also fühlt euch mal nicht so auf den Schlips getreten.

[flashbang]

Man hat nur jene Funktionen die der Visu-Knopfersteller da als Funktionen sich gedacht hat. Wenn Du nun eine Lampe / Aktor hast der eine Funktion mehr hat als was der Knopf da bietet dann hast zwar GA's und irgendwo Entitäten aber doch keine Entsprechung in dem "fixen" Gerätetemplate vom HA.

Und du bist dir sicher, dass hier https://www.home-assistant.io/integrations/knx/#light nicht deine passende Leuchte dabei ist oder was ist dein Problem?

Ganz ehrlich erstell du mal in Edomi eine RGB Leuchte mit Visualisierung und dann sag mir wie lange du dafür benötigst.

In HA sind es folgende paar Zeilen und du hast die Leuchte definiert:

- name: "RGB Küche"
individual_colors:
red:
brightness_address: "1/2/61"
brightness_state_address: "12/3/72"
green:
brightness_address: "1/2/62"
brightness_state_address: "12/3/71"
blue:
brightness_address: "1/2/63"
brightness_state_address: "12/3/70"

In der Gui bei dem Leuchtentemplate musst du nur einen Datenpunkt "RGB Küche" angeben, wirklich, mehr nicht und du bekommst folgende Visu:
Screenshot 2025-02-11 211034.jpg
Einen Slider zum Dimmen
Einen Colorpicker
Du kannst dir zur Laufzeit deine Wunschfarben abspeichern ohne zusätzlicher Logik.


In Edomi hab ich mir eine Logik zum umrechnen von HSV nach RGB machen müssen:
Die Logik zum Abspeichern einer Wunschfarbe hab ich mir gar nicht erst angetan.Screenshot 2025-02-11 211916.jpg

Dann muss noch alles visualisieren, mit 11 Elemente, allein für den Dimmpart...
Screenshot 2025-02-11 212132.jpg

Habe eh nie den Sinn, hinter diesen "Männervisus" verstanden.
Dieser Zeitaufwand und alles pixelgenau definiert. Hast ein neues Handy und zack passt nix mehr.


Ich versteh dich/euch schon.
Es ist nicht einfach, die hart erarbeiteten Visus und die Logiken aufzugeben und auf ein neues System zu setzen.
Ich will keinen misionieren. Muss jeder für sich entscheiden ob er mit seinem Server zufrieden ist.
Für mich ist Edomi an seine Grenzen gekommen.
Es ist halt ein KNX Server. Ja dass kann er sehr gut, aber wenn es halt dann ums integrieren anderer Schnittstellen geht, wird es schwierig.
Musst schauen, dass du die richtige PHP Version hast sonst läuft der Baustein nicht. Dann musst u.U. in der Bedienungsanleitung lesen, was du sonst noch händisch per yum befehl installieren musst. Dann sind die Bausteine, im Downloadportal, auf einmal gelöscht wegen, ja weil halt...
Dann frägt man im Forum nach wer den Baustein "ausleihen" kann. Laut Lizenz dürfte man das gar nicht, vom weiterentwickeln ganz zu schweigen.

Hör mir auf, so ein Käse.


Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende

[henfri]

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.

Du hat das Problem noch nicht verstanden.
Die Information, die für HA benötigt wird, ist in der ETS nicht vorhanden: Nämlich welche GAs zu einem Licht gehören.
Es gibt da die Möglichkeit, in der ETS "Funktionen" zu nutzen, die ja genau dies machen: Aus vielen GAs ein Gerät. Dafür gibt es dann ein Skript, um das nach HA zu exportieren.
Aber ganz ehrlich: Da war ich manuell schneller.

Alternativ hatte ich mal mit meti durchdacht, wie man eine KNXPROD für HA machen kann (mit Hilfe der OpenKNX Tools). Aber auch da muss ich sagen, dass die Nachteile überwiegen. Man muss bei jedem neuen Gerät in HA (z.B. einem Lichtschalter in HA) eine neue KNXPROD erzeugen.

Das bisherige Vorgehen via YAML sehe ich dann erstmal als temporären Workaround und hoffe, dass das nicht mehr zu lange dauert.

Naja, es gibt ja ein UI, um die Entitäten zu erzeugen. Bisher aber nur für ausgewählte Typen. Aber auch da bin ich per YAML schneller.


Sobald man einmal eine light-entität erzeugt hat, ist halt das tolle, dass man auf alle Eigenschaften jedes light gleichermaßen zugreifen kann. Bei Smarthome-ng war ich nicht diszipliniert genug. Da war es dann bei dem einen eg.wohnzimmer.licht.farbtemperatur und bei dem anderen og.schlafzimmer.ct. Und bei Edomi (vermute ich) muss ich die richtige GA raussuchen - auch wenn sie per Namen in Edomi, HS und Co bekannt ist (in HA übrigens auch, per knxprod import) halte ich das nicht für einfacher.


Aber wie gesagt: Bin kein Missionar.

Gruß,
Hendrik

[Dampf]

Ich verstehe das Gejammer wegen dem bisl „soft YAMLing“ nicht. YAML ist in Bezug auf KNX Kram zusammenschreiben wirklich ne übersichtliche Sache. Und ich bin wirklich kein Freund von per Text programmieren.
Light Entitäten bis RGBCCT als Gerät kann man in HA in der UI zusammenklicken. Wie sich das mit den restlichen Geräten, die noch per YAML erstellt werden müssen, verträgt kann ich nicht sagen.
Und ist das Gerät erstmal erstellt, kann man es ihn HA nutzen wie den IoT Kram auch.

[gbglace]

Ganz ehrlich erstell du mal in Edomi eine RGB Leuchte mit Visualisierung und dann sag mir wie lange du dafür benötigst.

Ich habe EDOMI nie genutzt weil mir das auch zu umständlich war, gerade bis man da was als Knopf fertig gebaut hatte. Hatte EDOMI mal auf extra HW als auch im Container laufen.

Ich bin da halt absolut nicht derjenige der eine Visu mit dem letzten Pixel individualisieren möchte.

Insofern ist HA für EDOMI-Nutzer sicher auch eine Offenbarung an Einfachheit auch wenn ein anderer Ansatz.

In HA sind es folgende paar Zeilen und du hast die Leuchte definiert:

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.

[gbglace]

Die Information, die für HA benötigt wird, ist in der ETS nicht vorhanden: Nämlich welche GAs zu einem Licht gehören.

noch nicht standardisiert. Daher ja es fehlt derzeit noch auf beiden Seiten das mal zu realisieren.

Ich habe das schon sehr wohl verstanden.

Die ETS tut sich da halt sehr schwer Ihren Ansatz mit Funktionen mal in diese Richtung virtuelles Gerät dahingehend zu verbessern und brauchbar zu gestalten.

Aber die Macher der ETS haben es auch verstanden, sehen aber auf die Schnelle auch noch keinen Horizont das kurzfristig fertig zuhaben, leider. Ich empfehle die Stammtische für entsprechenden Austausch.

wie man eine KNXPROD für HA machen kann (mit Hilfe der OpenKNX Tools). Aber auch da muss ich sagen, dass die Nachteile überwiegen. Man muss bei jedem neuen Gerät in HA (z.B. einem Lichtschalter in HA) eine neue KNXPROD erzeugen.

Ja das wäre ein zu umständlicher Ansatz. Würde zwar das Thema ETS Dummy-Erschlagen aber viel mehr auch noch nicht.

ein konsequentes GA-Namensschema wäre einfacher. Halt eher der Ansatz wie onehome das ETS Projekt verdaut.

Sobald man einmal eine light-entität erzeugt hat, ist halt das tolle, dass man auf alle Eigenschaften jedes light gleichermaßen zugreifen kann.

Ja das kenne ich in meinem TWS auch so.

[henfri]

Ja das kenne ich in meinem TWS auch so.

Und wie erstellt man da ein Licht?
Und ist das besser? (warum?)

[gbglace]

Du kannst zu allen Objekten Tags vergeben und es werden zu zunehmend mehr Objektsystemen weitere Strukturbäume parallel angeboten, wenn man das nicht mit Tags machen möchte.

Will man irgendein Element verbinden stehen einem in dem Dispatchermodul alle Tags, alle GAs, alle technischen IDs, alle Namen, alle Ordner zur Verfügung tippst also in das Suchfeld irgendetwas ein, filtert er ab dem dritten Buchstaben über alle diese Merkmale die gesamte Objektliste und filtert auch direkt nach zumindest grob kompatiblen Datenformaten. Dabei findet er also auch wenn ein boolesches Objekt verbunden werden soll ein KNX-Byte Objekt, da er 0 als false und alles größer 0 als true interpretiert. Will man eine anderen Interpretation oder Mapping muss man wie anderen Systemen üblich erst eine Logik zwischen schalten.

Ob das zu verbindende KNX, MQTT publish /subcribe, Visu-Element, Http-API Element, Logik-Ein oder Ausgang ist ist egal, bzw. wird auch passend gefiltert, weil Eingang bzw Ausgang sich auch meist gegenseitig ausschließen.

Naja im vergleich zum reinen KNX ja ist es besser weil ich ja nicht nach Aktor 1.0.112 KO 24 suche sondern eben nach Lampe Wohnzimmer Decke Erker.

Wenn ich da also einen Knopf in der Visu anlege und die virtuelle Leuchte aus einem Spot an einem KNX-Aktor und einem HUE Spot besteht. Ist das da egal. An den Ausgang für das Bedienelement kommen da einfach beide Schalten-Objekte dran verbunden das eine aus dem KNX-Objektsystem und das aus dem API Objektsystem mit dem die HUE Bridge angesprochen wird. Einfach direkt ran keine Automation wegen Technologiemix.

Man verbindet noch jeden "Draht" einzeln. Also nicht Visu-Multifunktionswidget Lampe und dann sind da alle Objekte dran verbunden. Das ist da noch nicht realisiert. Aber der Workflow im UI geht schnell.

[Tom Bombadil]

Die ETS tut sich da halt sehr schwer Ihren Ansatz mit Funktionen mal in diese Richtung virtuelles Gerät dahingehend zu verbessern und brauchbar zu gestalten. Aber die Macher der ETS haben es auch verstanden, sehen aber auf die Schnelle auch noch keinen Horizont das kurzfristig fertig zuhaben, leider. Ich empfehle die Stammtische für entsprechenden Austausch.

Nun, das ist wie mit jeder 'Asssociation', die ich im Laufe des letzten halben Jahrhunderts kennenlernen durfte.
'Neu machen' - geht nicht, verlieren wir unser Geschäftsmodell. 'Anders machen' - vielleicht, dauert. 'Kann ich mich bei Ihnen kostenpflichtig zertifzieren lassen? - 'Passt Ihnen morgen früh um 7:30, der Einsatzwagen steht dann vor der Tür?'

Ernsthaft, Göran:

HA geht da einen anderen Ansatz. Die Entwickler sind eher Enthusiasten aus dem 'Mileu'. Alles Open-Source, jede Codezeile kann durch andere Ideen verbessert werden; notfalls durch eigenen Fork. Haben ihre eigenen Qualitätslevel für Integrationen (bronze, gold, silver). Kommen HACS-seitig (HACS ist nicht HA Core) mit dem Approval nicht mal hinterher, da zuviele Leute beitragen (ich häng da immer noch in queue # 283 oder so). Bieten eine kostenlose Integration für ein Exoten-System namens KNX an - das jeder Anwender aktiv verbessern kann, siehe oben. Die brauchen dafür nichtmal nen 'Stamm'Tisch. Und es wird immer noch rumgeheult ... Ich kapier's einfach nicht ...

/tom

[mfd]

Die brauchen dafür nichtmal nen 'Stamm'Tisch. Und es wird immer noch rumgeheult ... Ich kapier's einfach nicht ...

Vielleicht bräuchten die den doch...
Die in Beitrag #53 angesprochenen (für mich und andere unnützen) Funktionen lassen sich nicht mal einfach standardmäßig "wegkonfigurieren".
Das interessiert aber seit 2019 anscheinend keinen der Entwickler. Seltsame Prioritäten, wenn man nicht mal das Admin-Backend dahingehend in Ordnung bringt. Vielleicht ist ja die siebenhundertvierundzwanzigste Smart-Funzel eines unbekannten Herstellers wichtiger.

Solange KNX in dem System der Exot ist - den Eindruck hatte ich ja von Beginn an auch - sind wohl die WLAN-Lampen-Benutzer die bessere Zielgruppe für HA.