Light Sensors & Cloud Suppression: improvements

[m0r0c0ns]

Hello, I would suggest 2 improvements for the "Light Sensors & Cloud Suppression" section:

1. I noticed that when a value is reached (for example "Lux threshold") the cover goes almost immediatly to the corresponding position. That's a problem when you have, let's say, a cloud hiding the sun for a very little time: the cover goes up and down unnecessarily.
   So, would it be possible to add a configurable delay (condition needs to be true for x minutes to move the cover)?

2. When the real measured or reported value constantly fluctuates around the configured value, then again the cover moves unnecessarily. To prevent this, would it be possible to add a configurable hysteresis?

Thank you very much for considering this feature.

[jrhubott]

These are honestly the two most common asks I get about cloud suppression, which is why the wiki page exists.

Right now the cloud-suppression handler checks the lux and sun thresholds instantaneously, with no debounce and no hysteresis band. So the up-down cycling you're seeing on a passing cloud is how the current handler is built, not a bug.

You can get both behaviors today with a template sensor, though. For the delay, wrap your lux sensor in an HA template binary sensor and use delay_on (add delay_off too if you want the reverse debounced) so the condition has to hold true for 5 minutes before it flips: that's your configurable delay. For the hysteresis, use a two-threshold Schmitt-trigger template, on below 2500 lx and off above 3500 lx, so noise around one threshold stops triggering repeated moves. That hysteresis pattern actually came from a community contributor, @MSL-DA, who ran into the same problem you're describing.

The simplest setup, Variant C on the wiki, folds both into a single "Is Sunny" binary sensor, with delay_on/delay_off plus the two-threshold band baked in, wired straight into the integration's "Is Sunny binary sensor" field, and the Lux entity left unset.

I'd still like to build both natively into the cloud-suppression handler at some point since they're good candidates for it, and I appreciate you laying it out this clearly. I opened issue #864 to track it. For now, the template route gets you exactly what you're asking for.

For details, see the Handling variable cloud cover wiki page.

[m0r0c0ns]

Hello,
sorry for the late reply. Shame on me, I didn't check the wiki before posting!
I'll give a try to the template, altough it is not as convenient as an integrated solution, and will follow issue #864

[Bastituta07]

Hi everyone, I'm also concerned about this issue, as the constant up and down movement caused by passing clouds is surely not good for the roller shutter motor in the long run. The template is a good workaround, but it would still be great to be able to integrate it directly. So thanks in advance for the quick implementation.

[jrhubott]

Yeah, that constant chasing of every cloud shadow really does add up on a roller-shutter motor over time. It's exactly why I filed #864 instead of calling the template workaround good enough. Follow that issue for updates on the native debounce/hysteresis work.