9

I'm working on a device that sense and collect information from the environment such as temperature, humidity, etc.

The device is not connected to any power source, but it has a battery, and a solar panel to charge it.

It's almost in a deep sleep state most of the time, and it only wake up when it need to sense and transfer data. This operation takes about 1-2 minutes, and then it goes to sleep again.

I'm not an expert in this area, but I think MQTT should be a good option if the device need to be accessible to receive messages from a topic all the time, but in my scenario it only read sensors, and send data to a server periodically.

Currently I'm sending the data through HTTP, but I'm wondering if it makes sense to implement MQTT? Should I get any advantage over HTTP for this scenario?

  • 1
    It's similar, but my point is to understand if do I need to implement MQTT in my scenario: when my device will be in deep-sleep 99% of the time, and just waking up for sending readings. – zephrax May 19 '17 at 20:28
  • 1
    I would suggest neither. Firstly write out your requirements, and implement the most simplistic protocol. It would not make sense to use a Ferrari Engine in a lawn mower to cut grass. Do not get caught up in the buzz-wordiness of things - Just do your basic research and implement what works best. – Xofo May 19 '17 at 21:48
  • Would be nice to capture the requirement in the question title, Generically, you're asking about small, infrequent sensor values, I think. – Sean Houlihane May 19 '17 at 22:17
  • @Xofo I'd be interested to see an answer around that, and why you might suggest using a custom protocol. Is it worth the additional effort of 'rolling your own', plus the security issues, etc? – Aurora0001 May 20 '17 at 10:33
  • Not a custom protocol ... I said first define the requirements. Some of the protocols prescribed are often too heavy. – Xofo May 22 '17 at 18:07
8

If you are storing data, simply stick with HTTP. HTTP is just a one way signal.

If your server or any other "thing" should react to a specific signal (low temperature,...) then use MQTT. Like this many devices can subscribe to your temperature signal and immediately react without using your server.

  • 1
    Also there is a division between big (http) and small (mqtt) amount of data at once and also mqtt is more reliable on bad signal conditions. – mico May 19 '17 at 17:56
  • 1
    The server only receives data from sensors. The point of my post, is that I'm not sure if makes sense to use MQTT, because the device will be 99% of the time in deep-sleep state (all of the buses, modem, sensors turned off) and it only wakes up to read sensors and send data. – zephrax May 19 '17 at 18:40
  • If you store your data somewhere, this means you have a database and a backend way to query it (apache server, command line SQL,...). If you put a MQTT on top of this you will have another instance and port to manage. – Goufalite May 19 '17 at 21:03
  • 1
    I agree with this answer. If you don't need two-way communication, and the device is asleep a lot of the time, then HTTP is a simple and suitable protocol choice. – TheMagicCow May 20 '17 at 14:15
8

You mention a solar panel and battery as part of the device, so you probably want to minimise the power usage during transmissions to make sure your device doesn't run out of power completely.

Therefore, you might want to consider CoAP, the Constrained Application Protocol, which is specifically designed for constrained devices in the Internet of Things.

In the paper Comparing the cost-efficiency of CoAP and HTTP in Web of Things applications, you can find some pretty compelling evidence that CoAP might get you some power savings here. In Appendix A (page 38), you can take a look at the expected battery life of devices in Table A.4. For a time interval of 120 seconds, as you're expecting in your use case:

tbat (HTTP), days — 2013

tbat (CoAP), days — 11013

Those calculations were run on a pair of carbon-zinc AA batteries, but you can clearly see that CoAP uses a lot less power, so it might be worth considering. Its 'push mode', as described in the paper, seems like exactly the sort of thing you plan to do.

Although you didn't specifically ask about CoAP, I think it's worth a mention, since Goufalite has already covered the essential differences between MQTT and HTTP. A good rule of thumb is: do you plan to communicate one-to-one, or one-to-many? If it's the former, HTTP and CoAP seem like better fits. If it's the latter, MQTT is probably more convenient.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.