uhm curl line with my key works indeed
The formatting was destroyed with cut and paste,
In my config it is the same as on top
I will try to delete it and rewrite it (talk about computer science problem solving …)
Ok. If it still doesn’t work, then you could try making a small change to illuminance.py to have it output the url to the HA log. I.e., starting on line 38, change:
resp = await session.get(
_API_URL.format(api_key=api_key, features='/'.join(features),
query=query))
to
url = _API_URL.format(api_key=api_key, features='/'.join(features),
query=query)
_LOGGER.debug('url: {}'.format(url))
resp = await session.get(url)
Then check the log to see what the actual url is that it’s trying to use.
1 Like
strange enough the _LOGGER.debug() is not working…
So I put the url inthe raise clause…
2018-07-06 17:45:18 ERROR (MainThread) [custom_components.sensor.illuminance] ValueError: (‘Error from api.wunderground.com: No cities match your search query’, “http://api.wunderground.com/api/MYapiKey//q/‘pws:IBRACCIA6’.json”)
reinan@ReinasServer:/home/homeassistant/.homeassistant$
The only thing I notice is an extra backslash after the key and a missing “conditions” string.
So I think this is the problem
Where shall this come from?
Actually, when the component is setup, the first query will be without conditions, so there will be two slashes. So that is not unexpected.
The problem seems to be an extra set of quote characters around your query string. And actually, they seem to be fancy curly quotes, not the simple single quote character. This is why formatting your config when you post it is so important. I suspect if you edit your config file, and change the fancy curly quotes around pws:IBRACCIA6 to simple single quote characters, that will fix the problem.
1 Like
And there was light (a lot, it’s hot over here!)
Thanks
One more lesson learned… It was indeed the extra quotes in config.yaml
Glad you got it working. Just to be clear (and for future reference), quoting the string is not a problem, but using the wrong quote character is. For example:
query: 'pws:IBRACCIA6'
is ok, and
query: "pws:IBRACCIA6"
is ok, but
query: ‘pws:IBRACCIA6’
is not ok.
1 Like
Thanks for this 
I’ve just set up and and it seem to be working well.
Now I just need to decide how best to use it for some automations 
1 Like
I’ve updated my repo to add support for custom_updater. See: https://github.com/pnbruckner/homeassistant-config#custom_componentsjson. (None of my code had version numbers, which I just added, so you’ll probably have to update if you use, or want to use, custom_updater.)
1 Like
Many thanks for this custom component @pnbruckner. I’ve been looking at the data it has been reporting over the 2 weeks & it’s generally quite accurate to the current cloud conditions throughout the day.
I just wondered, if I have questions on how best to integrate this component with the sunset scrips I already have, where would be the best place to ask?
On this thread or shall I create a new one for my questions?
many thanks
I would recommend creating a new topic. If you like, you can create that topic with a pre-populated message (that you can edit before submitting) that says something like “Continuing discussion from…” and it will include a link to this topic. If you see the Share button (the one with the link icon, either at the bottom of this topic, or below your own message above), and if you click on it, it gives you the option to start a new topic. Just click where it says “+ New Topic”.
1 Like
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