Closed lee-booy closed 7 months ago
Whoa! I did a double-take on the one word vs. two. This must be a bug!
The code snip shown below is designed to strip off the suggested area should it be prepended in the preferred name. It doesn't care for word count...
For a quick fix hopefully, replace it with the following and report back: local function getEntity(entity) return entity end
local function getEntity(entity)
if _L.sa ~= '' then
local startIdx, endIdx
repeat
startIdx, endIdx = entity:find(_L.sa, 1, true)
if startIdx and startIdx == 1 then
entity = entity:sub(endIdx + 1):match'^%s*(.*)'
end
until not startIdx or startIdx > 1
end
return entity
end
This raises two questions, Lee. First, whether I should be doing this at all, and second, why the heck does a two word suggested area NOT get scrubbed from the start of the preferred name? Edit: (I have sa= names like Bedroom 1, Bedroom 2, Family Room, and they all get stripped off, so what is different for you?...)
Once you do this and restart MQTT send receive you will end up with a bunch of duplicated devices. On my system, I removed the MQTT integration, then re-added it to remove all the duplicates. Every came back as planned.
I am not sure that I like this behaviour. I possibly might add a variable to change to one way or the other at the top of the script. Thoughts?
It still begs the question about the weird one word/two word behaviour, which clearly wants sorting...
I think a toggle is a great idea as it both sign posts the feature (so it's never unexpected) and gives the user to turn it on or off, especially as naming conventions are highly personal 😄
I'll give the work around a test over the weekend, I've already broken enough things for one weekend project (unrelated to this 😄)
Done.
It was a little more involved because of how I name the entities. 'entity' used to equal 'name'. Now the name can be different.
In d862770 there's now a variable near the top to adjust for taste. Plus also if this is set to true then it can be overriden for individual GAs with the new keyword 'exactpn' should just a few unmodified names be required.
All prior names will be cleaned up if this variable is changed.
Let me know how you go with it, and if it's all god I'll update the readme.
Actually hold off, @lee-booy. It has an issue. 'exactpn' works, but the overall preference doesn't.
Fixed in https://github.com/autoSteve/acMqtt/commit/02ae45a9ecd8700579c42f28f3b734b152ccdfa9, @lee-booy.
You are too quick @autoSteve, I'll test and report back :)
I had one question based on a comment you made, when you say how you named the entities... does this mean the entities in HA? Just asking as my entities don't take on the preferred name, they still come through as something like cbus_mqtt_254_56_12
😎
Sorry to confuse you. Entity in my code. This is used to set the 'identifier' (ids in the json), which I didn't want to change with this change. The object ID (obj_id) is cbus_mqtt_254_56_12, and will remain the same.
{
"ic":"mdi:lightbulb",
"pl_off":"OFF",
"dev": {
"ids":"Front Lounge Main Light",
"mdl":"CBus",
"sa":"Front Lounge",
"mf":"Schneider Electric",
"name":"Main Light"
},
"obj_id":"cbus_mqtt_254_56_10",
"stat_t":"cbus\/read\/0\/56\/10\/state",
"cmd_t":"cbus\/write\/0\/56\/10\/switch",
"bri_stat_t":"cbus\/read\/0\/56\/10\/level",
"avty_t":"cbus\/status",
"uniq_id":"cbus_mqtt_254_56_10",
"on_cmd_type":"brightness",
"name":"",
"bri_cmd_t":"cbus\/write\/0\/56\/10\/ramp"
}
I had assumed you didn't mean the HA entity, but that didn't mean there wasn't a glimmer of hope ;)
With the new variable set to off, here's what "dev" looks like. Identifier is exactly the same. (I don't think this is visible anywhere in HA.)
"dev":{
"ids":"Front Lounge Main Light",
"mdl":"CBus",
"sa":"Front Lounge",
"mf":"Schneider Electric",
"name":"Front Lounge Main Light"
}
Just asking as my entities don't take on the preferred name
The entity name? Or the entity ID?
Entity ID, I currently manually rename them as looking up the number string for dashboard / automations is a pain :)
That sounds like manual labour... This is home automation, after all. We hate manual. 😉
Thinking out loud, would a variable option to name the entity IDs like light.bedroom_light according to the preferred name, lowecase with underscores for spaces work? If there were duplicates it could get confusing, but I could check for those and error them out with a log notice.
Unique ID would stay the same, but that's internal HA stuff AFAIK.
Haha you are a man after my own heart 😊 If I were going to design it I would do this;
Turning this feature on present the Entity ID with the preferred name (minus special characters), If you turn on this feature it's important that all your preferred names are unique as Home Assistant doesn't allow duplicate Entity ID's. Duplicate Entity ID's will generate a error in the log.
Entity ID example Keywords - MQTT, light, pn=Bathroom Light - Vanity, img=mdi:led-strip, Entity ID - light.bathroom_light_vanity
A slight modification. Could the ID be the identifier/lowercase/etc.? E.g. "Front Lounge Main Light", which I construct using the suggested area and name. For my set-up, I have a bunch of entities just named "Light" in HA.
Of course, if the area is already in the name that identifier stays the same, if that makes sense.
If I'm understanding you correctly its (type).(sa)_(pn)
So keywords MQTT, light, pn=Bathroom Light - Vanity, MQTT, light, sa=Bathroom pn=Bathroom Light - Vanity, MQTT, light, sa=Bathroom pn=Light - Vanity,
Would all result in Entity ID - light.bathroom_light_vanity
If so that's a good call as my original format would end up in lots of duplicates for people who don't have the area in the pn
Spot on.
This is going to need a flashing red lights warning in the readme about changing the entity ID naming. 😂 All dashboards will have missing entities, but only if MQTT integration is removed and re-added, because as you've found, the entity ID remains even if the discovery topic holds a different value. (I could bugger this up/accelerate this for folks, though... If I delete the discovery topic when an entity ID change is detected, then add discovery again the changed ID will go away. ...Laughs an evil laugh...)
But I think this will be just better, so well worth it. I wish I'd done it this way from the get go. You should have said something... 🤣🤣🤣
Haha one doesn't want to push the friendship :) I also just assumed I was a wierdo for renaming them but 🤷
This. Is. Done.
Two variables: entityIdAsIndentifier - use the alternate entity naming forceChangeId - as the notes say, use caution as this will probably break stuff
Thanks for the inspiration, @lee-booy.
Such quick work 🚀 I just did a test, I noticed I had to restart the SHAC before it would work properly 🤷
It's all working as expected, amazing work 🤩 I thought I had found a bug, but it was a typo on my part 😄
Thanks again
How odd the SHAC needing a restart. I'll think about that...
When I updated the script I stripped the MQTT label from them all, so I could test it with 2 devices first. I noticed the devices came back into HA but they still didn't have the sa in the device name despite the flag being correct. Restarted the SHAC and they came in correctly.
No clear reason why but my first port of call when anything is unexpected is a restart :) Thanks again for the work and fast turn around 🥇
I've noticed that if the sa is one word then the area is omitted from the name in HA, but if it's two words it's passed through. I'm not sure if this is on the HA side or the script 🤷
My pref is the fullname is always passed through.
MQTT, light, sa= Lees Office, pn=Lees Office Lights, img=mdi:light-recessed, MQTT, light, sa=Ensuite, pn=Ensuite Lights, img=mdi:light-recessed,
I've tested with a couple of lights to confirm the behaviour