HASS.Agent
HASS.Agent copied to clipboard
LAB02-Research
Bug: MQTT entity name starts with the device name in your config - HA 2023.8
Hi,
There was a change about MQTT naming for HA Core 2023.8 about not having device name in entity name. It seems HASS agent uses device name in the entity name, for example:
2023-08-01 07:48:57.836 WARNING (MainThread) [homeassistant.components.mqtt.mixins] MQTT entity name starts with the device name in your config {'availability_topic': 'homeassistant/sensor/ANTO/availability', 'icon': 'mdi:webcam', 'unique_id': '1004c0a3-9f4c-4cf3-95ba-2a91843c225f', 'device': {'identifiers': ['hass.agent-ANTO'], 'manufacturer': 'LAB02 Research', 'model': 'Microsoft Windows NT 10.0.19045.0', 'name': 'ANTO', 'sw_version': '2022.14.0', 'connections': []}, 'name': 'ANTO_HP_webcamactive', 'state_topic': 'homeassistant/binary_sensor/ANTO/ANTO_webcamactive/state', 'payload_off': 'OFF', 'payload_on': 'ON', 'payload_available': 'online', 'force_update': False, 'availability_mode': 'latest', 'enabled_by_default': True, 'payload_not_available': 'offline', 'encoding': 'utf-8', 'qos': 0}, this is not expected. Please correct your configuration. The device name prefix will be stripped off the entity name and becomes '_webcamactive'
All the mqtt entites generated by HASS agent generate this log.
Ive read the post from HA regrading this but im not really getting it fully. Saw your post ImSkully so im asking here.
If i understand correclty, is Hass.Agent not going to work after 2024.2.0 if Hass.Agent isnt updated to comply with this before that?
it sounds like it wont break HASS agent, but rather duplicate the device name according to Frenck
It already removed the device name from the friendly name on my system, but it has not changed the entity itself.
same messages here:
MQTT entity name starts with the device name in your config {'availability_topic': 'homeassistant/sensor/XXXXXXXX/availability', 'icon': 'mdi:battery-high', 'unique_id': 'XXXXXXXX_battery_charge_remaining', 'device': {'identifiers': ['hass.agent-XXXXXXXX'], 'manufacturer': 'LAB02 Research', 'model': 'Microsoft Windows NT 10.0.19045.0', 'name': 'XXXXXXXX', 'sw_version': '2022.14.0', 'connections': []}, 'name': 'XXXXXXXX_battery Charge Remaining', 'state_topic': 'homeassistant/sensor/XXXXXXXX/XXXXXXXX_battery/XXXXXXXX_battery_charge_remaining/state', 'force_update': False, 'encoding': 'utf-8', 'qos': 0, 'payload_available': 'online', 'payload_not_available': 'offline', 'enabled_by_default': True, 'availability_mode': 'latest'}, this is not expected. Please correct your configuration. The device name prefix will be stripped off the entity name and becomes '_battery Charge Remaining'
This should not be a breaking change when it does come into effect in 2024.2 so the deprecation warning is safe to ignore for HASS.Agent users.
It would be good to perhaps have the option to change the broadcasted entity name for sensors in the same way entity IDs can be provided.
Excuse me, for me this is a breaking change ... or what am i doing wrong ??
What can I do ? Thanks.
@heilingbrunner looks like these are AhoyDTU warnings, refer to the issue over there: https://github.com/lumapu/ahoy/issues/1066
The easiest way to fix this is to do it yourself. You need to manually rename all of your sensor names to remove the device name from the sensor name:
Screenshot
So it should look like this:
Screenshot
Restart Home Assistant and the warning caused by HASS.Agent entities should disappear. Or another way is to ignore it and wait until someone creates a PR, and it will be merged.
I also tried to rename all the sensors and commands but it failed in an unexpected way.
If you have multiple computers set with the same names for the sensors and commands, you get a unique_id error in the Home Assistant logs and the duplicates are not listed and never show up. I ended up having to rename everything with the device name again and live with the repair warning.
Renaming the names will/can break the entity ids - sensor.<XYZ> within HA as with the current discovery payload, HA is creating entity IDs base on the name. You can leave it for now as it's only a deprecation warning. A PR is in the works to address this.
the entity id names don't change, it's the friendly names that are changing. and changing the names worked perfectly for me. Now I just need to get my dafang cameras and espresence updated.
I also tried to rename all the sensors and commands but it failed in an unexpected way.
If you have multiple computers set with the same names for the sensors and commands, you get a unique_id error in the Home Assistant logs and the duplicates are not listed and never show up. I ended up having to rename everything with the device name again and live with the repair warning.
Same here, the disk sensor failed and only one pf the machines with hass agent showed disk c. Also decided to go back and rename with devicename.
I renamed my buttons and sensors in HASS Agent removing the device name from them and problem solved.
Alternative if you have more than 1 instance of the Agent deployed would be to change the sensor names somewhat so that they do not contain the device name yet still be unique across the Agent instances.
I moved the device name to the end of command name and sensor names. Seems to be OK so far.
For anyone following this and was confused as I was (subscribed to the issue but not activly following the project), there's a fork under the new hass-agent org that's had some ongoing development since this repo/org appears to be dormant.
Fixed in 2.0.1 and up.
Which "2.0.1"?
Latest release according to https://github.com/LAB02-Research/HASS.Agent/releases still is this:
It's a joke or do I miss some GitHub mechanisms here?
I ran into the very same issue after updating HA almost ONE YEAR after this issue arrised for the first time (HA 2023.8) - and there still is no fix in a stable HASS agent release? Are you kidding?
As I have more than one client running HASS agent, just removing the device name in hass agent sensor config is not a solution.
Maybe switching to the maintained fork as mentioned in https://github.com/LAB02-Research/HASS.Agent/issues/337#issuecomment-1985050154 is a proper future-proof "solution"...
Fixed in 2.0.1 and up.
Which "2.0.1"?
Latest release according to https://github.com/LAB02-Research/HASS.Agent/releases still is this:
It's a joke or do I miss some GitHub mechanisms here?
I ran into the very same issue after updating HA almost ONE YEAR after this issue arrised for the first time (HA 2023.8) - and there still is no fix in a stable HASS agent release? Are you kidding?
As I have more than one client running HASS agent, just removing the device name in hass agent sensor config is not a solution.
Maybe switching to the maintained fork as mentioned in #337 (comment) is a proper future-proof "solution"...
They are referring to the fork https://github.com/hass-agent/hass.agent
I know and I have now switched all my clients to that forked version. Event it's "only" the client component (HA integrations like HASS.Agent can stay untouched according to https://www.hass-agent.io/latest/getting-started/installation/#migration-from-pre-200) it was a lot of work to remove the duplicates of these sensors:
- batterie_charge_remaining
- batterie_charge_remaining_percentage
- batterie_charge_status
- batterie_full_charge_lifetime
- batterie_powerline_status
- speicher_total_disk_count
...which are not all existing sensors, so in MQTT plenty of topics still exist with the old devicename_sensorname setup and only those listed above got a new topic name deviceUniqueID_sensorname.
Wondering what about all the remaining ones?
Not sure what the forked version did on this. I can only see when editing existing sensors which have a device name in its name, it gives an information - that's it.
I'll check if HA will continue to complain - I think so...
I don't see why one would post such non-contributing rubbish to a factual report. I'd recommend the mods to mute your post as it contributes absolutely nothing. Have a great day.
Have you not been listening?
There are no mods.
This repository is dead.
This issue is also closed.
The picture above is inaccurate, you are actually flogging a dead horse.
Yes I got that. Seems to be an invitation for some folks (like @pabloaugusto) to behave like in the wild west. I'm out of here.