Outdoor illuminance estimated from weather conditions reported by Weather Underground


#41

I’m so happy you’ve added support for YR.
I use YR as it’s “Out of the box” so happy to not have to add a second platform just for this.

(also commenting so that I can easily find this again and try it once once I get chance!)


#42

@INTEL & @klogg (and anyone else interested :wink:), I’ve updated the beta implementation to only periodically update when using WU. When using entity_id (with YR or Dark Sky), it will now only update when that entity’s state changes (kind of like how template sensors work.)

If you try out the new beta (2.0.0b3) let me know how it works for you.

I’m going to use it for a day or so before I release this change.


#43

Updated (beta) documentation available here.


#44

Ok, so obviously I need to add periodic updates back in for the “ramp” periods… Stay tuned.


#45

Beta version updated (to 2.0.0b4.) It now should properly ramp up and ramp down the estimated illuminance value for non-WU sources around sunrise and sunset. The link to the beta version I provided a few posts above is still valid if anyone wants to give it a try.


#46

Testing atm and it’s giving out 10lx which is probably OK given it’s night here :), will see what happens in the morning :slight_smile: Many thanks for the work you put into this :slight_smile:


#47

Beta version updated (to 2.0.0b5.) Adds one more update after sunrise or sunset “ramp period” has ended to make sure it reaches the estimated value.


#48

Released 2.0.0.

Adds support for Dark Sky & YR entities as source of current weather conditions. For WU, no longer get sunrise/sunset data from the server, just use HA’s sun data. Add documentation.


#49

seems the updater is confused?

01

update manually for now


#50

in my ui, everything is ok:
updater


#51

Are you using Custom Updater 3.1.8? If so, then can’t explain. If not, then that might explain it.

EDIT: Unless you tell it to check for updates it only does that on its own once a day. That could also explain why it was still seeing 1.0.0.


#52

maybe that. still thought it peculiar it saw 1.0.0 as an update to 2.0.0b5. Unless betas don’t count?


#53

It doesn’t compare versions. It’s pretty simple – it only knows what you have and what is available at the source. If they’re different then it shows it as having an update which, to me, is the way it should be.


#54

ok, I’ve worked it out.

please allow me to ask: the sensor illuminance shows 10 lx when dark, is that correct? Im not sure about the true lux numbers, but my philips light sensors go down to 1, and have many settings between 1 and 10.

lx is calculated as follows: lx = round(float(10**((lightlevel-1)/10000)), 2)

this is what Philips uses for their scale:

#Philips Hue definition                 Lux               MeasuredValue
#Overcast moonless night sky              0.0001                  0
#Outdoor: Bright moonlight                1                       1
#Home: Night light                        2                    3000
#Home: Dimmed light                      10                   10000
#Home: ‘Cosy’ living room                50                   17000
#Home: ‘Normal’ non-task light          150                   22000
#Home: Working / reading                350                   25500
#Home: Inside daylight                  700                   28500
#Home: Maximum to avoid glare          2000                   33000
#Outdoor: Clear daylight            > 10000                 > 40000
#Outdoor: direct sunlight            120000                   51000

and this is the sensitivity in home now:

42

while your yr sensor shows:

23

supposed to be darker outside then inside… is this a factor 10 off somehow?


#55

It’s just a rough estimate. It’s not intended to be anywhere near as accurate as a light sensor. It only has a few levels: 10, 200, 1000, 2500, 7500 & 10000. And during an hour around sunrise and sunset it scales that value. It’s an algorithm that someone else implemented in Samsung Smartthings that I used when I used ST, and borrowed when I moved to HA. It’s been good enough for me to drive light simulations when we’re not home. It’s not intended for anything but that.


#56

Ok I understand, thanks for explaining. Should have read your documentation (…) better.
With all these weather components, there must be one with a true measured light level? Seems too silly to not exist.

for reference:

http://www.domoticz.com/wiki/Real-time_solar_data_without_any_hardware_sensor_:_azimuth,_Altitude,_Lux_sensor

another(@Kobold 's) sun.py using the above: https://gist.github.com/anonymous/9dde1a5fadef4178bc288939176ee0d5
(note: also creating attribute daylight, but with another meaning: light level, vs amount of time from today’s sunrise to today’s sunset (in seconds) )

Maybe you would consider adding an extra attribute light level too to your enhanced sun CC?

and a thread here dedicated to the subject: Virtual light sensor


#57

I’m now using this with DarkSky and today (now) I have a situation where Illuminance is giving

image

but the sun is showing

image

and the Dark Sky icon is

image

and Dark Sky cloud coverage is

image

Is this correct?
(Or maybe I have something configured wrongly - always an option!)

For the record here is todays Illuminance graph.

EDIT: While I was writing this it has been going down as expected so maybe this is all expected but if that is the case then I think the times today when it went down to 1000 may be suspect as it is a lot darker now than it was at any time during today. Despite the weather we’ve had!


#58

Remember, this component can not look out your window to see how bright or dark it is! :wink:

It’s simply using the reported weather condition summary and looking that up in a table of estimated values, and around sunrise and sunset it ramps the value up and down. That’s it. No magic. As I said, I got this algorithm from an implementation someone else made that I was using in SmartThings. I don’t claim it’s perfect, or even very good. I’m sure there are better estimates out there – @Mariusthvdb pointed out a few. But it’s been good enough for my automation needs, at least with WU as the data source. I’ve been noticing that YR and Dark Sky don’t often agree with WU, or each other. So ultimately, this is limited by the weather data source. The more accurate/timely it is the better, and vice versa.

At this time I’m not looking to make this a better, more accurate estimation of outside light level. I appreciate the feedback and suggestions, but that’s not on my to-do list. I’ve bookmarked the suggestions and at some point down the road I may try some improvements.

So, bottom line, what you describe is kind of what I’d expect.


#59

No problem., No criticism was meant, I am very appreciative of all your work not just on your custom components but also in answering questions here.

It was as you say, only meant as an observation in case you wanted to act on it but there is definitely no expectation on my part that you do.

Thanks again.


#60

fwiw, my ‘local’ weather component Buienradar, is horrifically slow at boot, causing all kinds of timing issues. And when all has finally been initiated, I see big differences between the components Yr, Yahoo, Buienradar and Open weather map.

Even on Temp or windspeed. Its amazing to experience that, and makes one wonder about the reliability of things.

To keeps things short: ultimately, a hardware light sensor is the only reliable source for outdoor illuminance i am afraid. Pointing my indoor sensors to the outside works fine already, and the soon to be released outdoor sensor for my Hue system should offer final answers… I hope.