
ARM Mbed IoT Device Platform - fitzwatermellow
https://www.mbed.com/en/#
======
Sanddancer
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.

~~~
dmritard96
Sanddancer - Interesting perspective - We are building sensors and vents
([https://flair.co](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.

~~~
Sanddancer
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.

------
officialchicken
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] [https://docs.mbed.com/docs/mbed-client-
guide/en/latest/Howto...](https://docs.mbed.com/docs/mbed-client-
guide/en/latest/Howto/#security-object-resources)

[2] [https://docs.mbed.com/docs/mbed-client-
guide/en/latest/api/c...](https://docs.mbed.com/docs/mbed-client-
guide/en/latest/api/classM2MSecurity.html)

[3] [https://github.com/ARMmbed/mbedtls](https://github.com/ARMmbed/mbedtls)

*edit: formatting

~~~
DyslexicAtheist
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/](https://connector.mbed.com/)).

2\. To get a better feeling on how a device would actually connect to the
server, here's an easy to follow example: [https://github.com/ARMmbed/mbed-
client-linux-example](https://github.com/ARMmbed/mbed-client-linux-example) \-
this can be built & run on an Ubuntu machine. (Note: there are some
prerequisities, as explained in [https://github.com/ARMmbed/mbed-client-linux-
example/blob/ma...](https://github.com/ARMmbed/mbed-client-linux-
example/blob/master/README.md))

3\. You can see in main.cpp ([https://github.com/ARMmbed/mbed-client-linux-
example/blob/ma...](https://github.com/ARMmbed/mbed-client-linux-
example/blob/master/source/main.cpp)) that we're using certificate mode (line
128), and that's also on free accounts

------
danielvf
Since it took me far to long to find actual code, here's the hello world
equivalent getting started code.

[https://docs.mbed.com/docs/getting-started-mbed-
os/en/latest...](https://docs.mbed.com/docs/getting-started-mbed-
os/en/latest/FirstProjectmbedOS/)

------
siscia
All I am looking for is a couple of devices that you pair together.

The first devices should only be able to read values from some standard input
source and transmit them in a secure way to the second device.

The second devices, the receiver, should only be able to receive values from a
swarm of transmitter and stream values over via USB.

Those devices should be crazy cheap, actually they do close to nothing, very
power efficient, open source and without whistle and bells...

No integrated editor (why do I need an editor anyway), no integrated dashboard
or data collect services, that can be easily implemented later...

Is there anything similar ?

Edit: USB, not TCP/UDP

~~~
TickleSteve
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.

~~~
siscia
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.

~~~
TickleSteve
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.

------
danjayh
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?

~~~
johnny22
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.

~~~
pedalpete
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?

------
pasiaj
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.

