coretechr / omote Goto Github PK

I'm a long time Harmony user and this remote looks like an awesome alternative for when my Harmony inevitably stops working.

I saw in the write up that device support is currently limited and you're hoping to develop an application with, I assume, similar functionality to how the Logitech Harmony App works for programming a remote.

I did some digging today in the MyHarmony App for iOS and was able to pull some data from the Logitech API by searching for a random device, a Denon AVR-A1, just to see what I could get.

Attached is the JSON output:

jsonExport1.txt
jsonExport2.txt

I did a quick skim of the data and I can't see anything that jumps out to me as IR codes that could be helpful for programming a OMOTE but I'm also not an expert on this.

I guess my question is: Is this data at all useful? and would you like more if I could figure out how to get more?

I'm having issues uploading to my board. I had previously uploaded without issues. I thought maybe I did something to my board and fried it, but another board that I haven't tinkered with also is having the same behavior. From my initial investigation it seems the automatic bootloader reset is not working as expected, but that could be a wrong assumption.

Any ideas why this could be happening?

Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (6.1.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES: 
 - framework-arduinoespressif32 @ 3.20007.0 (2.0.7) 
 - tool-esptoolpy @ 1.40500.0 (4.5.0) 
 - tool-mkfatfs @ 2.0.1 
 - tool-mklittlefs @ 1.203.210628 (2.3) 
 - tool-mkspiffs @ 2.230.0 (2.30) 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 45 compatible libraries
Scanning dependencies...
Dependency Graph
|-- SparkFun LIS3DH Arduino Library @ 1.0.3
|-- IRremoteESP8266 @ 2.8.6
|-- Adafruit FT6206 Library @ 1.0.6
|-- lvgl @ 8.3.7
|-- TFT_eSPI @ 2.5.31
|-- PubSubClient @ 2.8.0
|-- WiFi @ 2.0.0
|-- Wire @ 2.0.0
|-- Keypad @ 3.1.1
|-- Preferences @ 2.0.0
Building in release mode
Retrieving maximum program size .pio\build\esp32\firmware.elf
Checking size .pio\build\esp32\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [===       ]  34.2% (used 111904 bytes from 327680 bytes)
Flash: [========  ]  84.6% (used 1108533 bytes from 1310720 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, esp-bridge, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port...
Using manually specified: COM9
Uploading .pio\build\esp32\firmware.bin
esptool.py v4.5
Serial port COM9
Connecting......................................

A fatal error occurred: Failed to connect to ESP32: Invalid head of packet (0x5B): Possible serial noise or corruption.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
*** [upload] Error 2

Looking at the schematics - could you explain what prevents the battery to drop below safe voltage ?

Some of the footprints/models for components are pointing to a /mkern/ library that does not seem to be stock in the kicad application. If these are custom footprints, can those models be shared?

Hey @CoretechR I am super interested in contributing to this project. But currently when I open the simulator project it will not build.

I was wondering if you considered forking the simulator repo and then adding it to this project as a submodule?

I could also help set up some GitHub actions to get build validation.

It seems like 3R3 is too low for protecting the IR LED.
Is this a mistake or on purpose?

You previously went through and added the BOM in #3 but I found a couple minor discrepancies when looking at parts today:

1. R1; R38; R39; R40 has a quantity of "2" listed, when it should be "4"
2. R6; R11; R12; R13; R14; R19; R20; R22; R26; R30; R31; R32; R33; R34; R35; R37 has a quantity of "15" listed, when it should be "16"
3. J4 is missing. It looks to be just a standard pin header that most people building this probably have sitting around, but for "completeness", it should probably be added

Hi Maximilian,

Great project, thanks a lot for it!

On my board (created with your PCB files), "battery_ischarging = !digitalRead(CRG_STAT);" does not deliver reliable results.
Sometimes result is correct, sometimes not. Wrong detection happens both when battery is empty or when it is full.
Seems to be a little bit random.

Could it be that you cannot both connect a LED to STAT and at the same time digitally read the state of STAT?
The MCP73831 datasheet states:
STAT is an output for connection to an LED for charge status indication. **Alternatively**, a pull-up resistor can be applied for interfacing to a host microcontroller.
So maybe the digital read of STAT is not longer reliable if a LED is connected.
Unfortunately STAT is connected to GPIO21, which cannot read analog values.

What do you think?

Would be great to have the gerber/bom/placement files so it can be produced by a company like JLPCB or PCBWay.

I tried exporting it from Kicad 7 but there are so many options, not sure what to do, I'm new to this.

Hiho,

OMOTE Rev3.pdf seems to be broken.

Best regards

Hi there,
is the Discord Link in the readme still correct?

Hi,

I saw in the schematic some components like C27, U10 is marked with X. Are these not supported to be in the pcb? BOM.csv file seems to not have these but Kicad schematic and pcb files seems to have these components. I plan to get PCBA service from JLCPCB so İ will need to upload the gerber files, bom and cpl. Not sure what files to use since those have these components Any help here is appreciated.

Firstly, I love this project. Not just from it's sole purpose, but also for someone trying to learn electronic engineering better. I am studying the PCB to try to figure out how everything was done and the purpose of each yet.

I figured I'd start to build at least one of these. I created a BOM here: https://octopart.com/bom-tool/xXZMKVQA

The issues I have thus far, are:

1. Making sure everything on that BOM is correct.
2. Sourcing specific components that seem to be obsolete or not readily available.

Can you check that this BOM is correct, or supply one separately, to address issue 1?

For 2, I'm finding that SFH4346 is considered "obsolete" and not readily available anywhere that I can find. I think that SFH4546 might be a replacement, but I'm unsure. Additionally, trying to source the CH340C is tough as far as I can tell outside of LCSC. Is that where you got yours, or did you find it (or an alternative) elsewhere?

Thanks!

[    15][D][esp32-hal-cpu.c:244] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 Mhz, APB: 80000000 Hz
[   440][I][esp32-hal-i2c.c:75] i2cInit(): Initialising I2C Master: sda=19 scl=22 freq=400000
[   441][W][Wire.cpp:301] begin(): Bus already started in Master Mode.
[   568][D][WiFiGeneric.cpp:1035] _eventCallback(): Arduino Event: 0 - WIFI_READY

Brownout detector was triggered

The UART output is like this, sometimes this segment will repeat 4-5 times, sometimes 1-2 times, and then the screen will light up normally

Make the remote able to advertise and connect to HID hosts to allow keyboard and mouse control of devices like android tv.

This would allow us to put Arduino library dependencies in the OmoteUI.hpp which would be really nice.

When abstracting out wifi and other HW component MQTT support dropped off so need to add it back.

Could be useful to have

an interface for sim and hardware to implement so both can support this or
a platform independent library

(Pending investigation in #23)

Is a Case manufacturing like https://www.wiphone.io (basically an aluminum profile with two plates, eighter also aluminum or plexiglass) feasible? Does anyone know a company that does somethin kline that...?

someone sent me a link to this project and it looks really cool, i was considering doing it myself when my harmony remote dies but i hope i wont need to.

one thing though, it mentiones not needing a hub as a good thing but i think there a quite a few functions that a hub provides that make having one a good thing. in particular it allows for your av devices to be controlled through an app, webpage or automation system wihtout worrying about where the remote is and if its pointed at the devices. it also allows the remote to control devices that may be hidden without needing an IR repeater setup.

while i do think not needing one is good it would be great to have the option of adding one. i dont know if it would be best to try and add a direct RF connection to a hub or just rely on them both connecting to wifi but i think having a hub of some form is great.

same goes for a dock, having contacts exposed on the case and a dock that just has 5v on a pair of pogo pins would be a great addition to eliminate the need to activly charge the remote at all

either way i love this project and will be following it with great intrest. and would be happy to have a stab at a hub to go with this if you would be intrested

When I initially open the PCB designer, I get a message that the Fredoka Light font is missing, since it's not a system font. I'm not sure if it's super important to have that specific font, but if so, it might make sense to include it in the repository and reference it.

When the rev.3 hardware is run from battery the remote sometimes (probably) does not initialize the LCD correctly. The result is that the backlight is lit but the screen is blank. The user-led pulses its heartbeat and the buttons do work correctly. Usually I can let the remote rest until the screen shuts off and the ESP32 goes to sleep. After that usually the screen functions normal again.

Does anybody else experience this phenomenon and what could be the resolution? Change the start delay, add some capacitors or something else?

The LCD is an Adafruit original and run at the default 40MHz.

Would you consider adding an IR-receiver to allow IR-learning abilities (via a future firmware update) to this remote? It will vastly expand the use-cases for it.

Hi Max,

I always had the issue that it was not possible for me to do the firmware upload with PlatformIO on Windows.
On the same computer, same USB port, same hardware, the upload was possible from WSL2.
Obviously the drivers on Windows and Ubuntu handle EN and GPIO0 slightly differently.
It was always a pain for me to switch between Windows for compiling and WSL2 for uploading.

On Windows this is a widely known problem.
Sometimes older driver versions help, but not in my case. I tried a lot of different driver versions and driver settings.

I have only basic knowledge about wiring, PCBs and so on, but I found this:
https://docs.espressif.com/projects/esptool/en/latest/esp32/advanced-topics/boot-mode-selection.html#boot-mode
If this circuitry is implemented (all Espressif boards have it), adding a capacitor between the EN pin and GND (in the 1uF-10uF range) is necessary for the reset circuitry to work reliably. This is shown in the ESP32 Module section of the schematic.

As far as I understand, the OMOTE has 100 nF as capacitor (C15) between EN and GND. Espressif recommends 1uF-10uF. So I added 10uF in parallel.

This did the trick. No more switching between Windows and WSL2.

As you are currently working on a new version of the PCB, maybe you want to think about increasing C15.

I just got my board together and i'm seeing the following problem rather frequently, but i'm not entirely sure how to track down what is causing it yet.
[133754][E][Wire.cpp:513] requestFrom(): i2cRead returned Error 263

My screen appears to be working, but I'm thinking this is going to cause a headache if I don't figure it out now.

EDIT: This may have just been because I didn't have the display taped down yet and any movement was causing an SPI error. I will tape it down and hope no more errors happen.