SOTI Pulse Logo

SOTI Surf, send a URL in a script

7
74HCT04
Jersey Post

Hi,

I am trying to Script SOTI Surf to be used for the sole purpose of downloading a firmware update zip file to the device. I need to do this without any input from the user and with reliable download manager.

Is it possible to send Surf a URL via a script, something like sendinfo net.soti.action.surf URL http://www.google.com 

I'd need the file to downloaded overnight when the device isn't being used and for Surf to be closed afterwards. So far I've whitelisted Surf in my Kiosk, without a launch icon (our users don't normally have access to a browser, so Surf itself is in kiosk mode also) and have set the URL as the homepage. It can be launched by a start net.soti.surf script but it shows a plain white, confusing, screen whilst the download is occuring in the background - a bad user experience.

2 years ago
SOTI surf
ANSWERS
MD
Matt Dermody Diamond Contributor
2 years ago

Why do you need to use Surf at all to download the file? It seems like you're trying to unnecessarily recreate a manual process versus trying any of the available alternatives. I can think of at least 5 different options that would be better.

Alternatives include:

  • File Sync rule to deliver the ZIP file from the SOTI server to the device
  • Package to deliver the ZIP file from the SOTI server to the device.
  • ftp script to direct the device to download the file from a remote FTP server
  • httpget script to direct the device to download the file from a web server that is hosting the file.
  • Honeywell EP generated settings to instruct the device to download the update from a web or FTP server.

7
74HCT04
2 years ago

Hi Matt,

Thank you for your reply.

Sorry, I should have been more specific.

1. We use a MobiControl cloud instance.
2. We have several hundred devices to upgrade, each with a file of perhaps 1.5GB

3. To avoid hundreds of GB of internet traffic, the upgrade file is hosted on a server, internal to our network and currently served using http.

4. The download must take place overnight and, ideally be windowed so that I can stop it without having to take down the server, should it overrun. Manually stopping a download is not ideal but is accpetable.

5. In some areas, our WiFi network suffers intermittent connectivity / packet loss meaning downloads may need to resume / restart.

I've tried almost every suggestion apart from a file sync rule or package. These would violate 3, above.

The current approach is to use Honeywell's EzConfig, importing an Provisioner.xml file. This works but I cannot stop an ongoing download (confirmed by Honeywell Support) so it violates 4. For fear of using all available wifi bandwidth once the working day starts, I have to upgrade devices in small groups. There's another issue with this approach - sometimes a 'stalled download (?)' occurs, where I need to reboot the device to get EzConfig to retry the download. This  manual intervention is unnaceptable and if the end user were to reboot before I had attended such a device, the download will restart, using precious battery capacity!

So far the best and most resilient method is to use Chrome to download the file. However, I cannot automate this (user needs to accept terms and conditions and tap a download link). Hence, I am now looking at either third party Download Managers, learning to write my own App to utilise Android's built-in Download Manager or using a different browser to do the work. 


RS
Rafael Schäfer
2 years ago

Why you don't use following already mentioned by Matt:

  • httpget script to direct the device to download the file from a web server that is hosting the file.

You write on your own that the file is hosted using http, so this should be a suitable way. This should exactly fit to what you want to do.

If you still want to go the "Browser" way, you can provide the link as a private web-app (if you use managed playstore on your devices) which the user then can execute or configure a bookmark using managed app config for chrome or the Catalogue in the Soti Surf settings (profile).

Or just via script: sendintent -a "https://<URL>#Intent;action=android.intent.action.VIEW;end"
https://www.soti.net/mc/help/v15.6/en/scriptcmds/reference/sendintent.html

7
74HCT04
2 years ago

Thanks Rafael. 

This works but I have no method to stop the download, nor check on it's progress. Also I am not sure whether it will restart if the download is interrupted.

I can instruct the users to press a button to initiate the download but there are two problems: 1. Some users ignore the instruction. 2. I need the download to happen overnight when the devices aren't being used.


as it happens, I have just tried this "Or just via script: sendintent -a "https://<URL>#Intent;action=android.intent.action.VIEW;end"" This works, I think. I just need to figure out how to make Surf the default browser. I will do some research. Thanks


RS
Rafael Schäfer
2 years ago

Yes, and no. Even i never tried: Shouldn't the download stop if you turn off (kill) the browser?

This could be done via script:

kill_application bundleid(from chrome)
7
74HCT04
2 years ago

Thanks. The re-introduction of kill_application has already proven to be a very useful legacy script command for us.

7
74HCT04
2 years ago

Sending the script

set_default_browser net.soti.surf/net.soti.surf.ui.activities.SplashActivity

Then

sendintent -a "http://192.168.0.169/files/HON660-P-88.00.18-(0191).zip#Intent;action=android.intent.action.VIEW;end"

Results in Surf launching with an Alert popup stating:

"You are not allowed to access this page"

and a "Go To Home" button.

The home page is currently set to http://192.168.0.169/files/HON660-P-88.00.18-(0191).zip

something still isn't right - probably with my Surf configuration


7
74HCT04
2 years ago

I solved the above issue by whitelisting the URL http://192.168.0.169 and disabling Surf's kiosk mode.

Unfortunately, Surf doesn't resume a download after an interrupted connection so I will need to look for another solution.

MD
Matt Dermody Diamond Contributor
2 years ago

A File Sync rule is what we've ultimately landed on for handling these sort of updates on devices we manage. The file will resume downloading where it left off if the device is rebooted, the battery dies, the WiFi disconnects, or the download is otherwise interrupted. 

7
74HCT04
2 years ago

Thank you very much for those extra details about the file sync rule, Matt. I wasn't aware of its resilence. 

I think that for smaller, incrimental Honeywell updates, this is probably the way to go. So long as the WiFi restriction works, that is! (I check for their presence on the device and that their total size is correct with some Javascript before installing using another Provisioner.xml)

I believe I can specify an activation and deactivation time for the rule. It's a shame that this can't be made a daily window.

RC
Raymond Chan Diamond Contributor
2 years ago

For downloading a firmware update zip and subsequent installation,  using of file-sync policy has the highest flexiblity.  With the support of advanced features and library in the javascript script engine of MC device agent, sophisticated script(s) file associated with file-sync rule can be used to perform much smart installation operation than is possible with the legacy MobiControl script.

7
74HCT04
2 years ago

Thanks Raymond. I am finding MobiControl's Javascript API very useful of late. If only there was way to send an intent, then I think I could not only check for the presence and size of the firmware zip but also initiate the the installation of the update (something I currently do with an intent in a legacy script).

I am planning on building and testing more automation around the firmware upgrade process and scripts (mostly executed in a time-window using MobiControl profile)  are already a key part.

For smaller update files I am planning to try file sync rule delivery, also.

RC
Raymond Chan Diamond Contributor
2 years ago

Hi Hex-CMOS-Invertors,

(Just joking.  Your nickname rings a bell.  I worked on VLSI RTL and board-level hardware designs for 15+ years before spending some time on MDM solutions)

For your information,  I have communicated to various parties at different levels of Soti to improve their javascript engine in the latest Android device agents, so that many missing features (e.g. intent, custom attribute access, ... etc.) of legacy MobiControl script engine can be supported, hopefully in the very near future.

7
74HCT04
2 years ago

Hi Raymond,

Yes, I was -and part of the time- still am, a board-level hardware designer. RTL takes me back, in fact it is older than me :-). It's a small world as they say, and being a full time electronic engineer is something I greatly miss! (As you know, a 7404 is a hex inverter... My username is a based on an old in-joke around a 7404 worn on a necklace as a protective amulet... Not by me, I should add, but if you discover the name of one of the companies I used to work for, it would make more sense).

Thank you for encouraging SOTI to expand their Javascript API to encompass legacy script commands. Having one scripting language to cover "all bases" could lead to some very powerful automation.

Similar Discussions