IoT, like BigData before it, is suffering from an overload of people building technology for the sake of technology. I have done a lot of hands-on work in the Remote Service side of IoT, implementing solutions for GE, the TSA, etc.
At no point did I ever encounter a customer who longingly cried out "Woe is me, is there a horizontal technology anywhere that kinda solves a piece of my problem?!".
I fear that as we follow down the hype curve in IoT over the next 24 months, the roadsides will be littered with interesting and functional platforms that failed to solve a business problem.
Companies like the one described above will continue to make money and solve problems without any of the press that comes along with each new IoT platform.
Anything that you can share about it?
The language geek in me loves the use of C#, Java and similar safe stacks in the IoT domain. :)
I wasn't here when the C# decision was made, but it's worked out really well for us so far, Silverlight notwithstanding. Microservices work out really well for us too because there's a lot of code written for specific RTUs which will not (and should not) be shared, and having them explicitly separated keeps everything tidy. Microservices communicate via a centralized publisher using WCF, which uses MSMQ as the underlying transport method. Our #1 priority is to never loose data so these technologies are a pretty safe bet. Like I mentioned before, C# has good support for low-level stuff, but we don't do as much low-level as you think. Our greatest challenge is handling several distinct protocols with as much as the same code path as possible, and C# has really great generics support which makes our lives easy. We don't require the performance a C++ platform would bring.
To elaborate a bit more, our basic control flow goes something like:
Poll unit -> get data -> push data -> translate data -> assign data to business objects -> operate on data -> present data
Each step usually involves a save to the database of critical info at that stage.
I am currently aware of stuff using .NET CF, the old WinCE/Pocket PC stack or just doing straight IO control from the PC side to "dumb" firmware that just follows the given commands.
And it's hard to remote because we have a poorly architected and somehow buggy SVN repo. git-svn can't load SVN history from it, so I don't get to use that. Still using VS2010 for the C# to target Silverlight 4, using my own free .edu ReSharper license, just factored out an entire Service from behind a C# Web Api by exposing solution-wide data classes.
Best bit? I don't have any concrete spec to build to. All I have is that it should look 'a bit like this'.
RIP me.
The entire hype wave of IoT has more or less passed right over us. Nobody has heard our name, save for the gas industry itself. But that industry is about to (not literally) explode. Helium is an extremely lucrative industry and is growing by the minute, and there's really nobody in this space but us. Remote monitoring - IoT - has never been more critical to helium than it has now. Without going into too much detail, knowing the pressure levels of your tank 24/7 can save you a lot of money.
So where do I come in? Our platform is written in C#, with the front-end done in Silverlight. I'm the dude getting us off it with some really hip JS work in React. Before that I wrote a lot of microservices to handle various aspects of our system. We were in a pretty bad state when I got there so I spent a lot of time improving our development team. We didn't have PRs for a long time. For a first job out of college, it's not bad. I get to do a lot of cool work, and on my current project I've made every technical decision. But sometimes I wish that we could attract better talent. Oh well, I'm (hopefully) leaving soon.