Don’t you hate it when you need to track someone down in an office building for an urgent message, or to sign some paperwork and you have no idea where they are? In a meeting perhaps, phone switched on silent? In the kitchen taking a break?
So here is a quick and easy worker locator using RFID swipe cards with an IoT board that displays your office layout in Dynamics AX, and pin-points where you can find Waldo right now.
For this project we’ll use a $20 Adafruit HUZZAH ESP8266/WiFi board with an MFC522 RFID reader. Mount the reader in a small plastic casing as shown below. The signal is strong enough to read access cards through the plastic wall.
We’ll add a LiPo rechargeable battery to make this portable as well. Just in case you need to mount one of these as and when required.
Next we’ll solder the Adafruit board onto some PCB and add a red and green LED to signal “success” or “failure” when a card is touched to the box. The PCB is really just required to add resistors between VCC and the LED’s.
I like reusing stuff between projects so again, mounting the IoT board with headers onto the PCB makes sense. The completed PCB setup is shown below. The edges of the PCB have been trimmed to fit into the box with the rest, and that measures 8cm x 5cm so perfect to mount on a wall.
Once the RFID reader has been connected and soldered onto the PCB we can stack all of it safely into the box as seen below. The LiPo battery can be recharged via USB and we can get a lot of usage out of it between charges, by putting the ESP8266 WiFi chip into deep sleep mode as often as possible.
We’ll drill two small holes for the LED’s at the top, connect the battery and make another hole for a USB charger connection. All sorted the finished product is seen below ready for mounting.
Coding-wise, I’ve used C through the Arduino IDE to make the whole project work. The code for this is below.
First, we use a temporary AP and IoTLink (www.iotlink.net) to connect to the assigned AP for internet access. Once that is routed and connected, we wait for a card swipe. We read the worker details off the card, and send this to ThingSpeak via our WiFi connection.
ThingSpeak supports multiple channels with up to 8 fields per channel. For this example, I used a single channel and assumed each field will correspond to an office or room. Since that is limited, you might want to create a channel per location where you want to mount an RFID reader and just use one single field per channel. This is a prototype project so I took the easy way out.
Once we are satisfied that the electronics work, and swiping a card generates data in ThingSpeak, we can switch to AX 7.
This is a quick project I put together to explore using small-size IoT modules for practical work, say Health & Safety or Equipment monitoring and reporting. For this post I’ll use the super-compact Cactus Rev 2 which gives me multiple I/O ports with WiFi built-in via an ESP8266 and I will use that to transmit three sensor values to Dynamics AX 7 via ThingSpeak.
The Cactus Rev 2 module is an amazing little device that measures less than 4cm by 2cm and is half a centimeter thick. It can be powered via USB or RAW and runs off <4v which is important as I want to power this using a LiPo battery to make it portable. The Cactus is pretty close to being the best possible module to use for building “wearable” IoT and can be powered using two coin batteries, with the ESP8266 being disabled and enabled as required to conserve power.
To make things a bit more practical, I’ll add a DHT11 temperature and humidity sensor, as well as a light sensor. I can also add an MQ9 sensor to detect various dangerous gasses but since that requires 5v it will need a booster added to the circuit so I’ll pass. It’s the idea that counts, right?
The completed circuit is shown below after soldering everything to a PCB and doing the required wiring, using 1 x Analog and 1 x Digital port all up, so leaving plenty of room for other sensors if required. I tried to keep things small and this measures 5cm x 4cm and about 1cm thick when completed. Keep in mind that sending this to production will drastically reduce the size, but this is only a prototype.
I’m running this off USB to test, but ran the wiring (top-left) from RAW and GND to the back of the circuit where I can mound a rechargeable LiPo battery, and this will recharge automatically every time I connect the USB cable. So it’s portable, virtually wearable and can be recharged at your desk.
We’ll use WiFi via the onboard ESP8266 and for that we’ll need an Access Point (AP) and obviously SSID and PASS. I could have opted to use an Arduino Nano with NRF905 instead as well. While it’s a prototype, we want to be production-ready so the sketch includes WiFi routing via a vendor/customer IoT Directory available at www.iotlink.net and I have coded this into the sketch. This means we’ll just need a temporary hardcoded AP during installation (or search for open AP) and IoTLink will take care of the rest.
The sketch code (in C) is shown below, pretty straightforward. We connect to a temporary AP, then using that and IoTLink find the correct customer AP settings in the device directory and re-route. Once connected we can start measuring sensor values and send that to ThingSpeak to display in a dashboard.
I could have used Azure IoT Hubs and Power BI instead of ThingSpeak, but getting that working is time-consuming (compared to ThingSpeak), requires TSL from what I can gather and the Cactus just does not have the power nor storage capacity (it does support SSL though).
Running our circuit via the Arduino IDE in debug mode shows us it is all working nicely, as can be seen below:
Dashboards are getting populated too, so the data is streaming in and we can move this into Dynamics AX 7.
Say instead of wearable Health & Safety we wanted to use this to monitor a vital piece of equipment on the shop floor instead. For that we’ll create a simple dialog in AX, and add an extended control which will do the data fetching from ThingSpeak and display it on a factory layout diagram.
I’ve been looking into new the control extensibility API of the latest version of Dynamics AX and it has a lot of potential. Unfortunately, my first thought when reading about it was that it could lead to a way to develop “Custom Controls” pluggable from the ToolBox, similar to other popular commercial toolsets like grids. Sadly, that is not the case (it seems) which is unfortunate. It can potentially create a substantial commercial marketplace for extensions, if possible. Perhaps I missed the point, or maybe Microsoft has plans for it in the future. I sincerely hope so.
Until then, we can still use the control extensibility API to develop small HTML based elements with custom properties, and the first stop to make would be at GitHub where Sharrief Shabazz from Microsoft has uploaded some good examples to get you going.
So starting with the BasicValueControl example, I’m going to play around and see what I can do. First, let’s create our three items required to make this work. We’ll create an HTML file and stick an IMG tag into then, then bind the SRC attribute back to our X++ code.
The X++ code that drives this binding is shown below. We’ve added a Url property which we will access from our Form.
So let’s create a Form based on the Custom pattern and see if we can access an offsite image located somewhere on the web. I’ll stick the image URL into the HTML controls’ property and run the form.
Okay so that works well and raises a number of interesting use cases. First, instead of having to store a repository of images for your Fleet Management system inside the AX database for say, parts or stock, we can instead point the image to another site where we might have already built up a substantial library of images. Excellent.
Now let’s take this a bit further. Say we have an IoT hub of sorts, receiving a number of sensor updates, and we want to create a dashboard showing these values in Dynamics AX. Let’s assume that hub is not running on Azure nor Power BI, but on another popular platform called ThingSpeak.
ThingSpeak provides a REST interface for both pushing IoT data into, and then retrieving back using the same API. So we can access the latest field values from a channel in ThingSpeak with a simple call, and with a bit of luck display this back in AX. Let’s have a look at our updated HTML control below.
We’ve modified our class a little to make the WebRequest call to ThingSpeak, given our channel, API Key and field for temperature (field 1).
So below we see this works, we receive back “23” into the control which is correct.
A bit ugly so we can style the HTML slightly as shown below:
That looks a bit better.
To improve on this, let’s add two controls, one displaying temperature and the other humidity, and then create a reusable helper class for making the API calls. We’ll update the Form as shown below.
Our helper class accepts the URL and returns the response, as simple as it gets. You might want to add an exception handler that returns an error message instead of the value; always a good idea.
So here we have the two controls shown on the form, opening up a world of new possibilities into offsite integration, data retrieval, API calls to protect IP by keeping the logic offsite, etc. etc.
Hope this post was worth your time!