Add support to the RESTful integration for the configuration of an optional enable/disable control template

Feature Requests
1

There are a number of cases when it is not desirable for a RESTful integration in certain conditions to attempt to contact the HTTP resource. For example:

  1. see feature request " Restful Sensor support for conditional entity"
  2. in my case, I have a number of input_text helpers that store URLs for instances of the RESTful integration, but when HA is starting up it attempts to make HTTP requests before the helpers are ready, resulting in numerous log messages about “unknown” not being a valid URL.

What I have in mind is a template that evaluates to on/off. When it is off, the HTTP request is not attempted and all entities in that instance of the RESTful integration are ‘unavailable’. When it is on, things proceed as today.

In case 2 above, the template would be something like {{ has_value(‘input_text.url’) }}

Note that I am only proposing this for the RESTful integration and not the RESTful Sensor or RESTful Binary Sensor integrations (nor the REST API).

2

Just implement availability for your REST sensors, with your definition of ready.

See Rest sensor fails when inverter is offline - #8 by 1mfaasj as an example

3

Thanks @koying but the sensor availability templates are not evaluated until after the HTTP request is done. I am trying to stop the HTTP request being attempted when it is not possible to do so.

1 Like
4

Ah, right you are.
That FR might actually ask for availability to be moved and/or duplicated at the resource level (and to be evaluated before fetching).

5

Yes, that’s what I meant. I first thought of it as “resource availability” but didn’t use the word “availability” because the sensor availability templates are evaluated after the data has been obtained (in fact after the state has been evaluated) whereas the idea here is to control whether there is any attempt to access the data. So, I wrote it as enable/disable. If there is another integration with an equivalent feature I would copy that, but I don’t know of one.

6

You can do this with the spook integration (custom). I doubt it will ever make it to core, so I’d start there.

7

Mmm… What makes you think so?
Purely functionally, It seems to make sense to check availability at the resource level here, probably more than at the sensor level tbh.

How would you do that with spook, btw?

8

Because, core has taken a firm stance at “Not logically (with an automation) modifying things in configuration”. Therefore a service wouldn’t be added. Frenck made spook partially because of this stance.

As for how you’d do it, with spook you’d use the enable/disable polling for that entity.

9

Or we are not speaking about the same, or you lost me :wink:

I speak about doing:

rest:
  - resource: 'http://zefqz.sdqsd.sqdqsd'
    availability: "{{ false }}"
    sensor:
    - name: Availability test
      value_template: >
        {{ value_json["Temp_In"] | replace(",", ".") | float }}

rather than having

rest:
  - resource: 'http://zefqz.sdqsd.sqdqsd'
    sensor:
    - name: Availability test
      value_template: >
        {{ value_json["Temp_In"] | replace(",", ".") | float }}
      availability: "{{ false }}"

which always do a fetch anyways

10

OP Is asking for this

I.e. before the poll happens. Only way to do that is to disable polling via a service call that does this.

11

If I understand what is meant by “service call” correctly, none is required. The implementation can be done entirely within homeassistant/components/rest by:

  1. RestData.async_update() in homeassistant/components/rest/data.py evaluates the “enablement” template and, if false, returns with self.data=None and a property indicating why self.data is None;
  2. async_setup_platform() in sensor.py and binary_sensor.py check for that property and do not raise
    PlatformNotReady if it is set to indicate that enablement failed: this ensures that the sensors exists but have a state of unavailable.

@petro does this affect your view about its suitability for core?

12

This will likely never get added to core. I recommend that you use spook to handle this as said before.