-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Home Assistant Light Names #8995
Comments
I solve this by just putting a space character in the friendly name and putting the full name in the device Name field. Seems to work though it's a little annoying. |
thanks for the tip (@danmed). It works, even if it's more like a workaround. I've changed my devices. But still I think the implementation is wrong (this is more for the devs) because of two reasons: first: second: all in all I'll personally think that a it is the most compatible way to send only one of the names in case devicename and friendlyname1 are identical. Kepps current names, doesn't change "new" names and keeps also the workaround from danmed. EDIT: |
Once upon a time a Home Assistant dev asked to use a different name to identify a device under HAss to avoid repetitions, then people started to open issues about it here. Fear not, I'll remove the device name (just from relays/lights entities) in the next update and will use just a Friendlyname. Sensors will continue to use the DeviceName. |
Hello @effelle, don't get me wrong. I'm not complaining and I'm completly not unhappy with tasmota. This was only my thinking based on my experiences with some devices where I only set the friendly name (more of an upgrade issue). And I thought that this might be unintended behaviour. I can clearly see a need for device name (switch from module to device) and I see the need also for lights. So, if you think your change is a good way to go, than there is no need for a change, besides the docu maybe. Please don't change anything only to change it back again because we missed something here. I don't want to force something. There is a workaround available, so I'm fine. I had to remove the devices from home assistant DB anyway - this is possible via GUI now. Maybe it's enough for 99% of the devices to send only device name, in case the friendly name 1 equals the device name. If you didn't name you device than no harm should be done. Or maybe it is enough to have the possibility to have an empty friendly name 1. Something like that is may be sufficient to. Please take your time to think about it. I'm not pussing anything, and hopefully everone also, as there is a working workaround in place. |
PROBLEM DESCRIPTION
A clear and concise description of what the problem is.
Since Tasmota 8.1.3 (commit 950a4dc, issue #8462), the names of the home assistant lights (home assistant auto discovery) are generated from device name and friendly name. This results to "double" names in home assistant for simple switches.
E.g:
If the friendly name is light1, than the entity will be named light1 light1, because the device name defaults to friendly name 1. As I can clearly see the need for sensors and multi switch devices, on single switch devices (e.g. sonoff basic) this is a bit of a overshoot. Also it changes (needlessly) the already existing light entity names.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255
:Backlog Rule1; Rule2; Rule3
:Status 0
:(Please use
weblog 4
for more debug information)TO REPRODUCE
Steps to reproduce the behavior:
Set Friendly Name1 of a single switch device
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
I would expect a senseful light entity name, in case of a single switch device, where the device name defaults to friendly name 1. For example, if device name and friendly name 1 is identical, than only one of them is used as name in HA auto discovery.
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: