Wer nutzt denn eigentlich alles Home Assistant?

[mumpf]

Hmmm, irgendwas ist bei meiner Installation wohl schief!!!

Ich habe jetzt den Core aktualisiert und bekomme nun folgenden Update-Hinweis:

[B]Aktualisierung ausstehend 🎉[/B]

Home Assistant Core

Version
core-2021.6.4

Neueste Version
core-2021.3.4

Ich werde mal eine Neuinstallation machen und dann mein Backup einspielen... wollte sowieso mal üben, wie das geht und ob es problemlos klappt.

Gruß, Waldemar

[mumpf]

Hi,

das obige Problem hat sich erledigt, nachdem ich den Supervisor neu gestartet habe. Jetzt steht da korrekterweise core-2021.6.5... Tja, man lernt nie aus.

Gruß, Waldemar

[mumpf]

Hi,

ich versuche mal wieder, die Mysterien von HA zu ergründen bzw. zu verstehen, was da abgeht (nachdem ich erfolgreich auf die neuste Version updaten konnte).

Problem: Umbenennung von knx-entities. Ich hatte folgendes:

knx:
  sensor:
    - name: leas_strom_pc
      state_address: '4/3/43'
      sync_state: init
      type: 'current'

Hat auch funktioniert, aber ich brauche neuerdings im Haus vergleichbare Werte und habe das KO in KNX von Strom auf Leistung umgestellt. Dann wurde daraus:

knx:
  sensor:
    - name: leas_strom_pc
      state_address: '4/3/43'
      sync_state: init
      type: power_2byte

Das funktionierte erstmal, allerdings liefert das kW und andere Quellen liefern W, so dass ich alles auf W haben wollte. Also habe ich folgendes gemacht:

knx:
  sensor:
    - name: leas_strom_pc_kw
      state_address: '4/3/43'
      sync_state: init
      type: power_2byte

sensor:
  - platform: template
    sensors:
      leas_strom_pc:
        friendly_name: Strom Leas PC
        icon_template: "mdi:sine-wave"
        value_template: >-
          "{{ states('sensor.leas_strom_pc_kw') | float * 1000.0 }}"
        unit_of_measurement: W

Sprich: knx-entitiy umbenannt und ein template-Sensor mit dem alten Namen eingeführt und dort den Wert in Watt umgerechnet. Vorteil: In allen Visualisierungen sehen ich jetzt den neuen Wert in Watt - dachte ich. Aber in den Entwicklungswerkzeugen sehe ich:
HA-Entities.png
Der neue Name für das knx-entity wurde jetzt als friendly name verwendet und der neue template Sensor in ein leas_strom_pc_2 umbenannt. Und das wohlgemerkt beim Starten des Systems. Damit gehen natürlich dann keine Automations mehr (falscher Wertebereich). Die entity-ID wird doch an allen möglichen Stellen zur Referenzierung verwendet, wie kann man die dann beim Startup umbenennen?

Ich hab dann noch in .storage/core.entitiy_registry noch folgendes gefunden, das scheint der knx-Eintrag zu sein.

{
"entity_id": "sensor.leas_strom_pc",
"config_entry_id": null,
"device_id": null,
"area_id": null,
"unique_id": "4/3/43",
"platform": "knx",
"name": null,
"icon": null,
"disabled_by": null,
"capabilities": {},
"supported_features": 0,
"device_class": "power",
"unit_of_measurement": "kW",
"original_name": "leas_strom_pc_kw",
"original_icon": null
},

Das verstehe ich auch nicht. Wieso ist die GA die unique_id und nicht die entitiy_id? Wieso gibt es überhaupt noch eine unique_id zusätzlich zur entity_id?

Versteht das jemand und kann mich "erleuchten", wieso mit 2 Schlüsseln gearbeitet wird? Ist das nur bei KNX so oder ist das ein allgemeines HA-Problem?
Ich will es ja nur verstehen, um zukünftig irgendwelche Fehler zu vermeiden. Umbenennungen sind ja nicht unüblich und ich hab hier wirklich stundenlang gesucht, bevor ich auf die Idee kam, dass es an HA selbst liegen könnte...

Gruß, Waldemar

[meti]

Die entity_id kann man in der UI verändern. "leas_strom_pc" war schon besetzt, also hat das template _2 bekommen. Das kannst einfach zurückändern.
Die unique_id gibt es damit das alles möglich ist - ist kein Problem sondern ein Feature. Mit der aubique_id solltest du als user nix zu tun haben.

Das was man in knx entities als name konfiguriert ist eigentlich mittlerweile nur mehr für die Initialisierung des friendly_name und entity_id.

Und damit dein template auch einen Wert bekommt fehlt glaub ich ne Klammer um "... | float".

[mumpf]

Hi Matthias,

danke für die prompte Antwort.

"leas_strom_pc" war schon besetzt, also hat das template _2 bekommen. Das kannst einfach zurückändern.

Das geht gerade nicht, deswegen meine Frage. Wenn ich meine aktuelle (komplette) config durchsuche, gibt es nur das hier:

knx:
  sensor:
    - name: leas_strom_pc_kw
      state_address: '4/3/43'
      sync_state: init
      type: power_2byte

sensor:
  - platform: template
    sensors:
      leas_strom_pc:
        friendly_name: Strom Leas PC
        icon_template: "mdi:sine-wave"
        value_template: >-
          "{{ states('sensor.leas_strom_pc_kw') | float * 1000.0 }}"
        unit_of_measurement: W

Somit ist "leas_strom_pc" der Name vom template-Sensor und "leas_strom_pc_kw" der Name vom knx-Sensor. Aus Sicht der config gibt es überhaupt keinen Grund, ein leas_strom_pc_2 zu machen. Glaub mir, ich habe das Stundenlang probiert. Erst als ich in den hidden files (also .storage) gesucht habe (normalerweise sind diese Verzeichnisse von der Suche ausgeschlossen), habe ich noch den "sensor.leas_strom_pc" als knx-Sensor gefunden, der scheinbar von früher stammt. Das halte ich für falsch!

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.

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?

Und damit dein template auch einen Wert bekommt fehlt glaub ich ne Klammer um "... | float"

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.

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...

[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]

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]

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

[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?

[crazyfx]

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

[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?

[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.)

[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]

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.