Netduino is an open source electronics platform using the .NET Micro framework. I was using Netduino to create an IoT application which allows me to turn on the lights in the garage as I come closer to the garage.

Hardware:

  1. Gimbal (Proximity Sensor)
  2. Netduino Plus 2
  3. VeraLite (Z-wave controller)
  4. Z-wave enabled outlet.

Software:

  1. Azure Service Bus Queue – Setup to hold the commands/messages sent from the mobile App, consumed by Netduino/WCF service.
  2. Xamarin – To build the mobile app to detect the proximity sensor and send commands to the Netduino using the Azure Service Bus Queue.

This is the way I envisioned it to work:

IOT1

  1. The proximity sensor will be in the garage.
  2. The mobile app will get the proximity information from the sensor as the phone approaches the garage.
  3. If the user is close, the App will send a message to the Azure Service Bus queue.
  4. Netduino will poll to the queue for new messages.
  5. If Netduino finds a message, the command passed in the message is checked.
  6. The Netduino then connects to Veralite (Z-wave controller) and sends a command to turn the light on/off based on the command in the message queue.

In theory this all should work and it does in most part. I ran into a couple of issues here which I thought might be useful to anyone working on such projects.

  1. Proximity values from any sensor are always fluctuating. They are never precise. It only provides information that sensor is nearby. Don’t rely on the distance value. It is based on the strength of the signal and not reliable.
  2. Netduino runs on .Net micro framework. Currently, it does not support SSL. All the blogs I read said that SSL implementation takes up too much memory and Netduino does not have enough to support it. So, you cannot directly connect to the Azure Service Bus queue. Hopefully, someone will implement the SSL stack soon.

But if we modify the architecture a bit, we can overcome the SSL support issue. Here is the modified architecture that worked.

IOt2

I added an additional layer which acted as proxy between the Netduino and the Service Bus. Instead of Netduino connecting to the Azure Service Bus Queue endpoint, Netduino connects to the WCF service implemented behind the firewall. The WCF service checks for messages in the Azure Queue and returns the messages to the Netduino.

By using the Azure Service Bus Queues, we don’t have to open up ports on our router or setup port forwarding. Doing so, opens our network for all kinds of attacks. Not being a security expert, I would rather have all incoming ports shut tight than try and implement an authentication mechanism.