The link I provided quotes the data sheet for that product.
“Stable data should be got at least 30 seconds after the sensor wakeup from the sleep mode because of the fan’s performance.”
I have also personally measured and observed the measurements change rapidly during the warm up period for that particular device, which you can see in this post.
Again, not claiming it applies to this device, but it’s a thing for similar devices (edit: and I see in the chat it appears to now be confirmed for this device).
Some ESPHOME components have options for restoring last value on boot (E.G restore_value: , restore_mode:)
The sensor you’re working with doesn’t appear to have restore options (from what I can see). I suspect it doesn’t restore a value but don’t know how that works.
If you haven’t already, it’s worth looking over restore mode of the light. Possibly on_boot some restoration is occurring. I’ve seen reports on other chats of restore modes not quite working as expected and momentarily causing unexpected states through boot (mainly seen for switches iirc).
restore_mode:
This is looking slick BTW. Looks like you’re making really good progress for such a short time using HA and ESPHome. Nice one.
P.S in case you haven’t found it yet, you can also dig into the API reference and source code if you need to.
There’s also the Debug component, which can report reset reason which could be handy if you are getting unplanned reboots, but you already mentioned adding features is problematic…
on_value:
then:
- lambda:
if (isnan(id(pm25).state {id(blue).execute();}
What about instead of turning on blue light on boot you run a acript called blue when sensor gives a value of nan for being unavailable yet . You will have to write script to turn on the light to blue. You may have to adjust the indentation of my code as typed on phone
Hmm, that could work. The only thing I’m thinking is that it seems like the sensor gives NaN while updating the reading already. If I change during the read (State: Nan), when it returns a value that’s in the same range as before, it probably won’t run the on_value_range script again if it didn’t cross a different threshhold, so it’d be stuck on blue, right?
I did try (and failed) pushing a .publish_state(NaN) during the On_Boot to make sure it cleared, but I don’t think it sees a NaN as a valid value for consideration on whether it’s crossed ranges. I’d almost have to push a dummy value outside the range (i.e. -5), but that would mess with my history.
I did a mixture of recommendations, but ultimately decided to do all the LED calls in scripts (format: led_), then abandon sensor:on_value_range in favor of a lambda under on_value. So, it looks like this…
On_boot:
on_boot:
priority: 500
then:
#turn on blue light
- script.execute: led_blue
Sensor:
sensor:
- platform: sds011
update_interval: 1min
pm_2_5:
name: "PM 2.5µm"
id: "pm25"
force_update: true
on_value:
then:
- lambda:
if (isnan(id(pm25).state)) {id(led_blue).execute();}
else if (id(pm25).state <= 12) {id(led_green).execute();}
else if (id(pm25).state <= 35.4) {id(led_yellow).execute();}
else if (id(pm25).state <= 55.4) {id(led_orange).execute();}
else if (id(pm25).state <= 150.5) {id(led_red).execute();}
else if (id(pm25).state <= 9999) {id(led_purple).execute();}
I like the additional reset to blue when it’s reading. For some reason if the sensor gets stuck and pulls in a NaN, it won’t give a false indication on the LED by staying from a previous state.
