Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 7552 views
  • Likes 6 likes
  • Comments 55 comments
Related
Recommended

AVNET SmartEdge IIOT Gateway: the 2020 Linux Image and IoTConnect Scripts

Jan Cumps

AVNET published an updated image for the SmartEdge IIOT GatewaySmartEdge IIOT Gateway.

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.

 

image

 

Some highlights:

  • 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)

lsblk

 

unplug the SmartEdge, open it, connect the internal USB to your PC.

check that the jumper next to the USB connector is mounted.

 

sudo ./rpiboot

 

provide power to the SmartEdge

check what drives are added (look for new sd* devices, you should find a new sdX, sdX1 and sdX2)

lsblk

 

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

 

 

adds these parameters to see progress and get higher throughput:

bs=4M status=progress

 

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.

I will write an article to investigate the scripts for cloud service and other SmartEdge specific services.

 

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.

 

Related Blog
Industrial I/O
Use the Industrial I/O
Control Industrial I/O directly from GPIO Pins
C Program for the Industrial I/O
Control Industrial I/O directly from Node-RED
Display Industrial I/O on Node-RED Dashboard
CAN Bus
Use the Isolated CAN
CAN programming in C on Linux: Filter and Mask
2020 Linux Image
The 2020 Linux Image and IoTConnect Scripts
Understand the Custom Scripts and Services (Pt. 1: intro and reset button service)
Understand the Custom Scripts and Services (Pt. 2: led service)
Understand the Custom Scripts and Services (Pt. 3: IoT Connect service)
Parents

  • Thanks for the update, Jan!

     

    I still have a SmartEdge sitting on my desk, hoping to eventually put it to good use. It sounds like this new image might make it stable enough to use for something interesting, especially when using the extra settings you describe: ie, removing it from the Avnet cloud - I never did figure out how to connect a local ESP-based sensor to their cloud without a whole lot of hoops and hurdles.

     

    You said that after disabling the services:

    "> the I/O pins are pristine."

     

    Does that mean all of the regular Raspberry Pi pins are useable then? For example, I could hook it up to run my OpenSprinkler controller? That's assuming it can run all the usual Python type apps on it too.

     

    ps, I don't recall, but this unit doesn't have an SD card, right? Is it using built-in flash for that? how reliable is that, and what size? Does it makes sense, and is it possible, to add an SSD to the SmartEdge for things like a git server?

     

    Thanks,

    -Nico

  • in reply to ntewinkel

      wrote:

    ....

    You said that after disabling the services:

    "> the I/O pins are pristine."

     

    Does that mean all of the regular Raspberry Pi pins are useable then? For example, I could hook it up to run my OpenSprinkler controller? That's assuming it can run all the usual Python type apps on it too.

    ...

    I was referring to the industrial DIGIO pins that are available from the outside. The IoTCloud SDK demo reads the status of the input ones and sends that to the cloud, as part of the example.

    All classic Pi GIO pins should be available, whether you run the demo or not. They aren't tied to the Pi's GIO.

    Python 2.7.13 and 3.5.3 are installed.

    The GCC toolchain is 6.3.0.18

    All is fairly similar to Raspbian taste of stretch

     

    PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
Linux smartedge 4.14.79-v7+ #91 SMP Tue Jul 16 05:42:32 PDT 2019 armv7l GNU/Linux

     

    It is stable now. The culprits for bricking were the custom reboot mechanism and issues when upgrading Linux (fixed by marking kernel and bootloader on hold for upgrades).

    Both are addressed. I've rebooted the device many times. And kept it running for days without issues.

     

    ps, I don't recall, but this unit doesn't have an SD card, right? Is it using built-in flash for that? how reliable is that, and what size? Does it makes sense, and is it possible, to add an SSD to the SmartEdge for things like a git server?

     

    There's no SDCard connector. It's using on-board memory. I forgot how to check the size, but when I download an expanded image, it's 7.12 GB.

    I have no experience with Pi and SSD. I read a post about it today, here on e14, for a Pi4.

    If it's an USB one, it should be as easy as mounting the /dev/sdX  device that pops up.

     

    edit: from product page:

    • Robust program storage with 8GB eMMC Flash pre-programmed with a secure boot version of the Raspbian Linux OS
  • in reply to Jan Cumps

    I see their documentation hasn't improved any.

    They might have added a few extra notes and guidance into that github readme!

     

    side-note, looks like a version 1.3 is in progress too.

     

    Best,

    -Nico

  • in reply to Jan Cumps

      wrote:

     

    It is stable now. The culprits for bricking were the custom reboot mechanism and issues when upgrading Linux (fixed by marking kernel and bootloader on hold for upgrades).

    Both are addressed. I've rebooted the device many times. And kept it running for days without issues.

     

    What were the symptoms of it "bricking" before?  I'm wondering if after this v1.1 upgrade I should not have said "yes" to the script's reboot... it is now automatically rebooting about 5 or 10 seconds after the login prompt appears image

     

    I updated to v1.1 using the github script.

     

    Thanks,

    -Nico

  • in reply to ntewinkel

    Open the box and remove the watchdog jumper.

    image

     

    When this one is placed, the watchdog needs to be entertained. I haven't fully checked yet who/why/when this needs to happen...

     

    ... What were the symptoms of it "bricking" before? ...

    Not starting up at all. No prompt, not registered on the router, infamous Pi Rainbow screen (means pre-linux boot fail) when attaching a HDMI screen.

  • in reply to Jan Cumps

    Hi Jan, thanks for the advice.

     

    Sadly for me, it was already open - hanging off the one pin, like yours shows. not jumping the two pins.

    It's about 15 seconds to reboot after the login prompt shows.

     

    I might have to follow your routine above to flash the full image instead.

     

    ps, thanks for details about the bricking. Good to know it's at least a step better than that image

     

    pps, is there someone at Avnet I should be bothering instead?

     

    -Nico

     

    edit:

    ppps, to upgrade, I used Git to fetch the avtse_iiotg_upgrade repository to my Mac, and then used SFTP to send it to the SmartEdge (github was giving me authentication grumbles direct from the SmartEdge).

    I then did a

    chmod 777 install-iot

    to make it executable.

    and then used

    sudo ./install-iot

    to run the upgrade, which appeared to happily run through a LOT of things with a success message at the end, with the "reboot now?" kind of question to finish up,

Comment
  • in reply to Jan Cumps

    Hi Jan, thanks for the advice.

     

    Sadly for me, it was already open - hanging off the one pin, like yours shows. not jumping the two pins.

    It's about 15 seconds to reboot after the login prompt shows.

     

    I might have to follow your routine above to flash the full image instead.

     

    ps, thanks for details about the bricking. Good to know it's at least a step better than that image

     

    pps, is there someone at Avnet I should be bothering instead?

     

    -Nico

     

    edit:

    ppps, to upgrade, I used Git to fetch the avtse_iiotg_upgrade repository to my Mac, and then used SFTP to send it to the SmartEdge (github was giving me authentication grumbles direct from the SmartEdge).

    I then did a

    chmod 777 install-iot

    to make it executable.

    and then used

    sudo ./install-iot

    to run the upgrade, which appeared to happily run through a LOT of things with a success message at the end, with the "reboot now?" kind of question to finish up,

Children
  • in reply to ntewinkel

    pps, is there someone at Avnet I should be bothering instead?

     

    I don't know the proper way to repot that. You could log an issue in the github repo that holds this script...

    https://github.com/Avnet/avtse-iiotg-upgrade/issues

  • in reply to Jan Cumps

    Hi Jan,

     

    Funny that they don't seem to have official support for it. Or maybe that's what the Github issue area is for.

    All I found was links back to element14, and the suggestion is to ask in the forums.

     

    So, Jan, I think Avnet is secretly redirecting support to you image

     

    I've opened an issue in Github like you suggested.

     

    If there's no response there I'll probably just flash the image like you showed in your original post above.

     

    Thanks again for all the guidance!

    I'm kind of hoping it will be a good stable machine to host some of my own sensor data - assuming all the usual Raspberry Pi type software will run on it.

    It appears to be more solid than a regular Pi, with better power supply and better cooling.

     

    -Nico

  • in reply to ntewinkel

    Safest bet is to check if you can get access to the file system working via the micro USB.

    If there is a fix, it will always have to be done external on the file system. Nothing you can do in 15 seconds.

  • in reply to ntewinkel

    I'm re-flashing my device. To check if the method is repeatable, and because I need to check a few file and user  permissions  "out of box":

    • what user (root) and group (gpio) do the /sys/class/gpio files belong to?
    • does the avnet user belong to group gpio.

     

    I'll time the exercise. It's going to be faster than waiting on a solution for your bootloop image.

    image

    2001 seconds

    image

  • in reply to Jan Cumps

      wrote:

     

    .... To check if the method is repeatable, and because I need to check a few file and user  permissions  "out of box":

    • what user (root) and group (gpio) do the /sys/class/gpio files beling to?
    • does the avnet user belong to group gpio.

     

    After a new install:

    - all objects in /sys/class/gpio are owned by root gpio. As expected.

    - user avnet is part of gpio group.

     

    Also: all industrial pins are exported by default. And each set in the relevant direction.