AVNET published an updated image for the .
Not a huge leap. It's still Raspbian GNU/Linux 9 (Stretch).
There are some improvements and changes worth updating for. The most important reason is the improved stability.
- The CAN driver got an update. There were issues after every other reboot with the original image.
- It's now safe to call reboot without risk of bricking the device
- It's safe to upgrade Linux on the device.
How to upgrade?
edit: avnet released an upgrade script: https://github.com/Avnet/avtse-iiotg-upgrade.
This is easier than the "from image" explanation below.
The SmartEdge is family of the Raspberry Pi Compute. You use a rpiboot to load an image.
I noticed that with my device, the Windows and Linux rpiboot didn't work.
If I build the AVNET version from source on a Linux (virtual) machine, it works.
sudo apt install libusb-1.0-0-dev git clone https://github.com/Avnet/smartedge-iiot-gateway-custom.git cd smartedge-iiot-gateway-custom/rpiboot make
check what drives are available (look for sd* devices)
unplug the SmartEdge, open it, connect the internal USB to your PC.
check that the jumper next to the USB connector is mounted.
provide power to the SmartEdge
check what drives are added (look for new sd* devices, you should find a new sdX, sdX1 and sdX2)
You can now use the dd utility to move the image to the SmartEdge (replace the X with the new device that appeared when running lsblk the 2nd time):
sudo dd if=avtse-iiotg-v11-20200326.img of=/dev/sdX
ntewinkel adds these parameters to see progress and get higher throughput:
Just before finishing, place an empty file called ssh on the boot partition. This will allow you to connect over an ssh terminal (e.g.: PuTTy) as soon as the device is set up. It saves you from having to go find a QUERTY keyboard and monitor.
Then you can unplug the USB cable,power cycle the SmartEdge, and use the AVNET's IoTConnect app to set the WiFi. I had to remove the existing device in the app, before searching for the "new" device.
The IoTConnect Integration
The SmartEdge image installs some services that make it interact with AVNET IoTConnect cloud service.
You get a 30 day subscription when registering your application with the app.
It's worth checking this out, and to try extend the examples.
The example is elaborate right out of the box. It will by default exchange the die temperature. If you attach SmartSensor devices to USB or RS-485, it will initiate those and try to exchange their data too.
You can enable the use of the DIGIO input pins, and exchange their status too.
When not using the IoTConnect services:
If you used the original image before, you will have noticed that there are some changes in the way the AVNET IoTConnect scripts are started, and how the device specific hardware is handled in this version
In the first image, more was done in the rc* scripts. All has moved to system services now.
If you want to use the device in the intranet, or use another cloud service, it makes sense to disable the services.
This will free the following resources:
- the custom LED is now available for your own program
- the device doesn't connect to the internet every so many seconds
- the I/O pins are pristine.
- no traffic to RS-485
Easiest way: I disabled following services, by navigating to /etc/systemd/system and renaming them from *.service to *.bak:
- iotconnectservice (connect to AVNET IoTConnect and run the demo)
- ledservice (control the user LED, attention, also entertains the watchdog)
- quectel (keep GSM modem connection alive. My box doesn't have the modem)
- smartedgehalt (part of the user LED functionality)
None of these changes are impacting. You can rename them back to *.service and you have the demo functionality back.
I left the services related to the reset button and watchdog running.
I commented out 2 lines in the reboot script, related to the user LED.
The script makes the led flash fast, and after reboot, that's normally stopped by the ledservice.
If we leave the two lines of code in, we have a flashing LED after reboot.
sudo nano /opt/avnet-iot/iotservices/reboot
Then at the end, put a # in front of the LED commands:
# echo 20 > /sys/class/leds/smartedge_led/brightness # echo 128 > /sys/class/leds/smartedge_led_duty/brightness
A little harder but cleaner method: the proper way to disable the services is actually, for each service, stop and disable them.
There is some more work to it, because some of the scripts re-enable services (watchdog stopwd script tries to restart smartedgehalt.service).
If you want to do the exercise by disabling services instead of the rename "hack",
don't rename the .service files to .bak files, and follow instructions below:
sudo systemctl stop iotconnectservice.service sudo systemctl disable iotconnectservice.service sudo systemctl stop ledservice.service sudo systemctl disable ledservice.service sudo systemctl stop quectel.service sudo systemctl disable quectel.service sudo systemctl stop smartedgehalt.service sudo systemctl disable smartedgehalt.service
Then make the same change to the reboot script as described above.
Then similar for the halt script, comment out the line that makes the red let blink at reboot:
sudo nano /opt/avnet-iot/iotservices/halt
# echo 36 > /sys/class/leds/smartedge_led/brightness
And in the stopwd script, prevent that the smartedgehalt.service gest re-enabled:
sudo nano /opt/avnet-iot/iotservices/stopwd
# systemctl enable smartedgehalt
Whether you used the 1st or 2nd method, the result is that the IoTConnect extensions aren't started at boot or reboot, and the red led is no longer used for signaling device / service specific statuses.
Watchdog and reboot service are still active.
Other Changes, Watch outs
You can now reboot without issues. The Linux default reboot command now points to /opt/avnet-iot/iotservices/reboot.
The reset button works better. A short press calls the above reboot script. A long press (> 10 seconds) resets to factory.
Attention when using the WatchDog service (when you put the watchdog jumper). The Led Service has to run too, because it stops the watchdog and prevents a reboot.
The initial image release could become unstable when performing an upgrade.
The user documentation contains the measures to take to avoid this. But at the end of the document, in an addendum.
The new image has these actions taken for you:
$ apt-mark showhold raspberrypi-bootloader raspberrypi-kernel raspberrypi-sys-mods
The server isn't recognised by its name on my network. I had to install avahi for that:
sudo apt-get install avahi-daemon
Once that command executed the smartedge published the name it was given in the raspi-config utility.
In a later post I'll untangle how the different AVNET services work together.