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!

The Summer Countdown timer is complete! Check it out yourself (and maybe build it, too?) on GitHub. We got dates working. I ended up forgoing the compacted dates (removing the highest values in order if they're zero) for a more consistent style on the LCD. I also began using padded zeros for each of the values, because they're all two digits max (hopefully no one is countdowning to 160 years in the future). We're just gonna clean up the code and README, take a video, and then ship!

WE GOT LIQUID CRYSTAL DISPLAY DISPLAYING—Hello, Hack Club!

WE GOT FORMATTED DATES BABY

On another note, I hate C++ so much. (/s) Coming from a JS/TS background, fixed-size arrays, pointers, integer sizes (uint16t vs uint32t), and a lot more were totally foreign to me though not unheard of. I've learned a lot about the language, but my lack of proficiency in it definitely slowed me down.

Anyways, we can now get the time difference between two dates and have it nicely formatted. Plurals, redundant dates, and dates in the past are all taken care of. Nice.

Next, we need to hook everything up to the LCD and add some neat messages! Should be easier than this.

I've gotten all the wiring ready (jumpers for now, since I don't know how to solder lol)
You can see the RTC module and the LCD in the photo. Next step is to sync the RTC module since I haven't used it in a while.

Alright! The website should be ready for deployment, and should soon be accessible at:

https://practice.skalixur.com

that is, once DNS finishes propagating 😭

Project's done! Works on mobile, success threshold and count persist between refreshes, and options and about page works. Looking forward to actually using it, now.

So, what is this?
It's a dead simple counter to help me practice piano. I've been playing piano for a couple years, and whenever practicing, I try to play each measure correctly at least seven times in a row before moving onto the next one. Before creating this website, I used a dice to keep track of my progress, but I've since lost it! (thanks, dear brother)

So, this is my solution to that: a website. Here's the functionality I want to include:
- Tap in the bottom half of the screen to increment the counter by one
- Tap in the top half to reset it to zero
- A motivational message, once you get to seven
- A customizable success threshold to choose the difficulty of practice
- Mobile compatibility (because I'm not putting a computer on the piano, please!)

So far, the first three requirements are good. All that's left is to make it look a little prettier, make it customizable, and clean up mobile functionality.