5 ms·

I've been contracting with an IoT company for 3 years now. It's interesting to see guys who coded exclusively for radio or infrared based remotes get pulled int

I've been contracting with an IoT company for 3 years now. It's interesting to see guys who coded exclusively for radio or infrared based remotes get pulled into the software development world. V1: 5 years ago everything was raw sockets and custom messaging formats with hand coded firmware and all data stored in a custom vector format, builds were distributed on google drive and flashed by hand. V2: 3 years ago we dragged them kicking and screaming into http and hand coded json apis, firmware was still custom, data still stored in custom vector format but updates were now done on a non secure server with a hash check. V3: this past year they started on a small box with a micro linux distro, apis are provided by standardized library, data now stored in sql, updates done over https. Things are better now, except they still expect to sell and support those first 2 options for the next 10 years.

nitrogen 9y ago
Part of what you are describing is exactly why IoT is sometimes called IoS. We've moved from solid, fast, low-latency, low-power hardware to unpredictable, slow, jittery, high-latency crap. Take the Philips Hue bridge for example. Raw binary protocol lighting tech from the 1980s can outperform it in terms of latency, throughput, and jitter. It's unaccpetable for a button to take action after some random delay between 100ms and 5s. It's even worse if there's a remote https round trip required, as network lag adds another layer of unpredictability.
- seanalltogether 9y ago
  Raw binary protocol lighting tech from the 1980 was stateless, but nobody is willing to accept that nowadays for home automation. "Turn device on" - Great I can do that fast "Turn device off" - Great I can do that fast "Is device on or off?" - Hold on while I poll a serial rf signal device by device while I determine state. All of the slowdown coming from our tech and others that I've seen is because hardware guys still think these old stateless solution are acceptable and then have to hack something dirty on top to turn it into a stateful solution.
  - ianhowson 9y ago
    > guys still think these old stateless solution are acceptable and then have to hack something dirty on top to turn it into a stateful solution Isn't this the foundation of modern web development?
xg15 9y ago
Maybe the industry should listen to their kicking and screaming. So the engineering problem could be solved with a micro-controller and some binary communication protocol - yet now you're solving the same problem, but need a system-on-a-chip, so you can run a linux distro, so you can run a web-server, so you can serve JSON. Because... why? I don't think that's the spirit of the linked paper either. Yes, we should find standardized, secure update mechanisms. But why do we have to bring the web stack into this again, even though nothing of this has anything to do with the web? Generally, I don't see how adding more layers and moving parts increases security.
- seanalltogether 9y ago
  > So the engineering problem could be solved with a micro-controller and some binary communication protocol - yet now you're solving the same problem, but need a system-on-a-chip, so you can run a linux distro, so you can run a web-server, so you can serve JSON. Because... why? I can actually walk you through each piece of this and explain why things are better now, just because I've been in this swamp for so long. 1. Raw socket communication is bad because if the socket is dropped, you have to reinitialize it. On mobile it's going to get dropped alot. Plus new commands require lots of custom dev instead of using a standard REST library. 2. Binary packets are simple but also not flexible. "Hey we need to change device name to allow 64 characters now instead of 32, but you can't break all older hubs that still restrict to 32 characters in the binary packet, this means battery level could start at offset 108 or 140" Now repeat that for 5 other properties over the course of a year. 3. The bridge data was stored in a custom vector format instead of sql, so we can't get the engineers to cleanly migrate that data as new requirements come down from management. Testing takes 4 times as long to make sure nothing breaks. 4. I had a different client who built an entire bridge around udp thinking this would mean everything would be 1 or 2 milliseconds faster for home automation. In the end they had to rebuild tcp on top of udp to ensure correct state. 5. Custom firmware, they used to just download new firmware over http, check the hash and then apply it directly. If anything bad happens during this process the bridge is bricked, there's no rollback mechanism, no integrity check, just a dead hub. Moving to a micro linux distro at least brings in sanity checks for updates.

nitrogen 9y ago

Part of what you are describing is exactly why IoT is sometimes called IoS. We've moved from solid, fast, low-latency, low-power hardware to unpredictable, slow, jittery, high-latency crap. Take the Philips Hue bridge for example. Raw binary protocol lighting tech from the 1980s can outperform it in terms of latency, throughput, and jitter. It's unaccpetable for a button to take action after some random delay between 100ms and 5s. It's even worse if there's a remote https round trip required, as network lag adds another layer of unpredictability.

seanalltogether 9y ago
Raw binary protocol lighting tech from the 1980 was stateless, but nobody is willing to accept that nowadays for home automation. "Turn device on" - Great I can do that fast "Turn device off" - Great I can do that fast "Is device on or off?" - Hold on while I poll a serial rf signal device by device while I determine state. All of the slowdown coming from our tech and others that I've seen is because hardware guys still think these old stateless solution are acceptable and then have to hack something dirty on top to turn it into a stateful solution.
- ianhowson 9y ago
  > guys still think these old stateless solution are acceptable and then have to hack something dirty on top to turn it into a stateful solution Isn't this the foundation of modern web development?

xg15 9y ago

Maybe the industry should listen to their kicking and screaming. So the engineering problem could be solved with a micro-controller and some binary communication protocol - yet now you're solving the same problem, but need a system-on-a-chip, so you can run a linux distro, so you can run a web-server, so you can serve JSON. Because... why? I don't think that's the spirit of the linked paper either. Yes, we should find standardized, secure update mechanisms. But why do we have to bring the web stack into this again, even though nothing of this has anything to do with the web? Generally, I don't see how adding more layers and moving parts increases security.

seanalltogether 9y ago
> So the engineering problem could be solved with a micro-controller and some binary communication protocol - yet now you're solving the same problem, but need a system-on-a-chip, so you can run a linux distro, so you can run a web-server, so you can serve JSON. Because... why? I can actually walk you through each piece of this and explain why things are better now, just because I've been in this swamp for so long. 1. Raw socket communication is bad because if the socket is dropped, you have to reinitialize it. On mobile it's going to get dropped alot. Plus new commands require lots of custom dev instead of using a standard REST library. 2. Binary packets are simple but also not flexible. "Hey we need to change device name to allow 64 characters now instead of 32, but you can't break all older hubs that still restrict to 32 characters in the binary packet, this means battery level could start at offset 108 or 140" Now repeat that for 5 other properties over the course of a year. 3. The bridge data was stored in a custom vector format instead of sql, so we can't get the engineers to cleanly migrate that data as new requirements come down from management. Testing takes 4 times as long to make sure nothing breaks. 4. I had a different client who built an entire bridge around udp thinking this would mean everything would be 1 or 2 milliseconds faster for home automation. In the end they had to rebuild tcp on top of udp to ensure correct state. 5. Custom firmware, they used to just download new firmware over http, check the hash and then apply it directly. If anything bad happens during this process the bridge is bricked, there's no rollback mechanism, no integrity check, just a dead hub. Moving to a micro linux distro at least brings in sanity checks for updates.