Automatically go back to home?

Good evening,

Long time no see! I’ve been making some new projects, including a nice new pool light color dashboard, and I have an interesting conundrum:

I’m running SharpTools on Fully Kiosk Browser on Android.
I have a shortcut on my main dashboard to my color controls dashboard. When I click it, obviously, SharpTools opens the color dashboard as expected. I also have a back button on this color control dashboard that takes me back to the main dashboard. Standard stuff…

What I’d like to happen is for the main home dashboard to come back after either an input on the color dash, or after a timeout of no activity (1 minute should be perfect). I’m finding that it’s nobody’s natural inclination to hit the back button after they select a color, and I don’t want the control panel sitting there on the color control dashboard after its usefulness has worn out.

Here’s what I THOUGHT I would do: Since I’m running Fully, I tried the feature Auto Reload on Idle. Set for 60 seconds. Works great. --Except it keeps reloading on the main dashboard as well, which is distracting and too much unnecessary traffic and downtime.
HOWEVER, this feature also has a “skip auto reload if showing the start url” setting. Great! So, it should reload to the start URL after a minute of idle time on the color control panel, right?

THAT’S where the problem starts. Fully ALWAYS THINKS IT’S ON THE START URL. I checked the behavior in Chrome, and when I click the shortcut to the color control dashboard, the url changes in the address bar. When I click back, it changes back to the start url. In Fully, it does not do this. To double-check, I turned on the address bar in Fully and watched it. Sure enough, it doesn’t change when clicking the shortcut. --As if it’s cashed and thus doesn’t matter, or (??) I’m scratching my head on this one.

Hoping someone can tell me why Fully is acting this way, or if there’s another way people are having their dashboards reset. If I could just get it to display what URL it’s actually on, this auto-reload setting would work perfectly for what I need. Perhaps there’s a setting in there somewhere or a different way to input my start URL?

Thanks for your help!

Ricky

1 Like

That is quite odd indeed. Have you reached out to the Fully Kiosk Browser developer about this?

I’m not sure if it would work in this particular case, but one approach that we’ve seen used in similar situations is to use the Fully Kiosk Browser integration for SmartThings (DTH) or Hubitat (driver) which exposes some neat commands like loadURL() or loadStartURL() that you can use to control your dashboards from rules.

Morning, Josh,

Thanks for the response. At least it’s good to hear the problem seems to be with the browser, and not the way SharpTools loads. I haven’t reached out to the Fully Dev yet, no, because I had just discovered the problem, and I was hoping maybe there was a way to solve it built in or that others use, plus I’m already a member over here.
I did notice last night as I was restarting Fully, that it told me quietly as it started up to “update webview.” Maybe that will help? I just have to work on it in spurts once the work week starts.

As for using the Fully Kiosk Browser Controller device in Hubitat–I actually do use that quite a bit for various things, such as making announcements and turning the screen on in the dark, etc. But I don’t know how it would help in this case. Yes, I could send it a command to reload the start url, but on what condition? Perhaps I could get closer by having it return right after a command is sent to change the pool color. --But not on idle. It would still need to know it’s idle on the wrong page in order for that to work. But thank you for the idea. It’ll get me halfway for sure. Maybe webview will get me all the way.

That’s the question! Unfortunately, the Fully Kiosk Browser (FKB) driver for Hubitat does not expose the Current URL as an attribute on the device… and when I manually checked the FKB API, it thinks the ‘current url’ is still the original page that was loaded anyway.

I’ll reach out to the Fully Kiosk Browser developer to see if he has any thoughts.

Yeah, unfortunately I think knowing the current URL is really the most ideal approach for what you are looking to accomplish. Anything else would just be a rough approximation.

Right! That’s what I was finding. I use the remote admin, and that’s where I first discovered it was not updating the current URL, like so:


(Picture is significant because I did NOT, in fact, have my start url loaded)

I did discover I can’t update my webview without losing a whole new ROM. :unamused:
Because I’m on a modified Kindle Fire running a custom AOSP-based ROM, updating webview from the play store doesn’t update the webview that’s actually used. This is per Fully’s documentation, and confirmed when I updated and it still told me I was on an old version.

Thanks for looking into it! Curious to hear if there’s anything to be done about that attribute not updating. :+1:

Hi Ricky-
Just an update that the Fully Kiosk Developer responded very quickly and resolved the issue in the Fully Kiosk Browser 1.39.1. I only just now found the message from him in my spam folder when I went to follow up on my original email to him.

2 Likes

Oh, wow, that’s awesome! So that’s a new version then? Can’t wait to get home and try it out! That’s been bugging me. :slight_smile:
Thanks again, Josh!

Yes. Looks like Fully Kiosk Browser 1.39.2 is the latest version available as of writing this post. Just a reminder that you’ll want to grab the version for Fire OS from the download box if you are using a Fire tablet - or if it’s a regular Android tablet, you can get the update from Google Play.

I tried it out and it seems to work as expected with the settings you mentioned, but give it a shot and let us know if it works as expected for you!

Man, that’s fantastic! I’ve hacked my kindle 7s to run custom ROMs, so I’ve got Play Store and full root, etc. I finished up installing my Shelly and got everything working beautifully with my pool lights over the weekend, but this will be the perfect finishing touch, having the browser default back to the homescreen! I’ll probably let Fully take care of it entirely, assuming this works as expected. Again, this is what makes these communities so great, and this one in particular. I’ve seen you reach out so many times to devs on other systems and hardware manufacturers to bring use cases and bugs and things to their attention. These are connections we don’t have, or wouldn’t know what to ask, and I’ve seen great results like this so many times. Kudos to you on being so effective in that role.

Thanks again.

2 Likes

Just a note there is an updated hubitat fkb device driver coming out. The dev said he has added some additional functionality. Screenshot_20200512-171320_Gmail|690x331

2 Likes

Ooooooooh…[rubs hands together in anticipation] this could be goood…

There’s a little bit of super minor nitpicky stuff that’s been nagging me about my tablets that I wanted to fix with automation. This sounds like it could almost definitely help with those issues! Thanks for the heads-up!

2 Likes

Quick update here: Updated around 2 this am. Works perfectly, exactly as I had originally intended. :grin:

3 Likes

Thanks for pointing this out Ricky. I didn’t realize it was an improvement I was missing out on until you pointed it out. I confirm it’s working well for me with the new browser update!

2 Likes

Awesome! Happy to do my part in these communities. I’m no dev, but I sure can put a lot of use cases into play. :slight_smile:

3 Likes

FYI Version 1.35 of FKB device has been released. [RELEASE] Fully Kiosk Browser Controller - Code Share - Hubitat

3 Likes