Adjust code design more towards HA standards #56
Conversation
…HA standards (WIP)
| sensor_name, friendly_name, val, unit_name, device_class | ||
| ) | ||
| # legacy support / prevent breaking changes (will not directly work this way because keys changed) | ||
| # return f"sensor.sonnenbatterie_{self.coordinator.serial}_{self.entity_description.key}" |
There was a problem hiding this comment.
Siehe _atttr_has_entity_name weiter oben ...
Wenn geänderte Key-Namen unumgänglich sind, dann müssten wir da zumindest eine Liste mitliefern. Sonst denken die Leute nach dem Update ihre Integration ist kaputt.
There was a problem hiding this comment.
Wie gesagt sind sie nicht unumgänglich, aber es wäre halt besser wenn sie einheitlicher benannt werden.
Wir können auch weiterhin die alten nehmen, dann muss ich die halt wieder alle umbenennen (in der Entity Liste und in den translations).
There was a problem hiding this comment.
Naja, ich gehe halt davon aus, dass es Leute gibt, die bereits die alte Integration benutzen und ggf. darauf aufbauend auch Automatisierungen gebastelt haben. Da aus meiner Erfahrung niemand das Readme liest, sondern einfach nur auf Update geklickt wird und der nächste Weg dann sofort der zum Issue-Tracker ist, weil die Anzeige/Automatisierung/was-auch-sonst-immer nicht geht, denke ich es wäre netter gegenüber den Nutzern, nach Möglichkeit die alten Entity-Bezeichnungen zu behalten. Wenn es triftige technische Gründe für eine Änderung gibt, dann ist das wieder was anderes.
Letztlich ist das aber nicht meine Entscheidung, das darf der Chef machen @weltmeyer ;)
There was a problem hiding this comment.
Was wir auch machen könnten, wäre, für jeden Sensor ein weiteres Attribut legacy_key hinzuzufügen, das dann den alten key beinhalten würde, um den unique_key zu generieren um die existierenden entities zu behalten. Dadurch könnten wir intern weiterhin die neuen keys verwenden, die auch für die entity ids benutzt werden würden.
Und wer weiß, vielleicht gibt es ja irgendwann die Möglichkeit, unique keys zu migrieren.
Das würde eben ein paar zusätzliche Zeilen in der SENSORS Liste brauchen.
There was a problem hiding this comment.
Und wer weiß, vielleicht gibt es ja irgendwann die Möglichkeit, unique keys zu migrieren. Das würde eben ein paar zusätzliche Zeilen in der
SENSORSListe brauchen.
Wenn ich mir https://community.home-assistant.io/t/replace-entities-and-keep-history-breaking-change-starting-ha-core-2023-4/639465 und https://community.home-assistant.io/t/how-to-replace-entity-in-energy-dashboard-by-new-one-without-losing-history/545933 so durchlese, dann fürchte ich, dass genau das jetzt nicht mehr geht. Für mich liest sich das so, als wären die alten unique_ids in Stein gemeisselt.
There was a problem hiding this comment.
Aktuell spinnt meine Sonnenbatterie(Komme weder zuverlässig auf die API noch auf das lokale Dashboard... -.-),
Möglicherweise in letzter Zeit das LAN Kabel bewegt?
Meine Sonnenbatterie ging von Anfang an auch nur sehr unzuverlässig und langsam, bis ich irgendwann rausgefunden hab, dass die Techniker das Kabel ziemlich in die Kabelkanäle gequetscht haben und es dadurch kaputt gegangen ist. Mein Kabeltester hat wie wild durcheinander geblinkt anstatt in der Reihenfolge 1-8 😆
There was a problem hiding this comment.
Hmm also wenn durch das update als solches die Entity-IDs nicht verändert werden und die namen sich nur durch eine neu-installation verändern, dann würde ich das okay finden
Gut, dann werde ich das mit den legacy_keys machen.
There was a problem hiding this comment.
@RustyDust hast du die Möglichkeit den PR als Update zu testen?
Wenn ich wieder Land sehe :/ Ich wollte das schon längst gemacht haben, aber die letzten Wochen waren die Hölle auf Arbeit ... ich schau wie ich dazu komme und melde mich.
There was a problem hiding this comment.
Okay, kein Problem. Ich glaube es wäre sowieso besser, wenn ich zuerst die legacy_keys mache, damit du dann das "finale" Update testen kannst.
There was a problem hiding this comment.
Habe die Option hinzugefügt und bis auf diese Sensoren wird nun alles übernommen, inklusive Namen und Entity IDs.
|
Yay, ich bin endlich mal dazu gekommen, mit den PR anzusehen. Rein funktional sieht alles gut aus, allerdings zeigt mir HomeAssistant nach dem Update auf die PR-Version ein paar fehlende Entitäten an: 
Das ist halt insofern problematisch, als dass beim Nutzer keine Info erfolgt und gerade bei den Werten für "Production (in/out)" und "Operating Mode" die Wahrscheinlichkeit hoch ist, dass da Automatisierungen dranhängen. Kriegt man das noch irgendwie mit Alias geregelt? |
Was genau sollte Production in/out eigentlich anzeigen? Habe das nicht im Code gefunden und macht doch eigentlich kein Sinn, denn Produktion geht ja nur in eine Richtung (von den Solarzellen zum Netz, und nicht vom Netz zu den Solarzellen). Der Operating Mode Sensor wurde aus den beiden Sensoren zusammengeführt. In der Oberfläche wird immer der Text angezeigt. Für Automatisierungen kann man den Numerischen Zustand nehmen (wird in Entwicklerwerkzeuge angezeigt). Deshalb gibt es den "(Text)" Sensor nicht mehr. Das der Temperatur-Sensor nicht mehr geht ist etwas komisch, denn dort habe ich als legacy_key "tmax" angegeben, was doch eigentlich der key vom alten Sensor sein sollte: |
Wollte mal irgendwer haben, weil die Produktion tatsächlich manchmal negative Werte anzeigt (im kleinen ein- bis zweistelligen Watt-Bereich). Finde nur gerade den Screenshot nicht. Kann man denke ich vernachlässigen, hast Recht.
Ok. Sollten da Issues reinkommen können wir die ja an dich leiten ;)
Der Alias geht ja auch ;) Wobei dieser Status - zumindest bei meiner SonnenBatterie - schon immer Quatsch war. Aktuell behauptet sie zum Beispiel, die Batterie hatte 0,31 °C. Also entweder war da schon immer was falsch oder da stimmt was mit der Berechnung nicht. |
Sadly because the keys changed this is a breaking change.
When an user updates, all his old entities will be unavailable and new ones will be generated and he can manually change the entity ids to the old ones if he wants to.
If we want to keep using the old unique ids to prevent this breaking change we would need to look for the old entity keys and use them instead. This isn't really hard but needs some work and we would remain using these (in my opinion) badly named keys that would also be used in the entity id then like before.