OK, kind folks of openHAB. I feel kind of stupid right now. My Google foo is failing me.
So here is the deal. I get a Solar Radiation value from wunderground as part of the current conditions. No problem. And I think I understand the values I’m receiving (i.e. how much energy I’m receiving from the sun at that time in W/M sq) though the values seem a bit low for my altitude.
What I can not figure out is does this value correspond with how bright it is outside right now? Or does this figure include all the UV+ and IR- light ranges the sun is emitting? I’ve plotted the values against whether it is cloudy or not outside and I do see a correlation.
I know, my cloudy chart (the blue one at the bottom) is wonky because I’m probably using mean as a fill.
Ultimately I’d like to know if I can use this information, maybe with some other information available from Wunderground, to get a measure of how bright it is outside which I can use to drive my lighting during the day.
I’ve tried to apply the solution here but I have no Synop stations that are broadcasting nearby.
For now, I’m just using whether or not it is cloudy based on current conditions. But I would like something a little smarter without deploying a light sensor outside, which I will do eventually but am not ready to do just yet.
It appears to be accurate enough for my purposes, assuming I am understanding the numbers and the data is coming from a station less than a mile away. I’m already using current conditions and that is accurate enough for my needs.
But if you’d rather challenge my question rather than being helpful that is fine too, or as my southern us born mother in law would say, bless your heart.
I know I can buy and or build a device that will be way more accurate. And I plan to do so. I said as much in the OP. But that won’t be for quite some time. So I asked the question to see if basing it on solar radiation might be a useful alternative.
To me the question is not how bright it is outside, but how bright it is INSIDE, in the area/room you want to control. So gating off a luminosity sensor (I have an Aeotec DSB05 – I think) in the room in question makes more sense. If it is bright outside, but the room you are in is North/NorthXern facing, it will be dimmer in that room. I did this with my kitchen, skewed with daynight and adjusted for luminosity. It is a South-facing room, but there are buildings across the way and the natural light comes in thru the curtained door to balcony. I (for one) can stumble around for coffee without too much light but when I have a knife in hand for slicing, I want it to be well-lit.
I have been through this and it’s trickier than it looks.
First things first: the solar radiation is useless when trying to control visible light, (the luminous flux as you well said contains the full specter including ir and uv) unless you calculate the illuminance, which as I recall has to be done for specific wavelengths! For the sunlight, I remember there was an approximation for getting the lux level (this one is useful), something like lux*0.0079=W/m2.
Second thing: what and how do you want to control in terms of lighting level? The best constant lighting environment is obtained using PID control. Take care, if you don’t have accurate data about clouds, things might get weird! Of course per room calibration is necessary and you need a lux meter for that.
Yep. My comment was way too brief - sorry - but that’s what I meant when I said weather binding data isn’t local enough.
We don’t know the exact purpose Rich you’re after, and yes, I’m rather challenging your question than being helpful - another sorry -, but at times, don’t we all need someone to ask if we really want to proceed through that tunnel in front rather than to take the (way nicer and in the end possibly even faster) long path across the hill ?
From a distant and long term perspective, it’s surely beneficial to have as much and as up-to-date and as local data as possible … I’ve got luminance sensors in many rooms and outside and use their information to auto-light and auto-shade, and I found that each and every room is different, so you need per-room local data to get (potentially several) luminance-dependent job(s) done in the best possible manner.
That is what I feared. Thanks for the clarifications. I’ll continue to work with just the current conditions for now. It works well enough. I was just hoping to replace a big ugly mapping from current conditions to a isCloudy boolean with a simple if(solarRadiation > 250) but that probably won’t work as well.
I’m not trying to be that clever at this point. If it is cloudyish outside I just want to turn on one of my lamps automatically. It doesn’t matter if the light comes on and it is actually sunny right where I am. It doesn’t matter if the lamp is off when it is actually cloudy where I am. And it doesn’t matter if the light turns on/off with a 5 minute lag behind the actual conditions. I’m not trying to do anything unreasonable with the quality or timeliness of the data.
Ultimately I will have a weather station to tell me what it looks like outside and light sensors of some sort inside to be smarter about this sort of thing.
For now, my main use case is if it is cloudy in the morning I want there to be a good chance (not expecting guaranteed by any means) that the light at the base of the stairs will be on.
I had assumed that my “But I would like something a little smarter without deploying a light sensor outside, which I will do eventually but am not ready to do just yet.” comment would have made it clear that I am aware that the “correct” approach to this problem would be to deploy sensors, outside or inside or both. My main desire is to have a lamp turn on most of the time before I go down the stairs in the morning when the sun is not as bright as it usually is because of clouds or haze or smoke (there are tons of fires in the western US right now and the smoke is drastically reducing visibility where I am). It really don’t need anything all that accurate, precise, or timely for this. In fact using the current conditions from wunderground is working just fine. I just wanted to see if there was an opportunity to simplify my code.
And I don’t fault you for challenging the original question. I often challenge OP’s questions. BUT, after challenging I try to answer the actual answer asked or ask for more information if there wasn’t enough to provide an answer.
I agree. But for my use case that is overkill right now. I will eventually implement that (I have plans for sensors in every room) but that is months or more away. In the mean time I just want one staircase to not be too dark most of the time in the morning when I go down to feed the pets. I don’t even require it to be completely accurate. If it works as well as using the current conditions (i.e. turn on the light if the current conditions indicate clouds from partly cloudy to dust storms) I’d call that a big win.
Seriously, if you have one PROXIMATE problem (i.e. feeding the pets etc scenario), just put a luminosity sensor in. You’ll have to titrate you lux threshold a bit per your personal taste and the sensor’s “personality”, but other than that, I’m with @george.erhan and @mstormi on this one.
That will happen eventually, as part of a wider system of sensor nodes that I will be deploying throughout the house. But I don’t want to start building nodes until I’ve got a good architecture drawn up and time to work on it is really short right now. I will not have the time or money to start building them until January at the soonest.
I already have a rule that works just fine using current conditions. This whole exercise was to see if I could simplify this existing rule with something that works roughly as well. Turns out the answer is probably no given how much non-visible light filters through the clouds that get included in that one number.
This thread served its purpose. I learned something new (i.e. a little more about how radiance is calculated) and learned that it probably wouldn’t work any better than what I’m doing now.