I’m having trouble with finding a good kiosk solution for my mac mini, which i use to drive my main tablet. I had just been using Safari in full screen, but it keeps going out of full screen randomly, so i need something to lock it down in full screen it seems. I am trying out WebKiosk because it seems to be one of the few that is up to date and actively maintained.
WebKiosk works well, except that it doesn’t seem to be automatically refreshing the background page according to the settings in Sharptools (the force refresh every X minutes setting). Any idea why WebKiosk doesn’t do this and/or how to fix? If it’s on their end, such as them not honoring certain paradigms in their browser, would be helpful to know what technical feature the force refresh uses so that I could ask them to implement…
Also open to other kiosk solutions for mac if anyone knows them…
It’s strange because WebKiosk is updating all tiles dynamically as expected. It’s just the background image that isn’t being updated dynamically according to the refresh interval…
Does it have any debugging tools where you can access the browser console?
Can you share more details about how your background image is configured? You mentioned force refresh in your initial post a few times, but I want to confirm that you have the default ‘Force Refresh’ option enabled with the background image autorefresh?
Yes, this is how it’s configured. And it works as expected in Chrome, Safari, etc.
But each individual tile updates just fine; it’s just the background image. Do those rely on different types of things to where the kiosk browser might not be implementing something right with respect to the background image? How would you word an email to their support team, asking them to check their implementation for properly handling auto refresh of the background image?
There’s not any magic with the background image. The basics of what happens are included in the force refresh article I linked in my previous post.
Based on your configured refresh interval, it basically just adds another <img> tag and since you have the force refresh option enabled, it appends some random characters in a st_uuid query parameter.
In other words, if your media URL was:
https://my.image/path
Then when the page first loads, it would add an img like:
https://my.image/path?st_uuid=ABC123
Then when your refresh interval hit, it would add another img on top like:
https://my.image/path?st_uuid=DEF456
Without seeing logs, it’s hard to tell if there are any errors or what’s going on. In theory, if there were errors loading the new image, you would see a red toast message. It’s possible that the browser is aggressively caching resources and ignoring the query parameter, but that would be quite odd.
Where is the image hosted? If you’re hosting the image yourself and generating it dynamically, you might be able to check the logs on your image hosting server to make sure you are seeing new requests coming in at your specified refresh interval from the WebKiosk app.
Is it dynamically updated somehow? Like a new image pushed to GitHub every so often or something?
IIRC, Github raw caches files for at least 5 minutes and ignores URL parameters, so updating faster than that in the autorefresh setting likely won’t help.
Oh, right, forgot how I have it set up. My hubitat hub chooses which github-hosted image to expose at a cloud endpoint URL. So I guess it’s my hubitat hub that is getting the request from the browser for which image to display. I similarly change the URL-encoded parameter of my cloud endpoint URL to avoid caching problems.
So, yeah, good idea, I will put in some logging to check if I’m getting the requisite refresh requests on the hubitat side.
I think you have to be running mac silicon and then only when the developer allows you to access it through the app store. You can sideload apps when it is not available through the app store but it is a pain. I checked the app store and I don’t see kiosker and on their site it says only for IOS.
@josh I have tried a few things to figure out the issue but am not having any success in resolving.
I switched image hosting from GitHub to hosting locally on my Synology NAS with web station. Hopefully that avoids the potential issues with force refresh.
I added debug logging to tell when my Hubitat hub is being pinged for an updated image. Although I am seeing the debug logging on initial page load, I am not seeing any log for the background image refresh. Same result whether it’s the kiosk browser, safari, or Chrome…
Not sure if that suggests it’s some issue with auto updating of the background, or what… Any idea on next steps? It would seem this has morphed into a question about background refresh because it doesn’t seem limited to the kiosk software.
I’m not able to reproduce this. Is this on a new dashboard or were you updating an existing dashboard?
If you were editing an existing dashboard, make sure to actually apply the background settings when you open it up for editing. The ‘force refresh’ feature is relatively new (<2 months), so while it will default to ‘true’ in the settings UI if it wasn’t already explicitly set, that setting won’t exist on older dashboards and thus the default setting won’t be applied until you actually tap the Apply button when editing your dashboard background settings.
If that doesn’t help, I would need more details on your setup.
That depends on how things are setup. If the background is set to a URL on your Hubitat Hub that dynamically determines which image to display (perhaps via a redirect?), then you would want to make sure you have appropriate logs in the Hubitat app and that you are reviewing the logs there.
If the Hubitat app redirects to an existing image URL path and your browser already has that final image path cached, then you won’t see the logs for the requests at the final image source (eg. NAS) since the browser would load the final image from cache.
Again… this really depends on the details of how you have things setup.
