Repository navigation
Known Working Hardware
ESP32 boards and RS485 interfaces reported working with InfinitESP. Carrier equipment compatibility (thermostats, furnaces, heat pumps, bus device map) is tracked on the Infinitude wiki, not here:
InfinitESP is hardware-agnostic: it needs a uart::UARTComponent at 38400 baud 8N1 and an RS485 transceiver wired to the ABCD bus (A and B terminals, C as signal common). Every entry below is a community report. Status legend matches the Infinitude matrix: ✅ confirmed working, ❓ attempted but unconfirmed, ❌ reported not working.
| Board | Status | Direction control | Reported in |
|---|---|---|---|
| Waveshare ESP32-S3-Relay-6CH (Amazon) | ✅ reference board | auto (SP485EEN, RC one-shot) | author's install, WidnerM (SAM emulation, 4 zones) |
| Waveshare ESP32-S3-Relay-1CH (Amazon) | ✅ | manual, DE on GPIO21 | lurgh, 64kbyte |
| Waveshare ESP32-S3-RS485-CAN(-U) | ❓ | same RS485 circuit as Relay-1CH | asked in #34, attempted in #17 |
The author's board. Its SP485EEN transceiver handles direction with a discrete RC one-shot, which has a time constant too short for 38400 baud: long runs of constant-level bits drop the driver mid-byte, and on an insufficiently biased bus the line collapses. InfinitESP ships the uart_rmtx component to work around this in firmware with no hardware changes. A live bus may also tolerate the flaw without any fix, depending on topology and biasing.
Uses an SP3485EN whose driver-enable pin is wired to GPIO21, so set flow_control_pin: GPIO21 in the uart block. lurgh runs it in production. Two caveats from #17:
- The board has no RS485-side ground terminal. 64kbyte soldered a wire to pin 5 of the SP3485EN (SGND, isolated from digital ground) and tied it to bus terminal C. Do not connect the digital GND terminal to the bus.
- First light after that fix showed data with residual CRC errors, still being debugged (possibly tap location or power).
lurgh compared the schematics and found the RS485 section identical to the Relay-1CH, so the same GPIO21 flow control and SGND notes should apply. No confirmed install yet. If you run one, report it (see below).
| Combination | Status | Direction control | Reported in |
|---|---|---|---|
| ESP32-C6 dev board + HiLetgo TTL-to-RS485 auto-flow module (MAX13487) | ✅ | auto (on-chip) | hip-hopanonymous, long-running SAM emulation (captures) |
| Olimex ESP32-POE-ISO + DSD TECH SH-U12 (MAX13487) | ✅ | auto (on-chip) | alton987, solved after a ground fix |
| Generic ESP32 + MAX485 module | ✅ | manual, flow_control_pin on a GPIO |
colings |
| ESP32-S3-DevKitC + Waveshare Pico-2CH-RS485 used as a transceiver (SP3485) | ✅ | per-board | coconutjuiceartist, SAM emulation |
| HiLetgo HW-519 (MAX485 + CD4069 buffer) | ❌ ran hot, browned out the 3.3V rail on one install | manual | #39 |
The MAX13487E does direction control on-chip with a state machine, so it transmits long frames cleanly on a properly biased bus and does not need uart_rmtx. If you see CRC errors clustered around your own transmissions, look at wiring, bus loading, or biasing. Two wiring notes from the field:
- These are usually 5V modules. The receiver output (RO) swings to 5V and ESP32 GPIOs are not 5V tolerant: use a divider or level shifter into the ESP RX pin (#39, #15).
- An ESP TX line that sits low (during boot or a misconfiguration) drives the transceiver's input constantly, which keys the bus and drops the thermostat's link to the indoor unit. If the thermostat recovers as soon as the ESP is powered off, suspect this failure (#39).
Tie DE and RE together and drive them from one GPIO via flow_control_pin in the uart block. Same 5V divider note on RO. colings' build in #15 works with this arrangement.
| Variant | Status | Notes |
|---|---|---|
| ESP32-S3 | ✅ | all Waveshare boards above, DevKitC-1 in #21 |
| ESP32 (WROOM-32E) | ✅ | Olimex ESP32-POE-ISO, PoE-powered, #39 |
| ESP32-C6 | ✅ | #17 / #18 |
| ESP8266 | untested | one user started on a D1 mini and switched to ESP32-C6 before isolating the fault (#17); a dev config exists in the repo but no install has been confirmed |
- A/B polarity. Wrong orientation has produced both silence and garbage frames. Swapping A and B is free and has fixed both (#15, #39).
-
Ground path resistance. A Dupont jumper in an IDC socket added enough resistance to drop a module's supply to 1.8V while the host 5V rail read 5V. The transceiver received the bus fine but its RO output could not cross the ESP's input threshold, so
rx_bytesstayed 0 for two days (#39). - Terminal C is the bus signal common. On the author's system it ties to earth ground. Installs have worked with C tied to transceiver ground and with it floating (#17, #39).
- Tap point. Taps at the wall control subbase and at the indoor unit have both worked. 64kbyte's 8 ft stub at the indoor unit initially showed no traffic and lost the thermostat its IDU link until the SGND and flow-control fixes landed (#17).
- Troubleshooting order. Before debugging InfinitESP itself, get raw bytes off the wire with a plain RS485-to-TCP bridge config (#39 has a working example). Until netcat shows traffic, the firmware cannot possibly work.
Open an issue with the board, the transceiver, the ESPHome version, and whether you run passive monitoring or emulation. A REPORT? snapshot or STATS lines confirms the bus is healthy. Passive-only reports count: emulation is not required to add a row to the tables above.
Amazon links on this page may be affiliate links. Purchases pay a small commission at no cost to you.