Grouping "next alarm" sensors of device_class=timestamp and type=min doesn't work

Configuration
1

I have several devices that can set alarms and provide sensors like sensor.devicename_next_alarm of device_class timestamp. The idea is that any of these can set an alarm which shall trigger a HA script, and I always want to use the “next” (=minimum) alarm from the group of devices to trigger the next run of the script.

ha-next-alarm-sensors
ha-next-alarm-sensors1023×645 54.4 KB

So I naively created a “group” using the UI’s “Helper” functionality, entered the “next_alarm” entities, and set type to “Minimum”. I also set “Ignore unavailable” to on. The “group” created by the helper doesn’t create an old-style group.something but instead a sensor.something.

ha-helper-group
ha-helper-group407×624 10.8 KB

I expected its state to become the minimum timestamp (in ISO format, like the original device sensors) if any alarms on the grouped devices were set, or unavailable if none were set. So I could easily use the “group minimum” as a trigger to start the next alarm script.

Unfortunately, this doesn’t work, and the group sensor always returns unavailable, even if one or more alarms are set on the grouped devices.

Q1: Is handling of device_class timestamp in helper groups not yet implemented? If so, will it be implemented?

Q2: Any easy-to-implement workarounds (possibly using only the UI), in HA Core 2025.4.2 and newer?

2

Sensor Groups

The old-style groups are YAML only, but they would not provide a calculated state from any kind of sensor.

No, for sensor groups only numeric states are processed when grouped.

3

Believe me, I read through all these and experimented a lot. I fear the culprit here is

[…] holding numeric states

All device_class=timestamp sensors I have seem to report the ISO datetime string, not a numeric timestamp. Then again, if I remember correctly, an entity’s state is always a string.

I reckon it’s simply not (yet?) implemented for device_class=timestamp. Something that should be possible, I’m thinking.

4

I’ve never seen any indication that timestamp sensors will be included in sensor groups that support calculated states, but it could happen.

It can be done with a Template sensor helper…

{% set sensors = ['sensor.sony_handy_next_alarm', 
'sensor.xiaomi_watch2_next_alarm'] 
| reject('is_state', ['unavailable','unknown']) | list %}

{{ sensors|map('states')|sort()|first|default(0|as_datetime, 1) }}

If you keep the Sensor group helper, you can actually use it to supply the entity IDs for the state template:

{% set sensors = state_attr('sensor.weckzeit_von_mobilgerat', 'entity_id') 
| reject('is_state', ['unavailable','unknown']) | list %}

{{ sensors|map('states')|sort()|first|default(0|as_datetime, 1) }}
5

Gee, thanks! That’s a good workaround for now, and should do what I try to achieve (and didn’t know how to do). Instead of hard-coding the list into the template (for making changes easier), is there a way I could maybe expand the group into an entity list in the above? So I could easily add/remove device from the group via the UI without having to remember all the places where it’s hard-coded?

EDIT: Two guys, one idea—you were faster. Thanks again!

6

Hmm. sensor.weckzeit_von_mobilgerat has no list of entity ids, so the second variant doesn’t work here.

7

Well, that’s annoying. It seems to populate the entity_id attribute fine as long as the sensors’ states are numeric.

As an alternative, you could give the sensors a label, then use that to provide the list of entities to the template.

{% set sensors = label_entities('next_alarms') 
| reject('is_state', ['unavailable','unknown']) | list %}

{{ sensors|map('states')|sort()|first|default(0|as_datetime, 1) }}
1 Like
8

Yeah, good idea, thanks again. “Grouping by label”, hee hee.