@123 No, just I thought if the entity state value was changed, last_changed would not get updated, but last_updated would (I have never been absolutely clear on the difference though).
@Didgeridrew thanks - not ventured into these before.
However, I donāt believe itās the solution. For example, after you create it, its value will be unknown until ble_weight exceeds 70. The moment you Reload Template Entities or restart Home Assistant, it will go back to unknown.
If you attempt to compensate by adding additional triggers to handle reload/restarts, it introduces another problem.
On restart/reload it will simply set the Template Sensorās value to the current ble_weight (and refresh last_updated/last_changed).
If you attempt to mitigate that behavior by enhancing the state template with a test to check if ble_weight is >= 70, then youāre right back to the where you were with your original Template Sensor.
ā¦ but donāt let me stop you from trying it; maybe Iām wrong about how itāll work.
You are correct, but that is no worse than it is currently as the base sensor reports unknown on restart for a period.
Thanks for the suggestion, it works (of course). However, how do I add the second sensor? Duplicating that and changing the sensor names, complains of a duplicate label in VSC.
I can see the documentation says You can define multiple configuration blocks as a list. but TBH Iām not sure how to do that and perhaps an example of this would help .
Also, I have a number of sensor templates, getting to the bottom of the documentation (looking for multiple sensor examples) I see that this format seems to be deprecated (in my sensors.yaml - this also has the unknown at start problem of course).
I keep forgetting that availability was added to all Template entities recently (mostly in the September release) including this bug-fix for Trigger-based ones. On some rainy day, I should review all of my Template entities and enhance them with availability.
Iām thinking that I need to set the state via an automation rather than a template as I need a trigger (base sensor updated) and a condition (greater than the threshold).
Definitely a job for Node-Red then.
For future reference, Iād still like to understand the syntax for specifying more than one trigger/sensor pairing.
Yeah, thereās that too; standard behavior for Template Trigger and Numeric State Trigger (ālatchingā that must be reset before it will trigger again).
Quick and dirty method is create an automation with a State Trigger monitoring the ble_weight sensor. Use a Template Condition confirming trigger.to_state.state is >= 70 (or a Numeric State Condition). The action is a service call storing trigger.to_state.state to a Helper like an input_number or input_text. The Helperās value survives restarts and itās updated/changed only when the sensorās value is above 70. Only drawback is itās a Helper, not a sensor.
If it has to be a sensor, it can be done with an MQTT Sensor (assuming you already use MQTT for other purposes, otherwise you would need to set it up first).
EDIT
Just read what you posted while I was typing furiously ā¦ Looks like we have the same idea about an automation.
template:
- trigger:
- platform: time
at: input_datetime.whatever
sensor:
- name: 'cat'
state: '{{ ... cat template... }}'
- name: 'dog'
state: '{{ ... dog template... }}'
binary_sensor:
- name: 'up'
state: '{{ ... up template... }}'
- name: 'down'
state: '{{ ... down template.. }}'
- trigger:
- platform: state
entity_id: binary_sensor.something
to: 'on'
sensor:
- name: 'fish'
state: '{{ ... fish template... }}'
This example shows Trigger-based sensor and binary_sensor entities but you can also define standard non-trigger-based sensors, binary_sensors, and numbers. See the documentation for examples.
.
.
