Wer nutzt denn eigentlich alles Home Assistant?

[droid]

Wie gesagt ich bin völliger HA Anfänger. Deswegen die Frage gibt es irgendwelche Einschränkungen im Gegensatz zum Openhab KNX Addon? Bisher sehe ich kaum noch einen Grund warum ich zu OH3 gehen sollte.

[meti]

Zur Zeit 350 HA knx user laut analytics.home-assistant.io (das ist afaik opt-in). Ist das das "minimal"?
Wieviele sind es denn bei OpenHAB?

Ich würd eher das nehmen das dir besser gefällt - optisch und in der Benutzung. Kannst ja beide mal ausprobieren - musst ja nicht das ganze Knx System gleich integrieren, reicht ja mal ein Licht und einen Thermostat für nen Einblick.

[droid]

Hallo zusammen.

Ist denn hier jemand von Openhab 2 auf den HA gewechselt?

Ich überlege gerade ob ich nun auf OH3 oder den HA wechseln soll. In beiden Fällen hätte ich Initialen Aufwand.

HA ist ja das weit größere Projekt (auch alleine die Github Activity ist viel größer). Aber die minimale KNX Community innerhalb von HA macht mir Sorgen. Was würdet ihr sagen? Ist die Sorge unbegründet?

VG Denis

[meti]

Oh cool, den kannte ich noch gar nicht!

Falls du Fragen hast wegen den Platformen und Typen kann ich den xknx discord server empfehlen 😉

[Harv]

ja kann ich bei Gelegenheit mal hochladen. Ich hatte mir ein paar Skripte angeschaut uA auch das von dir verlinkte und ein anderes in Ruby (https://github.com/laurent-martin/ets-to-homeassistant)

Ein halbwegsschlaues Mapping von meinen ETS Namen -> Type und Funktion in HA wird jetzt spannender, die Namesvergebung ist Gott sei dank recht Stringent

[meti]

Harv gäbe bestimmt einige Leute die sich drüber freuen würden 😉
Wenns eh in Python ist könntest du auch xknx importieren und zb. https://github.com/XKNX/xknx/blob/a9...pt/dpt.py#L120 benutzen um zB. die DPT nummer zu parsen. Aus dem DPT-Objekt kannst du dann zB. `.value_type` verwenden. Oder gleich die Nummer als String. Und wenn es nicht parsebar ist musst du dirs manuell anschauen.
Allerdings sind die genauen DPT Nummern in ETS Projekten nicht immer perfekt vergeben...

Hast du dir das mal angeschaut: https://github.com/JensVanhooydonck/...ation-importer
Es benutzt aber noch die alte xknx config. Der Ansatz mit den Functions ist aber cool - vorallem für ETS-Inside Nutzer.

[Harv]

Danke!

Ist in Python geschrieben, aber nicht auf GitHub, eigentlich auch wirklich nur ein billiges Skript dass die zugrundeliegenden Infos aus der XML zieht. Glaube aber mittlerweile der der weg über ETS->CSV export und dann Weiterverarbeitung ist einfacher

[meti]

Naja, dieses Jahr hab ich (nach aktueller Zählung) 504 knx-entities mit zugehörigen 938 automations geschafft. Da ich über 3000 GA habe, hab ich noch einiges vor mir

Ich meinte mit Objekten eigentlich Wohnobjekte. Also Häuser, Wohnungen. Aber es sieht so aus als ob es nur dein eigenes wäre - und jetzt weiß ich auch nicht wofür du diesen Aufwand treibst 🙃

Der einzige Weg da programmatisch weiterzukommen ist, die alte knx-entitiy zu löschen (dann wird eine neue erzeugt) oder die alte passend umzubenennen, das muss ich noch ausprobieren.

Wie gesagt bringt umbenennen in der yaml config nix. Allerdings kann man die entity_registry programmatisch ändern - das ist nur n json file - sollte kein Hexenwerk sein. Musst halt aufpassen dass du keine entity_id doppelt vergibts.

Und hier verstehe ich ehrlich gesagt nicht, warum das nicht als Problem gesehen wird? Die entitiy_id ist der Schlüssel für alle Referenzen. (...) und ich kann sie in der KNX-Integration nicht konfigurieren?
(...) Ich verstehe zwar nicht, warum die knx-Integration so tickt, wie sie es tut

Die configuration.yaml wird von HA nicht verändert - read only. Sobald eine Entity eine `unique_id` hat bekommt sie einen Eintrag in der entity_registry. Ihre `entity_id` ist dann darin gespeichert - und quasi reserviert. Übers UI kann man die dann ändern wenn das notwendig sein sollte.
Das ist das Design von HA, das hat nix mit der KNX-Integration per se zu tun. `unique_id` und damit den Eintrag in der entity_registry unterstützt die knx integration aber erst seit kurzem - daher vermutlich die Verwirrung. Vorher wurde die Entity quasi bei jedem Neustart völlig neu angelegt. (Hätte man einen "Name:" aber doppelt vergeben, hätte eine Entity davon auch ein "_2" suffix bekommen.)

[meti]

So habe mir ein kleines Skript geschrieben, dass die *.knxproj ausliest, gibt es irgendwo eine Auflistung über die "types" die HomeAssistant unterstützt, also "light", "tempreture" usw.? damit man sich ein Mapping Name->Type bauen kann?

Cool! Worin hast du das geschrieben? Hast es irgendwo öffentlich?

[crazyfx]

https://www.home-assistant.io/integrations/knx/

[Harv]

So habe mir ein kleines Skript geschrieben, dass die *.knxproj ausliest, gibt es irgendwo eine Auflistung über die "types" die HomeAssistant unterstützt, also "light", "tempreture" usw.? damit man sich ein Mapping Name->Type bauen kann?

[mumpf]

Hi,

da muss ich erstmal nachlesen und das Ganze sacken lassen. Für interessierte - Ich hab noch das hier gefunden: https://www.home-assistant.io/blog/2...uture-of-yaml/

Für wieviele Objekte im Jahr machst du HA-configs?

Naja, dieses Jahr hab ich (nach aktueller Zählung) 504 knx-entities mit zugehörigen 938 automations geschafft. Da ich über 3000 GA habe, hab ich noch einiges vor mir .

Keine Ahnung was du da generierst aber so lange sich die unique_id GAs https://www.home-assistant.io/integr...icate-entities nicht ändern solltest du garnichts löschen müssen.

Das Problem hat nichts mit der Generierung zu tun, sondern mit der Behandlung der entity-id durch die knx integration. Wie Du oben bestätigst, kann man die entity_id nicht selber vergeben. Die wird initial aus dem   name:  erzeugt und kann danach nicht mehr mit config-Mitteln geändert werden. Nur über das UI. Der einzige Weg da programmatisch weiterzukommen ist, die alte knx-entitiy zu löschen (dann wird eine neue erzeugt) oder die alte passend umzubenennen, das muss ich noch ausprobieren.

Es wird auch nix automatisch umbenannt,

Wie ich schon oben schrieb, da hab ich ein Gegenbeispiel. Nicht durch die knx-integration, aber durch HA selbst, in meinem Fall wohl die template plattform. Der template-Sensor sollte leas_strom_pc heißen, hieß aber leas_strom_pc_2, wurde also umbenannt. Die Ursache für die Umbenennung war allerdings die fehlende Möglichkeit, mit config-Mitteln eine entity_id zu ändern (von leas_strom_pc auf leas_strom_pc_kw).

nur eben nicht über die KNX yaml config weil das eben nicht die entity_id ist die da konfiguriert wird

Und hier verstehe ich ehrlich gesagt nicht, warum das nicht als Problem gesehen wird? Die entitiy_id ist der Schlüssel für alle Referenzen. Template-Sensoren, Automations, Lovelace selbst, alle arbeiten mit der entity_id, und ich kann sie in der KNX-Integration nicht konfigurieren?

Wie gesagt, Du hast mir sehr geholfen, ich verstehe jetzt zumindest besser, was da abgeht und kann hoffentlich darauf reagieren. Ich verstehe zwar nicht, warum die knx-Integration so tickt, wie sie es tut, aber damit muss ich wohl leben.

Gruß, Waldemar

[meti]

Hab ich da was verpasst? Ich hab seit März jetzt HA nicht so intensiv verfolgt, aber damals ging noch alles über yaml. Und es scheint jetzt auch noch zu funktionieren.

Kommt auf die Integrationen an. Viele sind schon auf config flow gewechselt und haben noch support für yaml, manche wechseln komplett auf config flow und andere bleiben bei yaml. Kommt halt drauf an.
Schau dir mal zb. ADR 10 an https://github.com/home-assistant/ar...ree/master/adr Evtl. gibts auch irgendwo nen Blog-post. Und in den Release-Notes siehst du immer welche Integrationen config flow implementiert haben bzw. yaml deprecaten.

ein eigenes python-script, dass mittels jinga2 alle config-files als packages generiert.

Wenn du mit Packages https://www.home-assistant.io/docs/c...tion/packages/ meinst, dann sind die, so wie ich ADR 7 verstehe, deprecated. Frag aber vielleicht mal im HA Discord nach.
Für wieviele Objekte im Jahr machst du HA-configs?

falls ihr in diese Richtung forscht (alles nur noch über das UI), dann sag mir bitte Bescheid

Eher nicht. Und falls doch käme sicher eine Art batch-ingress dazu um die Erstprovisionierung möglichst einfach zu gestalten. GAs einzeln in ein Textfeld eintragen hat keinen Sinn, darüber sind sich alle einig.

Kann ich eigentlich in der knx-config neben name: zusätzlich auch entitiy-id setzen?

Nein.

Alternativ muss ich bei meiner Generierung alle knx-entities aus der entity_registry rauslöschen.

Keine Ahnung was du da generierst aber so lange sich die unique_id GAs https://www.home-assistant.io/integr...icate-entities nicht ändern solltest du garnichts löschen müssen.

Ich will einfach den Zustand haben, dass ich meine config aus git rausziehe, generiere und dann soll es zuverlässig laufen.

¯\_(ツ)_/¯ stell halt die entity_registry ins git.

Erstmal stundenlang schauen, ob irgendetwas automatisch umbenannt wurde, weil das System (egal wer jetzt quasi "Schuld" ist) der Meinung ist, eine entity gibt es schon, weil in einer registry nachgeschaut wird, die für den User nicht transparent ist, finde ich suboptimal.

Du kannst doch eh alle entity_ids einsehen https://my.home-assistant.io/redirect/entities/
Es wird auch nix automatisch umbenannt, im Gegenteil - die entity_id bleibt bis du sie manuell umbenennst oder löscht - nur eben nicht über die KNX yaml config weil das eben nicht die entity_id ist die da konfiguriert wird - siehe oben.

[mumpf]

Hallo Matthias,

Deine ausführliche Erklärung hat wenigstens etwas Licht in das Ganze gebracht. Ich habe die entity-id vom Sensor mal am UI geändert, jetzt muss ich prüfen, ob das alles läuft. Hier komme ich jetzt auf jeden Fall weiter und bin sensibilisiert.

Aber ein Satz Deiner Antwort hat mich aufhorchen lassen (bzw. ich bin richtig erschrocken):

Das hat den Hintergrund das die yaml-Konfiguration ja eigentlich nicht mehr stand der Dinge ist, sondern eigentlich alles über das UI (config_flow) konfiguriert werden sollte.

Hab ich da was verpasst? Ich hab seit März jetzt HA nicht so intensiv verfolgt, aber damals ging noch alles über yaml. Und es scheint jetzt auch noch zu funktionieren. Was ist denn da geplant? Falls Du einen Link hast, würde es mich freuen (ich suche natürlich auch gleich). Warum mich das kalt erwischt und wirklich erschreckt: Ich mache GAR NICHTS an der Konfiguration im UI. Ich lasse alles generieren. Ich nutze lovelace_gen für das UI und ein eigenes python-script, dass mittels jinga2 alle config-files als packages generiert. Das meiste kommt natürlich von knx, aber nach und nach kommen auch weitere Sachen dazu... Derzeit hab ich nur meinen Fernseher und die FritzBoxTools als integration über das UI konfiguriert, alles andere ist gescriptet. Und die beiden sollten auch noch ins yaml wandern...

Mich beruhigt ja die Aussage, dass das mit knx nicht geht, aber falls ihr in diese Richtung forscht (alles nur noch über das UI), dann sag mir bitte Bescheid. Denn dann ist HA wohl nicht das Richtige für mich... ich will nicht für über 3000 GA alles im UI zusammenklicken . Für mich war es ein absoluter Pluspunkt, nicht alles über ein UI zusammenklicken zu müssen. Das es jetzt in die andere Richtung gehen soll, finde ich bedauerlich.

Und noch was: Kann ich eigentlich in der knx-config neben   name:  zusätzlich auch   entitiy-id  setzen? Alternativ muss ich bei meiner Generierung alle knx-entities aus der entity_registry rauslöschen. Ich will einfach den Zustand haben, dass ich meine config aus git rausziehe, generiere und dann soll es zuverlässig laufen. Erstmal stundenlang schauen, ob irgendetwas automatisch umbenannt wurde, weil das System (egal wer jetzt quasi "Schuld" ist) der Meinung ist, eine entity gibt es schon, weil in einer registry nachgeschaut wird, die für den User nicht transparent ist, finde ich suboptimal. Und irgendwelche Nacharbeiten am UI liegen auch nicht im Fokus meiner Interessenschwerpunkte... Zumindest muss ich noch irgendwelche Checks einbauen, um die Umbenennungen vorher rauszufinden. Da ist noch viel Arbeit!

Gruß, Waldemar

[meti]

Der Name in der config spielt jetzt keine Rolle mehr. Der ist nur für die erstmalige Vergabe der entity_id und des friendly_name und nachher zum wiederfinden in der Config. Man kann hier also auch ruhig Leerzeichen, Sonderzeichen und Groß-Kleinschreibung verwenden. Theoretisch kann man ihn auch ganz weglassen.

Der Sensor hat vorher "leas_strom_pc" geheißen und hat die entity_id "leas_strom_pc" bekommen. Wenn du ihn in der config umbenennst hat er immer noch die entity_id "leas_strom_pc". Das musst du im UI ändern - auf den Sensor klicken und oben am Zahnrad.

Wie sollte es sich denn verhalten, wenn ich entity_id umbenenne? Es war ja insofern kein einfaches umbenennen, ich wollte ja in allen automations das "leas_strom_pc" lassen, nur eben über einen template-Sensor umrechnen. Ich habe also ein knx-entity umbenannt und gleichzeitig ein template-sensor mit dem alten knx-Namen erzeugt.

Es ist weit weniger kompliziert als du denkst 😉 Wenn du es umbenennst (in der UI) wird nur die eine entity_id umbenannt und die Automations funktionieren dann halt nicht. Dann kannst du in aller Ruhe ein Template mit der entity_id erstellen. Oder eine andere Entity statt der so benennen.

Ich werde mal schauen, ob ich das reproduzieren kann. Die Frage ist aber immer noch: Ist es ein Fehler der knx-integration oder vom HA-Framework. Oder anders gefragt, wer liest/schreibt die .storage/core.entitiy_registry?

Die Integrations schreiben da rein. Das hat den Hintergrund das die yaml-Konfiguration ja eigentlich nicht mehr stand der Dinge ist, sondern eigentlich alles über das UI (config_flow) konfiguriert werden sollte. Das macht aber für manche Ausnahmen keinen Sinn (zb. Templates, MQTT, oder eben KNX) weil es da kein Discovery oder so gibt und es nicht wirklich einfacher ist die Konfiguration in Browser-Textfelder zu machen anstatt in zB. nem VS-Code mit auto-completion Addon für HA config.
Es ist also weder dort noch da ein Fehler. Es ist nur irgendwie schlecht dokumentiert / kommuniziert was der `name:` Eintrag in der Config genau macht.

Das klappt auch ohne Klammern, da | stärker bindet als *, aber ich werde sicherheitshalber auch die Klammern setzen. Dass der Wert 0 ist, liegt daran, dass es kein "leas_strom_pc_kw" gibt.

Achso ja. Sicherheitshalber brauchst es nicht machen, es geht oder es geht nicht. Hab das verwechselt - würdest man zb. `(... | float * 1000 | round(0))` machen würde nur 1000 gerundet und man hätte das selbe Ergebnis wie ohne round...