Reloading integration deletes entities friendly names

nagyrobi commented 2 years ago

Version of the custom_component

0.6.4

Configuration


Not relevant as it's independent from config.

Describe the bug

Steps to reproduce:

Install a plate having GPIOs configured. Switches will be imported in HA accordingly. For examle, Lanbon L8 will have switch entities like light.plate_konyha_light_12, light.plate_konyha_light_14, etc.
In HA Lovelace click on any of these entities and set a name for them. Any name like Light Bedroom Left
Go to Configuration > Devices and Services > (your plate) > 3-dots menu > Reload
Check the entities you've set name for. It will be missing, Reload function deleted the name.

Debug log


2022-01-23 21:33:53 WARNING (MainThread) [homeassistant.helpers.service] Unable to find referenced entities openhasp.plate_konyha
2022-01-23 21:33:56 WARNING (MainThread) [homeassistant.helpers.service] Unable to find referenced entities openhasp.plate_konyha

dgomes commented 2 years ago

this is not handled by the CC...

nagyrobi commented 2 years ago

It only happens with openHASP CC... Restarting HA will keep the names...

nagyrobi commented 2 years ago

Added names to customize.yaml - not taken into account

dgomes commented 2 years ago

customize.yaml is being deprecated, for integration based on config_entries most things already don't work

nagyrobi commented 2 years ago

yes I know it's deprecated, just gave it a chance... It's really annoying that for a minor change in Openhasp config you need to restart entire HA if you don't want to loose entity names :-(

nagyrobi commented 2 years ago

Would be nice to be able to pre-set the friendly names for these switches from the yaml configuration. That way, they will never be lost. ESPHome does the same thing, you set the friendly names of the entities from within the yaml config of the device.

dgomes commented 2 years ago

I think it could be set in firmware configuration :) and then I could receive it during discovery like it happens in tasiota

cc @fvanroie

nagyrobi commented 2 years ago

Actually that would be great. Have a field in the Webif to set the names.

fvanroie commented 2 years ago

What would the discovery messages need to look like to handle the names?

nagyrobi commented 2 years ago

Perhaps "output":{{"gpio":"14","class":"light","name":"Kitchen lights"},{"gpio":"12","class":"light","name":"Kitchen cabinets"},{"gpio":"12","class":"switch","name":"Pedal switch"}} or "outputs":[12,14,27], "out_types":["light","light","switch"], "out_names":["Kitchen lights","Kitchen cabinets","Pedal switch"]

in the discocvery payload? (because you can have more types (device classes) than just power and light)

Also "Moodlight" and "Backlight" would be nice if had configurable names.

kquinsland commented 2 years ago

I just got hit with this as well

I don't understand why this is not a CC issue even if it could be addressed on the device side. Under the hood, HA appears to track a device ID as a sha1 of mac address and some other system things and each entity id e.g.: switch.bathroom_switch_12 also gets it's own sha1.

Somewhere in HA it keeps track of what name the user would prefer sha1(switch.bathroom_switch_12) be known as.... unless reloading a configuration means erasing the sha1(device) and all it's children sha1(switch.bathroom_switch_12) from the HA store?

/shrug.

What would the discovery messages need to look like to handle the names?

That depends on if the CC is doing the devic reg or not.

For "basic" function like the GPIO built into a device (relays, power sensors, rgbled), i'd prefer going the "fist party" route using mqtt based auto-configuration. I did some work on the orig HASP to get some neopixels to be discovered automatically via MQTT: https://github.com/kquinsland/HASwitchPlate/blob/add-neopixels/Arduino_Sketch/HASwitchPlate/HASwitchPlate.ino#L3061

This way at least the basics of a device are accessible in HA w/o the CC and will "just work". Of course, advanced UI stuff will still need to leverage the CC but I think there's a lot to be said for a sequence that works like this:

Install device
Connect to AP, configure real wifi/mqtt
New device page with toggle switches for the relays, backlight, moodlight show up
New sensor for power use shows up

nagyrobi commented 2 years ago

Also a side effect: reloading the integration renames the main entity openhasp.plate_35 to something like openhasp.plate_35_2. I remember having something similar back in the summer, when entity IDs of the switches were renamed with _2 after certain scenarios (not reload), but @dgomes fixed that.

To fix, need to restart HA and then manually rename back to openhasp.plate_35. Impossible to rename without restart as the old entity name is still stuck in HA.

This is a problem because I have automations relying on the main entity of the plate.

nagyrobi commented 2 years ago

Also a side effect

This was caused by the plate running on a different IP address than at the time it was configured. Removed the plate from integrations, re-discovered and reloading config doesn't seem to rename the entity anymore.

nagyrobi commented 2 years ago

Seems fixed but it only works on latest HA beta version 2022.2.b number entity fails on HA versions prior to that

nagyrobi commented 2 years ago

Reloading itself actually broke. Plate and HA loose connection. Restart HA fixes it.

kquinsland commented 2 years ago

Also a side effect

This was caused by the plate running on a different IP address than at the time it was configured. Removed the plate from integrations, re-discovered and reloading config doesn't seem to rename the entity anymore.

My DHCP server is pretty sticky. The device that I renamed the entities on and then reloaded the config for did not restart or otherwise get a new IP address.

HASwitchPlate / openHASP-custom-component