state: >-
{{ states("sensor.xiaomi_cg_1") }}
availability: >-
{{ not states("sensor.xiaomi_cg_1") in ["unavailable","unknown"] and
not is_state("sensor.xiaomi_cg_1",99999) }}
It takes a state of some source sensor (Xiaomi Cleargrass Air monitor).
Why using this “99999” filter?
A couple of years ago a source sensor’s state was “99999” - so this was an attempt to filter these spikes.
To check for a invalid attribute value - I need to compare to 99999 (number).
To check for a invalid state value - I need to compare to “99999” (string).
Why I think so?
First I observed this 9999-issue with a PM2.5 (a state) in year 2021.
I added a check for “99999” (string) for all template sensors from this device (pm25 taken from state & others taken from attributes - co2, tvoc, temperature, humidity).
And there were no 99999-spikes for PM25 since then.
Recently (February 2023) there were spikes for “Temperature” & “Humidity”.
And that check for “99999”-string did not work.
Checked again in Dev tools (manually set 99999 values for “Temperature” & “Humidity” attributes) - and my string filter did NOT work.
Tried with a 99999-number filter - it worked.
So I replaced all my “99999”-string filters with 99999-number filters.
And now I think that for “PM25” (taken from a state) I should keep a “99999”-string filter.