ESPSomfy-RTS icon indicating copy to clipboard operation
ESPSomfy-RTS copied to clipboard

Motors Non-Responsive After ESP32 Migration + 3D Case Contribution

Open brammmieee opened this issue 4 months ago • 1 comments

Hi there,

First off, big thanks. What you’ve built is truly awesome!

I started out with an ESP32 + dupont cables (pic below) for controlling a couple of screens and a single shutter. Everything worked pretty well except:

  • The remote controlling the screens stopped working (not an issue, Home Assistant now handles it)
  • The shutter remained working only via the remote, commands are at least detected in the logs panel

Image

Since I didn’t like the messy cables, I designed a 3D-printed case for a spare ESP32 + RF module (pic below). Setup went smoothly, but now I hit a bigger problem:

  • The shutter remote commands are still detected in the logs pannel, ruling out hardware issues
  • None of the screens respond when using the new setup established from a backup of the previous system

Image

Feels like it’s related to pairing/encryption (maybe 1-to-1 binding?), but I can’t figure it out. I’ve gone through the docs multiple times and I’m stuck.

I'm hoping that someone could shed some light on what is going wrong here.

Thanks in advance!

(P.S. For anyone interested in the case models please let me know. I'm happy to share them as a contribution to this incredible project!)

brammmieee avatar Sep 14 '25 16:09 brammmieee

Can you post a picture of the board, with the pins connected?

If you use GPIO12 you might get problems.

Why Using GPIO12 Can Be Problematic: GPIO12 is one of the ESP32’s strapping pins, which means it plays a role in determining certain hardware configurations during boot—specifically, the flash voltage level.

  • If GPIO12 is pulled high (3.3V) during startup, the ESP32 may incorrectly set the flash memory voltage to 1.8V instead of the required 3.3V.
  • This can lead to boot failures, unstable behavior, or inability to read from flash, which is critical for loading firmware, GUI components, and executing commands.

Performance Impact: Even if the ESP32 manages to boot, misusing GPIO12 can cause:

  • Slow GUI loading
  • Laggy command execution
  • Random crashes or resets

These issues stem from unreliable access to flash memory, which stores most of the program and data.

Safer Alternatives: To avoid these problems, it's recommended to use other GPIOs for functions like RX (GDO2), such as:

  • GPIO4
  • GPIO14
  • GPIO27

These pins are not involved in bootstrapping and won’t interfere with startup or system stability.

jaarsa avatar Sep 27 '25 23:09 jaarsa