I have released a driver that can store and display image urls on a cycle, i.e. moving from one image to the next with a configurable period in between. My current use for this is with my Rain Radar driver, but this could be used for any purpose really.
The Image Cycle Driver manages both a JSON file for storing the image URLs, along with outputting a HTML file to use in an iFrame in a dashboard. Both of these files are stored on the HE hub.
The driver is available through HPM.
I will update this topic with more details over the weekend, but if anyone is interested, let me know and I can put a few notes together quickly.
Was playing around last night looking at ways to display radar images from the Australian Bureau of Meterology (BOM) on a tile, as was able to do this with a HTML file stored on my HE hub, some PNG files I downloaded from the BOM's FTP site and an IFrame in a virtual device. I want to build this in such a way that other people could use it potentially outside of Australia or for another purpose other than weather radar display, where cycling through images on a single tile is useful.
Here's an example of the output. The land and water background is one png image, the place names another background image, then the cloud / rain is 5 images that are cycled through.
It might be useful for cycling through security camera views on a dashboard. That would require live images rather than static files. Do you think that is possible with the way you're doing it?
You might need an app or script on the webserver side that serves up different images from the same URL, like a couple of apps that @JustinL has put together.
I at least looked at the thread for his dashboard background image cycle and the more I read I felt it was such a different use case that it would be hard to shoe-horn in what I wanted to do. Rather than changing images periodically or based on logic in a rule, I want the images to cycle as you are looking at the dashboard.
Maybe, maybe not.... Separate to this little project, when it comes to weather services / drivers, etc, my thought process has always been that I like to have a separation between data collection and presentation, with a few exceptions. With the EcoWitt drivers I have recently taken on, they are predominantly focussed on getting data into HE, with some convenient templates for displaying this information on a dashboard. I don't mind that approach, supplying some simple built-in display feature.
But I also would like to see more general weather display options, so, ideally, no matter what weather system you are using, everyone can make use of the display options developed, Hubigraphs provided an example of this. This project is an example of that, I plan to look at ways of downloading the images from our weather bureau under a separate set of drivers, but the cycling of the images can be an independent feature, not tied to where the images are being sourced, allowing it to be used for other weather platforms or even things like security camera stills.
So in answer to your question, I probably am not looking at supporting live streams, but certainly if someone could write code to output a series of stills then this code could display them on a dashboard.
Totally agree. If you can cycle images at fixed URLs, then anyone can serve up whatever they want to those URLs. Weather images, camera feeds, snapshots from Dropbox photo backup, etc.
That is another good point that I didn't mention in my earlier post.. I do intend to dip my toe into developing an app with this, and want to include options to configure the URL's for the images, so it won't be required that they are stored locally on the hub, that would just be one option for where the URL's could point.
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.
