Ich habe schon vor längerer Zeit von Z2M auf ZHA umgestellt, glaube mich aber erinnern zu können, dass man bei Z"M analog zu ZHA die Geräte und deren Entitäten frei umbenennen kann.
BTW: Bei mir mit ZHA kam die Warnung nicht und ich habe auch Namen, die mit dem Gerätenamen beginnen.
Jeder hat ja eine andere Ordnung bei der Namensgebung aber ich denke mal viele Benutzer setzen den Gerätenamen ja so das man direkt weiß um welches Gerät es sich handelt. Wenn ich jetzt eine Zigbee Steckdose nun mal “ZigbeeSteckdose_1Etage_Wohnzimmer_Standleuchte” als Gerät so benenne warum soll ich mir dann noch einen anderen Namen zusätzlich ausdenken. Für mich wird das so absolut unübersichtlich. Eine Umstellung hatte ich auch schon mal überlegt aber mich da noch nicht eingearbeitet.
So, die Shelly-Fehlermeldungen sind weg.
Man muss alle Shelly’s unter Advanced Developer Settings / CoIoT auf HA-IP:5683 stellen und
nach dem Speichern einmal rebooten und dann in HA neu laden
(den Reboot hatte ich vorhin vergessen 
).
Jetzt besteht nur noch das Problem mit den zwei FRITZ!-Geräten, da hoffe ich mal auf die
nächste HA-Version 2023.8.1 (wahrscheinlich morgen oder übermorgen).
Das ist übrigens die Fehlermeldung dazu:
Moin,
gestern das Update von HA auf : " HA 2023.8.0 Supervisor 2023.07.1 Operating System 10.3 Frontend 20230802.0 - latest " gemacht. HA läuft bei mir auf einem NUK .
Nach einem Neustart meldet sich Z2M mit der Nachricht:
" Erkannte MQTT-Entitäten mit einem Namen, der dem Gerätenamen entspricht …
Dies funktioniert nicht mehr in Version 2024.2.0. Bitte behebe dies vor dem Upgrade.
Einige MQTT-Entitäten haben einen Entitätsnamen, der dem Gerätenamen entspricht. Dies ist nicht zu erwarten. Als Work-Around wird der Entitätsname auf „null“ gesetzt, um einen doppelten Namen zu vermeiden. Bitte informiere den Betreuer der Softwareanwendung, die die betroffenen Entitäten bereitstellt, um dieses Problem zu beheben. "
Liste der betroffenen Entitäten:"
dann kommen meine 20 Geräte.
Meine Namen bestanden bis jetzt aus z.b.: Zig Testdevice , daraus macht HA dann z.b. switch.zig_test_device usw.
Bis jetzt dachte ich es liegt an meinem Namen also das Gerät mal umbenannt in ZigTestdevice , bringt aber genau " 0 ".
Verstehe ich hier was falsch bzw. kann man den Fehler gar nicht beheben bis es ein Z2M update gibt ?
Ich setze gerade bei mir alles neu auf und möchte nicht schon wieder die Zigbee Integration wechseln.
Hab Deinen Post mal hierher verschoben und schau mal einen Post weiter oben! 
@monstergubl schau dir einfach Post #44 an, dann siehst du, dass es ein “Fehler” ist.
danke für den Hinweis, hätte in der Nachricht irgendwo ein “Normale User können die Nachricht ignorieren” gestanden, dann wären hier ein paar Posts weniger 
Nachtrag:
Moin, kann ich bestätigen bei mir “steht” die Hälfte meiner Automatisationen da Fritz nicht mehr funktioniert und ich sehr viel da drüber integriert habe.
Es ist unglaublich, auf was für eine Baustelle ich mich eingelassen habe oder einfach HA 
by HarryP: Zusammenführung Doppelpost.
Ich habe auch “gelernt” bei HA lieber nicht immer gleich auf den Update-Button zu klicken, wenn ein Core-Update ansteht
Oder mindestens noch vorher ein Fullbackup erzeugen, dass man wieder zurück kann.
Bei den vielen Problemen und recht kurzfristigen Updates nach der "0"er-Version frage ich mich, was testen eigentlich die Beta-Tester in den 10 Tagen vor dem Release. 
Bei mir funktionierte der Fritz Repeater nicht mehr. Da beim Repeater ein Firmware-Update Anstand habe ich das Mal durchgeführt. Jetzt ist der Repeater auch in HA wieder da. Evtl. hilft ja auch nur ein Neustart des Repeater oder der FritzBox.
Gute Idee, funktioniert bei meinen beider FRITZ!-Geräten leider nicht.
Im Ereignisprotokoll des Repeaters tauch die Verbindung zu HA auf, aber die Initialisierung in HA kann nicht erfolgreich abgeschlossen werden.
Komisch ist nur, das meine anderen Repeater und CLIENT-F!B problemlos funktionieren, nur ein Repeater und ein Powerliner haben die Probleme.
@psyganja
Guckst Du hier:
der Link wurde in #43 schon mal gepostet!
es war Post #44
Außerdem ist die Antwort immer 42…
Mittlerweile melden sich bei mir doch 2 Shelly 1 mit Temparatur-Addon wegen der ColoT peer Einstellungen.
Habe wie in der Beschreinung 192.168.1.130:5683 angegben (IP & Port) und die Shellys re-bootet, aber der Fehler kommt wieder
… und anschließend den Shelly neu laden, dann sollte der Fehler weg sein.
habe ich verpennt, aber ein Reboot von HA sollte es dann ja auch tun - oder
Ja klar, aber wie gesagt einfach den Shelly über die 3-Punkte neu laden reicht.
