Controlling My A/C with a Gameboy | Hacker News Reader

Controlling My A/C with a Gameboy

jg.sn.sg

144 pointscheeaun30 comments

Reverse engineering IR remotes, and implementing them into my own projects has been an interest of mine for the past few embedded projects I worked on at home. The hardware overhead for getting a wireless IR transceiver working is basically nothing, and there's something especially pleasing about requiring line-of-sight for accurate transmission. The novelty of line-of-sight works especially well for game-based projects!

I just got some new air conditioners for the shelter-in-place summer, and I'd like to control them from a central thermostat, but it's annoying that the remote sends "next mode" or "toggle power", with no way to jump to a known state.

The cool/fan/dehumidify/heat mode is indicated with a vertical column of LEDs (EdgeStar AP14001HS), so I can probably stick a photocell at the top, and have a program repeatedly send "mode" while watching the brightness level, to deduce the state and stop on the correct one. The fan speed uses a different column of LEDs, but stopping on "dehumidify" forces the fan to low. The temperature can be set blindly because it stops at the minimum/maximum value.

I haven't actually tried to build anything yet, but it at least seems possible using a Raspberry Pi with 1 analog photocell and 1 IR transmitter.

Unless you really want to dive into building it for fun, check out the Sensibo Sky. If your unit is compatible, I think that's the way to go. I honestly think they're slightly overpriced for what they are, even on sale, but I've also bought 4 and have been very happy.

Basically you get all the control/features you want by app or API, based on the unit's thermostat and hygrometer. Remote control, scheduling, auto on/off based on your location if you want that, and the big thing for me: programmable event control with any settings (cool/dry/fan at X degrees and Y strength/angle).

I mostly use the temperature based on/off programability because that feels the most like a traditional central air to me. I usually do: "when temperature is >24C, turn unit on to cool 20C medium fan strength" and "when temperature is <23C, turn unit off".

How does Sensibo handle the state synchronization problem? I would happily pay for something that works, but throwing state-dependent IR codes into the void is a recipe for pain.

Monitoring the current draw may give some clues

We make a smart thermostat for minisplits using IR (flair.co/products/puck). We have solved for state problems but some brands were such a PITA!

According to [1], Flair doesn't work with stateless remotes, and EdgeStar is not on the manufacturer list. My units are dual-hose portables, because I can't put equipment outside the building.

[1] https://support.flair.co/hc/en-us/articles/360004153852-Can-...

I was recently toying with the idea of hacking on my old Gameboy Color, I'm excited to see this on the front page. Has anybody else had some positive experiences hacking their GBC?

These are the types of articles I come here for. Fantastic work, and thanks for all the detail in the article!

This is amazing! I'd be interested in more details about capturing the IR signal, both by the invasive method and the "operate an LED in reverse" method.

At one point I thought about trying to do something similar with my old garage door opener, but ended up not pursuing it.

You can get cheap USB IR receivers specifically made for capturing the IR "codes" of remote controls for adding to third party remote control systems.

I've used them at work in the past for setting up touch panels, etc. to control older equipment like DVD players and TV displays. Point remote at IR receiver, push "power" button on remote, record the string for "power on", then program your control surface to send that same set of pulses via IR emitter when you push the software button for "power on" on the touch screen.

You can build something like this as well:

https://www.instructables.com/id/How-to-Capture-Remote-Contr...

I have a Casio CMD-30 that can ‘learn’ codes; its a fun watch.

“National” brand is Panasonic. At least this is true for rice cookers.

I always thought it was kind of a bummer that so few games leveraged the Gameboy Color's IR.

AFAIK, the only game that did anything with it was Pokemon Gold/Silver and their "Mystery Gift" trading feature.

The 3DS has an IR port, but almost nothing used it. Again, except Pokémon, which uses it for local trading/battling, presumably for at competitions when there would be too many people for wireless (that's what I found in a Google search).

The PSP also had IR but was never used, as far as I know.

Awesome. I had a smartphone with an IR emitter once. Tried using it to control my air conditioners but for some reason it couldn't do what this Game Boy can do.

Cool, but receiving an IR signal is a bit trickier than sending it.

Why are you using gifs instead of HTML5 video? Not only they take a long time to download for visitors, but you are using up your server resources too.

Now THIS is Hacker News!

Gameboys are neat, but I'm kind of sad that people are still mostly focused on hacking on the wimpy-microcomputing tech of 30 years ago. Nobody seems all that interested in hacking on the wimpy-microcomputing tech of today! (Well, except Arduinos—but is it still hacking if that's what they're for?)

Imagine what can you accomplish by writing custom firmware for modern IoT devices, e.g.

• a smart thermostat (Nest et al)

• a smart speaker

• a smart remote (Harmony et al)

Another very under-explored device category is the Shenzhen knock-off portable game console (not the Bittboy; the cheap stuff.) These sometimes have surprisingly good hardware in them, but only use it to run (bad!) emulators that don't take full advantage of the CPU power / memory capacity / screen resolution / etc. Native code could get a lot done on these platforms!

The gameboy is a well established piece of gaming hardware in which millions were made and sold around the world. It's a household name. I can still insert a copy of The Legend of Zelda: Link's Awakening DX into my Gameboy Color to this very day and it will run. It doesn't need an internet connection, account or subscription. I also have a fond memories of the gameboy and it's been a part of my life for damn near 30 years. Of course this means I have a whole draw full of gamboys and so does my brother. And it was right there in your hands, it was a part of you. You develop a fondness for those kind of things. They're also simple machines to program and pretty well documented.

Contrast that to a passive IoT thing. It isn't front and center like a console so it isn't going to produce fond memories. In 20 years will anyone remember Sonos? Nest? Can someone dig it up, plug it in and start enjoying music again? I'm pretty sure those answers are "No." They just don't have the popularity or exposure the gameboy has and are quickly forgotten about.

Not sure how complex modern IoT devices, but I tried to get started hacking around in larger platforms, and it seemed impossible to get into. I wouldn't be shocked if these companies make it damn near impossible to hack around in these devices (for a hobbyist at least). Especially given how worried people get regarding IoT and security.

I spent a truly obscene amount of time trying to just figure out how to make a DIY smart speaker discoverable to Alexa / Google Home / etc.

The discoverability of the documentation was varying degrees of deplorable, mostly with a heavy slant towards funneling you into end user docs. In the end all I found was how to write little voice apps. I know these smart assistants have standard interfaces for many kinds of devices. I just don't know where the hell the docs are for those interfaces.

Two things here:

First... you're not the target group for integrating with Alexa, G Home, Siri and friends; the vendors want (and tbh, probably need) only the "big brands" such as car makers, Sonos, Sony, Samsung etc., especially as they likely pay a hefty chonk of money for the privilege of accessing official SDKs and documentation plus support - they'd feel ripped off if the vendors would give away all that stuff.

Second: support itself. Assume that you're Google which is notoriously different to get support from a human being. What would you like more to support: a couple dozen highly skilled developers from huge companies or a bunch of thousand "hobbyists"? And who will the users blame if their 10 $ gadget doesn't work with Google Home one day, the gadget maker or Google?

tl;dr: we'd all like more open access but as long as Google and friends don't allow us to pay money to talk to a human able to solve your problems (did I already mention Google is extremely nasty to get in contact with?) that won't happen.

Totally agreed on point one, I think it is an incredibly sad state of affairs though.

For point two, I'm pretty desensitized to the sad state of affairs that is big-player web service support. The phishing vector of "Hi, I'm calling from Microsoft and need your social security number" is mind boggling. I've had to tell older family members (including lifelong software developers and tenured CS professors) that no major tech company would ever let you speak to a real human to save your life... too many times. I don't see progress happening on that front for some time, but I don't think that should stop them from giving us devs the damn docs. And for who the user would blame, I see a few counterarguments there. First, if I get some weird no-name IOT device, I'm definitely blaming the maker first if there is a problem. I think most consumers place a fair amount of trust in the big tech companies, and would come to the same conclusion. Second, if they want to lock down their platforms, they could just use the Play Store approach, and require adding a developer key somewhere and enabling a dev mode on the smarthome device.

I mean, sure, it is relatively impossible to get into. I wouldn't expect newbies to embedded programming to get their feet wet with these systems.

My complaint is that even the old hands in e.g. the demoscene aren't bothering to play with these modern embedded devices, when hacking on at-the-time-modern "happens to have a computer in it" embedded devices was exactly where the demoscene got started. Nowadays, for some reason, it's ossified into just building hacks for the same old retro devices that were popular in the scene 30-50 years ago; rather than exploring what can be done with modern appliances.

I feel like the only modern "playfulness" in exploring the capabilities of these devices, comes when someone writes a funny "we did it" screen to be triggered by their PoC exploit chain for some "secure" device at DefCon. But they never bother to go further than that and actually make it to something neat—because they're security people and that's not their thing.

Maybe it would be fruitful if there were an event where security folks and demoscene folks team up and collaborate—the security people to handle getting code to run on the device using known (if still only PoC) exploits; the demoscene people to explore the capabilities the resulting "access surface" of the device grants them, and create art demonstrating their findings.

But that's the point. If you want to make something neat with severe computing limitations, the old devices are great for that. If you want to try to run your own code onto a thing trying to stop you from running your own code, the new devices are great for that. But how many people are in BOTH groups?

The old devices tried to stop you from running your own code, too! These problems have long been solved; but hacking around lock-out chips, manually re-flashing soldered ROMs, etc., was always part of the original demoscene culture—just like urban exploration and parkour has always been part of street-art culture. Sometimes a fence gets between you and your canvas, and you need to go around!

I suppose that might imply that "the old demoscene" had this intersection of interests, and so was inherently limited to a much smaller group of people than "the modern demoscene" is; but it still was large enough to exist and have network effects of people joining in—so I'd expect to see some analogous community today, however small, and I still find it kind of weird that I don't!

On another note, remember the venerable https://en.wikipedia.org/wiki/Crack_intro ? It seems warez groups had this intersection of interests, too: an equal focus on reverse-engineering/copy-protection-removal; and on attaching hardware-bending art to the results. Where'd those people go? Who are their spiritual descendants?

I'd like to play with a hackable smart watch, but it seems like the mainstream brand ones are cryptologically secured from boot, and the hackable ones are cheaply-made/aren't up to spec.

And the devices you mention probably also have strong crypto to prevent tinkering...

Reply on news.ycombinator.com