The virtual demo for Pelion is a software only device that connects to the Pelion Device Management service so that the service can be used and demonstrated without the requirement for any device hardware. The project was specifically created to help discussion of high-level device management topics with the constraints of travel due to the Covid-19 pandemic but can be used any time that a screen share demo would be useful when a face to face physical demo isn't possible.
An example demo walkthrough script is provided that gives an example of where the virtual demo can be used: Pelion-virtual-demo-script.md
To use this demo you'll need to have a Pelion Device Management account, visit the Pelion Device Management site to sign up for an account if you don't already have one.
Running the demo will register a device to your account and allow you to see and write values to and from the device management service in real-time via your Internet link.
Note This demo is great for:
- Demoing a connected device on a computer so that you can explain IoT device management without the overhead of configuring and running up physical hardware
- Running a real Pelion Device Management demo in a video call screen share
- Quickly and easily connecting a device so that you can experiment with the Pelion Device Management Portal in real-time
- Testing out the FOTA firmware update tools that Pelion Device Management provides
- Connecting a device as part of your work to implement and test the REST API for Pelion Device Management. Pelion doesn't know that this is a virtual demo device
The demo is not intended to be used as a:
- Starter template for a constrained, low power IoT device. The Linux platform that we use to be able to demo the device on a computer is too heavyweight for a constrained hardware device. We suggest you apply the concepts explained here to an application running on an mbed enabled board.
- Method of running firmware update management for Linux IoT devices. The firmware update method demoed here is for single-application updates. When you're working with real Linux IoT devices you should implement update methods for Linux packages and any application libraries that you use. We suggest that you take a look at Pelion Edge if you're implementing that type of product.
- V1.2 Oct 2021
- Support for factory-provisioning mode
- Mbed cloud client updated to v4.11.1
- V1.1 Feb 2021
- Mbed cloud client updated to v4.7.0
- Firmware update added including delta update generation
- Multi-sensor type support. Inclusion of an option to build a counter-type device with the same functionality as mbed cloud client example
The virtual demo can be run using a docker container without any code changes. You can run the environment locally on your machine or you can use our walkthrough on Katakoda.
If you're running the demo locally then docker needs to be installed on your host machine https://www.docker.com/products/docker-desktop. A docker image has been prepared and uploaded to the docker hub site, the commands below will pull the pelion/virtual-demo image from docker hub and run an instance on your machine
-
Generate an Access key from Pelion Device management Portal. You'll find the Access keys in the Access Management section.
-
Start the
pelion/virtual-demo
container image replacingCLOUD_SDK_API_KEY
with your key:docker run --name pelion-demo -p 8888:8888 -e CLOUD_SDK_API_KEY=<YOUR_PELION_API_KEY> pelion/virtual-demo
NOTE: You can also specify the default Pelion Cloud address to use using
CLOUD_URL
environment variable, if omitted the default 'api.us-east-1.mbedcloud.com
' production address is used. -
Point your web browser to http://localhost:8888 to access the user interface of the virtual device.
-
Note the deviceID and find the device in your device list on the Pelion Device Management Portal. You can now browse resources and see the data updates from the virtual device in real-time.
Kill the demo with CTRL-C. The docker container running this instance of the demo will be suspended. You can choose to come back to this same container and resume it at a later date (the deviceID will be preserved), or you can issue a fresh docker run
command to create a new device instance and a new device in your device directory.
docker restart pelion-demo
docker attach pelion-demo
The default device type simulated when running the virtual-demo is a vibration sensor(/3313/0/5700). If you want to build a counter device(/3200/0/5501) or temperature(/3303/0/5700), then append either -e SENSOR=counter
or -e SENSOR=temperature
respectively when invoking the docker run instruction. Further, the default sensor update interval is set to 5 seconds, but you can override it by appending the -e INTERVAL=secs
parameter.
docker run --name pelion-demo -p 8888:8888 -e CLOUD_SDK_API_KEY=<YOUR_PELION_API_KEY> -e SENSOR=counter pelion/virtual-demo
The docker image comes already pre-configured with the necessary tools to perform a firmware and delta update. In particular, build tools and the suite of tools from manifest-tool are included to a) create a delta firmware image and b) sign and produce a firmware manifest ready to be uploaded to Pelion portal to start an update campaign.
For more information about Pelion Device Management update, please consult our documentation page.
Let's change the firmware code running on the virtual device, to simulate a code change and subsequent firmware update. With the docker container running, open a new terminal. Then:
-
Clone the virtual demo repository locally:
$ git clone https://github.com/PelionIoT/virtual-demo-for-pelion.git && \ cd virtual-demo-for-pelion
-
Switch to the directory where the 'firmware' source code is located:
$ cd mbed-cloud-client-example
-
Copy credential sources and manifest-tool configuration from the running docker container to your local folder::
$ docker cp pelion-demo:/build/mbed-cloud-client-example/mbed_cloud_dev_credentials.c . && \ docker cp pelion-demo:/build/mbed-cloud-client-example/update_default_resources.c . && \ docker cp pelion-demo:/build/mbed-cloud-client-example/.manifest-dev-tool .
NOTE: If you are planning to apply a delta patch update, you must also save the existing running firmware, otherwise you can skip the following step:
$ mkdir firmwares $ docker cp pelion-demo:/build/mbed-cloud-client-example/__x86_x64_NativeLinux_mbedtls/Debug/mbedCloudClientExample.elf ./firmwares/current_fw.bin
-
Let's alter the emitted simulated value sent by the virtual demo to be multiplied by 1000. Using
vi
editor, opensource/blinky.cpp
, navigate to line:308
and add the following line:_sensed_count = _sensed_count * 1000;
Save and exit.
-
Bootstrap a new development container of the virtual demo image to use it for building our new firmware. Notice that we local mount the credential sources and the manifest configuration we copied in step 3 above so that they are available from inside the new container:
$ docker run -it --name pelion-demo-dev \ -v $(pwd)/source/blinky.cpp:/build/mbed-cloud-client-example/source/blinky.cpp \ -v $(pwd)/mbed_cloud_dev_credentials.c:/build/mbed-cloud-client-example/mbed_cloud_dev_credentials.c \ -v $(pwd)/update_default_resources.c:/build/mbed-cloud-client-example/update_default_resources.c \ -v $(pwd)/.manifest-dev-tool/:/build/mbed-cloud-client-example/.manifest-dev-tool/ \ pelion/virtual-demo bash
NOTE: If planning to perform delta patch update, we need to local mount the 'firmwares/' directory too. Simply append
-v $(pwd)/firmwares/:/build/mbed-cloud-client-example/firmwares
in the command above.
You can now choose either to perform a full firmware image update or a delta patch. Follow the appropriate section below.
-
Switch to the firmware source code directory:
cd /build/mbed-cloud-client-example/
-
Build the new firmware image by invoking the
make
tool:make -C __x86_x64_NativeLinux_mbedtls/ mbedCloudClientExample.elf
-
Upon completion of the build, a new firmware binary is generated:
$ ls -l /build/mbed-cloud-client-example/__x86_x64_NativeLinux_mbedtls/Debug/mbedCloudClientExample.elf -rwxr-xr-x. 1 root root 7115152 Oct 11 07:12 mbedCloudClientExample.elf
-
We now need to generate the firmware manifest describing the update, upload it to the portal and start an update campaign. The
manifest-tool
can conveniently perform all this in one step. Simple execute:$ manifest-dev-tool update -p __x86_x64_NativeLinux_mbedtls/Debug/mbedCloudClientExample.elf -w -n -v 0.2.0 INFO FW version: 0.2.0 INFO Uploading FW image __x86_x64_NativeLinux_mbedtls/Debug/mbedCloudClientExample.elf INFO Uploaded FW image http://firmware-catalog-media-ca57.s3.dualstack.us-east-1.amazonaws.com/uPHX9cwDMtxNeLKde4bJW4 INFO Vendor-ID: da64439cf2d3433c8a19d844b8e56dc1 INFO Class-ID: 67ebb37962224e30a0ed38e5ab5f54d4 INFO Attention: When updating Mbed OS devices, candidate features must match the device's bootloader features. Incompatibility may result in damaged devices. INFO Created manifest in v3 schema for full update campaign INFO Uploaded manifest ID: 017c6e213ce900000000000100100153 INFO Created Campaign ID: 017c6e213fae00000000000100100363 INFO Started Campaign ID: 017c6e213fae00000000000100100363 INFO Campaign state: publishing INFO Campaign is finished in state: autostopped INFO ---------------------------- INFO Campaign Summary INFO ---------------------------- INFO Successfully updated: 1 INFO Failed to update: 0 INFO Skipped: 0 INFO Pending: 0 INFO Total in this campaign: 1
At the console prompt of the virtual demo, notice the firmware update being initiated, then downloaded and applied. Upon completion the device reboots with the new firmware:
Firmware download requested (priority=0) Updating component MAIN from version 0.0.0 to 0.2.0 Update priority 0 Update size 7115144B Downloading firmware. 0% Downloading firmware. 5% Downloading firmware. 10% Downloading firmware. 15% Downloading firmware. 20% Downloading firmware. 25% Downloading firmware. 30% Downloading firmware. 35% Downloading firmware. 40% Downloading firmware. 45% Downloading firmware. 50% Downloading firmware. 55% Downloading firmware. 60% Downloading firmware. 65% Downloading firmware. 70% Downloading firmware. 75% Downloading firmware. 80% Downloading firmware. 85% Downloading firmware. 90% Downloading firmware. 95% Downloading firmware. 100% Resource(3313/0/5700) automatically updated. Value 5 Firmware install authorized [FOTA] Successfully installed MAIN component In single-partition mode. Creating path ./pal Start Device Management Client Using hardcoded Root of Trust, not suitable for production use. Starting developer flow Developer credentials already exist, continuing.. Generating random from /dev/random, this can take a long time! Finished generating random from /dev/random. Commander initialized and waiting for cmds... Application ready. Build at: Oct 8 2021 11:20:59 PDMC version 4.11.0 Network initialized, registering...
-
Switch to the main program source directory:
$ cd /build/mbed-cloud-client-example/
-
Assuming you've modified
source/blinky.cpp
as suggested above, we can now proceed and produce the new firmware:$ make -C __x86_x64_NativeLinux_mbedtls/ mbedCloudClientExample.elf
-
Copy the new firmware to
firmwares/
directory:$ cp __x86_x64_NativeLinux_mbedtls/Debug/mbedCloudClientExample.elf firmwares/new_fw.bin
-
The
firmwares/
directory should now contain both the new firmware(new_fw.bin
) and the currently running one(current_fw.bin
):$ ls -l firmwares/ total 13904 -rwxr-xr-x. 1 1000 1000 7115152 Oct 11 07:11 current_fw.bin -rwxr-xr-x. 1 root root 7115152 Oct 11 07:12 new_fw.bin
-
We are now ready to generate a delta firmware using the
manifest-delta-tool
:$ manifest-delta-tool -c firmwares/current_fw.bin -n firmwares/new_fw.bin -o firmwares/delta-patch.bin 2021-10-11 07:13:21,572 INFO Current tool version PELION/BSDIFF001 Wrote diff file firmwares/delta-patch.bin, size 180745. Max undeCompressBuffer frame size was 512, max deCompressBuffer frame size was 37.
If we list the directory contents, we can verify the producing of the
delta-patch.bin
firmware. Notice the significant shrinkage in size, from 6.8MB of a full firmware image, down to a delta of 177K!ls -l firmwares/delta-patch.bin -rw-r--r--. 1 root root 180745 Oct 11 07:13 delta-patch.bin
-
Start the update campaign
$ manifest-dev-tool update -p firmwares/delta-patch.bin -w -n -v 0.2.0 INFO FW version: 0.2.0 INFO Uploading FW image firmwares/delta-patch.bin INFO Uploaded FW image http://firmware-catalog-media-ca57.s3.dualstack.us-east-1.amazonaws.com/iXHsjUj5zJbZ9KTMS1HSXi INFO Vendor-ID: da64439cf2d3433c8a19d844b8e56dc1 INFO Class-ID: 67ebb37962224e30a0ed38e5ab5f54d4 INFO Attention: When updating Mbed OS devices, candidate features must match the device's bootloader features. Incompatibility may result in damaged devices. INFO Created manifest in v3 schema for delta update campaign INFO Uploaded manifest ID: 017c6e36a8aa00000000000100100161 INFO Created Campaign ID: 017c6e36ab5d0000000000010010036a INFO Started Campaign ID: 017c6e36ab5d0000000000010010036a INFO Campaign state: publishing INFO Campaign is finished in state: autostopped 2021-10-11 07:17:35,404 INFO ---------------------------- 2021-10-11 07:17:35,414 INFO Campaign Summary 2021-10-11 07:17:35,414 INFO ---------------------------- 2021-10-11 07:17:35,415 INFO Successfully updated: 1 2021-10-11 07:17:35,415 INFO Failed to update: 0 2021-10-11 07:17:35,416 INFO Skipped: 0 2021-10-11 07:17:35,416 INFO Pending: 0 2021-10-11 07:17:35,416 INFO Total in this campaign: 1
At the console prompt of the virtual demo, notice that the device logs the downloading of the new firmware and the successful delta update:
Firmware download requested (priority=0) Updating component MAIN from version 0.0.0 to 0.2.0 Update priority 0 Delta update. Patch size 180745B full image size 7115152B Downloading firmware. 0% Downloading firmware. 7% Downloading firmware. 17% Downloading firmware. 24% Downloading firmware. 25% Downloading firmware. 32% Downloading firmware. 41% Downloading firmware. 50% Downloading firmware. 55% Downloading firmware. 62% Downloading firmware. 68% Downloading firmware. 77% Downloading firmware. 87% Downloading firmware. 96% Downloading firmware. 100% [FOTA] Successfully installed MAIN component In single-partition mode. Creating path ./pal Start Device Management Client Using hardcoded Root of Trust, not suitable for production use. Starting developer flow Developer credentials already exist, continuing.. Generating random from /dev/random, this can take a long time! Finished generating random from /dev/random. Commander initialized and waiting for cmds... Application ready. Build at: Oct 8 2021 11:20:59 PDMC version 4.11.0 Network initialized, registering...
Once the firmware update is completed, the Pelion update campaign dashboard should display the successful completion:
and the device should display the new firmware version (0.2.0 in our case):
Notice now that the vibration sensor values sent by the device are indeed multiplied by 1000 marking the successful firmware update!
Congratulations !
All previous examples showcase virtual-demo running in development mode where development certificates are generated and used to connect and authenticate to Pelion device management platform. For production deployments though, the factory provisioning process should be followed. To aid in learning, virtual-demo also supports this mode too. The container image conveniently includes all the required artifacts and services required (simulated TPM, PARSEC), assembled together to support a 'simulated' factory provisioning process.
NOTE: This section assume you have basic knowledge of how the factory provisioning process works and want to apply this knowledge with the virtual-demo. If not, head over to our documentation page for a brief introduction. Also, worth looking is our end-to-end factory provisioning tutorial.
-
Start virtual-demo in 'factory-provisiong' mode.
docker run -it --name pelion-demo -p 8888:8888 -e FACTORY_PROVISIONING_MODE=ON pelion/virtual-demo
You should see the factory-configurator-client starting up, then blocks waiting for connections from the factory-configurator-utility:
INFO:launching in [factory-provisioning] mode.. INFO:starting 'tpm_server'.. INFO:setting up authentication to 'tpm_server'.. INFO:starting 'parsec'.. Application ready. Build at: Oct 8 2021 11:17:07 In single-partition mode. Creating path psa/ [INFO][fcc ]: factory_configurator_client.c:84:fcc_init:===> [INFO][fcc ]: fcc_output_info_handler.c:472:fcc_init_output_info_handler:===> [INFO][fcc ]: fcc_output_info_handler.c:479:fcc_init_output_info_handler:<=== [INFO][fcc ]: factory_configurator_client.c:106:fcc_init:<=== Trying receive interface ... Client IP Address and Port : 172.17.0.2:8888 Client is waiting for incoming connection... Factory flow begins...
-
Assumming you have correctly setup factory-configurator utility in your local machine, you can proceed to inject the configuration to the virtual-demo adjusting accordingly the parameters with your details:
python3 ft_demo/sources/ft_demo.py inject --endpoint-name=virtual-demo --serial-number=10101 tcp --ip=localhost --port=8888
Once done, the 'factory-configurator-client' should report a successfull provisioning and exit.
Factory flow begins... [INFO][fcc ]: factory_configurator_client.c:152:fcc_storage_delete:===> [INFO][fcc ]: key_config_manager.c:75:kcm_finalize:===> [INFO][fcc ]: key_config_manager.c:96:kcm_finalize:<=== [INFO][fcc ]: storage_psa.cpp:822:storage_factory_item_delete:===> item name = mbed.BootstrapDevicePrivateKey len = 30 [INFO][fcc ]: key_config_manager.c:37:kcm_init:===> [INFO][fcc ]: storage_psa.cpp:256:storage_build_item_name:<=== [INFO][fcc ]: storage_psa.cpp:520:storage_rbp_read:===> item name = saved_time [INFO][fcc ]: storage_psa.cpp:256:storage_build_item_name:<=== [INFO][fcc ]: storage_psa.cpp:520:storage_rbp_read:===> item name = last_time_back [INFO][fcc ]: storage_psa.cpp:256:storage_build_item_name:<=== [INFO][fcc ]: key_config_manager.c:66:kcm_init:<=== [INFO][fcc ]: storage_psa.cpp:762:storage_get_item_name_for_deleting:===> item name = mbed.BootstrapDevicePrivateKey len = 30 [INFO][fcc ]: storage_psa.cpp:256:storage_build_item_name:<=== [INFO][fcc ]: factory_configurator_client.c:163:fcc_storage_delete:<=== Storage is erased [INFO][fcc ]: fcc_bundle_handler.c:279:fcc_bundle_handler:===> encoded_blob_size = 2134 [INFO][fcc ]: fcc_output_info_handler.c:484:fcc_clean_output_info_handler:===> [INFO][fcc ]: fcc_output_info_handler.c:496:fcc_clean_output_info_handler:<=== [INFO][fcc ]: key_config_manager.c:37:kcm_init:===> [INFO][fcc ]: key_config_manager.c:66:kcm_init:<=== [INFO][fcc ]: factory_configurator_client.c:289:fcc_is_factory_disabled:===> [INFO][fcc ]: storage_psa.cpp:520:storage_rbp_read:===> item name = factory_done [INFO][fcc ]: storage_psa.cpp:256:storage_build_item_name:<=== [INFO][fcc ]: factory_configurator_client.c:294:fcc_is_factory_disabled:pal_status:-63, factory_disable_flag:0 [INFO][fcc ]: factory_configurator_client.c:300:fcc_is_factory_disabled:<=== [INFO][fcc ]: fcc_bundle_handler.c:360:fcc_bundle_handler: key name SchemeVersion [INFO][fcc ]: fcc_bundle_handler.c:360:fcc_bundle_handler: key name Keys [INFO][fcc ]: key_config_manager.c:111:kcm_item_store:===> ... ... ... [INFO][fcc ]: factory_configurator_client.c:143:fcc_finalize:<=== Successfully completed factory flow INFO:[factory-provisioning] completed successfully, please start virtual-demo with 'docker start -a pelion-demo'..
-
You can now start virtual-demo in production-mode:
docker start -a pelion-demo
You should see virtual-demo starting up, connecting to the platform:
INFO:launching in [factory-provisioning] mode.. INFO:starting 'tpm_server'.. INFO:starting 'parsec'.. INFO:[factory-provisioning] has already occurred, starting 'virtual-demo' in production mode.. DEBUG:Using selector: EpollSelector DEBUG:Using selector: EpollSelector In single-partition mode. Creating path psa/ Start Device Management Client Commander initialized and waiting for cmds... Application ready. Build at: Oct 6 2021 12:30:07 PDMC version 4.11.0 Network initialized, registering... Add sub components Client registered Endpoint Name: virtual-demo Device ID: 017be3e8875cd285fba5223800000000
The process of firmware updates in production-mode is similar to development-mode with some subtle differences:
-
Prior to compiling the new firmware you should:
a) Comment
DMBED_CONF_APP_DEVELOPER_MODE
in define.txt, so the firmware is built in production-mode.b) Pass the
PARSEC_TPM_SUPPORT=ON
and use define_linux_psa.txt as parameter toDEXTERNAL_DEFINE_FILE
In a nutshell, the following series of commands should be used:
$ # remove the existing (dev) firmware build artifacts inside the container $ rm -rf __x86_x64_NativeLinux_mbedtls/Debug/ $ # deploy dependencies $ python3 pal-platform/pal-platform.py deploy --target=x86_x64_NativeLinux_mbedtls generate $ # generate cmake files $ cd __x86_x64_NativeLinux_mbedtls $ cmake -G "Unix Makefiles" -DPARSEC_TPM_SE_SUPPORT=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=./../pal-platform/Toolchain/GCC/GCC.cmake -DEXTERNAL_DEFINE_FILE=./../define_linux_psa.txt $ # start the build $ make mbedCloudClientExample.elf
-
Since we are not using the
manifest-dev-tool
in production-mode to auto-create the underlying dev certs and config files, we need to manually create and sign the manifest, upload the firmware and manifest to Pelion portal and start the update campaign. Follow the instructions in our documentation page for more information on applying firmware updates in production-mode. -
The Linux firmware binary generated by the build is rather large(40+ MB), so we suggest to opt for a Delta update directly. The precompiled production running firmware is located in
/build/mbed-cloud-client-example-production/
inside the docker image to use it as the parameter ('-c
') with themanifest-delta-tool
.
The demo has been implemented to be run in 2 parts:
- an instance of the Pelion device management client built with your certificate that writes sensor values to the Linux message queue running inside the docker container
- a graphical representation (GUI) of a device that picks up the sensor values from the queue and displays values in a "fake device" so that conversations about managed devices can take place.
Our pre-existing docker image has a Linux environment and a pre-built set of objects to run the demo. When you use the docker run
command with your Access key as an argument the scripts inside the container use the Access key to retrieve a device certificate from your Pelion Device Management account and finalise the compilation of the client using your certificate. The client instance is then run, a firstrun
file is written to the root of the docker container's Linux environment and the demo starts running. The client passes values to the GUI using the message queue running inside the container, the GUI is rendered on port 8888 of your local machine, the vibration values can be seen under the 3313/0/5700 resource for this device listed in the Pelion device management portal.
When you kill the demo with CTRL-C
you are halting the docker container ´pelion-demo´ but not destroying it. When you start the demo with the supplied launch scripts you are resuming the previously halted container, this solution means that the pelion client is re-used and the same Pelion deviceID used over multiple demo sessions. If you don't use the restart command in the launch scripts and instead issue a docker run
command then a fresh instance of the docker image will be created as a new container, which in turn means a fresh instance of the client will be executed, and a new deviceID will be issued by Pelion. This would create a growing list of stale devices in the device directory list of the Pelion portal webpage so we use the resume feature instead.
The virtual demo docker image and the contents of this github repo can be used together as an environment to tweak and build your own modifications to the demo. Clone this demo to your local machine and use the following commands to mount the cloned directories inside the docker image, the result will be that any code changes you make to the repo's files on your machine can be built and executed inside the docker container.
-
Generate an Access key from Pelion Device management Portal
-
Start the
pelion/virtual-demo
container image from the root of the cloned repo replacingCLOUD_SDK_API_KEY
with your key and add-e SENSOR=counter
if you want to build a counter device instead of the default vibration sensor:docker run -it --name pelion-demo-dev -p 8888:8888 -v $(pwd):/build -e CLOUD_SDK_API_KEY=<YOUR_API_KEY> pelion/virtual-demo bash
This will create a container with the name tag "pelion-demo-dev" that is running the pelion/virtual-demo image with a bind mount folder on your local machine. You can use the pelion-demo-dev container name if you exit the running container and want to return to it with docker restart and resume commands.
- You'll be at the bash shell inside the container, you now need to create the build environment to allow the demo to be rebuilt with your changes
cd ../mbed-cloud-client-example
mbed config root .
mbed deploy
python3 pal-platform/pal-platform.py deploy --target=x86_x64_NativeLinux_mbedtls generate
cd __x86_x64_NativeLinux_mbedtls
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=./../pal-platform/Toolchain/GCC/GCC.cmake \
-DEXTERNAL_DEFINE_FILE=./../define_linux_update.txt -DFOTA_ENABLE=ON -DFOTA_TRACE=ON
cd ../../sim-webapp
- To build your changes you can use the sim-webapp.py python script. The first build will require all object files to be built, this can take 30+ minutes but subsequent builds will only rebuild your modifications. At the end of each build the script adds a marker
firstrun
file to the sim-webapp directory to ensure further executions of the script only cause the demo to be executed and not compiled again. Similarly, acertexists
file in the root of the docker container ensures that the certificate for your device is only pulled once. To kick a fresh compilation of your code changes execute the following:
rm -f firstrun && python3 sim-webapp.py
- When the system has compiled your changes and the demo is running you'll see the console output at the bash shell, and you'll find the webapp running at the localhost:8888 URL on your host machine.