Devlog 0

yap yap

A whole lot of things today are built on being convenient and therefore wireless, but sometimes things are too convenient that they end up creating an annoyance. Case being the amount of remotes that powers an LED strip at most once a month and then hides away collecting dust ready to be forgotten, and it being the only way to power these devices makes them quite necessary.

I wanted to solve this by creating my own IR remote, which can read any signal and proceed to save it so that I only need one remote for LEDs, TVs, or other IR devices. Using the beloved ESP32, I also have bluetooth functionality and thought it would be good to bring the idea of a universal remote into a modern age by allowing it to also connect and give wireless commands through bluetooth. This allows it to pause/play/skip media, act as a shutter for a phone’s camera, become a macro pad, all through the various profiles that you can set up for your own needs.

what I’ve actually done

Now with all these lofty ideas requires a strong foundation, so after testing all the libraries and components individually I needed to bring these all together gracefully (at least to the best of my ability).

So I started creating a framework for all of the components and how they will relate to each other without having the ability to cause direct harm to the other parts of the system should I mess up (which is likely). I’ve done enough coding to get my way around and find what I need, but I wouldn’t be able to name what approach I’m using at the top of my head, and maybe putting everything in header files isn’t the best idea long term but that’s a problem for later.

Component wise I’m using an esp32-c3 with a standard OLED module, a rotary encoder, several buttons, and a shift register. Apparently the shift register is rated for 5v logic only, but it appears to be working during my tests so I’m assuming its fine.

Anyways actually creating a derived class and propagating the values of the current state of the program was a bit more involved than I thought, so I needed to spend time debugging that while I was setting up the screen logic at the same time. It currently works by showing the title of the current profile, the available 8 commands (which would map to the 8 buttons),  and whether there are more commands that can be scrolled to using the rotary encoder. 

Video stuff

Attached is the video that shows the first 8 commands of a profile being drawn step by step. 

Afterwards is a showcase of some of the planning and code (terribly written I’m sure) that I’ve done so far