I get that, but consumer electronics are focused on the average consumer, who doesn't want that. And they're cheap because the people making them relentlessly focus on price optimization, not add-on features for niche markets.
I reverse-engineered the protocol for a cheap vacuum [1], and it's my professional opinion that the protocol is pretty slapdash. It works well enough for the intended use, but has a bunch of rough edges. It clearly wasn't made with randos like me in mind, and making a good consumer API would have been a bunch more engineering work. Plus documentation and support. That would take money and time, and this was Wirecutter's #1 recommended vacuum because it was cheap for what you got.
It isn't anymore, though, because one of their competitors dropped the wifi connection and put the money into other features that general-audience consumers cared more about. "The most obvious downside is that the 11S doesn’t have Wi-Fi, so you can’t control it from your phone or with voice commands. We’ve asked around and were surprised to find that actually, most people are pretty lukewarm on Wi-Fi control anyway." [2]
So I too like tinker-friendly features. But the economics of mass production being what they are, I expect I'll generally have to pay niche-audience prices for them.
I'm definitely not asking for consumer electronics to have a "good consumer API" or support for being hacked on. It'd just be nice if there were slightly better notes on what those slapdash protocols were.
Often I find this documentation already exists (for internal use), but just isn't shared publicly. For instance, Insteon smarthome devices have stopped publishing new developer docs for their hardware, but they do have them internally and on rare occasion I've gotten someone to share one.
I get it. That would be nice. But from the product manager's perspective, I don't think it's generally workable.
The problem with publishing whatever they have lying round is is that a) even if you won't, many people will complain that it's a poorly documented, slapdash protocol, b) it's now a public protocol that they're going to have to support, and c) it sets a precedent, so that people will expect future product to have public documentation and support. It also builds a constituency that will noisily push for niche features that may not be economical.
Letting people reverse engineer and dealing with occasional document leaks don't add the same risks. Indeed, it's probably cost-optimal: the hackers still get what they want, but the company takes on no new obligations and makes it very clear that the hackers are on their own.
The Chinese Saleae Logic clones are great, they're dirt cheap and you can use them with sigrok, which is open-source and has built in decoding of many wire protocols like SPI and I2C.
I reverse-engineered the protocol for a cheap vacuum [1], and it's my professional opinion that the protocol is pretty slapdash. It works well enough for the intended use, but has a bunch of rough edges. It clearly wasn't made with randos like me in mind, and making a good consumer API would have been a bunch more engineering work. Plus documentation and support. That would take money and time, and this was Wirecutter's #1 recommended vacuum because it was cheap for what you got.
It isn't anymore, though, because one of their competitors dropped the wifi connection and put the money into other features that general-audience consumers cared more about. "The most obvious downside is that the 11S doesn’t have Wi-Fi, so you can’t control it from your phone or with voice commands. We’ve asked around and were surprised to find that actually, most people are pretty lukewarm on Wi-Fi control anyway." [2]
So I too like tinker-friendly features. But the economics of mass production being what they are, I expect I'll generally have to pay niche-audience prices for them.
[1] https://github.com/wpietri/sucks/blob/master/protocol.md
[2] https://thewirecutter.com/reviews/best-robot-vacuum/