There is inconsistency with showing device_class duration in Frontend.
So, it is more general issue, not related to Ping integration.
As for “why these data became sensors” - it was my original issue caused a corr. PR: these durations occupied lot of place in DB, every update of a ping entity caused a new record in attributes table.
So what’s the difference between that and with every update causing a new entry in the state table?
I’m pretty sure the reasoning is that there is a conscious architectural decision to move away from attributes where the value can be better represented as an entity. No idea what the guidelines are but some values will stay as attributes.
Before: every update caused 1 new record in “states” and 1 new record in “state_attributes”.
After: every update caused only 1 new record in “states”.
At least this was an initial idea, have not checked DB yet.
As for a real reason: ofc there is a general trend, but this particular PR was added after that issue as following that trend.
Yes, it’s a general issue with how durations are handled in some cases, but it’s not completely isolated to the frontend, as the linked frontend issue to the link I posted explains too. The problem is that nobody has a really good suggestion at the moment.
It’s just now more glaring with the changes made to the ping integration, where you don’t want any variation on HMS formats, but just want a decimal value (int or float).
I think there were cases where some sensors would update way more frequently than the attributes, leading to a lot of duplicate attribute entries (imagine there being 10 attributes, but only 1 changes at a time), but there were also cases where static attributes have been removed. In this case though, all these values update together everytime, so I’d agree that there’s probably no saving here.
I’m glad to hear there are plans to move away from attributes. Hanging lots of them off an entity probably seems like a great idea until you look at how they’re stored in the database. Basically, that creates a lot of unnecessary duplication of data. And no good way to exclude the unwanted data. Here’s a recent example of how that affects the database.
Ok, I really only had a quick glance on that issue; hope it will be fixed at least on the ping integration’s level - and then we will keep testing how these duration are displayed.
If a state was changed 10 times and attributes were not - then each record in a “states” table contains same value of “attributes_id” (pointing to the last record in the “attributes” table).
As for ping bibary_sensor: for every update a new “states” record and a new “attributes” record was created. Since I did not need these “duration” attributes - I suggested to change this behavior.
Now, if a user does not use “durations” - the changed implementation will save a lot of space in DB; if a user does need these “durations” (and thus enables these sensors) - then may be even more space in DB will be used as it was before…
The action is null when z2m sends the device update. After the update to 2024.10.1 the mqtt integration now sets the action to unknown as soon as it receives the null value in the above message. So this can happen at random times.
I am using Home assistant Core with docker. Is it safe to upgrade now with the 10.1 release? I saw somtehing like this: After adding /srv/homeassistant/bin to path in the SystemD service file HA core 2024.10 runs as expected. How to add that?
Seems safer to me to wait until next month…
Also: since I use a lot of yaml in packages, it seems that I have to crawl all the code to update to the new syntax, so I need to plan some time for it…
I’ll try to explain but I did these automations a long time ago lol.
I have a mix of Aqara and Linkind buttons. They have their own specific actions they send.
Here is how I use an aqara button action value in an automation…
Value Description
single = toggle lamp on short press
hold = either dim or brighten lamp while button is held on long press
release = change between dim and bright mode for hold action when long press is released
double = toggle ceiling light
These all continue to work fine because I trigger on a specific value.
What did break is I was triggering an automation on any state change of the action button. This would disable the motion detector in that room for 30 minutes on any press. Now when the button action value changes to “unknown” it triggers that automation. That would be whenever z2m sends a status update for the device.
So I can see how this would break automations and blueprints as noted in the other replies.
I’m testing a workaround of creating a manual mqtt sensor in yaml set to disregard the null value.
Thanks, I may end up doing that. But I am kind of against using the MQTT integration sensor that is going to unknown on z2m device update messages.
I think this manually created mqtt sensor in the config file using “is not none” will work for me. Sort of just the same thing as your suggestion.
# send value if it is not none else send empty string
- name: "Test mikes zigbee button action"
state_topic: "zigbee2mqtt/Mikes Room Zigbee Button"
value_template: '{{ value_json.action if value_json.action is not none else "" }}'
