Just realised that the BOM image is missing the radar reticule which is handy to have. Is it possible to include this in the driver?
As in how many minutes ago? Or the colour chart? Either should be ok to include I would think,.
Edit: there may be some complexity for the countdown to try and coordinate this with the radar images.
I was thinking of the 2 concentric circles and the crosshairs that you see in the radar loop on the BOM website. It's another static image I think? Makes it easier to identify where the radar location is (it's hard to see on my 7" screen 
)
I think the colour chart wouldn't be necessary as Australian users kind of know what the colours mean anyway. Also IMO the only useful "minutes ago" image is the most recent one (if that's possible to label somehow)
1 Like
If I can make another suggestion, adding the topography layer would make the radar much nicer looking compared to a single terrain colour.
That's certainly something we can do easily.
1 Like
A new release of the BoM Radar Data File driver is now available, v1.0.0. Thanks to @rocketwiz for his feature request.
- Addition of the Range image as a background image
- New Preference Settings for what background images to include: topography, locations and range
I have left the range image off as a default.
A minor update was required for the Image Cycle driver to allow for 4 background images.
The update is available via HPM.
When installing, it does appear you need to open the image cycle child device and click Save Device, for the update to take effect, if you want to include all the background images. Side note... I want to work on my understanding of how to better manage changes like this, to reduce the need for user involvement like this.
Simon
1 Like
Looks great - thanks Simon!
1 Like
With a fair bit of rain currently I just noticed that the range circles and cross hairs are hidden under all the rain images. Is it possible to have this as the top layer? Not sure if this is even feasible though but thought I'd ask.
Good idea. I can't see it being a problem. I might introduce the concept of static foreground images in the image cycle driver to achieve this.
1 Like
Sweet - this is now an exact BOM replica!
1 Like
I have updated the HTTP calls in the driver to be asynchronous, to reduce load on the HE hub. Update is available via HPM (version 1.2.0)
1 Like
Thanks to @user1025 for reporting that the radar images were not being detected in recent times. Not 100% sure of the reason why this changed in the way the driver worked, but I have been able to fix it and released an update, version 1.2.1.
1 Like
My old install seems to be working. What was the issue?
That's interesting that yours still works. Would be curious to know what platform version you are running.
It was a weird one... Row 112 in the data file driver, where it is parsing each of the images listed in the HTML returned from the BOM, was previously using it.value.toString() when referencing the array entry (image listing from the HTML), but this seemed to return an array of numbers, which I assume was the ASCII codes for each character. When I removed the ".value.toString()" from this part of the code it started to work as expected.
images.each {
imagesJson += "\"image${i}\": \"http://www.bom.gov.au/radar/${it.substring(32).substring(0,it.substring(32).length() - 7)}\"";
if (i != images.size()) { imagesJson += ',' }
imagesJson += '\n'
i++
}
I didn't have an existing instance of this driver setup to compare to myself, but when I installed v1.2.0 of the driver on my dev hub and setup a virtual device I saw this behaviour of a string of numbers returned, then corrected with the updated v1.2.1 driver.
I can't say whether the HTML returned has somehow changed from when I originally developed this, but it seems unlikely. Looking at the code, which I likely took in part from an example elsewhere, the use of value in particular seems to be incorrect, more likely required when working through a list of key-value pairs rather than an array of Strings, but this makes it even more strange that it worked previously.
So a bit of a mystery, but I expect was just an anomaly with how the code was previously interpretted and this has forced me to write it in a more correct way.
1 Like
2.3.6.140
I'll update anyway.
1 Like
That makes a little more sense now. 2.3.8 I think it was introduced an updated Java version, so can only assume there was some difference in the way the driver code was interpreted.
Got it. I haven't updated my C7 for a bit as nothing really problematic 
1 Like
