Force a sensor update as part of an action sequence

I’m working on sending myself a notification with commute time when my wife leaves work. Since I’m a purest I would like to trigger a recalculation of the commute time just before the message is sent. Something like:

  trigger:
    - platform: zone
      entity_id: device_tracker.wife_cell_gps
      zone: zone.work
      event: leave
  action:
    - service: update
      entity_id: sensor.wife_to_home
    - service: notify.my_cell
      data_template:
        message: "Wife has left work, commute time: {{ states.sensor.wife_to_home.attributes.duration }}."

Is anything like this possible?

Thanks,
Omen

Purest is the wrong word. You are trying to get the most “accurate” estimate of when she’ll be home, but honestly it probably won’t make it more accurate in real life.

I mean, if you don’t move anywhere, the estimate of travel time at 4:55 will be pretty much as accurate as leaving at 5:00. It really isn’t worth the effort.

With that said, I am working on an update to the Google travel time component that will let you change the update rate. I changed mine to 2 minutes to get a smaller window for when I declare that the target reached the destination. The real benefit is that my wife won’t wait outside for an unnecessary amount of time waiting for me to get the notification that she is here. However, if I ever get around to submitting it, it’ll let you close the window between when your life leaves and the last estimate taken.

2 Likes

I’ve tweaked a local copy to update once a minute, but that’s excessive 20 hours of the day. And all weekend. At this point I would be pretty happy to have an action sequence that could change the update time (set to 1 minute at 3pm, set to 5 minutes at 7pm). I’m new to HA, so maybe I’m just missing how to do this.

Thanks for the reply,
Omen

+1

I would love this for a few sensors I use so I can have the state recalculated at midnight. Setting the scan interval to 60 seconds for a sensor that only changes at midnight seems like overkill.

Btw, @OmenWild, you can vote for your own feature request :wink:

Sounds like you need to trigger your sensor update from a device_tracker attribute change event.
I need to do exactly the same thing.

Is there really currently no way to have a sensor subscribe to an event for performing its updates?

What about setting the scan_interval for the sensor to something very small - like 10 or 15 seconds - but then adding a check to the beginning of the sensor update code that looks at the last update time for the device_tracker entity and bails out immediately if it hasn’t changed? So you’d only actually have to perform the actual sensor update once an hour - or whenever a device_tracker location actually changes…

Actually I’m thinking of something very similar.
I have a soundbar which I can detect via Bluetooth - if detectable then it is turned on. Otherwise it’s off. I also have some device that sends IRDA signals to turn the soundbar on/off.
So what I’m doing in my automations is:

  • turning on soundbar via IRDA
  • waiting for device to be discovered via BT
  • connect with BT
  • wait for binary command line sensor to report that device is connected

This task takes veeery long, as default refresh rates for BT discovery and are very long - 20 seconds for BT, 60 seconds for command line sensor. What I was thinking on was finding a way to:

  • say to bluetooth device tracker: “hey. Someone tried to turn on the soundbar. For one minute increase the refresh rate for soundbar’s entity so it is detected faster”
  • say to command line sensor: “hey you, you are useless if soundbar is turned off, so don’t do anything until the soundbar is on.”

The first one seems tricky, but I’ll try to do it by adding a service - something like device_tracker.set_interval which will change the refresh rate for tracker. Creating it in a way it allows to stop automatically after some time may be hard, but there’s always a fallback - it would take a parameter defining refresh rate and user could manually (or via automation) call service to enable intensive discovery and after a while call the service to disable it.

The second idea is what you’re trying to achieve here. Enabling the sensor when condition is met. It can be done with some kind of “activated” parameter in configuration that takes template defining when to work. The only hard part may be integrating it with all sensors. I’ll try to implement it soon, when I’ll have some time.

However currently I’m out of time. So I’ll get to it probably in a week, not earlier.

1 Like

Adding a vote for this one.

For me it’s the modbus component. When I manually change a register value via an input_number or switch I don’t want to wait 30 sec to see if the new value stuck or not. 30sec delay between input and response is a looong time in an HMI.