ARM Mbed IoT Device Platform
mbed.com
mbed.com
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.
Relevant link: https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/1...
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.
[1] https://docs.mbed.com/docs/mbed-client-guide/en/latest/Howto...
[2] https://docs.mbed.com/docs/mbed-client-guide/en/latest/api/c...
[3] https://github.com/ARMmbed/mbedtls
*edit: formatting
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 - 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...)
3. You can see in main.cpp (https://github.com/ARMmbed/mbed-client-linux-example/blob/ma...) that we're using certificate mode (line 128), and that's also on free accounts
https://docs.mbed.com/docs/getting-started-mbed-os/en/latest...
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
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.
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.
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.
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.
Because some markets like the industrial market - will be willing to pay a bit more for that.
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...
https://en.wikipedia.org/wiki/Weightless_%28wireless_communi...
LoRa is a low power,low data rate modulation scheme that can transmit miles. Modules are starting to be available: http://www.microchip.com/design-centers/wireless-connectivit...
There are also a much wider variety of boards available:
https://developer.mbed.org/platforms/
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.