As You can see I have 2 input_text with some digits. If the temperature go in one of 3 intervals I receive 3 different messages.
That’s works like it shoud. But is I want more than one temperature sensors I need to repeate this code multiple times. this is because You cannot add “entity_id” option in platform: template. It’s not perfect from my point of view.
on each state change below the set threshold the automation will fire. You’d have to at least set some extra conditions to not trigger per 0.1 degree, imagine 5 sensors triggering this
would only make sure the trigger is below the input. But if it changes and stays below that threshold, it would constantly trigger on each state (and attribute )change.? Or why am I missing
Ok, you see what’s happening of course. I would at least add something like:
- condition: template
value_template: >
{{ trigger.to_state.state is not none and
trigger.from_state.state is not none and
trigger.to_state.state != trigger.from_state.state }}
to prevent it from triggering on all attributes changes.
I receive messages only when:
a. system started and receive sensor information (once per sensor)
b. sensor state switched from one interval to another
c. on HA restart I receive unavailable status for all sensors. that’s because deconz is no more connected at this time.
d. looks like after I’ve asked about sensor states over telegram (i have an automation for that)
There was a strange behavior if I change temperature limit over lovelace. but
a. it ok. just once
b. I’m not sure it fires now. need to test more.
ATM it’s looks perfect for me. Someone know how to disable an automation on shutdown? It’s doesn’t work like this
@Mariusthvdb Too bad, You was right. On previous configuration (W/O conditions) i received messages only when states moved from one intervat to another.
With conditions it fires each time temperature changes. At least for outside. There is no so much changes inside a house…
On first though I thinked to check if Emoji has changed. this is a good point to catch interval changes. But as we automate sensor.outside_temperature not sensor.outside_temperature_emoji I cannot check
{{ triggger.to_state.state != trigger.from_state.state }} for emoji sensor…
yep, as was expected I am afraid.
you could maybe add a range for the change, say 1 degree? That way it wouldn’t trigger on each tenth of degree the sensor measures.
Also add a condition since last_changed > 300 (seconds) ?
Can you explain what you are attempting to achieve with these three conditions? Because as I understand them, they accept any numeric value (and you don’t need three Template Conditions to achieve that).
There are three Template Conditions where each one checks if the value is within a certain range.
Range 1: value < low
Range 2: value >= low and value <= high
Range 3: value > high
1 | 2 | 3
---------|----------|---------
| |
low high
If the value is within any one of the three ranges, then the condition is true. In other words, any numeric value is valid. Removing the entire Condition section will achieve the same result.
first trigger is false, second trigger is true. action fired.
At leat it work like this (my first post without conditions and triggers platform: template). Resulting message is different because emoji sensor changes (not in this automation) .
When I use conditions I get a message on each state change of the sensor.outside_temperature.
It’s OK to use 3 triggers w/o conditions. But I cannot use that way when I want this automation for many sensors.
Outside sensor is a single entity. Indoor sensors are many. And I don’t want to write 5-10 identical automations with only one difference - entity_id. That’s why I try to find a way for templating this.
@123 's condition should be your main condition. Add 2 extra conditions, ( last_triggered >120, and difference > 1 degree) and my set for not triggering on attributes (the none set)
Also, if you want the automation to be able to use its last_triggered in a condition, you best put the conditions in the action part, and not the condition part.
the last_triggered isn’t set until the automation reaches its action part, and conditions preventing that, will also prevent the use of the condition last_triggered > 120… Sounds a bit cryptic, but thats just the way automations work.
@Mariusthvdb, last_triggered >120 will set minimum interval between messages for 120 seconds and difference >1 minimum value changes for 1 degree, right? I can’t see how it helps sending messages only when temperature interval changes. Did I miss it?
Will modify sensor and automation definition. Will it help in my problem?