I have a Temp sensor and I want to use it in a trigger with multiple ranges
the first one is > 12, < 20
the second one should be >= 20 , < 30
In the configuration for events I do have above and below
but they are > and < 
How do I get >=?
Sounds very weird to me we cannot do it in the config
M
Hi Massimo, you can use templates or if you want to keep it simple:
Lower range: > 11, < 21
and
Upper range: > 20, < 30
Change the second one so it starts 0.01 below what you want. Repeat for all other start temps in options 3 & 4.
Eg. Change:
- trigger: numeric_state
entity_id: sensor.temperature
# At least one of the following required
above: 20
below: 25
To
- trigger: numeric_state
entity_id: sensor.temperature
# At least one of the following required
above: 19.99
below: 25
ouch this is bad 
there is always a hole in it I'll open a change request
Please vote it here:
Issue with numeric state - missing the "equal or" · home-assistant · Discussion #3903
It's a workaround but it too randomic and depends on the precision of the numeric sensor.
I could write 19.99 and then I have a 0.01 gap
And If I write
- trigger: numeric_state
entity_id: sensor.temperature
# At least one of the following required
above: 19.99
below: 25
- trigger: numeric_state
entity_id: sensor.temperature
# At least one of the following required
above: 12
below: 20
I have a 0.01 overlap where both are true
Sure, it's a workaround.
It depends on the precision of the physical sensor, so what?
I don't have any sensors that report more than 3 decimal places - most are only 1 or 2 decimal places.
Hence as long as I state all of my thresholds to 4 decimal places (19.9999) there will never be an actual gap in practice.
If you really care about the "missing" >= operators you have a few options:
You have the full power of Jinja, so in template triggers all the the standard operators exist.
There may be a tiny performance penalty over numeric state triggers, however I would challenge you to come up with any real world scenario where that performance drop would actually cause a problem.
Triggers can have identities (id attribute) and you can use that id as part of later logic for example as a "Triggered by" condition in a choose block.
However you don't have to use the triggers identity (id attribute) as part of your later logic, instead the logic can go back to the actual sensors and do the calculation "correctly".
In that scenario the only thing that the triggers do, is start the automation running.
Given the typically polling delays (30-60 seconds) before updates arrive from sensors, it's possible you might have to wait for one additional polling cycle before the automation kicks off
I care about the delay between when I walk into a room, the presence sensor detects me and the light turns on (fractions of a second are annoying).
In most other cases, small delays or sensors being off by 0.1 etc make little difference to me.
I know that a lot here like to over complicate stuff with template triggers and stuff but really this is what the generic thermostat is designed for, unless i am missing something obvious.
I usually give the same advice (use Generic Thermostats).
However there are cases where you want to do something different, for example display 4 different colors of light, based on the temperature. The OP didn't state what the actual problem they wanted to solve was, heck I am not even sure if that temp is in F or C (probably not K).
Early in my HA journey I got into using Jinja - I found it easier to combine logic (and and or conditions) as a result when I started to need to do more complex triggers, I just cut and pasted the conditions into template triggers.
However I have recently started to take a step back and started looking at using simpler triggers, so I have started using Numeric state triggers in new automations.
This is really a reflection of the "Dumb Triggers" section from my previous post - it doesn't really matter if automations kick off a few too many times - in most cases they are just turning stuff on/off and turning something on that is already on doesn't really matter.
My point is there are some deeper "Philosophical" points around how you view triggers, conditions, logic and more basically how many automations you should have / if they should be small or larger combined ones, where you land on those points may affect your choice to use features like template triggers.
If your sensor reports > .01 resolution, you will have an overlap and will need to add more 9s to the above: part.
If it has <= .01 resolution, then you don't need to do anything. There is no overlap in above: 19.99 & below: 20 if you're using them for separate triggers.
I do agree on all but they are all work arounds
it leaves me very perplexed that on HA we do not have all the correct operators.
It appears to be to be a design flaw and I cannot see any reason on why there should not be the = too
From currently line 792 in core/homeassistant/helpers/condition.py at ffc6eeadc2328f19756ca251c156446f3a090da2 · home-assistant/core · GitHub it can be seen that:
above, it triggers when the value is above the limit (v>l)below, it triggers when the value is below the limit (v<l)ll<=v<=ul)It might be better just trigger off all changes to the sensor and work out what to do in the conditions or actions block. If you let us know what you're trying to do, I'm sure someone could assist.
HA provides multiple ways to solve the same problem.
Some of the approaches provide all operators some do not.
It is incorrect to say that HA does not provide all operators.
This is a requirements question, specifically to keep things as simple as possible for the common use case of someone simply wanting to turn on cooling/heating at a given temperature point.
In the case of simple automations (lets define that as only having a single temperature where the heating should be turned on) and assuming that the sensor reports to 2 decimal places frankly it makes no Perceivable difference if the heating turns on at 18.50 or 18.49 C.
The fact that HA provides additional methods that allow for more precise control (for those that need/want it), means that there is no flaw in the design.