There is a glaring, painful hole in the current mBed IoT platform as it currently stands which unfortunately is something recurrent throughout the IoT ecosystem. There are no server functions. If your device is going to pulling and pushing to the mothership, and only the mothership, then the API they gave is adequate. However, if you want your IoT temperature nodes to be able to talk to your IoT vent register nodes, you have to have both of them polling the main server to fetch and get data, and have both become expensive paperweights when your internet connection drops.
It seems to be a recurrent problem with the mbed universe. The mbed editor, which they're going to be revamping Real Soon Now, has very much the same problem, where losing internet connectivity means that you're without an editor until whatever problem is corrected. IoT is only really going to be useful if the Things can talk back, otherwise, you're just going to have half-assed toys.
Sanddancer - Interesting perspective - We are building sensors and vents (https://flair.co) and definitely getting the right amounts of function with and without the cloud is a major portion of our platform. Not using mbed Intranet vs Internet of Things is a huge question mark on the IoT imho.
Yeah, that balance is something I'm working on in the various animatronic and costuming projects I've got going. Yes, there is interesting reason for an internet enabled costume, but yeah, it shouldn't all fall apart just because it can't get signal. Though your product so far looks pretty great, it's definitely something I'm going to be bringing up with my housemates regarding the problems a household of seven generates regarding heating and cooling.
I took a look at the mbed os socket API, and it supports opening a socket in 'listen' mode. With a few lines of code, you should be able to build this into a basic server. What functionality is missing that would be required for the use cases you mention?
mbed's documentation is an absolute mess, with islands of information and little to no linking to relevant places. I had been looking at their mbed client api -- https://docs.mbed.com/docs/mbed-client-guide/en/latest/ -- which only supports client -> their server activities, and doesn't link at all to the lower level APIs. The socket support they provide is also a lot more limited than other RTOSes that target Arm Cortex-M devices, for example TI RTOS and NXP's MQX both offer IPv4, and full IPv6.
Then again, it seems to typify a lot of ARM's software offerings. They have Keil uVision, which is an Eclipse-based IDE, that is barely mentioned at all in the various mbed documentation, and doesn't have any integration with their newer toolchain they seem to be building up. It just gives a very unfocused feeling in general regarding using their toolings.
Insecurity of things... by default, the connection is insecure [1][2] and unencrypted. But at least they're starting to move in the right direction [3], if you have a commercial license.
1. The link you provided is about LWM2M Security Object, not about how the mbed client connects to mbed Device Connector (https://connector.mbed.com/).
One of the various esp8266 boards comes to mind. You can find them for a few bucks off ebay with various levels of functionality. They can act as wifi aps, support wpa, and have a few io pins at the very least.
Though one of the things you'll discover with a lot of embedded chips is that the integrated editor they are paired with tend to have utilities to help you manage the IO configuration registers, clock dividers, and other less than and/or non-intuitive parts of development.
There are innumerable ways to do this with traditional embedded software tools, not need for any "IoT" stuff, for example LwIP on any number of supported dev boards.
What people never seem to realise about embedded s/w is that these devices are only cheap (and hence viable as products) when produced in many thousands/millions...
Because of this, the bill-of-materials overrides any other concerns so you end up picking the smallest/cheapest possible device you can and do your utmost to make it work.
This means you need to be intimately familiar with the low-level aspects to be able to optimise your code to the hardware.
The best you can say about these environments are that they are for "rapid-development". no one would ever take a design created in one of these type of environments (Arduino included) and make a viable product from it unless cost was not an issue, which is never the case in the embedded world.
So, in answer to your question, it is all possible... apart from the 'cheap-as-chips' part unless you opt for traditional low-level embedded s/w design.
Don't quite grasp it, I am not into the field much, but I try my best.
A little chip that can read analogic OR digital IO and securely send over via radio seems to me like a very standard, reusable and useful piece of hardware.
It is something that you can sell to pretty much every industry, so you have a lot of scale to leverage.
I do understand that, if your application need to read temperature and send it over you will design the whole chip together, but when your application need to read also humidity and send it over I believe that you can reuse the design of the old chip; so, over the years, a standard way to read from IO and send over secure radio connection should emerge.
There are standards for each part of that process, both reading the ADC and transmitting data over a low-power WAN.
The problem is that on its own, that isn't a saleable product, everyone who has a need for that would be able to make it cheaper if integrated into their product as-a-whole.
Integration is everything.
I would recommend low power nRF51 chips. It's a Cortex M0 with integrated 2,4GHz radio. You can use is for Bluetooth Low Energy and communicate with other chips / smartphones / etc (manufacturer provides a BLE stack) or your own simple protocol. There are some modules below $10, but those would require additional USB chip (like ft232 or $2 pl2303 / ch341 module).
If you need a long distance (like 1km) communication then you need a "larger" radio which works in ISM band. For the cheapest solution I'd go with mass produced devices - two WiFi APs with 2 directional antennas + some custom boards ob both sides or APs with open firmware like openWRT.
The really missing piece is the connectivity, I need something that can read data somehow and then transmit a point A to a point B, where A and B are at least 1km away from each other...
The 1km requirement is the killer for this plan, as you run into radio regulatory requirements. There is the "Weightless" system operating in the old analog TV bands, but I'm not sure that's made it into shipping products yet.
Every time I see Linux used in a project like this, it feels like hitting a trim nail with a sledgehammer. I hadn't seen mbed OS prior to this article, and after perusing the documentation and checking license (apache), I have to say I'm pretty stoked about it. mbed os seems to be far better suited for tiny / lightweight devices than Linux ... anybody used it in an actual project? Have any thoughts to share?
Some of them are really cheap, e.g. the ST Nucleo boards are about £6.
The only reason I can see anyone would choose Arduino over mBed is if you really need native 5V. One could also argue that while the Arduino "IDE" is totally awful in almost every way, at least they have one. mBed currently only has an online IDE which is powerful but slow and online, or Yotta which is nicely written but currently command line only, and only supports a few boards.
the little microprocs I'm dealing with, couldn't even run Linux (256kb storage, and 32kb ram). I'm using it, but only for prototyping so far. Works nice enough so far, except that I'm not very good at C/C++! The ecosystem their setting up around their yotta tooling is very promising.
I've been doing a bit more than poking around in this space, and I'm curious what your language of preference and hardware specs are? Something like an esp8266? Or smaller?
One of the best things about all this is ARM buying and open sourcing PolarSSL. We at Thingsee have been using another POSIX-like RTOS called NuttX, but there was no viable free SSL-library with low memory profile before that anyone could use.
It seems to be a recurrent problem with the mbed universe. The mbed editor, which they're going to be revamping Real Soon Now, has very much the same problem, where losing internet connectivity means that you're without an editor until whatever problem is corrected. IoT is only really going to be useful if the Things can talk back, otherwise, you're just going to have half-assed toys.