Ok, this seems to work, I’ll mark it as a solution when I have tested it a bit more long term:
I updated configuration.yaml to include a REST sensor (sensor.json_ftx_water_sensor) that gets the nested ‘last_changed’ value directly from deCONZ and puts it as an attribute of the sensor. I then updated the availability check sensor to use this attribute instead of the one provided by HA.
This gives me the nested ‘last_changed’ value from the REST request in the attribute ‘sensor.json_ftx_water_sensor.last_updated’ which I can use. You can test this value in dev tools:
{{ states.sensor.json_ftx_water_sensor.last_updated }}
gives me:
2020-08-15 07:54:47.267667+00:00
My sensors section of configuration.yaml now looks like this:
sensor:
- platform: yr
name: yr
monitored_conditions:
- temperature
- platform: time_date
display_options:
- 'time'
- 'date'
- 'date_time'
# Get the FTX water sensor 'state' values via REST towards deCONZ and put them in the sensor as attributes
- platform: rest
name: JSON FTX water sensor
scan_interval: 300 # updates sensor every 5 minutes to not overload deCONZ
resource: !secret ftx_aqara_water_sensor_resource_url
json_attributes:
- state
value_template: '{{ json_ftx_water_sensor.state[0] }}'
headers:
Content-Type: application/json
User-Agent: Home Assistant REST sensor
# The following sensor checks if FTX water sensor has refreshed its state within a certain timeframe (60 minutes/3600 seconds for Aqara water leak sensors), if not they are considered unavailable
- platform: template
sensors:
rest_ftx_water_sensor:
entity_id: sensor.time # updates sensor every minute
friendly_name: "REST FTX water sensor"
value_template: >
{% if as_timestamp(utcnow()) < (as_timestamp(states.sensor.json_ftx_water_sensor.last_updated ) + 3600) %}
available
{% else %}
unavailable
{% endif %}
One small thing because I used @jazzyisj unavailability package is that the state of the rest sensor ‘sensor.json_ftx_water_sensor’ is always “unknown” which makes it trigger the notification automation. The solution for me was simply to put it in the package blacklist since I’m actually checking the sensor “sensor.rest_ftx_water_sensor”. If you’re not using this package you can disregard this paragraph.
When I add more battery powered zigbee devices, I simply need to add one REST sensor to get the right values from deCONZ, and one template sensor to make the determination if the device is still considered available.
For anyone struggling with the resource URL, it’s in the format:
http://YOUR_IP:YOUR_PORT/api/API_KEY/sensors/DEVICE_ID
You can change “sensors” to “lights” etc. More information and how to get started, generating the API key, etc, is available here. This also help with determining the DEVICE_ID.
