Thanks I will include a few tiles, I changed the icon location to your TinyURL but i still get this
You have that set here, right?:
If so, it works for me and no one else has reported it not working? Perhaps you have some virus/malware protection or VPN/DNS blocking that may be blocking access to that site? Do you need to whitelist the link location?
You could try the non-TinyURL link to see if that be be the cause. The TinyYRL points here so it is the same location:
https://raw.githubusercontent.com/HubitatCommunity/WeatherIcons/master/
Hi Matthew
You were spot on, I completely forgot about my PiHole and this was blocking TinyURL. Thanks again.
1 Like
[UPDATED]
V1.2.9
12/15/2019
- Suggested change from @nh.schottfam (Thanks!
) to fix 'pressured' definition (the string version of the barometric pressure) to avoid excess events. This creates no visible change, just better efficiency.
1 Like
I'm just hoping to clarify something. As I understand this thread, MyTile will always show the same things, regardless of what is turned on or off in the optional switches. The only way to show those things is individually on their own tiles, or by making my own other tile.
In other words, if I wanted to show exactly what is in MyTile without pressure or humidity, I'm rolling my own.
Have I got it right?
I believe you understand correctly how it works. The only way to remove any item (or add any item) to MyTile, weatherSummary or the Three Day Weather Forecast attributes is to go into the code and make those adjustments. None of the 'optional attributes' have any impact on the pre-defined tiles.
Matthew
Issue w temperature. Device data shows temp is 17 degrees, MyTile always shows
53 degress
Thanks
I can't recreate this (mine updates as expected). Any errors in the logs? Try clearing the browser cache, maybe?
Great, thanks for the quick feedback. I commented out a few lines in the MyTile display code, and it's perfect. Awesome driver!
1 Like
When importing the code, I'm getting the following error message: "Metadata Error:Please check if you inadvertently pasted driver code into apps code window on line 100"
That's because you posted the driver code into the apps code page.
1 Like
Thanks, that's what I get for doing it early and without coffee. Brain Fog! LOL
Cleared cache, same problem; also no errors in logs. Added new tile using weather tile, temp is correct. Added new tile using attribute tile myTile, temp is always 53.
Thanks
I am stumped. I do not know why this would happen? I have no explanation as to why your myTile would update some data from the driver, but all data from the driver? Mine does not do this and no one else has reported this as an issue .... so I am guessing it is something unique to your setup.
The default weather tile, myTile, the weatherSummary and the Three Day Forecast should all be in-sync when the driver polls the data from DarkSky. Mine looks like this:
The only thing I can recommend is to start from scratch, Remove the virtual driver and the driver code then reinstall the latest code and create a new virtual device and select the new driver code.
1 Like
Matthew
Deleted & recreated device, problem resolved.
Thanks
2 Likes
Anyone experience what seems higher then normal Lux. I originally had a rule setup with Lux and condition codes but it end up getting corrupted and was very long. So the new rule I just based it on lux only but for example yesterday it rained all day but the lux was reading 4-5k and even today its full cloud cover and its 3500+. I usually have certain lights go on when below 3k lux, and but since it's generally higher then that they never go on.
I thought it the driver was supposed to take into count the cloud cover also, or is there specific attributes that I need to enable?
You must select the optional attribute of 'illuminance' if you want it to update when Darksky is pulled. You also would use that attribute in any Rule Machine rules.
Yeah I have had that enabled, I was wondering more for how the driver calculates lux based on cloud cover. I did enable the cloud cover attribute, but was not sure that was even needed. I just find it too dark inside with just lux, seems like I may need to go back to condition codes to compensate for current weather. It's just more complicated with Darksky then APIXU, since the condition codes are not just numbers, so my rule ends up being much more complicated the it really should be.
The lux calc starts on line 1091 of the code. This part of the code was originally written by @bangali and improved/altered by @csteele (and perhaps several others) along the way. It does use the cloud cover attribute (if is is provided) in it's calculation, along with the relative time of day and the condition code. I guess it is possible that if DarkSky is not reporting those elements (or not reporting them properly) for your location that your lux result would be impacted. I have not had an issue with my location and it seems to report consistently and as expected for me.
2 Likes
The Lux calculation has no 'weather' basis initially. Sunrise, Sunset and Noon are acquired for your hub's latitude. Then the Time of Day is used to calculate what is largely a 'sun angle', which is then subtracted from 10,000 lux, a guestimate of what Lux would be if the sun wasn't the sun, and the sky was cloudless. While no two days in a row are absolutely identical, the same day 4 years later would be.
THEN, if selected, cloud cover is used to further reduce the calculated Illumination.
The exact same code is used in the Luxuriant Driver, which is exclusively for Illumination. If you only need Lux, then Luxuriant Driver is a lighter load on your Hub.
2 Likes
