Comment by seanalltogether | Hacker News Reader

Comment by seanalltogether | Hacker News Reader

Parent Full thread

seanalltogether

> 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.

Solving these problems does not require moving to Linux, though.

> Raw socket communication is bad because if the socket is dropped, you have to reinitialize it

I don't know what to say here. This is a fundamental requirement of network programming and not a difficult one to meet.

Best case, you can re-use an existing connection. Worst-case, you have to establish one from scratch, which puts you in exactly the same position as an HTTP-based solution.

Once you factor in the large time required to establish an SSL session on a small CPU, you really want to think about holding connections open.

> new commands require lots of custom dev instead of using a standard REST library

You still need to implement the REST client and server code.

> Binary packets...

If you're reading fields out of a struct with no version checking or inline layout description, with full knowledge that the layout might change, again, I have no words. This is basic software engineering. The packet length ought to tell you which frame format you've got...

JSON doesn't really solve this. You've got limited RAM, remember? There's no limit on the length of a JSON document.

At least use protobufs or Avro or something.

> bridge data was stored in a custom vector format

Not all the world's an SQL database. An array of structs will fit even the tiniest computers and serve most of the same use cases.

> built an entire bridge around udp thinking this would mean everything would be 1 or 2 milliseconds faster

Eliminating TCP session startup and teardown could easily explain this. It sounds like a reasonable decision for some applications.

> they used to just download new firmware over http, check the hash and then apply it directly

Most cheap IoT devices do exactly this. It's not good, but it's common, and if you have a simple recovery bootloader it works well enough.

Using the A-B partition switching makes this mechanism basically foolproof (once you add verification of firmware blobs).

So you can do one of two things:

1. Run Linux and try to do in-place updates 2. Run something smaller and use the extra flash space for a backup partition

I would go for (2) every time on robustness and simplicity grounds. My clients prefer it too as it makes their devices cheaper and simpler.

I get the point you're trying to make, but making everything custom adds cognitive load that isn't necessary and restricts your design space. The more time you spend thinking about your custom solutions, the less time you can spend on features that differentiate your product.

I had to troubleshoot an issue that a higher up in the company was having with their bridge at home. I asked him to hit a specific endpoint on his bridge in the browser and send me the result, a win for HTTP.

We just released swagger docs for internal devs and 3rd parties to plug into without needing to spend time writing excessive documentation on what our data format look like, a win for JSON.

The list goes on for all the extras you get for free when working with standardized tools.

> The list goes on for all the extras you get for free when working with standardized tools.

I guess this is the balance between how much less you pay for standardized tools and tech (and R&D), and how much more for all the BOM extensions required. TTM may be important too, favoring using of-the-shelf techs. On the long run, and with big quantities, the balance might actually justify the custom-made.

However, it is with the big quantities deployed that the issues of firmware upgrade -- reliability, ease of use, security -- become really serious, tipping the balance again towards the standard tech.

With big quantities, BOM cost becomes the overriding factor.

It's the reverse of the web dev scalability argument. In web dev, you go for high abstraction and divisible components because it's the only way to handle more requests per second while keeping the software flexible.

In hardware, to scale the business, you need to keep BOM cost low. To do this, you must use cheaper (smaller) hardware and specialize the software to fit. You need to eliminate abstraction and keep the software as tight as possible. Even bootup time matters -- 30 seconds for Linux to boot adds $1 of manufacturing floor time per device.

Linux adds massive BOM cost, and once you're shipping more than 5000 devices per year, it's usually worthwhile to eliminate it.

Reply on news.ycombinator.com