4

I have a internet connected IoT device (let's say advanced internet connected weather sensor, which can send sensor data and perform some advanced operations like rotating, switching on, opening valves/and few other operations).

EDIT:

The device is wall powered (electricity socket), and has mobile internet connection standard wired Ethernet connection (just plug in Cat5 cable)

I need to be able to get status (approx 500bytes of data) of the device, AND want to be able to send simple commands like:

  • rotate-180-deg
  • turn-lights-on
  • turn-lights-off
  • open-valve-1
  • switch-sensor-X-on
  • switch-sensor-X-off

Currently my device is sending a HTTP request every (2minutes) to my central server with it's status. This works perfectly for getting readings of the devices sensors. However this approach becomes more problematic when I want to send commands to the devices. Eg. if I want to send command rotate-180-degrees, my central server has to wait until it is contacted by the device and in the Response for the HTTP request - I can put some command, so when the device receives the response, it will actually execute the command.

However this approach has flaws:

  • it is not real time (I have to wait for 2-3 minutes before I have a chance to send a command)
  • i do not know whether the command was received by the device or not (eg. in case of network error)
  • i do not know whether the device has acknowledged or executed the command (neither the status)

What could be the solutions for this problem?

UPDATE: As @mhopeng suggested, the most flexible solution seems to be turning the device into a "server", so that it can accept incoming connections. However, because the considerations of security, firewalls and complexity we cannot go this way. Also device needs to be simple to install: third party maintenance stuff should be able to simply plug the device into wall and ethernet, and it should work. (No need for configuring port forwarding, firewalls, etc).

FYI We also use PIC microcontrollers in this device.

Dimitry K
  • 2,236
  • 1
  • 28
  • 37
  • Seems like you want a server running on your device, waiting for incoming commands. Choose your protocol (maybe HTTP, since you already use it), then implement a server. – mhopeng Feb 11 '16 at 18:56
  • @mhopeng thank you for the idea, but I thought that turning device into server (as opposed to passive client), will increase complexity: what if the device is behind firewall and doesn't have public IP to connect to. Also security layer will be much more complicated in this case. Also it opens up new vector of attacks (eg. flooding etc). So even though turning device into server seems to be most flexible approach, it seems to complex for our simple device and environment. Any new ideas are appreciated! – Dimitry K Feb 12 '16 at 10:33
  • You might consider a lightweight messaging protocol like [MQTT](http://pubsubclient.knolleary.net) or [zeroMQ](http://stackoverflow.com/questions/8867881/is-it-possible-to-run-zeromq-on-an-arduino). Of course, "it just works when I plug it in" is not an easy thing to do, no matter the protocol... – mhopeng Feb 12 '16 at 21:06

1 Answers1

2

This article details three options for sending data from a server to a device.

From your description, it sounds like you're using short polling:

The most basic way to solve this communication problem is called short polling—a method where the client periodically asks the server if there is new data available for it. This is the simplest solution to code, though it is not recommended if you need to notify a device in real time.

The article then goes on to describe option 2, long polling:

The next option is long polling. In this case, the client performs the request and the server won’t respond until it has something to send. This enables real-time push notifications from the cloud to devices, though it requires the device to leave the connection open for as long as it needs to listen to the server. Using this technique consumes more energy and also risks the loss of the connection. Consider the case where a device remotely controls the door of a truck. If a long poll request has been made, and then the truck goes into a tunnel, the mobile connection will drop. The device will then need additional logic to kill the hung connection and open a new one.

And finally, it details option 3, using a different protocol:

A third option is to use newer protocols like CoAp or MQTT, for example, which were designed to provide low latency, small packet sizes and stable communication over weak networks. These newer protocols provide a two-way communication channel, which in turn supports push notifications. This makes them good choices for IoT projects requiring the ability to control connected devices in real time. The only downside could be the lack of firmware libraries and examples for embedded devices, which are significantly more abundant for HTTP-based connections. Choosing the right protocol will depend on your application and how often you will need to communicate with a device.

Patrick
  • 11,552
  • 7
  • 29
  • 41