Multiversal Remote

Devlog 7.1

Was just about to ship when I realized there was a bug that I somehow never noticed before that would mean you couldn’t functionally use more than a single page of profiles (4), which would be quite detrimental to anyone wishing to turn on more than a set of lights

Devlog 7

While I could at leas try to make something pretty, I’ll just say I’m a pragmatist and don’t need extra fluff.

The casing is just a wooden frame that I drilled holes for the buttons and screen, and the final and basically only functional button is just taped on at the top, but with that being said, it does do what I want it to do, and I think that that is enough.

I’ve decided this project has set its sail and is about to roam the open waters of the shipyard. I’ve taken some fine looking photos to attach to the top of the github repository, shined up the README to make proper installation instructions, and am just about ready to ship what I have.

Devlog 6

I might just be the most oblivious person I know

Since my shift register wasn’t registering, I went ahead to continuity check every connection from each input pin to the register, then form the register to the microcontroller, then to just about every other pin, and cross referencing with the schematic, fixing minor issues and repeat like 5 times, but to no avail.

I seemed to believe I was Terry Davis or something because I was convinced it was a hardware issue and didn’t check any of the software, only the code that checks the inputs, which theoretically should have worked. 

I assumed at some point I catastrophically ruined the IC

So I desoldered all register related components and just used a single button for debugging. Just for fun I tested the IC on another breadboard with an ESP32 that I know was working and it functioned properly. Odd. When I’m rewriting the code to work for a single button I was trying to alter the logic for the register setup, it was at this moment I realized the setup function wasn’t called - gasp

one line – registerSetup(); would have made everything work. While I could put everything back together, I don’t want to deal with the glob just yet, I’ll wait to get a socket (in case the IC does actually break at some point)

I’ll also begin writing the README for the project on github since the major parts of the project are done

PS - I just realized I missed devlog 3 - welp there’s no going back now

Devlog 5

I’ve done a bit of soldering at this point, but I will say it is definitely not pretty. It is a rats nest of floating wires that probably won’t short or disconnect if I’m lucky, and all the power lines are held together with massive blobs of solder (or wires connecting the blobs since the blobs don’t stay together if they get too large)

In all my genius I also used solid core wire, which means they are more stiff, and more likely to break off from my weak solder points than flex, so I had to do a lot of reattachment.

Magically, it appears a lot of things are working, just not the shift register and its hard to say why. Perhaps I burned it and ruined the internal ICs, I’m not sure. I think I’ll disconnect it and reattach a singular button just to make sure everything else works (and I at least have some feasible product at the end of this).

Devlog 4

I’ve been working on some light soldering, but the most interesting part was the work on the woodwork for the actual remote chassis since I don’t have a 3d printer. I used an old wooden frame i had around. Maybe its the calm before the storm, but I found this part really relaxing. I would drill and chip away bit by bit, and eventually things would go in and fit flushly, and was really rewarding. During the timelapse you can see each hit as the camera moves, and I think its really satisfying cleaning the workbench, making progress, and the cleanup. 

Feeling the buttons and rotary encoder firmly in place made me realize I quite like the tactile feel, and I might want to implement some games, maybe like a memory game so I can use all the buttons or a space invaders replica.  

Devlog 2

Now that I have the bluetooth and IR functionality working together, the ir demo is attached in the video. 

I’ve also created a schematic, which was done as my first time ever using KiCad, so I first followed the web tutorial to get the basics, then went in. While I don’t need to get a pcb  since I plan on just soldering everything directly, it does make visualizing the connections easier. That is especially imoprtant since I’m running very tight on applicable GPIO pins.

I need 10 total IO pins for everything (screen I2C, shift register, rotary encoder, IR receiver and transmitter).

The board I’m using (ESP32 C3 super-mini) has 16 pins, 13 for GPIO. But of that 13, 3 are strapping pins (required to be in particular states at boot), and 2 are for UART transmission. Leaving only 8 fully open pins.

Theoretically I could just stack shift registers for everything input and only use like 5 pins, but that sounds overcomplicated, and I thought it would be a fun challenge to get everything to work.

I went through the datasheets to figure out which state would be safest and would logically not be a worry, for instance pin 8 should be low at boot, but afterwards it acts an output to the internal LED, that meant I could safely connect that to the IR since it would never need to be pulled high unless it was being used, and having a visual indicator of when the IR was transmitting seemed like a fun inclusion. 

I’m sure the final schematic is not the most tidy thing, but I think it works for what it needs to be. I attached it to the end of the video

Devlog 1

I seem to be very good at getting lost. 

I realized that I couldn’t safely handle Bluetooth or IR commands since all the logic uses the base class (that makes switching between them easy). The only problem is when I actually have to use the specific properties of each. 
So I went into a rabbit hole trying to get variants, and implementing some of the bluetooth protocols as I passed by that file, and when I remembered what was actually trying to fix I realized I could just force it to recognize it based on the state (the property that I had set up at the start). 

At least working on the bluetooth media part did make me realize that I only had the foresight to add character presses into my structs, and not necessarily media keys. So I’ll need to figure that out…
Since I’ll be getting my proper board with some other necessary components soon, I think I’ll also start to work on a schematic and readme as I’m getting closer to actually finishing (and shipping) this project

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