Is there a way to delay the RESTful template?
I would like to prevent executing to two requests to the same API/Host in parallel (rate limiting from the service) when HA is restarted.
Is there a way to delay the RESTful template?
I would like to prevent executing to two requests to the same API/Host in parallel (rate limiting from the service) when HA is restarted.
If you’re making requests to the same endpoint, try the RESTful integration instead:
One request, multiple sensors. If you need help refactoring your configuration, post your current sensor.rest
config here, correctly formatted, and we’ll help turn it into rest.sensor
.
No not to the same endpoint. To the same host, but two different endpoints.
And its not allowed to make >=two requests in parallel to the complete API
Disable polling by setting a really long scan interval (years) and update the sensors with time pattern triggered automatons (using the homeassistant.update_entity service).
I think it’ll still make two requests on HA restart, though.
Perhaps make use of resource_template
, and set up a template sensor that contains a dummy URL by default and the real URL if system uptime is high enough? For example (300s = 5 minutes):
template:
- sensor:
- name: "Delayed URL"
state: >
{% if now()|as_timestamp - states('sensor.uptime')|as_timestamp > 300 %}
the real URL
{% else %}
the dummy URL
{% endif %}
then:
sensor:
- platform: rest
resource_template: "{{ states('sensor.delayed_url') }}"
# the rest of your sensor config
Dummy URL could be anything that’ll fail, or you could even cobble up a local URL that’d return “placeholder” data.
Currently i have two different scan interval also on different time. First call every hour + 5 seconds. The other call once a day - 10 seconds. During HA is running everything works fine, but this interval is ignored during the start phase. After restart the calls are executed immediately.
Is there a way to make the scan interval dependent on a specific time/hour and not the start date?
See @tom_l’s post above — not directly, but set a very long scan_interval
and update from an automation calling the homeassistant.update_entity
service (docs).
If you combine that with my resource_template
trick above to prevent scan on HA restart (perhaps modified to change at a specific clock time rather than after a specific uptime) you should be able to have full control over when it updates.
Ok i will try that. Looks a not so comfortable for this “easy” use case
@Troon what happens if the request failed?
Does the sensor then have an old value or unknown?
Because currently if the request fails, the value is unknown. Can I avoid this?
EDIT: Delayed request is working.
And i just set with time automation → the new url + update the entity
Hmm, yes. Short of doing all sorts of horrible things with event listening, I’m not sure how to get around that. A possible solution is to default to the dummy URL and only switch to the real one when the update automation runs.
This structure stores the URL in an input_text
helper that you’d need to create with the dummy URL as its initial value.
- alias: "Update the mystery API"
id: 39d7ed0c-8a72-431e-9cff-8bac2af6e089
trigger:
- platform: time
at:
- "12:34:56"
- "00:12:34"
action:
- service: input_text.set_value
target:
entity_id: input_text.api_url
data:
value: "THE REAL URL"
- service: homeassistant.update_entity
target:
entity_id: sensor.YOUR_REST_SENSOR
- service: input_text.set_value
target:
entity_id: input_text.api_url
data:
value: "THE DUMMY URL"
then use:
resource_template: "{{ states('input_text.api_url') }}"
in the rest sensor. The template sensor in my last post is no longer needed.
Then, whenever you trigger the automation (here, at two specific times but do it how you want), the automation switches in the real URL, updates the sensor, then puts the dummy URL back in so that any unwanted reloads don’t hit the API.
Ah yes easy could just reset it after the real request.
I need no input.select. I have this Python script to change the state so i can reuse the sensor without a helper.