Register Azure IoT Edge Device on Existing Hub
Tags: actionshackathon, showdev, azure, github
Published: 2020-09-07 20:00:04

[Instructions]: # (To submit to the GitHub Actions x DEV Hackathon, please fill out all sections.)

### My Workflow
[Note]: # (Make sure to include the name of your GitHub Action and share where it's being used!)
This workflow is designed to register a new Azure IoT Edge Device on an existing Azure IoT Hub. I made my own custom docker action to handle setting up the azure cli, and read from a file in your repository which is a list of device names you'd like registered on your hub. Once the devices are registered on the hub, you can get their connection strings, and use the hub to deploy code to them as well. See the additional info section for more on that later in this article.

This isn't being used by anything yet, it is just a proof of concept for the actionsHackathon submission.

```
on: [workflow_dispatch]

jobs:
  register_iot_job:
    runs-on: ubuntu-latest
    name: A job to register an IoT Edge Device on Azure IoT Hub
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Register step
      id: register
      uses: rdlucas2/actionsHackathonSubmissions@v0.0.9
      with:
        azure-sp-client-id: '${{ secrets.AZ_SP_CLIENTID }}'
        azure-sp-password: '${{ secrets.AZ_SP_PASSWORD }}'
        azure-tenant-id: '${{ secrets.AZ_TENANT }}'
        azure-iot-hub-name: '${{ secrets.AZ_IOT_HUB_NAME }}'
        device-list-file-path: '/github/workspace/devices/list.txt'
```

I added secrets for my azure account information, although it wasn't necessary for some of them to be secret. The last item on the list, "device-list-file-path", is just a text file with each line containing the name of a device you'd like registered on the hub - which is why the checkout step is necessary. It is important to note that when you use a docker action, it will automatically pull in /github/workspace as a volume in the container.

On a successful run the devices should appear in your IoT Hub. Note that if a device was already registered, it will show an error message, but it should continue to register other devices and won't overwrite any existing.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/mfysrlsnqtd0igdy46f5.png)

### Submission Category: 

[Note]: # (Maintainer Must-Haves, DIY Deployments, Interesting IoT, Phone Friendly, or Wacky Wildcards)
Interesting IoT


### Yaml File or Link to Code
[*****Yaml file*****](https://github.com/rdlucas2/actionsHackathonSubmissions/blob/master/.github/workflows/mycustomaction.yml) 

[Note]: # (Our markdown editor supports pretty embeds. Try this syntax: `{% github link_to_your_repo %}` to share a GitHub repository)
{% github https://github.com/rdlucas2/actionsHackathonSubmissions %}

[*****Yaml file*****](https://github.com/rdlucas2/actionsHackathonSubmissions/blob/master/.github/workflows/mycustomaction.yml) 
For this one, I created my own custom action, but then used the checkout action and my custom action in concert to read device names from a file in the repo, and register them on the Azure IoT Hub. I did not register this action on the marketplace yet, but have created some pre-release candidates of it. I'd move it into it's own repository instead of utilizing my actions hackathon repo.

### Additional Resources / Info

Used the tutorial here for some of the setup: [IoT Edge Linux Quickstart](https://docs.microsoft.com/en-us/azure/iot-edge/quickstart-linux).

If you examine the code I wrote, you'll see I followed the IoT Edge Device tutorial linked above, and used ARM to deploy an azure vm with the IoT runtime on it, using the newly registered device's connection string to it. I then went into the portal and deployed the "simulated temperature sensor" marketplace code to this device through the portal page on the hub. I think this workflow could be built out to manage devices on an azure IoT hub. In addition to adding new devices, you could build out actions like deleting devices, deploying code to devices, and perhaps even collecting telemetry from devices. This was mostly a learning opportunity for myself. I had made a few other entries utilizing actions created by other individuals, and this one I wanted to explore custom docker actions.

I'm determining the proper workflow for this, as it might make sense to combine this in some way with a deployment action, where when you connect a new device, it can reach out to a repository to register itself on the hub, then update the hub connection string, deploy some code to the device with that updated connection string, then go about collecting telemetry from the device. I certainly learned a lot about how actions behave from this experience. Here are some links to my other submissions:

[Tell Alexa to trigger your deployment](https://dev.to/rdlucas2/tell-alexa-to-trigger-your-deployment-2im2)

[Alexa notifies you when someone stars your repository](https://dev.to/rdlucas2/alexa-notifies-you-when-someone-stars-your-repository-3nf4)

[Note]: # (Be sure to link to any open source projects that are using your workflow!)

[Note]: # (Be sure to include the DEV usernames of your collaborators, if any. )

[Reminder]: # (Submissions are due on September 12th (11:59 PM PDT) and winners will be announced on September 23!)