Have you looked in the Config > Entity Register?
You would need to stop Home Assistant first before editing the file if you go that way and be very careful not to break the JSON and then start Home Assistant again.
Yes I have and all looks ok there. It only seems to be the name the Integrations page displays.
I don’t know if it is because the GUI Integrations and Entity Registry came in when I was still relatively new to HA meaning everything changed when I had only just got comfortable with the ‘old’ way but I must admit to finding the GUI a little confusing.
That’s odd… normally I find editing them edits them in the integration as well.
You could remove the inter=gyration, restart HA and add the integration back again and restart HA again… It’s just odd some of these glitches at times.
I just removed the integration.
Restarted HA
Added the integration
and…
Exactly the same outcome. TV Room, not Sitting Room
And apart from that I am even more confused. Where did it get any of the names from? How did it know to name all my Sonos back to what they were? How did it know what Area to put them in???
Something is persisting even after removing Integrations…
I stopped HA
I changed ALL references of ‘TV Room’ to ’ Sitting Room’ in ALL files everywhere and still when I restart it insists on calling it TV Room.
Furthermore I decided to get with the programme and think about having my MQTT devices discovered.
I have one Sonoff I don’t currently use (but was defined in HA) so I am testing discovery with that.
I removed the manual yaml definition changed SETOPTION19 to ON and restarted HA
For some reason I now have that device suffixed with a 2
I went through the whole, Stop HA, Edit the core files, Restart HA thing again for this and what do you know I cannot get HA to remove this suffix.
I have absolutely no idea what is going on and wish I’d stayed with the ‘old’ way of doing things.
Try to rename in the entity registry… I have seen this once or twice as well… might be retained in the broker…
In the past I have disabled discovery setoption10 off, removed the broker, removed the integration and restarted then added back again…
Before enabling discovery again, you can use that MQTT explorer to make sure there’s nothing in the broker but if you delete the broker it will be empty anyway. Bloody Zombies!!
Well, I was a little nervous to do this following all the noise after the recent new version and with good reason. I decided to upgrade it before removing it and now I get tons of these messages. @DavidFW1960 you seem to be the closest we have on this forum to an expert in MQTT so I am hoping you may have an answer to this!
1552657093: |-- mosquitto_auth_acl_check(..., client id not available, Sonoff, $SYS/broker/load/bytes/sent/5min, MOSQ_ACL_READ)
1552657093: |-- aclcheck(Sonoff, $SYS/broker/load/bytes/sent/5min, 1) CACHEDAUTH: 0
I use an HA User called Sonoff which my devices connect with
Whenever I’ve seen _2 appended to an entity, it’s because of duplication. An entity was already registered (in .storage/core.entity_registry) and I had created a second one bearing the same name (one more thing: the entity has the unique_id option).
I stopped Home Assistant, opened core.entity_registry with a text editor, located and deleted the duplicated entity, ensured I had not corrupted the JSON syntax, saved the file, restarted Home Assistant. This resolved it. The duplicate was an MQTT-based component but, in my case, was not auto-discovered.
Looking forward to learn how this gets resolved for you.
The only way I could find that worked was pretty much as @DavidFW1960 outlined
SETOPTION19 OFF
Removed Mosquitto add-in
Removed MQTT Integration
Stopped HA
Removed all references to the device in the core storage files
Restarted HA
Installed the Mosquitto add-on
SETOPTION19 ON
Restarted HA
So now my spare unused Sonoff appears to be correctly setup and named in HA.
Which just leaves me wondering if I am going to have to go through this process again for all my other Sonoffs if I turn SETOPTION19 ON for them, which for consistency I probably should. My worry is that these are not spare devices and perform useful functions. I really don’t want to screw up my entire system.
So kind of resolved but…
…all is still not well in the Klogg MQTT and Integrations setup (continued in next post because I don’t want to lose sight of the remaining issues because of the glorious feeling of a partial success )
I still have a ton of errors in my MQTT log since upgrading to 4.1
1552659602: |-- mosquitto_auth_acl_check(..., client id not available, Sonoff, stat/sonoff02/STATUS10, MOSQ_ACL_READ)
1552659602: |-- aclcheck(Sonoff, stat/sonoff02/STATUS10, 1) CACHEDAUTH: 0
Now I have read a lot on this recently, could it be because some (all but one) of my devices are not ‘discovered’ I seem to remember reading something along those lines.
AND
Don’t forget why I originally posted!
How can I get HA to call my ‘Sitting Room’ my ‘Sitting Room’ and NOT my ‘TV Room’?
Yes, I can edit the entity to get it nearly right:
But why is it persisting? And my OCD doesn’t like that the underlying name is wrong! Also, what about that red heading?
So, it’s the nuclear option. Wipe out (almost) everything and start from scratch.
I share your concern about ‘what if this happens again?’
As far as I know, option 19 instructs the device to support Home Assistant automatic discovery. So if your config file already contains a Sonoff device configured as light.kitchen, auto-discovery is likely to find the same Sonoff again and re-register it in core.entity_registry as light.kitchen_2.
If light.kitchen is not in the config file and yet the auto-discovery process produces light.kitchen_2 then there must be an existing light.kitchen in core.entity_registry. If not that then possibly there’s some vestige of the entity held in this file: core.restore_state.
Long story short, there are only a few places that Home Assistant uses to store its configuration (unless Hass.io does things I’m unaware of) and they’ll be in configuration.yaml or within the .storage sub-directory.
One more thing you can do is look at what the Sonoff is sending to the MQTT discovery topic. I believe for light.kitchen its discovery topic would be: homeassistant/light/kitchen/config
Before we try the antimatter option (re-install Home Assistant … just kidding), I’d like to learn more about how Home Assistant discovers your Sonos speaker.
I assume when you purchased and configured the Sonos speaker, you assigned it the name “TV Room”? In other words, the device itself has a name, let’s call it the default name, and Home Assistant’s discovery process is using that default name. Correct?
The problem you’ve encountered is that, despite your efforts to have Home Assistant use a different name for this speaker, it always reverts to using the default name. Correct?
If I’m correct in both cases then (here comes my wild guess) is there a possibility that there’s a problem with the Sonos integration? Maybe it exclusively uses the speaker’s default name. Attempts to rename the Sonos entity are always over-written with the default name.
I really can’t believe I didn’t think of this. My only defence is that I’ve had the Sonos for about 15 years and the idea that I actually named them, kinda slipped my mind. Also I’m jumping on the
But to be fair I think I can see it both ways. Ultimately though, however daft the developer might think it, I do believe the user should be allowed to name their devices anything they like and HA should let them.
Really… Thank you!!!
This has occupied way to much of my time today and all because I didn’t like the underlying name to be different!
Now… if only I can get rid of those MQTT add-in errors messages…
Oh, and some reassurance that discovering my other Sonoffs isn’t going to cause me massive problems
Oh well, it’s all in a days work in the HA universe.
We wouldn’t like it any other way, would we?
Thanks again.
PS I haven’t actually tried renaming he Sonos itself yet, but I’m sure it will work
Imagine how you would’ve felt if you had re-installed the entire system … and the Sonos speaker would still be identified as “TV Room”!
I must admit this whole thing gave me a chuckle at your expense (sorry). You did everything possible to eradicate the name yet it kept coming back after discovery. I thought:
“I think Klogg forgot about where discovery is getting the name. From the speaker itself!”