What services does an IoT Suite provide?
mindrobots
Posts: 6,506
In response to Microsoft's newly announced Azure IoT Suite, I'm wondering what products and services should be in an IoT Suite if you were building one from scratch with Open Source offerings?
I'm picturing Javascript/JSON/Nodejs from end to end. Either Espruino or ESP8266 IoT widgets out ant the end points connected back to a central IoT service location where the "suite" is housed. The endpoint minimum is a device that can connect to an IP network and do TCP/IP or UDP directly or else some wireless device (Xbee/GSM/serial) that connects to an IP connected concentrator for an area.
So what do you guys this we need to put into the Open IoT Suite?
I'm picturing Javascript/JSON/Nodejs from end to end. Either Espruino or ESP8266 IoT widgets out ant the end points connected back to a central IoT service location where the "suite" is housed. The endpoint minimum is a device that can connect to an IP network and do TCP/IP or UDP directly or else some wireless device (Xbee/GSM/serial) that connects to an IP connected concentrator for an area.
So what do you guys this we need to put into the Open IoT Suite?
Comments
Anything where the designers have given ZERO thought to the security of the device, or anything on its network. I mean, why be different.
So. Rule number #1. Whatever I put up in such a service has to be portable to any other such service.
Like we have seen recently, Google's source code repository thing is being discontinued. So it can happen with any "IoT" service.
Just make sure that whatever you invest your time in can be easily moved elsewhere.
Quite why MicroSoft want's to reduce itself to a common or garden service provider is beyond me.
Anyway, my main point is, avoid any kind of "lock in". Same like we do with our desktop software now a days.
I forget an important line from my Azure comment.
A software package that you can run on your own hardware in your own network, or you hardware exposed to the Internet or a bare server provider or a IaaS services from your favorite cloud provider.
Are there IoT "suites" in the open source world that let you run wherever you want to avoid lock-in or at this point are people rolling their own with a custom API built on their favorite pieces parts. And, yes, I know there are individuals makkng their own. Any cohesive packages out there yet?
SRLM mentioned a couple in the other thread I hadn'hadn't had a chance to look at yet.
There's apparently money in API's, that could explain Msoft's motivation.
Consider: Traditionally (Well since bill Gates pushed the idea) software packages were binary executables. That meant that if you did not have the right platform, the right operating system, your expensive binary would not run. That was the "lock in". It still exists of course in the Windows/Apple/Android/Ios world.
Aside: That is "expensive" in terms of real money you paid for it, or the hard work you put in to create it.
OK, what about this cloud thing?
Well, a lot of that is done with languages that are not compiled to binary. Python, PHP, JavaScript, whatever.
So where is the lock in?
As you said the APIs provided by the cloud provider can be an attempt at a lock in. Is that data store API available else where? Do other guys handle that oh so seductive IoT protocol?
My stance is that if they cannot provide a bog standard Linux machine in the cloud on which I can run what I like then it is a no deal. I want to be able to move stuff around, or take it back home when I want. Luckily Microsoft and Amazon and so on all do that.
So, that sounds like the same old, same old lock in thing we have been living with for three decades and more.
Heater, why do you keep on bringing up closed source, machine specific, cloud solution specific examples when all I've asked about is open source?
I'm betting every IoT service provider is coming up with their own API for IoT devices to talk to - tthat's where the monitization of the platform starts.
We've established I can go to any of these providers, Azure IoT Suite being the latest to enter the game, and get some degree of IoT cloud services.
That's NOT my question at all!
In the OPEN SOURCE arena are there any up and coming APIs for supporting IoT services? If not, what kinds of things should that API support?
What pieces of OPEN SOURCE software would people see being in this suite providing the infrastructure?
I think I would go MEAN without the AngularJS part. There will need to be a lightweight IoT framework to run on the endpoints.
This, being made up of all OPEN SOURCE software could expand, shift, shrink and move from platform to platform as the need dictates. I could run it at home on my own hardware in my own network and have the same Open IoT suite and API that you are running on your bare metal Linux cloud server you got from AWS. A startup could take the same OPEN IoT package and launch it as SaaS to compete against Azure IoT.
It would be an OPEN API built on OPEN SOURCE software.
Nobody is locked in because you can take your ball and go home just like with any other OPEN SOURCE software.
Does it make sense yet? No windows executables, no lock-in to Azure or AWS IoT or anything else it is all OPEN.
Of course, you could run OPEN IoT on a windows machine if you desire.
There are so many possibilities. Where to start? Every common protocol you could ever want to use between your "IoT" thing and your server is available in Open Source: UDP, TCP/IP, XMPP, MQTT, Corba, SNMP, HTTP, web sockets, etc etc etc.
Meanwhile you have every possible language available to code your apps in at the "thing" end and the "server" end. C, C++, Python, Lua, Perl, Java, God knows what.
In the middle you can put server software, Apache or nginx etc for HTTP, Jabber and others for XMPP, Mosquitto for MQTT, and so on and so on.
IoT is not new. I have pressed a number of these solutions into service for remote field units since a decade or more ago.
So, I still don't understand you. We have everything. What is it you are looking for?
Home/Office/etc
This is effectively the "CLIENT" end.
A bunch of wireless devices, for example...
* An ESP8266 based standalone using the 2+ I/Os to drive/read simple on/off functions.
* An ESP8266 based with a co-processor (propeller/avr/etc) to perform more complex functions including ADC and DAC.
A single WiFi (and/or other cheap wireless interface) with processor for...
* Communicating with the ESP8266/etc client devices
* Internet connection (not sure what this is - ethernet, UDP, etc)
* Could be an old phone with WiFi and cellular data, with simple Android/iOS app running to service clients.
* Could be a Raspberry Pi based device.
*Could be a cheap router running WRT.
Cloud style server
This is the "SERVER" end.
* Could be Raspberry Pi based.
* Can be located anywhere on the internet, even at the "client" end.
* Purpose is to store and forward the client info, and service the "remote control interface".
* Must be capable of operating with the "client aggregator" device which may not have a fixed IP address.
Remote Controller Device
This is the "CONTROLLER"
* Typically a Browser on a phone/pc/mac/tablet.
* Able to log into the internet from anywhere.
* Can be multiple devices.
General
By using a simple and general text interface between the WiFi client devices and the server, the server need not know what the data represents. It just stores the last text message, and when requested by a logged-on browser, it passes the text data to the browser and accepts a text message in reply. Text messages would be quite short normally.
Security can be overlaid, as and when required.
This makes it easy to setup and simple to debug. Let it grow with time.
You have to excuse @Heater.. He hates closed source so deeply that he even do not read a thread completely as soon as that red bull appears in front of him. I stumbled about this a couple of times now. Since I really like @Heater. and do like his contributions I try to overlook his constant nagging. Sometimes I can't and complain, but usually I am able to handle it.
On the other hand he developed flight control software not being open at all (thanks God or whoever decided that) for a living. Getting paid for closed source, but denying other people to do the same. Sad thing.
As I stated before in a couple of threads - it is a religious thing. And discussion of religion is not wanted here by forum rules. So I don't.
Back to the original topic.
For a guy like me, having various servers out there in the Internet the 'IoT' thing does not need any special software at all to be written, Any webserver will do. Even one written in Node.js. As soon as a device is able to uses TCP/IP or UDP/IP you are good to go. If you have your own server out there..
TCP/IP is a quite easy to use transport layer. Like serial com is. Just a transport layer. The positive thing is that TCP has some rudiment error checking and validation build in, compared to serial.
The main question is - what do you think the 'IoT' thing should do for you? The 'IoT' thing is a nice marketing buzzword describing nothing. Like 'cloud services'. Buzzwords.
I am quite sure that @Heater. can put out the 20-40 lines of node.js code to set up some cmd-interface at port 999 or 666 or whatever to communicate with your 'IoT' device in under 10 minutes. And you can too. Honestly.
So in my humble opinion there is no real need for a 'suite' at all. But who am I to decide. Last century I turned down two German students wanting me to program for them a Flee market in the internet. I told them this is stupid, people go to Flee markets to touch and see them things. They found somebody else to do it; and sold out to a company now known as EBAY.
This shows that I am not a business orientated person. So you might be right that there may be a way to make money with a service like that. Just because I do not think so. I am often wrong.
Else I have the same question as @Heater. had. What is it that you are looking for?
Enjoy!
Mike
OK, I'll try this again. Maybe all these pieces exist and I'm just unaware of it and it just boils down to be learning more about the subject to get it straight in my little brain.
For web development, the standard web stack was LAMP (or WAMP) or MEAN or now days, pick your favorite combination of tools. It's a set of common standards and tools that groups can debate about and hopefully be more productive with.
For IoT, the given transport layer is TCP/IP or UDP/IP depending on your needs. Cool, we send data/commands/statuses/etc around and around and back and forth.
Now, a nice way to agree upon formatting that data might be JSON. Ok, so now we can send data and we have a way to describe the content and give that data some meaning.
Next, when our little IoT device has something to say, it needs a way to tell the server that it has something or wants to do something. So we use APIs.
At this point, our nice little world falls apart because vendor X has their set of APIs for their service and vendor Y has a slightly different set of APIs for their services, etc., etc.
Are there any Open Source standards at the API? I haven't looked at any of the service provider's APIs but I'm sure they are all using slightly different ways to provide the same set of services to that little IoT device. If there was a standard set of Open Source IoT APIs it would be another standard to use as you implement your server code in whatever you want to implement it in.
Beside the reason, "because it is there", why send HTML formatted messages back and forth between devices. Is there a better way to encapsulate the information that IoT needs/wants? I just looked and found AMQP . so maybe that. Then there should be the a framework in your favorite language to easily build standard AMQP message, for example.
@mike, I know you can roll your own in your favorite language and that's cool but are we still at the point of constantly reinventing both ends of our IoT connections? I don't think so, I just need to put all the pieces together and see the tools all lined up ready to work with.
So there is a possibility for a "suite" defined by the richness of the Open Source API, maybe? From the API then, in either direction, your implementation choices are left up to the developer depending on how easy they want it (standard frameworks) or how custom they want it (roll your own).
At this point, I'm probably rambling and making even less sense.
I looked up some of the Azure websites and I have absolutely no idea what they are talking about. Cluso's explanation above is more my sort of language.
Xively is working well for me.
However, Microsoft have a way to go. Right now, the IoT is too expensive. Nodes need to be battery powered, run for months on one battery and need to cost $5 or less. $50 or $100 nodes are not going to work in a toaster that costs $19.99. So the ESP8266 modules are very exciting - but they are a pain to work with and you can spend days doing something simple. So I gave up and used an old laptop to translate a voltage into an Xively upload.
If Microsoft want to do this, they ought to look at getting one of their languages working on IoT hardware. eg C# on an Arduino, or VB.Net on a Propeller. Both unlikely to happen, though there are some intriguing rumblings with .net and the Raspberry Pi.
Now, before there is a hue and cry about evil corporates wanting to force their evil languages on us all... I see a solution. I believe the Propeller and the ESP8266 can be paired together to make a really useful IoT node. Cheaper than the Pi. Sufficient ram to do the job (unlike Arduino). And way less power than my old laptop solution.
As far as I can see, it is a matter of translating some vb.net into Spin, with an emphasis on text string manipulation. There are two pieces of code, one to upload and one to download. Probably about 100 lines of Spin all up.
Then... maybe you don't need an IoT suite? Consider - you have two $4 temperature nodes built around ESP8266 modules. Both upload to a site somewhere in the cloud. Now, maybe in the cloud you do something clever, push the data to a website, do an http post, buy stuff on ebay automatically, I dunno. But there is another way. Say you then have a third ESP8266 node and that reads the data and does a simple calculation - if node temp 1 > x, and node temp 2 <y, then make a pin go high and turn something on.
Now your IoT suite is the code you write in an ESP8266 module (with or without a propeller chip supporting it for better real world interface). If Azure goes belly up, you can port it over to Xively fairly easily because all those cloud sites are actually doing is acting as temporary stores for the data, they are not doing much in the way of smart coding.
I do agree with most of your post. But I still do not understand what you are looking for. A general API for all possible sensors out there? A message format shared by different sensors? IMHO it all depends on what you want to do. Say measuring temperature and humidity in all of the rooms of your home compared to measuring the temperature and the humidity of the rain forest in Brazil.
The sensor/IoT thing might be the same, but the backend software will be completely different.
My question still is what you think the buzzword 'IoT' really describes.
Still confused!
Mike
Currently we have no idea what sort of IoT devices will be available. The only thing we know is there will be digital pins for input and output, and analog pins for input and output. So, both read/write and digital/analog. Hence my suggestion of using a simple text message transport mechanism.
Obviously then we are going to require a handler to decode the text message(s).
For now, I am looking at using ESP8266 based devices, some standalone with specific code to read/write digital pin(s). The more complex ones will have a micro attached, and for my purpose, I will be passing text strings both ways to the ESP8266 for exchanging with the server(s).
For the server end, I would like to use a Raspberry Pi B+ V2 to hold the text message(s) and pass them out to Browsers running Android/iOS/Windows/Linux on phones/tablets/pcs/macs.
They offer the tiny, low power,WIFI modules for your "thing".
They offer the "cloud" services that your "thing" connects to.
They offer apps and APIs for your mobile phones and such to connect you to your "thing"
The whole IoT platform end to end.
Is this what people are looking for in an IoT solution?
https://www.youtube.com/watch?v=35XCUbscziE
Excuse me, I think I'm going to bring up my breakfast....
http://www.computerworld.com/article/2863498/networking-hardware/iot-groups-are-like-an-orchestra-tuning-up-the-music-starts-in-2016.html
"It really brings out Barbie's personality?" Hello????
"She'll become you're daughter's new best friend." Only if she can jump off the shelf and break into the house and survive being the dog's new chew toy! Only then is she worthy!!!
Next year, they are introducing NSA Ken.
Interesting - looks like they get Murata to lay down Broadcom and ST chips into a module and they write the software side.
Usually my arguments are about not getting locked into a single source of supply for whatever you want to do. No becoming dependent on a single vendor.
That debate always gets us in to a argument for or against Microsoft, then it starts to look like MS vs Apple vs Linux fan boyism, but that trivializes or hides the main point. True. I create software. I get paid by the hour or the month. That's the deal, like many other work places. It's not really my business what happens to that software afterwards. When you say "thanks God or whoever decided that" are you suggesting that some how a Boeing 777 whould be less safe if all it's flight software were open sourced? Why? To say that is to imply that there is no logic behind my statements. This is certainly not true. There are many practical engineering and economic arguments for open source software. Ask IBM or Google or Face Book. There are also political issues of self determinism and control. Writing that off simply as some irrational "religious" notion is insulting.
Anyway, I'm back here today because I over cooked my arguments re: support of Windows 10 IoT by the Raspberry Pi Foundation with the result that they banned me from the forum for a few days. A slap to the wrist. See here:
https://www.raspberrypi.org/forums/viewtopic.php?f=62&t=109613
http://the.linuxd.org/the-day-i-was-banned-from-the-raspberry-pi-forum/
That should give you chuckle msrobots
I really have to learn to be more precise in stating my case about this issue.
Hello!
Nothing personal Heater, but both of those are rather strange. Back when I was actively trying to get my RPI device to "do something grand" I kept bumping into issues and advice that was appropriate if I did not already have around 15 years prior experience with Tux.
Remember the device is not aimed at beginners.
And they are indeed half right regarding software being used by the banks. You should see the mail messaging that goes on when there are issues regarding the applications that the banks run, (that are intelligent to make use of the lists for IBM software).
Besides what they are not telling us is that to make use of the product for the device model 2 that was written by Microsoft requires Visual Studio for this year. And that's a fairly big reach.
And its getting stranger and stranger. That site for the Microsoft side of the house is getting more and more difficult to understand. And help when we need help isn't as easy to understand or easy to find as it is in here. (Or strangely enough on that site that doesn't like you.)
It will sort itself out. My guess is that when they let you back in someone else will make a fool of themselves and you'll end up looking right......
What all of you should look at is the Netduino 3. It contains several features that make things easier to understand. And it would be easier to connect one of its ports to a product from Parallax via a specific serial protocol. Yes they promote the IoT application from Microsoft Windows Azure, but that's their currently supported method. I imagine people could make use of Xively instead if they needed it.
[/quote]
Remember the device is not aimed at beginners.
[/quote]
The Raspberry Pi was most definitely targeted at beginners. Young ones at that. That is the whole point of the Raspberry Pi Foundation's educational mission.