[SOLVED] Rollershutters based on light brightness (lux)

Hey all,
My rollershutters are closing/opening based on astro binding sunrise & sunset. As this was not precise enough I bought a light sensor which gives quite nice lux values.

Based on this lux value I can close the rollershutters now (when lux <= 50 && rollershutters == OPEN).
When thinking about enhancing the “opening the shades” with that lux value something came to my mind:

  • When the automatic outdoor lights are getting activated due to movement, the lux value might increase so that rollershutters do open…
  • Or kids playing with a light torch lighting the sensor so that shades go up and down after few minutes not lighting the sensor any longer. Very funny game I could imagine.

Anyone an idea how to overcome this drawback? Something with percentage change over time? or lux value must be lower X lux for Y minutes to close/open shades?
Thanks for your ideas.

Are the potential issues something you face already, or you think it is a risk?
In case of the latter, I would give the idea a miss :smiley:

Also, I am interested to under stand why the astro data was not precise enough?

Working with light values has its won challenges, like very dark clouds during the day, may let your rollos down in the middle of the day.

I am simply curious… as I have ordered a better light sensor for my ambient light level controlled lighting. In this case I want the lights to explicitly react to the ambient light level, until told otherwise.

Hey Max,
thanks for your reply. You’re right. This is only in theory and not a physical problem right now. But there are loads of cases this might happen. Playing kids or a cat walking by and triggering the motion sensors is just 2 possibilities. I’d like to be prepared when working on this implementation.

The astro binding was mainly not precise enough as sundown doesn’t mean its dark outside. Also with days getting longer/shorter the sundown offset needs to be tweaked every now and then.
Closing the rollershutters when its really getting dark was the my goal here. And it works like charm already.
My sensor has a quite big scale. from 0 Lux to 10.000. I close the shades once value is at 50. Sunny day is 8.000. Night is 0. Cloudy day around 300 - 1000.
This gives enough room to set proper values where rules can react on. And rollershutters wont close when its cloudy.

In fact I still want to verify in my rules if there is “abnormal” light from a torch or outdoor lights to NOT open the shades.

I’ve played a lot with this, too, as I have venetian blinds that you can set to a opening percentage depending on light level.
I’m combining two light sensor outputs, plus movement, plus astro sunset, plus day of week, plus… well, it has become the largest rule in my house already full of rules :slight_smile:

Long story short, to avoid the same problems that you proposed might happen, I’m persisting lux levels and use the average value of the last X minutes (X= 2…20) like in
var int Lux_avg = Garten_Auge_Lux.averageSince(now.minusMinutes(Lux_Nachlauf))

2 Likes

Also consider filtering the time series of the brightness to hide the “spikes” from events like motion-activated lighting. The underlying process of the earth turning is pretty slow and predictable.

Since openHAB pretty much sucks for dealing with state variables, I’d stick with something like Kalman filtering, at the most complex. The derivation looks hairy, but it comes from the days of discrete logic, long before “CPU” was a concept.

Oh dear. Didn’t know Kalman so I googled … do you want to code THAT in our rules DSL?
To mitigate the influence of spikes was essentially why I chose the average over time. And it’s a builtin function :slight_smile:

Kalman filtering will predict which is a nice thing, since you’re looking at a slowly time-varying parameter. Yeah, DSL is challenging, to say the least. If you’re able to kill the spikes with a simple moving average, great! Might want to consider median instead of mean, but if its working…

Kalman filtering isn’t as bad as the “raw” equations look. You could do it on a Z80, or in discrete logic. If you want to pursue it further one day, http://bilgin.esme.org/BitsAndBytes/KalmanFilterforDummies looks like a decent place to start.

1 Like

Thanks for all the input. Really appreciate your ideas.
I started implementing a 5min history “average” solution as @mstormi suggested. Seems to work quite nice and peaks in Lux values are flatted properly.
Again, thanks for your ideas to get me going.

Hi Sebastian

How did you connect the sensor with openHAB ? Is it Z-wave compatible ?

Thanks

Hey karld,
Doesn’t matter which connection the device uses as openhab handles all protocols properly in the backend. In my case the lux sensor is homematic. But indoor I also have Fibaro zwave sensors.
Best

Well, yes and no… OpenHab use “can” handle all protocols… but you need an adapter for some specific (like Z-Wave, you need a USB receiver). And I asked because I have only rfxcom so far