2

I've developed an IoT device utilising OpenWrt so my design needs run a on a shoe-string budget of resources.

I need to be able to push small amounts of data, up to 300bytes to my app on a very irregular basis, something once a week and other time maybe 10 times a day, so I'm not looking to over-engineer this thing, but I do want it to be well engineered. I don't run a web server, app server nor java on the device and everything else is coded 99% in ANSI C.

Now I need to develop a mobile app to push these 300bytes to the IoT device and I'm procrastinating on the design. I'm interested in others'opinions on how best to proceed. I've considered a daemon that listens on a UDP port for a basic bytestream with a checksum, but I worry about security even though the IoT device sits on an Intranet. If I add TLS that's a lot of work for very little use. I could utilise sftp/scp but then I need to run the applicable processes on the device, which breaks with my minimalist design approach.

The 300bytes being sent just need to be appended to the end of a file on the device.

It seems I'm getting caught up in my head so I'd appreciate any thoughts.

1

If your device can run OpenWRT it's many orders of magnitude more powerful than most IoT devices. You can use something like an Arduino or less powerful device to do this. I know for a fact that such a device can:

  • Use UDP or TCP.
  • Communicate using very well established cryptographic protocols considered to be secure for decades using a shared key unique per device (the key is loaded at the factory or in-house).
  • Perform reliable* firmware upgrades and downgrades between any two versions you want to run.
  • Send and receive many kilobytes per day for many years on a watch battery.

Running such a slim device actually gives you a lot of advantages:

  • A single person can actually understand all the software running on it. As soon as you're running Linux there is not a chance that you will ever have the time to read all the code and understand it.
  • You can tailor the communications protocol very easily. I've mostly worked with interchange languages like JSON and XML, but a very well-defined custom package format right on top of TCP is fantastic for debugging. Your communications stack is basically two or three levels shallower than most microservice architectures.
  • Since the only thing running on your device is so simple you actually have a chance to test it exhaustively. This should start on day 1, and if you follow it through you'll have a rock solid service.

* Atomic in the sense that only a single bit flip is responsible for deciding which stored firmware is running, reentrant as in resuming firmware upload at the exact package it last sent, secure because the entire transfer is encrypted like any other traffic, and safe because a checksum is verified before flipping to the new firmware.

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.