Although I use imperial units, I prefer the 24hour time format. Please make this a 12/24hr toggle.
@keithcroshaw & @arnb will do. traveling a bit for work so will be a couple of weeks. but will do.
2 Likes
I'm in the same boat. Thanks for the reply.
1 Like
Logs were getting eaten up...I just went through and commented out all of the log.debug entries, and changed the one entry that logs the poll command from a log.debug to log.info. Much cleaner logging now. Any change of getting a debug logging on/off switch at some point in the future?
I had a question also...is the forecast information, specifically perfect precip, for the next day or the next hour?
WU Night Icon Variants
@bangali I noticed that the code appears to have support for the night variants of Weather Underground keys in the forecastIcon attribute, but it appears to be hard coded to day.
On line 285 of the current release, the getWUIconName() call can be changed from:
sendEvent(name: "forecastIcon", value: getWUIconName(obs.current.condition.code, 1), displayed: true)
To:
sendEvent(name: "forecastIcon", value: getWUIconName(obs.current.condition.code, obs.current.is_day), displayed: true)
Was it hard coded for some particular reason or maybe just a remnant from testing that could be corrected?
Attributes Now Reporting in SharpTools.io
Just an update that the Hubitat 2.0.6 update includes some enhancements around this. SharpTools.io can now dynamically request which attributes to subscribe to so it can get events from 'non-standard' attributes like those used in several weather drivers.
localSunrise and localSunset impact
Also just a comment that the removal of the localSunrise and localSunset attributes means that sunrise and sunset will no longer be reflected/updated in the SharpTools weather tile.
2 Likes
yes will add this weekend. there is some pending work to add selectable attributes to publish intend to finish and push that as well.
1 Like
will check this weekend on why it was only publishing the day time icons. dont remember explicitly coding it to do so … so might just be a left over or bug.
did you want me to put the localSunrise and loclSunset attributes back in or that was a general notification for users so they update it in their sharptools config? 
1 Like
Bringing them back would be great. Otherwise users miss out on sunrise/sunset altogether. 
1 Like
updated to github with the following changes:
* Version: 5.0.0
* 3/10/2019: allow selection of which attributes to publish
* 3/10/2019: restore localSunrise and localSunset attributes
* 3/10/2019: added option for lux polling interval
* 3/10/2019: added expanded weather polling interval
2 Likes
Excellent update, @bangali!
One thing I noticed is that there is no wind or feelsLike entry in the attributesMap, so there's no way for the user to turn those on and thus they wont get published under the new sendEventPublish approach.
I also posted that as a comment to your GitHub along with a request to distinguish the description of localSunrise and local_sunrise in the attributesMap as they both read as 'Local Sunrise' (same with the sunset).
--
I haven't tested to see if it's an issue here, but one thing I've run into in the past is that if a device is defined as including a certain capability, but it doesn't publish the attributes associated with that capability, it can cause Hubitat to hang when trying to introspect the attributes.
// For Example:
// If a device indicates that is has the 'Switch' capability
// but it never defines a 'switch' attribute
// then code like this can cause the hub to hang
device.supportedAttributes?.collect {[
name: it.name,
dataType: it.dataType,
values: it.values
]},
Again, I haven't run into this in a while, so I haven't tested it recently. Ideally the platform would be able to work around this without hanging, but it's something I wanted to throw out there since you are now defining capabilities like Temperature, Illuminance, Humidity, Pressure, and UV and users have the options of disabling the publishing of those attributes.
--
One other minor comment is that once an attribute is published, there doesn't seem to be a way to 'unpublish' it... so perhaps the first post could be updated to call this out as an important configuration step?
While unchecking the option for those attributes would at least reduce the events on the system, it still keeps the attribute defined on the device which increases the burden on apps / the hub when trying to iterate through properties of the device.
Again, awesome work on the updates! Keep up the good work!
1 Like
Hi, thank you for your efforts. The driver is working. Now how can I get (if it is possible) a single Tile in a Dashboard with a resume of the gathere infos and some graphics?
Search this thread for 'mytile'.
I'm not so lazy… I evidently am so old 
I did'nt find!
Thanks it is working now.
@josh i will come back to this next weekend.
@damon.dinsmore thanks … pushing a release with this fix.
1 Like
Just downloaded the driver and installed. When I go to input my API key and save I get a 500 error in hubitat. Am I doing something wrong?
Nevermind Got it working user error
1 Like
I am wondering if anyone gets this problem with this weather.....I would like to have some of my indoor lights come on when the lux is below a value outside (ie: rainy day) and today it is has been rainy all day but my ApiXU says that it is Sunny. The destination is correct. Anybody else get this?
Are your logs showing that ApiXU is running and polling successfully?
I don't know what your Zip is, but using 'L0P' I get:
condition
text "Light rain"
icon "//cdn.apixu.com/weather/64x64/night/296.png"
code 1183
wind_mph 15
wind_kph 24.1
wind_degree 360
wind_dir "N"
pressure_mb 1005
pressure_in 30.1
precip_mm 0.8
precip_in 0.03
humidity 93
cloud 100
feelslike_c -3.2
feelslike_f 26.2
vis_km 16
vis_miles 9
uv 0
gust_mph 16.1
gust_kph 25.9
You can 'manually' get the JSON data the driver receives by pasting your Key and Zip over the corresponding words of this:
https://api.apixu.com/v1/forecast.json?key=apixuKey&q=zipCode&days=3
1 Like
