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!)
1 Like
@INTEL & @klogg (and anyone else interested 
), 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.
1 Like
Ok, so obviously I need to add periodic updates back in for the “ramp” periods… Stay tuned.
1 Like
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.
Testing atm and it’s giving out 10lx which is probably OK given it’s night here :), will see what happens in the morning 
Many thanks for the work you put into this
1 Like
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.
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.
seems the updater is confused?
update manually for now
in my ui, everything is ok:
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.
maybe that. still thought it peculiar it saw 1.0.0 as an update to 2.0.0b5. Unless betas don’t count?
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.
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:
while your yr sensor shows:
supposed to be darker outside then inside… is this a factor 10 off somehow?
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.
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:
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
I’m now using this with DarkSky and today (now) I have a situation where Illuminance is giving
but the sun is showing
and the Dark Sky icon is
and Dark Sky cloud coverage is
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!
Remember, this component can not look out your window to see how bright or dark it is!
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.
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.
1 Like
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.