How to trigger on this 'time' sensor

Mariusthvdb · June 16, 2021, 7:33am

somehow this either worked, or hasn’t worked before, and I didn’t notice it…

    trigger:
      - platform: time
        at: sensor.alarmclock_wd_time

where the sensor.alarmclock_wd_time has this as state:

and this as config:

sensor:
  - platform: template
    sensors:
      alarmclock_wd_time:
        friendly_name: Alarmtime weekday
        value_template: >
          {% if is_state('input_boolean.alarmclock_wd_enabled','on') %}
          {{'%0.02d:%0.02d'|format(states('input_number.alarmclock_wd_hour')|int,
                                      states('input_number.alarmclock_wd_minute')|int)}}
          {% else %} Not set
          {% endif %}

apparently I missed that it should be a sensor with device_class datetime…

is there any way this could be fixed? can I easily create a timestamp sensor based on this, or maybe an input_datetime automatically? complexing factor of course is the template it should follow.

or should I use a trigger template instead?

{{ states('sensor.time') == states('sensors.alarmclock_wd_time') if  states('sensors.alarmclock_wd_time') != 'Not set'}}

of course the ‘if’ can be left out…

{{ states('sensor.time') == states('sensors.alarmclock_wd_time')}}

please have a look? thanks

Troon · June 16, 2021, 7:39am

You can easily add device_class: timestamp to your sensor config, but the docs say:

timestamp: Datetime object or timestamp string (ISO 8601).

I don’t know if your HH:MM will work for that.

Your template trigger will work fine, although it will be evaluated every minute. In reality, that doesn’t matter unless you have an insanely-busy system running off underpowered hardware.

IMO, the best alternative would be to change your frontend to use a time-only input_datetime instead of separate hour and minute numbers, and you can then trigger directly off that.

Mariusthvdb · June 16, 2021, 7:44am

well, yes, should have mentioned that sorry, I did try and add the device_class, but then the frontend shows invalid timestamp error on that sensor, instead of the time string it now does. probably need to add the isoformat to it also.

yes that sounds interesting, would require my daily routine to change of course

and it should really be doable on a small handheld device (for which this already is a challenge now and then…)

Troon · June 16, 2021, 7:51am

If you really want your separate hour / minute numbers, you could set up an automation to mirror them into an input_datetime (which you’ll need to create first):

trigger:
  - platform: state
    entity_id:
      - input_number.alarmclock_wd_hour
      - input_number.alarmclock_wd_minute
action:
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.alarmclock_wd
    data:
      time: "{{ '%0.02d:%0.02d'|format(states('input_number.alarmclock_wd_hour')|int,  states('input_number.alarmclock_wd_minute')|int) }}"

Mariusthvdb · June 16, 2021, 7:55am

nice! thanks, you gave me 2 ways to walk today…

I’ll first check the input_datetime and see how that handles a mobile action, and if not, at least add the automation. (there’s a whole bunch of other sensors using the separate hours/minutes in my config, so that requires a lot of checking out. Legacy that works flawlessly, do I keep building around it, or do a rewrite all of it… choices choices

but wait, I have an input_datetime, which I almost never use (, because I don’t want the home telling me to go to bed…)
Also, I now remember this is not used because of the clumsiness in handling:

there really should be an alternative frontend for that, maybe I’ll search fo a custom card with 2 vertical roller scales.

Mariusthvdb · June 16, 2021, 10:17pm

found a custom card for the input_datetime, see: https://github.com/GeorgeSG/lovelace-time-picker-card:

which is a bit bare-bones, but what more do we need, plain and simple, with built-in embed. very nice
@georgeSG, if you read this, thank you very much!