Your Automation Skills will Travel Well

In 2020 our automation skills may be the only thing that does travel! What I mean is that the automation skills being evangelized by so many in the networking community (Kirk Byers, David Bombal, Nick Russo, Jason Edelman and the Network to Code team, Hank Preston and Cisco DevNet and many more ....) will serve you well across disciplines.

If you are still ambivalent about getting started with Ansible, Python, or your DevNet Certification I hope sharing my recent experience will nudge you a bit closer to getting started. It may seem like a cliff (many worthwhile endeavors do) but these new skills are valuable outside of networking. They can help your organization introduce new critical capabilities and technologies quickly.

Automated Contact Tracing and Proximity Alerting

In April of 2020, I became involved in an Automated Contract Tracing and Social Distancing initiative with Enterprise Information Acceleration (EIA), Cisco, NTT, and an Internet of Things (IoT) Application Platform company out of Belgium, WMW.

The solution leveraged IoT and wireless technologies I was not familiar with and, as you can imagine, the timelines were aggressive. While I had spent the better part of 2019 working with IoT and OT (Operational Technologies - think of IoT specifically supporting manufacturing) devices, it was more from a network and security perspective.

I was going to have to get up to speed and fast.

There were several major global manufacturing companies providing essential services that were looking at this technology to help them keep production going and keep their employees safe in the workplace.

By this point we were already seeing the issues with Contact Tracing Apps on mobile devices and while that concept was sound there were both technical and adoption issues with the implementation.

The pressure was on. Manual contact tracing takes significant effort and is immediately handicapped because it largely relies on an individual's memory.

An IoT Based Approach

The system I saw in April took a different approach. Using well established, low cost IoT technologies, the idea here is to provide each employee and visitor with a low cost IoT sensor, say a badge or other wearable. With this approach, everyone has a uniform device with which to assess distance and duration. This approach also addresses technical and adoption issues and removes the burden of having to use a personal device (some may not even have personal devices to use..I kid you not)

This low cost sensor performs a number of functions:

  • Scans for other sensors and alerts when you are within some distance (typically around 2m/6ft today)
  • Records each interaction (estimated distance and duration)
  • Records optional location information in order to determine choke points, maximum occupancy, and perhaps highlighting the need for changes to a line or process that can be more “social distancing” friendly
  • Backhauls this data to an aggregation server (a Network Server in IoT “speak” which can then send the data to an application server)

Now, when I call my HR department to tell them I just tested positive, they know precisely with whom I’ve been in contact, when, for how long, and in some cases where. In addition to pinpointing bottlenecks, the location data can also provide data on what areas to sanitize.

Valuable information and far more accurate and detail-rich than my memory would have ever been. Not only that, but with this type of data, interesting analytics are possible. For example, are violations increasing or decreasing?

Personal Sidebar

I didn’t know the half of it.

There is no question that our doctors and medical professionals are doing every thing they can but the bottom line is that there is very little they can tell us right now. The current conventional wisdom is a symptom and time based approach to the virus.

  • Incubation 3-14 days from exposure
  • 10-12 days from symptom onset is the critical time when the virus
  • 1-3 days prior to symptoms you are at your most contagious (probably)

The key or “anchor” symptoms upon which to base the timeline are fever, cough, and difficulty breathing.

I know from first hand experience that someone can test positive for the SARS-COV-2 (COVID-19) virus and not exhibit any of those “anchor” symptoms while still being very ill.

If that someone has underlying conditions, understanding that first day of exposure is vital. Without those anchor symptoms, the exposure time frame is the only thing you have to try to understand where in the course of the virus someone might be and when to be on high alert for worsening symptoms.

Back in April, it just seemed like a very tangible, systematic, data-driven approach which is always appealing and even more so in a situation full of unknowns. Today, having experienced some of those unknowns first hand, I'm grateful that companies are looking at this technology.

Getting up to speed with all components of the solution quickly

To my happy surprise, as I delved into the solution, I found familiar friends:

  • JSON
  • Data Manipulation and imports using CSV and Excel
  • GitHub Repositories
  • Python and modules like requests (to access the APIs) and Pandas (to look at trends in the data)

These skills, which I've been using daily in support of my Network Engineering work, all had applicability in this new IoT environment. It is noteworthy that they are all skills you will develop as part of the DevNet Certification program.

In each functional component of the solution, there was something familiar that let me get up to speed quickly. And so when time was of the essence, these skills easily shaved weeks or longer in terms of

  • getting up to speed with the end to end system,
  • deploying quickly and efficiently, and
  • providing value added analytics.
Functional Components of an IoT system


By design these are simple, low cost, low power devices but I was very happy to discover that many (at least the ones I’ve worked with) decrypt their data in JSON. JavaScript is very popular in IoT so that makes perfect sense.


For this Proximity application and many other IoT applications, LoRaWAN, was the sensor to gateway protocol of choice. This is a low bandwidth, long range wireless technology which means a single gateway can cover a large manufacturing plant or small campus. You can think of these gateways as bridges, communicating to sensors via LoRaWAN and packaging the payload and sending it to the Network Server over IP via a variety of transports like Ethernet, LTE, and WiFi. There is even a startup that allows you to use LTE if available and LOE satellites otherwise (Lacuna Space)!


Cisco’s offering in this space is their IXM Gateway. It runs an IOS overlay on top of Linux and a Container based system. Getting it up and running on the network was quick and familiar and I was able to quickly create a Jinja2 template for the base configuration. That might have been overkill since you don’t deploy many but I can’t help myself.


The TekTelic gateway is equally simple though less familiar, coming up on the network via DHCP, and requiring just a few updates to a JSON configuration file to get it up on TheThingsNetwork (TTN), an open, free IoT LoRaWAN network.


The MultiTech AEP has a very nice web front end and comes with a built in Network Server to get you started although I always start with TTN because there is a wealth of instructional material available.

Network Server

The LoRaWAN Network Server brokers connectivity and aggregates data from gateways, sensors, and applications.

Most gateways come out of the box designed to work with TTN so it's a good way to get started quickly and it's free. After TTN, it depends on the Client requirements.

Most production deployments or large pilots I've been involved with are on Actility ThingPark. In general, to use ThingPark Enterprise, you will need to load a different packet forwarder so that your gateway knows how to package up data for your specific Network Server. There is a cost for ThingPark but if you are working with Cisco, there is a 90 day evaluation license available.

The most time consuming part of configuring the Network Server is inputting all the sensors. So here, a small Python script to properly format the data into a CSV file that can then be imported was extremely useful and a huge timesaver. After that a call to the REST API to verify that all the sensors were successfully imported and communicating completed the process.

Application Server

The Application is the end goal in IoT.

  • Do I have to water the vineyards? (ground moisture sensor)
  • Where are my tools? (location sensors)
  • Where have all the cattle gone to? (Location sensors)
  • Which parking space is open? (Check out the IoT session from DevNet Day)
  • Has my shrimp been maintained at the appropriate temperature throughout the peeling process? (Temperature sensors)

And in our case:

  • Have I been within approximately 2m/6ft of someone and for how long?

This is by far the easiest part of the solution. Because of their modular framework, the WMW team was able to develop the Proximity application in 3 days.

The Application also provided a REST API which allowed us to pull data and run customized reports for specific clients.

If you are interested in an example of the Application, read on.

A Fictional Example

The Thing Movie Poster
The Thing Movie Poster

Those of you familiar with John Carpenter's masterful remake of Howard Hawks 1951 classic "The Thing from Another World" will immediately understand the applicability to today's situation. For those who have yet to see the film, an alien intruder thawed from ancient Antarctic ice revives and can infect and imitate any life form given the opportunity. All it needs is privacy, close contact, and time. The first instance of the alien took the form of a dog.

And so, at US Ice Station #31 in Antarctica, we have provided the "Dog Thing" and some of the key staff proximity sensors.

Private Personal Proximity Dashboard

Looking at the dashboard, we can see that RJ MacReady ("Mac") has come into contact with everyone, as have others. The badges provide an audible and vibration alert when too close to another badge in addition to logging the interaction. This helps maintain awareness of social distancing.

If we drill down to Mac's badge we can see additional detail.

Mac Asset Tag Details

You can see the specific unique close encounters Mac has had with others at the station. All of these are brief which tells us Mac is doing a good job of maintaining social distancing.

Mac Close Encounters and History

Mac has had a number of "close encounters" including one with with Dog Thing but of insufficient duration. Also, Mac was not alone with Dog Thing during the encounter (as you can see from the History data). For the purposes of our scenario we will assume that a duration of 15 minutes or more is cause for concern.

Mac History and Location


What we really need is to determine who might have been in close quarters with the "Dog Thing" (alien imitation dog), so let's look at the data for "Dog Thing".

Dog Thing Asset Tag

Clark and "Dog Thing" have spent a total of 30 minutes in close proximity. That is a concern, particularly if it was a single encounter.

Dog Thing History and Close Encounters

In looking at the history, we can see that one single interaction was for 30 minutes! Plenty of time to be taken over by the alien.

It's clear from our data that Clark has a high probability of being infected and may already be an alien.

Clark and Dog Thing

A silly example to be sure, but I hope you can see how valuable this data might be in determining who is now alien, who may have been exposed to the alien, when and for how long.

The end to end solution used for this demo includes: