Naively coming out of school, this slow realization that I would never be able to save any money by making cool gadgets was a bummer.
Except weirdly enough, basic home maintenance. I don't know what that says.
You could apply your logic to home building though. Builders get volume discounts on materials and labor. When someone is working the same repetitive job for months on dozens of homes, they can afford to charge their base hourly rate because they know their schedule will be full. If I built the exact same home the builder cranked out, it's going to cost me more despite using the same materials and people. When people build their own homes, they are usually going for something custom so a builder-grade starter home is not the goal.
Sometimes I don't want that headache and do the calculus of time & effort and spend the extra $ to get a speaker set that works with my phone :)
Wait until you get older and realize that if you want high quality, you have to drop down one-two levels on whatever you want to buy to avoid pointless shit like "Alexa" or "Google Home" integration.
Or you have to spend more to buy useful shit like alexa or google home.
I often use it to look at Bluetooth traffic from iPhone apps.
My personal experience with cec-utils is that device support is hit or miss.
I tried controlling a TV a while back, and I think I could get it to turn on, but not standby or off.
Worth a shot though.
(I do think his project is pretty cool, and it shows people that they can regain control of their dysfunctional iot devices)
What a polite way to say it.
CEC and DDC-CI, are these two things that should be absolutely nailed given in terms of low level commands how simple they really are and how long they've been around, yet are thoroughly broken through and through in so many subtle ways, from broken payloads to timing issues.
And even when the low level protocol is correctly implemented you can be sure that the high level behaviour of the devices is not doing what you'd want it to, with no workaround possible.
e.g one device turns -all- devices on/off no questions asked, another would not allow separate configuration of being controlled vs controlling, and/or power on vs power off, a third one would disable CEC the moment you select headset audio output because it goes in the way of their MegaMagicSync+ feature (which is just CEC with a bunch of useless proprietary stuff to talk to other devices of the same brand, coz gotta "add value" and "differentiate")...
It's probably too late for HDMI-CEC, there are too many crappy pieces of hardware out there. I'm just wondering what stops this from happening next time. It's a great system when it works and so much better than trying to reverse engineer other protocols. Just a shame that it's so bad it doesn't even get a mention in a post like this where it should have been the perfect solution.
Relatedly, does a £300 soundbar in 2020 still only come with one HDMI input!?
Instead observing an opaque box's external behavior, and reasoning from that, seems more "cleanroom".
I don't know whether that difference matters in this case, but I've long assumed it matters in some cases.
And yes, it is one of the unvoiced assumptions: as long as I heard two devices speaking, I can’t be breaking any EULAs or what not. Decompiling something would be another kettle of fish entirely.
Not to mention that often times apps (even Java/Android apps) are obfuscated, which might make the reversing much harder (than sniffing traffic).
An A1392 Airport Express which go for around £40 and a 3.5mm to TOSLink optical cable.
Nice work and I bet was a great sense of achievement.