Control My Aircon

After using this project for a bit, one stand-out problem was the occasional rapid beeping of the aircon whenever you plugged it in (or whenever Home Assistant felt like it). Following this, we now have a quick fix which debounces state updates to one second by default, along with not sending duplicate states anymore. Additionally, I've added some improvements for robustness since unsigned longs can only store milliseconds up to about 49 days.

The quick-and-dirty backend is complete! This is now essentially ready to ship. If you're seeing this (or perhaps are a reviewer reading this), and I haven't taken it down yet, you can control MY aircon at https://aircon.skalixur.com!

The username and password is public

Writing a quick and dirty frontend. It feels incredibly liberating to not feel the need to write clean code.

Home assistant sohuld now be cleanly supported!! Watch this video to see a demo. (i SWEAR I wasn't holding the remote)

Whoops! Ran into a bug where the mode attribute and power attribute would mismatch--so mode could be set to Cool and power would be off but HA wouldn't realize it and believe the aircon was still on. It's fixed now!

What a beautiful (disgusting) if-else statement. Anyways, this is most of the kind of logic that's been going on. Lots of just setting, writing, and reading options. There are some HA-specific quirks like Fan_only (doesn't work) not being equal to fan_only (works). Aside from that, we have reading, writing, and sending states from HA to the MCU to the aircon! The state should mostly be synced, too! All that's left to do is write a better README and do a full test of everything.

Hackatime's been acting up again, so this devlog comes a bit late! ( the ~~s represent line breaks, by the way)
~~
I recently learned about a home automation platform called Home Assistant. I've set it up, and it's quite amazing! I realized that this project fits perfectly as an integration with HA. Problem is, HA plays nicely with MQTT--a totally different protocol from HTTP which is what the project is currently using. So the plan is to migrate the entire thing over to MQTT to get very clean integration with Home Assistant. HTTP works via a request/response model, unlike MQTT which works via a publish/subscribe model. There will be a number of differences in the internal architecture, but the functionality should mostly remain the same.
~~
To keep the HTTP functionality of the whole project (because HTTP is quite a lot more accessible for use than MQTT), I plan to write a quick and dirty frontend which will be able to interface with the project either through a backend which acts as a middleman between HTTP and MQTT, or through MQTT over websockets.
~~
Home Assistant also adds some neat features such as device availability, optimistic rendering, and automatic discovery. Setting that up is a little bit more overhead, but you only have to do it once. So far, here's the progress of setting up HA discovery. We have most climate controls and all the boolean switches done.

Uh oh. It's been ten hours since the last devlog. Ten hours of finishing the backend, that is!

I became a little more ambitious and decided I wanted everything to be configurable—just in case I might swap aircons or move the device to a different room. I also figured, Won't the internal state (what the device THINKS the aircon's state is) and the external state (the aircon's ACTUAL state) slowly differ due to external commands or library incompatibilities?
Yes. Yes they will. That's why I added a VS1838b infrared receiver module. It receives external commands from the actual remote of the aircon and updates the internal state. Just in case the device received the command, but not the aircon, it also echos the command based on the updated internal state. (this is an option you can turn off)
Aside from that, many more options are now configurable. You can turn on and off echoing, customize the ignore window for reading IR messages after sending one, choose the protocol and model of aircon (based on the protocols and models the IRremoteESP8266 library supports), and update some options at runtime over network so you don't have to re-flash everytime.
Additionally, we've added some new endpoints. Theres POST /restart to restart the ESP, PUT and GET /config to update options at runtime, POST /resend to resend the internal state, and of course GET and PUT /state to retrieve or set the internal and external state of the device.
We've also got some more robust error handling, so the entire device doesn't die at the smallest malformed JSON or invalid states. It's now graceful and should self-heal at any issues, leaving what should be no issues just leaving it plugged in forever.
Finally, the README.md file has been polished! After writing it, I've gained a new appreciation for people who write actually good docs. Making them not absolutely terrible is truly an art, but it's necessary before you even think about someone else using your project.

Now that the backend is just about done, watch this video of me sending requests to the API through Postman to Control My Aircon!

So, where to start? Let's start with the components we'll need. Here's what I ordered online:
- 3x 940nm IR LEDs
- 100 ohm and 10k ohm resistors
- BJ(T) transistors
~~ Those BJTs never arrived. Instead I got a box of 560 pcs of shrink wrap wire tubing. Whoops! Good thing I ordered some MOSFETs alongside the rest of the items. They'll work, though they're suboptimal.
~~ After reading lots of docs and examples, I wired together the circuit and wrote some code. Flashing it to the NodeMCU, I tested it on the nearest aircon. Watch the video.

Next, we need to write a server and connect this to the internet!