Unless you're targeting consumer you might want to be careful with tech like web-sockets. After a decade of using sensors in industrial facilities I've come to appreciate the value of on-device buffers and transactional logging systems that don't maintain persistent connections. Real-world environments are unfortunately really tough on technologies designed for browsers.
You sound like you have some experience in this area so I'll ask. I'm working with fielded devices that typically sit on enterprise networks. We operate much like an IoT device, but without the hardware constraints. The current c2 system uses a traditional polling REST HTTP protocol and we're looking to migrate something more real-time (for config pushes) and lighter on the server. Currently looking at everything from HTTP/2 SSE, Websockets, MQTT over WS, or even HTTP using something like Google's Cloud IoT. As you can probably tell we'd like to keep the wire protocol enterprise-network friendly. Any advice?
It really depends on your edge data model, but the enterprise network should always be considered hostile.
At my previous company we ran SSH servers on our gateways for server->client pushes and it ran into the fewest problems with enterprise firewalls. We also ran our own mesh wireless networks a lot using our own gear. I'm guessing that's probably not an option, but when there's no admin running around looking for unauthorized wireless signals it's quite efficient.
Now all of these require a local host machine (or several) behind the firewall that do the brunt of routing and orchestration for pushes. There's a good reason for it though: It's a lot easier to get several hardened systems authorized to cross the firewall than a bunch of IoT devices. And if you can't get that authorization, you can put a cellular connection in the box or boxes more cheaply than one in every deployed device.
Happy to chat more if you want specific advice about certain situations. I also spend a lot of time investing in and mentoring Boston-based IoT startups so I have seen a broad cross-section of situations that can happen. brendan@sentenai.com
We have the full support of the network admin staff, so punching out is not an issue, we just want to keep it as clean as possible. My guess is our control channel will likely end up being some combination of WSS/Redis (if it plays nice w/ mutual auth and load balancing) or a variation of our current polling HTTP/REST solution. Thanks for the offer, I might take you up on it ;)
I'm totally in the you-dont-really-need-web for everything group but yes, this can be considered targeting consumers as-in ordinary people who want to use localized version of TTN.
I don't really approve use-cases like running a webserver to control lights on ESP8266 where simple TCP sockets would do.
Haskell-zre is pretty cool! I think I'll have some fun playing with it with some of our demo IoT setups. We're purely in the backend data infrastructure business so I don't do deployments any longer, but we'll probably have some fun with it anyway :)
