IoT Router idea

[zeke 693]

Howdy Everybody!

 

I have this big project idea and I don't know exactly where to put it so I'll try here in the off-topic forum first.

 

I was just thinking about a neato device that might be of benefit to us as a community and I would like to get some feedback to see if this idea has any merit.

 

I discovered the BeagleBoneBlack last month and Holy Mackerel is that cool! I was thinking of a product based on that work. Namely, an IoT router/aggregator/access point. 

 

It would be a Linux box that acted as a WiFi access point, an Ethernet router and, an RF access point. It would speak to all the wireless or ethernet enabled data loggers that we are making.

 

Combine this with thingspeak and this could be a game changing device. I think the IoT ecosystem would finally start to coalesce and become a firm, open source foundation to build on. It also wouldn't be in the hands of just a few companies who are trying to control it all i.e.:cisco, contiki, etc...

 

For fun, we could call it "Houston" ;-)

 

Does this IoT ecosystem idea hold water?

 

What do you think?

 

 

[jpnorair 340]

If you want to make it for yourself or hackers, then great, do it.  If you think it is going to be a hit with the general public, it probably will not be -- the IoT/WSN hub has been tried many times, but it's an engineer's solution to a problem that a marketer should address instead.

 

I think a better approach is to make USB sticks and try to develop a common interchange format so that host apps can be easily adapted to suit other protocols / technology stacks.  NDEF is a decent one to consider.

[zeke 693]

I like the idea of a common interchange format but I think that is where all the proverbial gunfights are happening right now.

 

I have encountered this from Synapse Wireless, Digi, Contiki, Exosite, Linear Technology to name just a couple. I am certain that there are more out there trying to carve up this IoT pie.

 

Maybe I will grep the RFC's and learn what interchange formats out there already.

 

I have to admit, this idea came out of my frustration with Contiki. The OS is free but the ThingCloud service is closed source. It's like every piece of the puzzle is right there except the server. Know what I mean? This is why I thought of ThingSpeak because it's open source and I can run it on *my* server.

 

To use an agricultural metaphor, I am contemplating the idea of clearing a field then plowing it and seeing who might want to plant their garden in it.

 

Yeah, I don't know if there is a real business case for this. I don't think I really want one, to be honest. Okay, my wife wants me to have one. 

 

Still, I am just dreaming out loud, I guess.

[jpnorair 340]

I like the idea of a common interchange format but I think that is where all the proverbial gunfights are happening right now.

 

Everyone with an application protocol seems to be very self-righteous about it right now, despite the fact that the application layer is not a terribly fundamental component.

 

Interchange formats are not really application protocols, just consistent ways to ferry protocol data (or whatever).  VT100 is an example.  Amazingly, there is an utter dearth of these.  NDEF is one such, although it's an NFC product so it's not through the IETF.  Frankly I'm not crazy about IEEE or IETF.  Almost never does anything worthwhile come out of these groups anymore, as they are way too bureaucratic and way too academic.  Occasionally, a company will inject a standard into IEEE/IETF and steamroll it through (at great cost, I might add).  That's the only time I see worth in IEEE.

 

Everyone right now in IoT is afraid to give users control of their data because no one is making any money.  That is, everyone is searching for a business plan, and no one wants to give-up anything in the event that Google, Facebook, or Apple want to pay for IoT user data through overvalued acquisition.

 

But, I can promise to you that some IoT companies are emerging that operate on a different model, namely opening an SDK but owning other parts of the stack.

[zeke 693]

Yeah, I agree about the self-righteous part. It's good to remember that we all started with nothing.

 

 

I think what I am focusing on with this concept is more than just an interchange format though. It's bigger. It's not restrictive nor expected to be a rigid concept. It's amorphous like a cloud or a big box of LEGO at the moment. 

 

In my imagination, this router concept is more like LEGO - it does one function really well or it can be combined into something else that does something else really well. So this will leave the end result up to the imagination of the user.

 

How would I like to use it? Well, I imagine it something like this:

 

I imagine that I would like to build an automated watering system for all the trees, the lawn and the fruit garden in my backyard. I would have water valves that would need to be controlled according to a time schedule with feedback from a local weather station - just to make sure that I am not watering during a rainstorm. These valves would receive instructions from a master controller. In this case, it would be this router. 

 

The router would provide a command and control console to a user via a webpage. So this implies that the router is TCP/IP capable. The router would also be able to talk directly to the remote valve controllers. Maybe the remotes have sensors on them as well? Anyhow, this implies that the remotes and the router would have some sort of communication pathway. This pathway could be anything you wanted it to be: RS485, Wireless, whatever you desire. It would simply be a module that you plug into the router. 

 

The router would have some sort of web server inside of it. Whatever the kids are using these days ;-)  The webserver would have to be easily programmable. None of this "compile a file system" bullcrap. Just ftp/samba/scp the files onto the server and POOF! they are there ready to get to work.

 

The web server would push JS files at the client so all the hard work would be done by the browser client and not the web server.

 

The router would also be able to talk to a remote database so that local file storage isn't a massive burden. The database server would run on something else like a Linux box. I was imagining ThingSpeak could be of service here. Why reinvent the wheel if you don't have to?

 

You could then browse to the router and see the real-ish time command and control web page. Or you could browse to the local ThingSpeak server and see the processed data i.e.: a year's worth of data that the system has collect. Or you could run reports on all that data. Again, the limit is your imagination.

 

The over arching idea is to enable the user to build complex systems in the simplest way possible just like LEGO.

 

I do like the name Houston because of the rocketry imagery with the LaunchPads. I don't know all of the folk lore so maybe a better name is Cape Canaveral or Mojave or whatever.

 

I don't intend on holding this idea to my chest in a selfish manner. My hands are open in a gesture of generosity. I have already participated in building such a system for a commercial entity. Now, I just want to build something cool that I and everyone else can use freely (like LEGO) ;-)

[roadrunner84 466]

I like your enthusiasm, but I fear you're just making a "standard number 42" so to speak.

Let me tear your system down to its bare minimum:

 

" Have a thing that does one thing very well and can be combined to do something else very well.

> A programming language, preferably a script, so you do not depend on compilers and the such.

 

" Have something run on a schedule and talk back and forth over the internet.

> Any socket or HTTP capable language which also includes timers.

 

" Control panel over HTTP.

> A webserver (with a scripted language inside).

 

" Communication with the sensors / actuators.

> A native interface for your language.

 

" Easily programmable webserver.

> Your framework will essentially have CMS capabilities.

 

" Push JS to client for number crunching.

>  Still webserver.

 

" Access remote database.

> Most SQL are agnostic to local/remote access. A REST API is possible too, or SSH, or FTP, or telnet...

 

" Parse raw data into (HTML) reports.

> Which is already possible by pushing JS.

 

" Build complex things in a simple way.

> Any expressive language with sufficient abstractions.

 

I may be a bit crude here, but what I try to tell you is that your idea is general enough to say:

"I want a comprehensive library to do what I mean and run it on an HTTP enabled device"

 

I'd suggest writing a nice library to run on top of Node.JS (which would in this case be my preferred back-end).

Storage and HTTP serving are trivial tasks.

Interfacing with hardware (eg: RS-485) is a bit less trivial, but doable as well.

The rest is all about a good design for the scheduling of well defined tasks.

[eck 4]

Have you checked panStamp? The server might do what you want (actually, it's two servers, one for interacting with the wireless netwok, the other for interfacing with the cloud), and seems also quite hackable in case something is missing. You can decouple the pieces, and have an own local protocol for talking to the wireless network (I'm just doing that with MSP430 based nodes using NRF24L01 modules).

[Automate 69]

Speaking of panStamp, they have a discussion about what people want in an IoT router/gateway.  http://www.panstamp.org/forum/showthread.php?tid=2872

From the comments there is a wide range of functionality people expect from a gateway.

[jpnorair 340]

panStamp is for the maker niche, as is the concept of an IoT router box in general.  If that's where you want to go, good, because that's probably the only space where an IoT router can be successful.  A beagleboard connected to a USB hub and an ethernet cable for internet is probably the choice hardware, and then you just need to worry about the software.

[zeke 693]

Yeah, these are all excellent responses.

 

@automate: The IoT router/gateway discussion is exactly what I am talking about. I can see that those guys are wrestling with the concept as well.

 

@@jpnorair & @roadrunner84: You are both right that the problem pretty much just boils down to software. And that's why this discussion tends to lose steam.  In fact, it is my guess that everyone is losing steam when talking about the router/gateway product design. 

 

I finished up on a project recently for a client and we too wrestled with this topic. The company is probably still wrestling with the server side software today because they cannot make up their minds. They are spending Millions of dollars a year because of this. I had to get away from them.

 

 

But, I do not dispair because I have a perfect example of a product that I think everyone should emulate. It's the NetAtmo Weather Station. The iPhone looks amazing and it is quite intuitive but that is not what I want to discuss. It is the backend that I think is the most important feature. 

 

You buy the Netatmo weather station and you plug it in at home. You use the app on the iPhone to configure it so it can use your WiFi. It then dutifully reports all the sensor data back to the Netatmo database server. When you fire up the app on the iPhone, the app reaches out to the server and spits back your weather data in a visually appealing way. You, the end user, think that you are talking directly to the device on your mantle but you are not. This process is simple and very effective. This style of implementation is what we should all aspire to.

 

This is my end goal - to make a device, a server and an app that allows you to acquire, store and monitor your data as simply as possible. It should also enable you to control your Endpoints as simply as possible as well.

 

We create the Endpoints and they do whatever we desire.

ThingSpeak is the server (I believe). 

The web app interface is the App for the end user to play with.

 

 

@@jpnorair: Commercialization of the concept is not a requirement at the moment. We are just making ideas fight each other to see what has merit.

 

@roadrunner84: A Node.JS server would be really awesome, I think. As long as the hardware it's running on is powerful enough then why not.

 

@eck: The panStamp is just an Endpoint so, sure, why not include it? The router should be able to learn new protocols as hardware modules are added.

 

 

Great ideas guys! Keep making them fight for their lives.

[eck 4]

@eck: The panStamp is just an Endpoint so, sure, why not include it? The router should be able to learn new protocols as hardware modules are added.

 

It is actually also a gateway, maybe a bit hidden, but here's more information: http://code.google.com/p/panstamp/wiki/lagarto

[zeke 693]

You are right. That was hidden. I will study that and see what I can learn.

[roadrunner84 466]

But, I do not dispair because I have a perfect example of a product that I think everyone should emulate. It's the NetAtmo Weather Station. The iPhone looks amazing and it is quite intuitive but that is not what I want to discuss. It is the backend that I think is the most important feature. 

 

You buy the Netatmo weather station and you plug it in at home. You use the app on the iPhone to configure it so it can use your WiFi. It then dutifully reports all the sensor data back to the Netatmo database server. When you fire up the app on the iPhone, the app reaches out to the server and spits back your weather data in a visually appealing way. You, the end user, think that you are talking directly to the device on your mantle but you are not. This process is simple and very effective. This style of implementation is what we should all aspire to.

 

This is my end goal - to make a device, a server and an app that allows you to acquire, store and monitor your data as simply as possible. It should also enable you to control your Endpoints as simply as possible as well.

 

We create the Endpoints and they do whatever we desire.

ThingSpeak is the server (I believe). 

The web app interface is the App for the end user to play with.

I see you're very enthusiastic about this idea. I certainly do not want to discourage you, I just tried such a thing (with a bit different situation) and the problem that arises is that there is a tradeoff between flexibility and ease of use.

 

The thing you describe (NetAtmo) works because it does one thing really well (monitor weather). As a result there:

- is a clear description about how the data behaves (frequency, units, detail).

- is a clear way such data is presentable to users (time charts with graphs for specific weather properties).

- is a possibility to design a concise user interface.

 

When you broaden the idea, you run in the problem that you have to trade the wider range of use cases to more effort to design the interfaces:

- is a graph the right choice when I monitor lamp usage in my home?

- is the data not too sensitive to send to a cloud unencrypted?

- is the setup of the sensors to the gateway as simple as the netatmo? (note that the netatmo uses a specific PAIR of sensor and gateway)

- does our current user interface provide the right controls for the user's intended use?

 

As a result you will end up with a frontend that must be completely scriptable (unless you confine your usage scope) and a gateway (sensor data aggregation point) that must also be completely scriptable.

Hence I say you'll end up with running a scripting engine (like nodeJS) in your router and another scripting engine (your browser's JS engine) in your frontend.

 

I'll finish up with a quote that basically tells just this:

 

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.

[zeke 693]

I am totally in agreement with your observations.

 

The thing you describe (NetAtmo) works because it does one thing really well (monitor weather). 

 

Agreed. Single application is superior. They control the entire ecosystem and make it do one thing very well.

 

 

When you broaden the idea, you run in the problem that you have to trade the wider range of use cases to more effort to design the interfaces:

As a result you will end up with a frontend that must be completely scriptable (unless you confine your usage scope) and a gateway (sensor data aggregation point) that must also be completely scriptable.

 

This is what Exosite is doing. They use Lua to program in the "instruments". It became too clunky and restrictive for my client so they moved on to parse.com. I am not a fan of Exosite.

 

 

Hence I say you'll end up with running a scripting engine (like nodeJS) in your router and another scripting engine (your browser's JS engine) in your frontend.

 

My client programs the gateway (an embedded Linux box) in C and Python and fires the data at a Parse.com database.

 

Then they have a custom iPad app that scoops data out of parse.com and presents it on the iPad. This iPad app is their money pit at the moment.

 

 

I suppose then there is no practical way of accomplishing this task since the best solution is a custom solution for each different application. Too bad.

 

Maybe the better thing to do is come up with an ecosystem architecture that is reusable like LEGO. Then acknowledge that the UI and database tables will always be a custom solution.

 

I will ponder a better set of questions to further this discussion.

 

 

BTW, I love your quote at the end. Amazing!

 

 

[zeke 693]

I just noticed this product from TI tonight:

 

ZigBee Home Automation Gateway reference design

 

Apparently, TI is trying to define and solve this problem too.