TrueMote - a true Logitech Harmony remote replacement?

TrueMote - a true Logitech Harmony remote replacement, for me at least :')

This has been some months of work, mostly think-work. Bear with me :slight_smile:

For a number of years I have been searching for the 'ultimate' remote control and they don't seem to exist. I have been using the Logitech Harmony Ultimate for a long time, but the battery consumption was too high which got annoying, plus their support no longer exists unfortunately. I have the hub which I still use, it has a nice API via which stuff can be controlled.

After I gave up on the search, I come across this wonderful device from Waveshare - the ESP32-S3-Touch-LCD-2, which has so many useful features - an IMU (gyro/accelerometer), capacitive touch, battery charging circuit, 16MB flash, 8MB PSRAM and ofcourse Wifi and BT. After ordering a couple of them (they are like €16) I started some experimentation, it ended up to be a rabbit hole, but I have now have a remote control :smiley: from which I can fully control anything and make it look/function the way I want, with ofcourse: Node-RED and Home Assistant.

Although it is not a remote control as in the classical infrared sense, but fully controlled using MQTT.

I experimented with breadboard layouts and prototype boards, it was too finicky to make it fit into a neat package, so the next rabbithole: let's try to make an actual PCB (using KiCad) - I have no skills or knowledge with electronic design, but i managed to design a PCB that actually turned out to be working (!) once it was manufactured in China.

Quite impressed with myself to be honest haha, but already learned from the many mistakes along the way (which is a great part of the journey).

Next, I had to design a case that would fit everything (using FreeCad), a lot of trial and error designing and 3d printing, but I have a fully functional prototype with a USB port for charging.

So what does this thing actually do:

It runs a webserver that lets you design your own interfaces using drag & drop of widgets, it is completely customizable and the way it does it might sound a bit janky, but it works quite well:

Drag and drop widgets onto the canvas - (resizable), this could be a button, images (MQTT), labels, data values (MQTT), sliders, list widgets (MQTT), charts (MQTT), press save and it will create a screenshot for the elements that cannot easily be rendered using the arduino graphics library (like icons on a button) - it will capture every x/y/w/h position of each element, stores in a json config and the graphics library will render the remaining elements on top of the background image.

You can also receive images via MQTT straight in the web interface and save it as a background image for the interface (ie you can design your own dynamic interfaces and put 'invisible' buttons on top of it).

9 Likes

Continued...

The dynamic elements come from MQTT. This very fast - it feels like a local operation. For example, a Spotify song image, it comes from home assistant, gets resized in node-red and publishes it on an mqtt topic as a binary (those are like 4KB) and when you go to an interface on the remote, it subscribes to the topics it requires and renders the interface. When I press the navigational button right/left, Node-RED capture it, send next/prev track to home assistant and a new image is immediately shown. In short, you can see who is at the door when the doorbell rings :wink:

Every dynamic widget can be configured with a topic. If you want to display a chart, send the data to the topic and the it will render a chart (chart type can be set in the web interface or in the MQTT payload).

Each button press (touch or physical) will emit an MQTT message with the current interface and the button name which, ofcourse can be captured in Node-RED. It has an API via MQTT - from which an interface can be loaded by sending a payload with the interface on a specific topic and it will load.

A slider will emit its value that can be set in the widget (range), can be done realtime or on release. And the current value can also be set via mqtt.

Some flows:

This means you can create fully dynamic interaction menu's - as the list widget is using mqtt to build it's nested menu's and can be controlled using the standard directional/ok buttons for traversing.

It has many power control features for deepsleep, it dims/sleeps after a (configurable) time, uses a ballswitch/angle sensor to wake up (pick it up and it turns on), the IMU/buttons/touchscreen keeps it on while using, and as long as the web interface is open it stays awake. The thing has been in use for ±7 days now, i don't know how long the battery will last, but i think it will be a while (2000mAh 3.7 LiPo).

It uses Wifimanager to setup and has full OTA support.

All this C++ code is way over my head and I am glad several AI's were helpful to write out my ideas (although it is a lot of handholding, datasheet verifications, still need to understand what you are doing and how it to get there).

Next step will be to create a better PCB layout for the buttons and instead of a remote control - and I am also thinking about a wall mounted display as this project would also fit very well.
New PCB schematic/layout will be the first step, after that I will open source it for however is interested.

Goal achieved: it has replaced my Harmony!

9 Likes

I have never designed a PCB, or know the first thing you should before doing so.

But… well done @bakman2

I love the “maker” attitude here — and the success of course, kudos! :clap:

1 Like

This is crazy cool stuff ! Thanks for sharing !

1 Like

Thank you for sharing. I have been wanting to do something similar. I found the OMOTE remote

which has most of what I want, but not everything. I wanted everything that the OMOTE remote has, plus a few more buttons, a microphone, and a speaker. I have never done any PCB design work, but trying to understand and modify the OMOTE PCB was proving to be much more than what I was wanting to undertake. After finding your post, I was able to find this:

which contains a majority of the features from the OMOTE remote as a starting point. The PCB design is much simpler with this starting point. I plan on doing all coding with ESPHome so it can be directly integrated with Home Assistant and what I learned from you was the missing piece. Thank you so much for your work/effort.

I am also curious how you implemented the webserver. Did you do that in node-red? Do you have it posted on Github somewhere?

My original plan was to simply design an LVGL dashboard using ESPHome, but if there is a way to adapt what you've done for my needs I think it would be a much more elegant end result.

The webserver is running on the remote, while it is awake the webserver is available and when the web interface is accessed the device remains on (when the webpage is closed the remote goes back to its movement detection behaviour).

I have looked at LVGL and it is just too cumbersome to deal with, I wanted a drag&drag interface that i could completely customize to my liking and I was mostly interested in sending images over via node-red (it is superfast) - it means you can design some interface, set it as a background and overlay interactive elements.

The whole interface and its interactions live inside a single json file. I did not put it on github, because I also looked at an implementation for a non-remote version like square display you can put on the wall and further developed from that viewpoint.

This display. But this had its own limitations, ie. it can run on batteries, but there is no way to wake the display via touch, thus need some kind of hardware button to trigger it, got stuck and distracted from there. The web interface is now way more smooth with this display - it is a 2 way binding - drag something on the canvas in the web interface and it immediately updates the display and any interaction on the display updates the canvas. I have to find some time and 'meaning' to continue with it though.