> Also, where’s the fun in spending 150 CHF more when you can buy the cheaper version, and then spend multiples of the price difference (and a lot of time) to get a similar feature set?

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.

It doesn't get better when your middle aged and realize that if it's not being built by the thousands as a consumer product, then it's going to cost ten times more to do it yourself all things considered.

Except weirdly enough, basic home maintenance. I don't know what that says.

Basic jobs get expensive invoices from pros because they'd rather be out there working a more substantial job. They don't want to drive out to your house, maybe need to make a trip to the store, and then be out of a job for the rest of the day since they couldn't schedule in anything else afterwards. I don't bother calling a pro for something unless I know it's something that will either take the whole day or isn't something I can finish before it must be done by. I can take my time redoing a spare bathroom or painting the exterior but a kitchen renovation would need to be finished quickly.

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.

What I've learned is that sometimes I do wanna spend a bunch of time and tinker so I will take the hard route.

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 :)

Home maintenance isn't being built by the thousands though, so that makes some sense.

> I would never be able to save any money by making cool gadgets was a bummer.

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.

That has nothing to do with the quality of a product, rather a personal preference for having something that's not internet connected.

Its a personal preference for having a device lasting more than a year.

The good news is that making cool gadgets remains fun.

Easier to read Bluetooth packages with BtleJuice (https://github.com/DigitalSecurity/btlejuice), then you only need two ordinary Bluetooth-USB dongles to see and change the traffic.

I often use it to look at Bluetooth traffic from iPhone apps.

But that’s only for BLE, right? Or does it also support Bluetooth Classic?

Was HDMI-CEC not an option here? Particularly considering a Raspberry Pi is involved.

I wonder if it would have worked.

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)

> hit or miss

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

I agree with everything you've said here (especially "MegaMagicSync+"). But why is it such a mess? Was it added to the spec late? Or maybe because manufacturers implement it as an afterthought and don't bother testing it. They seem to get the regular part of HDMI mostly right. Although now that I say that I remember having problems with HDMI switches in the past...

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.

HDMI-CEC might have replaced the remote control protocol, but it would have taken the (single) HDMI input, and the author wanted that for the TV. The TOSLINK input was unused.

I did have a quick look before posting and I thought I saw that bar had a hdmi input (for the pi) and then an output with ARC for the TV. I thought that would work but I admit it's been a while since I tinkered with CEC. But as others have said, it is flakey. I was subscribed to the libcec issue tracker for a while and it was relentless with per-device issues. I had a mostly good experience with a Sony TV but it seems to be pot luck.

Relatedly, does a £300 soundbar in 2020 still only come with one HDMI input!?

Couldn't they plug it in to the TV? My AppleTV can control my soundbar volume and it's plugged into the TV and not the soundbar.

CEC is always an incredible pain even with devices that supposedly have first-party support for it.

The YAS-207 CEC is is pretty flaky I'm afraid.

Raspberry Pi and a HiFiBerry? I've got four of those so far, though I use use them for roon, rarely airplay.

Yeah I use some RPi 3’s with MusicBox around the house and they work flawlessly. They’re all linked to a shared folder on my NAS for MP3s and also do Spotify/AirPlay/etc.

Just because it has alexa/google integration doesn't mean you HAVE to use it. You have full control over what it talks to and in theory you can restrict which domains it can talk to if you wanted.

Android apps can quite easily be decompiled to reverse engineer protocols like that. It would probably have been quicker than sniffing the Bluetooth packets and interpreting them.

I suppose one difference is that decompiling might cause one to be considered "tainted" by exposure to the internals, to some degree.

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.

That’s a good way of looking at it.

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

There is a pretty easy solution to this which is what I use although significantly less fun.

An A1392 Airport Express which go for around £40 and a 3.5mm to TOSLink optical cable.

And how does the airport express turn the soundbar on/off? :)

It doesn't but you have to stream from somewhere and my phone and Mac can turn the soundbar on/off.

Nice work and I bet was a great sense of achievement.

My A1392 gets very hot though.