Command_line sensor: is there any sort of expire_after (or alternative approach) available?

Configuration
1

I have a tablet that can respond to REST commands.
For example if I issue in terminal

curl http://192.168.0.1:2971/api/state

it returns

{“currentUrl”:“http://192.168.0.0:8123/alarm”,“screenOn”:false,“brightness”:1}

I’m playing with a command_line sensor trying to create the tablet’s availability sensor, but it doesn’t seem to give me what I need because it holds the last state even if the tablet stops responding to the commands (if I switch off REST service on it for example). Therefore comparison of its last_updated attribute to now() doesn’t make sense.

Here’s the config:

- platform: command_line
  name: entrance wallpanel available
  scan_interval: 5
  command: 'curl http://192.168.0.1:2971/api/state'

So what’s the right way to implement that availability sensor then? I’m a bit confused, sensors should have some sort of expire_after but this one does not and it makes it pretty useless…

2

try last_changed

- platform: command_line
  name: entrance wallpanel available
  scan_interval: 5
  command: 'curl http://192.168.0.1:2971/api/state'
  json_attributes:
  - currentUrl
  - screenOn
  - brightness

states.sensor.entrance_wallpanel_available.last_changed
3

Well, as far as I understand the only difference between last_updated and last_changed is that the former shows when the state changes and the latter shows when any of the attributes change.
In my case state is the whole JSON string and attributes are just parts of it.
And if there is no more changes to the state, there will be no change to any attribute, isn’t that correct?

4

last_updated tells you the last time data was received. last_changed is when the state or any attribute changes.

5

I’m afraid that’s not true according to the docs and my personal experience. Devs won’t allow anyone to update state attributes every time data received, that’s A LOT if you think about the whole lot of state objects.
I’ve been there and that’s exactly why expire_after attributes are useful.

6

Seems you are correct here.

That’s not how code works. No new state objects are created, the fields are replaced the memory address for the object is static. No extra memory. The behavior of these attributes was a design choice.

Anyways, that does stall the solution.

What currently happens when you lose connection?

7

The sensor retains its state. In HA log I can see

2019-10-18 20:40:14 ERROR (SyncWorker_5) [homeassistant.components.command_line.sensor] Command failed: curl http://192.168.0.1:2971/api/state

And its last_updated/last_changed are not useful.

On a positive note, I have some progress with REST sensor:

- platform: rest
  resource: 'http://192.168.0.1:2971/api/state'
  value_template: >
    {{ 'Connected' if value_json else 'Disconnected' }}
  verify_ssl: false
  force_update: true

It changes its state when I disable REST on the tablet, hurray!
If I disable REST, in HA log I can see

2019-10-18 20:39:17 ERROR (SyncWorker_10) [homeassistant.components.rest.sensor] Error fetching data: <PreparedRequest [GET]> from http://192.168.0.1:2971/api/state failed with HTTPConnectionPool(host=‘192.168.0.1’, port=2971): Max retries exceeded with url: /api/state (Caused by NewConnectionError(‘<urllib3.connection.HTTPConnection object at 0x71ec7610>: Failed to establish a new connection: [Errno 111] Connection refused’))

However, there are few question marks, namely:

  1. From what I can see its state is updated every 30 seconds, but it’s not configurable and there is no guarantee it won’t be 5 minutes or 1 hour in the next HA release :wink:
  2. I have no idea why when the request is successful, its state is Connected (as per code), but it becomes unavailable instead of Disconnected when I disable REST. I kind of feel that it’s something to do with my misinterpretation of how value_template works, but don’t know how to fix it…
    UPDATE: I think I got it - when the sensor fails to fetch new data, value_template is not used as there is no incoming data and state reverts to unavailable.
  3. If I start HA with REST disabled, the sensor does not exist, in HA log I see

2019-10-18 21:07:39 ERROR (SyncWorker_10) [homeassistant.components.rest.sensor] Error fetching data: <PreparedRequest [GET]> from http://192.168.0.1:2971/api/state failed with HTTPConnectionPool(host=‘192.168.0.1’, port=2971): Max retries exceeded with url: /api/state (Caused by NewConnectionError(‘<urllib3.connection.HTTPConnection object at 0x71cec630>: Failed to establish a new connection: [Errno 111] Connection refused’))

2019-10-18 21:07:39 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet. Retrying in 60 seconds.

and I don’t see the sensor in States (but it appears there as soon as I enable REST).
So basically I’ll need a binary template sensor to finish it off…

8

Well, unfortunately, I can’t help. I don’t have any experience using the rest sensors. Only creating them (from helping others). I don’t have any myself in my setups.

9

No worries at all and thanks for your suggestions.
I’ll create a separate topic if I need it… :wink: