Looks like WU will stop working by the end of the year. Any hope for this to work with darksky?
I’ve heard this once before. Where do you see that?
In any case, since at the very least WU has stopped giving out free API keys, I’ve been thinking about basing this sensor on another weather source. The one that seemed the most obvious is YR’s symbol option, since YR seems to be the default weather source for HA. I spent a little time already figuring out what many of the symbol numbers mean, and I just now found an article on yr’s website that explains (in English 
) what all the symbols mean, so I should be able to base the illuminance sensor on that data. And the nice part about using YR is I don’t have to query the server - the YR component already takes care of that. I’ll add this to my “to do” list!
I suppose I could also look at darksky. Do you see that as a significantly better source for current weather conditions than YR?
EDIT: See issue #54 on my github repo. Feel free to comment there as well.
1 Like
Here is the info about WU.
I’m using DarkSky for weather forcast, and for now I can tell it’s reliable. I didn’t use YR since lovelace introduction.
Thanks. There does appear to be a slight chance of use beyond the end of the year given this statement:
For developers who use WU API data for non-commercial purposes, you will have access to a new plan for a personal use, low call volume API. Stay tuned for more details as we build this out.
Of course no idea what that will be, or if there will be a charge to use it. Interesting, though, that I didn’t find out about this more directly. I did register for an API key, so not quite sure why I wasn’t directly informed somehow. Oh well.
Do you just like darksky better, or is there some reason you couldn’t use YR (possibly in addition to darksky just for this platform)?
FWIW, I have an initial implementation of my illuminance sensor platform that still supports WU (for now), but can use sensor.yr_symbol’s state instead. I still have work to do to make it more flexible, and I want to see how the estimated illuminance values from YR compare to the values derived from WU for a while, but this looks like a viable option to WU.
I’d be happy to look at darksky as well. Do you use the Dark Sky or Dark Sky Sensor component? Also, until I get this set up, can you share what the corresponding entity/entities look like? I’d need something that indicates, directly or indirectly, the current “conditions” (such as clear, rain, cloudy, etc.)
I’m using custom animated dark sky in lovelace, but if you have working YR sensor I could give it a try with one of my lights.
@pnbruckner It’s just a guess but I wonder if a lot of people are using Darksky for this
very reason?
It’s not a big deal but my vote would go to using DarkSky if that is possible, I don’t use yr weather and it’d just be cleaner to not add another weather component.
@INTEL & @klogg, I got an API key for Dark Sky and added the two component options to my config. I also checked their docs. It does look like this should work, too. The Dark Sky Sensor’s icon option and the Dark Sky Weather’s state provide a value that I can easily translate to estimated illuminance, just like with WU & YR. I’ll work on this and let you know when I have something to try.
2 Likes
@INTEL & @klogg, I have a beta version that supports WU (by querying it directly as before), as well as YR & Dark Sky (which uses the state of a corresponding entity.) Check out my gitub PR. You can grab a copy of the code here if you would like to give it a try.
I haven’t updated the docs yet, but basically instead of specifying api_key and query in the config, you instead provide entity_id, which should be the entity_id of a YR symbol entity, a Dark Sky Sensor icon entity, or a Dark Sky Weather entity.
If you (or anyone else) does give it a try, let me know what you think.
EDIT: BTW, the current beta implementation updates periodically (as specified by scan_interval) no matter which option you choose. You’ll also likely see an error at startup that says the specified entity_id has no state, but that should probably only happen once, and then on the second and subsequent updates you should get a valid illuminance estimate. The next thing I’m going to do is for YR & Dark Sky entities have the illuminance entity watch them for updates and update accordingly. (I.e., whenever the source entity updates, then the illuminance entity will update immediately based on their new state.)
Thank’s! I have added the sensor (darksky entity) and got my first reading out of it, still waiting for updates trough the day.
I will post sensor readings here as soon as it gets more readings.
1 Like
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:
