our swiss φθηνα ρολογια are all in now.
Version 4.x of SysInfo is now available on GitHub. This version has much improved JSON processing and includes additional commands Startapp, StopApp, Shutdown and Reboot. A customisable JSON file is used to list the app commands and their relative URLs. Update Version 4.5 has “Uninstall Package” command.
There are update of this blog for the new version of the OS:
Version 4.x of the app is now available on GitHub (see link below). Besides the capabilities of the earlier version (getting system information, network config, installed apps, installed devices etc) this version can start and stop installed packages as well as shutdown or reboot the system. The key configuration of the app is contained in a JSON (ie. text) file that lists all commands along with their web portal relative URL. This url can specify whether POST or GET (the default) is used when sending the REST Request to the portal. This means that, except for specific post processing, the app is simple to extend. Under the hood, the code behind has been substantially improved to make it more general. For example the, processing of the REST Response (text) string is quite generic (can handle any JSON string).
This continues the collaboration between two Microsoft Embedded MVPs, myself and Bruce Eitman. Bruce initially blogged about how to use the web portal to get the MAC address of a device in the Universal Windows code snippet format (for Windows 10). I turned it into a full UW app that exposed a number of other device properties. Bruce has since posted other how-to code snippets in this area (plus another relevant one) on stopping a running package as well as shutting down or rebooting a device which have been incorporated into this app. Bruce’s code can be directly copied from his blog posts here on Embedded101. His code and my apps will run on a device or remotely, say, on a Windows 10 desktop. Also, it is possible that given that they are Universal Windows code, they will also run on a Windows 10 phone ( there are some screen trigger resizing issues to resolve here though).
This app mimics the web portal to a Windows 10 IoT device that facilitates remote management of a device through a web browser. What is the purpose of this app given that it just implements the same functionality as the Windows 10 IoT Web Portal?
The latter point means that you could, for example, start and stop apps on a farm of Raspberry PI2 devices as well as rebooting and shutting them down. Also a later version may expose the remote Appx API enabling remote installation and removal of packages completing the requirements for remote management. Cool eh?
This app shows you how you access various system attributes of a Windows 10 IoT device from a Universal Windows App running on the device or on another Windows 10 device (IoT, Phone or Desktop). The source code exemplifies REST calls and recursive JSON parsing in a Universal Windows context.
My Blogs on this topic
Bruce Eitman’s Blogs on this topic
(Click-me to expand)
For general use refer to my first blog (as above).
The current list of commands is:
whatever you enter in its textbox
The URLs are appended to http://<device IPAddress or localhost>:8080/ when creating the HTTP Request. Note that for the 4 of the last 5 commands, the * indicates to use POST rather than GET ,which is used for all other requests. (the asterix is removed of course).
These commands and their URLs are listed in the project’s JSON file: See the JSON file listing here. This file is deployed with the app and so can be modified in-situ and so the app can be extended without modifying its source code.
The last 4 commands on the list above have a confirmation pop-up dialog. The stopapp also has an option to “ForceStop”. These run in a Try-Catch because the pop-ups don’t work on Win 10 IoT. At Universal APIs not functional in Windows 10 IoT Core at this time the API Windows.UI.Popups.MessageDialog is listed as not supported on IoT. I found that you can instantiate the class but it does not function. Certain references with it generate an error, hence the Try-Catch. This means that if you run the Universal Windows app on the desktop you get a confirmation but on the RPI2 it is effectively bypassed. There is though a Checkbox on the Configuration pane to optionally enforce the “ForceStop” for the stopapp command.
You can examine the HTTP communications via the network tab:
For example when you select the Devices tab, amongst the other requests from the web page is:
Name Protocol Method Result Content type Received Time Initiatorhttp://192.168.0.28:8080/api/devicemanager/devices HTTP GET 200 application/json 10.47 KB 114.19 ms XMLHttpRequest
Hence we can conclude that to get a list of devices the URL you need is api/devicemanager/devices
Another Cameo from Bruce Eitman:
Where did those URL strings really come from?
Bruce has pointed out that there is some undocumented documentation on the portal web interface. There is a web page with relevant information on the web portal at http://<the device IpAddress>:8080/RestDocumentation.htm eg:
Starts a modern app
HTTP verb: POST
appid : PRAID of app to start, hex64 encoded
Success : 200 OK
Error : 500 Internal server error
Error : 400 Bad request
If you wish to experiment with these API paths, note that these paths are copied into the box just to the right of the API textbox.When the [API] button is pressed, whatever path is in that box is used and so you can test any API path you wish. Note also that below the [API] button is another textbox. (Remember to append an asterix to the URL if POST is to be used.) This can be used to add any REST parameters, but it assumed that parameters need to be encoded. Bug: This feature did not work in 4.x but has been fixed in version 5.3 of the app.
David: Nice work pulling this all together in one app. Bruce