Signangelive is a platform for managing content on digital signage. It works on a variety of devices, including BrightSign, Chrome OS, LG webOS, Samsung Tizen TVs, and Windows. I recently used evaluated Signagelive for use with a BrightSign project.
One of the units of deployent on Signangelive is an HTML Widget. An HTML Widget is a zip file of HTML assets with a manifest and a .wgt file extension. Prior to now, the only place I’ve really seen Widgets used is on Samsung’s Tizen based platforms. The Samsung smart watches, TVs, and the Tizen powered phones support HTML applications through Widgets. The Widgets and other presentation items (such as videos, pictures, or other displayable elements) can be scheduled to run on a device and the platform will take care of the rest.
For the solution I am working on, I packaged it as a widget. The only additional file that I had to make to do this was a config.xml along with a PNG image to use as an icon. I updated the WGT into the signage live system, scheduled it, and sometime later the widget was running on the BrightSign. This deployment process would work great for a production environment, but it doesn’t work as well for development where you might want to make a quick change and refresh. I found two solutions for this.
One solution was to deploy an IFRAME whose address pointed back to my development machine. With this solution, if I want to make a quick change, I can make the change on my local file system and then refresh my view on the device. Refreshing the video on the device could be done by pressing the reset button, but that takes too long. If you have Chrome installed, you can connect to port 2999 of the BrightSign unit; connect to the browser instance; and then press the refresh menu option on your local browser. It results in the BrightSign refreshing too.
Remote File System Browsing
You can also upload files directly to the BrightSign. Connect to the BrightSign’s IP address (without the port specified). There’s a tab labeled “SD” (for the SD card). From there you can upload content to any place on the file system. After your files are copied, you can either reset the device (which in my opinion takes too long) or connect to the devices IP and refresh the view as described in the IFRAME section.
I initially ran into another problem with running my code in a widget. I mentioned in another blog posts that BrightSign does not support the HTML5 APIs for persistent storage. The solution that I suggest for this is using NodeJS within BrightSign. Signagelive runs the code that was packaged inside of a widget in an IFRAME. As it turns out IFRAMES on BrightSign does not support NodeJS functionality, but that is easily overcome. The IFRAME that contains the widget has access to the parent window. The child window cannot call NodeJS functions directly, but it can grab a reference to its parent and invoke the parent’s NodeJS functionality. To minimize the difference between code run within and outside of the WGT and IFRAME we can coalesce the possible locations of a needed function. To get access to the required function, I used the following.
window.require = window.require || window.parent.require;
File System Access
My attempts to access the file system would initially fail while hosted in Signagelive. To fix this it was necessary to modify AutoRun.brs. When the BrightSign version of Signagelive creates its HTML window (of type roHtmlWidget in BrightScript) it does not configure the window for file system access. To fix this the WebWindowHTML function in Autorun.brs needs a couple of items added, storage_path and storage_quota.
I talked to an engineer at Signagelive about addressing this issue. I do not know how frequently Signagelive makes updates., but this change may appear in future versions of the software making it unnecessary. If you happen to read this close to the time that the post was made, the change might not have rolled out yet. You can make the change yourself but beware of a possible risk. There is a possibility that an update will be made and pushed out to your device that does not yet contain this change. If that happens you would want your code to fail gracefully instead of simply crashing.