And the URL for the iframe is simply the location of the html file? ie
http://[hubip]/local/imageCycle.html
Also I was thinking since I've already got a pi with a 250Gb SSD that it might a good alternative to store the images on that, using node red to pull them off the BOM ftp site.
I've been using the Tile Master driver, mostly because I started using it to do that when I first added some IFrames to my dashboards from Grafana, but I would expect any driver would do.
I'll grab the Iframe code is a second, but I think it essentially sets the size and that is does not scroll, apart from setting the source URL of course.
The pi option is a fallback for me as well. Looks like I need to post a few more details on how I am approaching it, and some Groovy driver code. Essentially, I am using a python example as a starting point for retrieving the list of images from the BOM web site, storing those in a JSON file locally, then referring to that json file in the html ajax, so not actually storing the images themselves. I did try to use Cometfish's BOM driver to do the FTP'ing of the png files, but I wasn't confident I would be able to download and store a binary file.
Give me a minute and I'll come back with a few more details.
Here's the driver that looks at the radar loop site, currently hard-coded to my location, extracts the png file list and stores the json representation of this list in an attribute. I then use the trick I posted about using variables to output json from this attribute to a local file. That local .json file is what is referenced in the html file. I may need to update that in source control. I'll post back in a minute when I do.
Here's the python example I used as the basis for writing the driver:
I have mentioned to cometfish that it looks like the forecast data can also be accessed in a similar way, so we may be able to ditch the FTP / telnet setup, which is a bit of a pain to work with.
Looks like the image cycle us up to date. Note, the background and locations links are for my location. I intend to work these into the json file as well, being populated through similar preference settings to those already in the BOM drivers.
So just to summarise, and I'm not advocating this as a final setup....
I have a virtual device using the BOM Radar Images driver, setup in an RM rule currently to refresh every 5 minutes. This refresh populates the attribute with json. In the same rule I then output the json (via the variables) to a local json file.
I have the static html file sitting in the local files area
I then have an IFRAME virtual device, referring to this html file and being used in a dashboard
Obviously much of this could be rationalised down to a single device with the json, iframe and scheduled activities in place of the RM rule. And these are where I am intending to move to next. The html file could also be installed via HPM.
I think we will need to update the iframe device in some way in order for the images to change over time if the dashboard is left open.
Actually, looking back at the title of this topic, I expect I should put the full URL for the images in the json file. I currently put just the file name, appending the beginning of the URL in the HTML file. If I want to make this part of the solution unaware of what the images are or where they came from, the HTML file shouldn't be referring to the BOM web site.
Another thing I just noticed is I make reference to my DNS name for my HE hub, HERULES01. You will need to change this and I should look at where best to handle this as well.
Made a reasonable number of changes throughout today to all three parts, the HTML file, JSON file structure and the HE driver:
Incorporating the background images in the images json file, requiring changes in the processing of the entries by the Ajax in the HTML file
Including the full URL in the JSON entry
Rationalising some of the Styling in the HTML page
There's still some stuff that's not quite there, like the complicated setup of rules and variables, and the limitation of hosting only one tile due to the fixed json file name in the HTML file. I may introduce a configuration json file to help with some of this, including the time between image transitions.
Glad you mentioned iFrameAdvanced, had forgotten about this, but will be nice addition to using this, will be similar to the way the BOM app works with the radar sliding up and down, freeing up screen real estate.
Following conversation on the BOM weather driver thread, @rocketwiz requested and did the hard work of looking up options to scale an image to fit a dashboard tile:
I will look at including this as an option / feature in the image cycle driver.
Thanks Simon. The code works perfectly and the positioning of the final radar image can be fine tuned using standard CSS on the dashboard ("tile-primary"). I have not yet tried but I'm guessing that instead of scale() we could use scale X() and scaleY() to stretch/shrink the image a bit more in either axis for a better fit.
The only thing that can't probably be done unfortunately is the ability to get a full screen version of the radar on tapping the tile like we can with an image.
Hmmm... I'm torn between specific requests and something that works for all.... Must be what it feels like to develop the HE platform I'm also wanting to work through what the best options are for scale given I have included a width and height settings already.... Trust me, a good problem to have.... Scale may be more useful....
The full screen option could be achieved with the advanced iframe setup you linked early on in this thread, allowing users to click on an image (iframe) and see a larger version if we want.
Unfortunately the advanced iframe driver generates an additional button for the resizing (screen real estate is already precious when you're using a 7" Nest hub ). Anyway I'm just happy to have a proper weather radar instead of a static image!
Actually the width/height settings truncate the BOM URL "image" if set to smaller than the actual radar size rather than resize it. The actual BOM radar is 512x557 pixels so the default settings don't affect it as far as I can see.
That makes sense now that you mention it. There are probably uses for both options, allowing parts of an image to be cropped and then scaling the result... maybe...
Today I added the option to define static foreground images that appear on top of the images that cycle, primarily for the benefit of my Rain Radar image driver.
