Randanmerkung
Wenn ich zum Beispiel einen PV Wechselrichter migriert habe - also altes Gerät gelöscht und neues mit API und gleichem Topic angelegt - dann erscheint das Gerät doppelt. Das zweite Gerät ist jedoch nicht erreichbar. Ich konnte das lösen, indem ich die gesamte Integration aus HACS gelöscht habe und nach einem Neustart alles neu eingerichtet habe.
(Bild 1-4) Ich konnte es jetzt noch einmal nachstellen. Wenn ich die Gerätegruppe nachträglich auf genau den gleichen Namen wie vorher umbenenne, dann wird bei einer Aktualisierung das Einzelgerät doppelt angelegt. (siehe Anhang) Dabei sind die Entitäten des 2. Gerätes dann nicht verfügbar. Gleichzeitig sind beim aktiven Gerät alle historischen Daten weg und werden bei den inaktiven Entitäten abgebildet.
Einzige Lösung für mich derzeit...beim neu Einrichten nicht den gleichen Namen vergeben?! Was meinst du?
Edit (Bild 5): Ich habe jetzt einmal den Growatt WR neu eingerichtet und er wird korrekt angezeigt und die Entitäten behalten Ihre historischen Werte. Wenn ich nun den Namen der Gerätegruppe auf einen anderen ändere wird mir das Gerät erneut doppelt angelegt. Es hat also irrelevant ob der Name gleich war oder nicht. Jede Namenänderung legt dann dieses Duplikat an. Es muss also Irgendwo im Einrichtungsprozess ein Problem geben.
Kann ich bestätigen.
Es ist so, dass, wenn du einen Integrationseintrag anlegst, automatisch im HA ein Device/Gerät angelegt wird.
Das Device hat als Identifikator config_entry.title --> Also der Name, den du dem Gerät während der Konfiguration des, z.B. Wechselrichter, gibst (ohne Änderung wäre das z.B. openWB-pv-5)
Wenn du den Namen änderst (openWB-pv-5-andererName), legt HA ein neues Gerät an, wiederum mit config_entry.title, sodass das Gerät dann openWB-pv-5-andererName heißt. Trotzdem bleibt openWB-pv-5 stehen, allerdings alles auf unavailable.
Weiterhin gilt für die Namenskonvention der Entitäten
self._attr_unique_id = slugify( config_entry.title _ description.name)
Damit ist der Name des Geräts in der ID der Entität verbaut. Das ist Standard, der üblicherweise bei HA-Integrationen genutzt wird. Wenn du jetzt die Device-ID änderst, und die Integration neu lädst, werden die Entitäts-IDs zumeist angepasst. Oder der User muss das manuell machen (wenn er das will) oder hat wieder zurückändern (wenn er das nicht will).
Das ist also leider so und ich werde das so beibehalten. Geräte mit falschem Namen und nicht verfügbaren Entitäten kannst du ja auf inaktiv setzen.
TLDR: Wenn man die Historie behalten will, muss der API und der MQTT-Präfix gleich bleiben und man darf auch das Gerät nicht umbenennen.
a4320909533 hat geschrieben: Mi Dez 17, 2025 11:09 am
Kann ich bestätigen.
Es ist so, dass, wenn du einen Integrationseintrag anlegst, automatisch im HA ein Device/Gerät angelegt wird.
Das Device hat als Identifikator config_entry.title --> Also der Name, den du dem Gerät während der Konfiguration des, z.B. Wechselrichter, gibst (ohne Änderung wäre das z.B. openWB-pv-5)
Wenn du den Namen änderst (openWB-pv-5-andererName), legt HA ein neues Gerät an, wiederum mit config_entry.title, sodass das Gerät dann openWB-pv-5-andererName heißt. Trotzdem bleibt openWB-pv-5 stehen, allerdings alles auf unavailable.
Weiterhin gilt für die Namenskonvention der Entitäten
self._attr_unique_id = slugify( config_entry.title _ description.name)
Damit ist der Name des Geräts in der ID der Entität verbaut. Das ist Standard, der üblicherweise bei HA-Integrationen genutzt wird. Wenn du jetzt die Device-ID änderst, und die Integration neu lädst, werden die Entitäts-IDs zumeist angepasst. Oder der User muss das manuell machen (wenn er das will) oder hat wieder zurückändern (wenn er das nicht will).
Das ist also leider so und ich werde das so beibehalten. Geräte mit falschem Namen und nicht verfügbaren Entitäten kannst du ja auf inaktiv setzen.
TLDR: Wenn man die Historie behalten will, muss der API und der MQTT-Präfix gleich bleiben und man darf auch das Gerät nicht umbenennen.
Andreas
Alles klar - danke für die Info. Ich benenne es einfach nicht mehr um.
Etwas fehlt mir jedoch:
Ursprünglich hatte ich neben PV, Speicher etc noch eine Gerät mit Entitäten welches openWB Controller hieß. Das konnte ich beim Migrieren jedoch nicht auswählen?! Ich meine unter der MQTT Einrichtung nannte sich er Punkt "Wallbox". Hat sich der Punkt erledigt?
Gibt es für dieses "Gerät" keine Anbindung zur API? Ich habe es jetzt noch einmal Testweise über MQTT angebunden. Hier gibt es z.B. Werte wie den Gesamt PV Ertrag.
Ansonsten scheint auf den ersten Blick die Steuerung der openWB wieder schön zu funktionieren. Danke dafür
Dateianhänge
Bildschirmfoto 2025-12-17 um 15.07.33.jpg (359.25 KiB) 140 mal betrachtet
Wallbox
OpenWB Series2 standard+ – 11 kW via Standalone
Ansonsten scheint auf den ersten Blick die Steuerung der openWB wieder schön zu funktionieren. Danke dafür
Danke dafür. Freut mich, dass sich die Mühe gelohnt hat.
Gibt es für dieses "Gerät" keine Anbindung zur API? Ich habe es jetzt noch einmal Testweise über MQTT angebunden. Hier gibt es z.B. Werte wie den Gesamt PV Ertrag.
Sorry, hab ich vergessen zu beantworten: Leider nein. Ich vermisse das auch, da ich mir da Zusammenfassungsentitäten spare. Mein "Workaround" wird weiterhin die MQTT-Integrationsvariante dafür sein.
a4320909533 hat geschrieben: Mi Dez 17, 2025 2:21 pm
Gibt es für dieses "Gerät" keine Anbindung zur API? Ich habe es jetzt noch einmal Testweise über MQTT angebunden. Hier gibt es z.B. Werte wie den Gesamt PV Ertrag.
Sorry, hab ich vergessen zu beantworten: Leider nein. Ich vermisse das auch, da ich mir da Zusammenfassungsentitäten spare. Mein "Workaround" wird weiterhin die MQTT-Integrationsvariante dafür sein.
=> d.h. Mqtt-Integration und Api-Integration können parallel betrieben werden?
Dann würde ich mir nämlich auch die fehlenden Controller-Entitäten per mqtt-Integration holen...
a4320909533 hat geschrieben: Mi Dez 17, 2025 2:21 pm
Gibt es für dieses "Gerät" keine Anbindung zur API? Ich habe es jetzt noch einmal Testweise über MQTT angebunden. Hier gibt es z.B. Werte wie den Gesamt PV Ertrag.
Sorry, hab ich vergessen zu beantworten: Leider nein. Ich vermisse das auch, da ich mir da Zusammenfassungsentitäten spare. Mein "Workaround" wird weiterhin die MQTT-Integrationsvariante dafür sein.
=> d.h. Mqtt-Integration und Api-Integration können parallel betrieben werden?
Dann würde ich mir nämlich auch die fehlenden Controller-Entitäten per mqtt-Integration holen...
Ja, geht beides gleichzeitig.
Wallbox
OpenWB Series2 standard+ – 11 kW via Standalone
=> d.h. Mqtt-Integration und Api-Integration können parallel betrieben werden?
Dann würde ich mir nämlich auch die fehlenden Controller-Entitäten per mqtt-Integration holen...
Jawohl. Nur nicht fürs gleiche Device. Aber ich denke, dass das selbstverständlich ist.
Da ja die meisten von euch am Schalten aus HA interessiert sind - was ja beim Controller eh nicht geht, da nix zu schalten ist - müsste das okay sein. Man hat zwar immernoch zwei Integrationstechnologien... Aber so ist es halt
a4320909533 hat geschrieben: Mi Dez 17, 2025 2:21 pm
Sorry, hab ich vergessen zu beantworten: Leider nein. Ich vermisse das auch, da ich mir da Zusammenfassungsentitäten spare. Mein "Workaround" wird weiterhin die MQTT-Integrationsvariante dafür sein.
Hmmm. Ohne jetzt den HA zu genau zu kennen, geht es da nicht um das energy-Dashboard? Die paar Topics aus den Summenzähkern von Produktion, Speichern und dem EVU-Punkt getrennt nach Vorzeichen wäre doch eigentlich sehr achön, wenn man die in die http-Variante noch dazu packt, oder? Zumal das Dashboard ja ein zentrales Ding des HA ist und die http-simpleAPI ja hauptsächlich auf den HA zielt. Vielleicht macht @openWB ja da nochwas.
openWB-pro+, openWB-Buchse, E3/DC S10pro+19.5kWh, 30kWp Ost-Süd, Model 3 und Ion
Wallbox
PV-Anlage (7,1 kW):
Zähler & Speicher (12 kWh):
