ESP32-C3 collects some sensor data from BT sensors and sends them to HA every 10 seconds
If data is not received in (say) 30 seconds, the sensor should become unavailable in HA
This works ok if the ESP32 stops sending data. The sensors indeed becomes unavailable.
Problem: the sensors become unavailable also if ESP32 succesfully sends the SAME value thrice during the 30 second window.
Why is the last_updated not working as expected and does not get updated even if the data is the same? Shouldn't there be a last_changed for that case? Or am I misunderstanding something else here?
(I'm still a n00b so I might've missed something important.)
No! Just learning and trying things out with HA and ESP32. And I definitely would like to know what other and better ways there are and what are their stregths. AFAIK MQTT at least helps to reduce the network (and power) usage. I guess quite easy to implement. What other benefits MQTT or HA api has over webhooks? Would they make it easier to create what I'd like to have? At least it feels nice to be able to know if a device stops sending data and goes offline for prolonged time.
And I guess eventually it would make sense to just use ESPHome on the ESP32. But let's not change all variables at once
Thansk, totally missed these three properties. last_reported is indeed the one I need in this use case.
But, it does not seem to work. The following also does not display anything for last-reported:
Ah, if you are not using ESPHome then things are way, way more difficult. I would definitely look into ESPHome because you'd probably need only a few lines of yaml to define the entire firmware and have the sensors in HA the way you want them to. Whatever you are doing is much, much harder.
Last reported does not show in the attributes, but it is definitely there. It was added later, the card whs implemented before and probably did not add support for it later on. Try this in the template tester. It shows last_reported for the sun.sun entity:
FYI, when using trigger-based template sensor, you can store any additional data you need in the sensor itself, as an attribute. The data will survive Home Assistant restarts. So, your template might look something like this (untested):
template:
- trigger:
- platform: webhook
webhook_id: esp32_multi_room_update
allowed_methods:
- POST
local_only: true
- platform: time_pattern
seconds: "/10"
sensor:
- name: "Living room Temperature"
unique_id: living_room_temperature
device_class: temperature
state_class: measurement
unit_of_measurement: "°C"
state: >
{% if trigger.platform == 'webhook' %}
{{ trigger.json.living_room.temp }}
{% else %}
{{ this.state }}
{% endif %}
attributes:
updated: "{{ now() if trigger.platform == 'webhook' else this.attributes.get('updated') }}"
availability: >
{% if trigger.platform == 'webhook' %}
true
{% elif this.state is undefined or this.state in ['unknown', 'unavailable'] %}
false
{% else %}
{% set u = this.attributes.get('updated') %}
{{ false if u is none else (now() - as_datetime(u)) <= timedelta(seconds=30) }}
{% endif %}
FYI last reported has not been implemented on template entities. I haven't looked into the system yet, but I don't believe it's a built-in system. I believe I have to add it.
It is documented in the official docs for the state object and the first built in integration I checked had it. But it is of course possible that not all integrations set it.
I think it defaults to just update when last_updated or last_changed updates and integrations need to go out of their way to provide a timestamp when an update was received and the state didn't change. I haven't looked into this at all but @karwosts mentioned something like this in the past. I'm going off memory here and could be completely wrong.
