Rest platform and error handling (with automation)

Configuration
1

I have a rest sensor that gets my public ip address :

    sensor:
      - platform: rest
        resource: !secret endpoint_public_ip
        name: public_ip
        value_template: '{{ value_json.ip }}'

and I have an automation on it to warn me when its value changes :

      - id: public_ip_change
        alias: public ip change
        trigger:
          platform: state
          entity_id: sensor.public_ip
        condition:
          - condition: template
            value_template: '{{ states.sensor.public_ip is defined }}'
        action:
          - service: notify.notify
            data:
              ...

It usually works well and as intended.
Except when the rest call stumbles on an error. (timeout, or any other)
In that case, the sensor.public_ip value becomes ā€œunavailableā€.
And of course, it triggers the automation.
This is usually very short in time and then the rest call works again and the sensor.public_ip is back as beforeā€¦
Which triggers the automation again.
This is very annoying and makes my use-case (beeing notified that my public ip changes) not possible.

Any idea on how to fix this ?

Emmanuel

2

You could try something like this for the template condition:

value_template: >
  {{ trigger.from_state.state not in [none, 'unavailable'] and
     trigger.to_state.state not in [none, 'unavailable'] and
     trigger.to_state.state != trigger.from_state.state }}

EDIT: Actually this might be better:

value_template: >
  {{ trigger.from_state not none and trigger.to_state not none and
     trigger.from_state.state != 'unavailable' and
     trigger.to_state.state != 'unavailable' and
     trigger.to_state.state != trigger.from_state.state }}
3

the correct syntax is

      value_template: '{{ trigger.from_state != none and trigger.to_state != none and
      trigger.from_state.state != ''unavailable'' and trigger.to_state.state != ''unavailable'' and
      trigger.to_state.state != trigger.from_state.state }}'

(ā€˜notā€™ is not recognized)

Iā€™m trying this, but Iā€™d prefer a way to fix the rest sensor directly, is there a way ?

4

Sorry, it was a typo. I meant trigger.from_state is not none, but trigger.from_state != none works, too.

I checked the RESTful Sensor code, and are you sure youā€™re getting ā€˜unavailableā€™? The code sets the state to ā€˜unknownā€™ when the REST query fails. So I think my suggested code would be the following instead:

value_template: >
  {{ trigger.from_state is not none and trigger.to_state is not none and
     trigger.from_state.state != 'unknown' and
     trigger.to_state.state != 'unknown' and
     trigger.to_state.state != trigger.from_state.state }}

But, to answer your question, what do you mean exactly by ā€œfixā€? Iā€™m pretty sure by design the state is set to ā€œunknownā€ when the query fails. If you would rather it left the state as-is in that case, then you could copy the code to custom_components/sensor/rest.py in your HA config folder and modify it to do what you want.

5

Oh, youā€™re probably right about unknown (my interface is in French).
I changed it, Iā€™m waiting for the issue to reproduce.

By fixing I mean, having the ability to just ignore the data points in the sensor where it is unknown.
Would it be possible with a template sensor ? I searched for it but couldnā€™t find.

6

Thatā€™s what the automation condition does. :slight_smile:

But to answer your question, the only way I can think of to not have the RESTful Sensor go to a state of unknown when the REST query fails is to change the code. If you want to have another sensor that ignores this sensorā€™s unknown values, youā€™d probably have to do that with an input_text and an automation, and the automation would probably have to have the same condition as what I suggested for your original automation. Iā€™m not sure itā€™s worth the effort.

But maybe someone else reading this topic will think of something thatā€™s not coming to my mind.

7

I meant ignoring it directly into the sensor, which would solve the problem at the source.
Iā€™d rather not make a custom rest sensor just for this case, so Iā€™m keeping on trying the ā€œautomation fixā€.

The ā€œunknownā€ didnā€™t work (I got a notification when waking up), so Iā€™m adding ā€˜unavailableā€™ to the conditions, hoping itā€™ll work.

8

the following condition seems to work:

      value_template: >
        {{ trigger.from_state is not none and trigger.to_state is not none and
           trigger.from_state.state != 'unknown' and trigger.to_state.state != 'unknown' and
           trigger.from_state.state != 'unavailable' and trigger.to_state.state != 'unavailable' and
           trigger.to_state.state != trigger.from_state.state }}

It doesnā€™t trigger on ā€˜unavailableā€™.
Iā€™ll have to wait a few weeks/months to see if it still triggers on an actual public ip change, though.

9

Nice.

For what itā€™s worth, you could slightly simplify it (and make it easier to exclude other unwanted states) this way:

      value_template: >
        {% set ignore = ['unknown', 'unavailable'] %}
        {{ trigger.from_state.state not in ignore and
           trigger.to_state.state not in ignore and
           trigger.to_state.state != trigger.from_state.state }}

This also seems to correctly handle the situation where trigger.from_state or trigger.to_state are none.

1 Like