I am trying to attach an ESP32 to the HCP bus of a Hörmann SupraMatic E series 4, manufactured 2025, using ESPHome’s hoermann_hcp external component.
The RS485 link is electrically sound — I receive bytes, and the byte pattern changes in a repeatable way when I change parity, swap A/B, or add termination. But not a single valid HCP/Modbus frame has ever been decoded, at any of the three parity settings. is_connected never goes true.
Before I buy a logic analyser, I would like to know whether 57600 8E1 is still correct on a 2025-build unit, or whether anyone has confirmed a different framing on recent hardware.
Hardware
| Item | Detail |
|---|---|
| Drive | Hörmann SupraMatic E series 4, purchased/installed 2025 (France) |
| MCU | ESP32-WROOM-32 devkit (dual core) |
| Firmware | ESPHome 2026.8.2, hoermann_hcp component, modbus role: server |
| Transceiver | MAX13487E module (5 V, auto-direction, built-in failsafe biasing) |
| Transceiver supply | 5 V from the ESP32 VIN pin |
| Level shift | RO → 1 kΩ / 2 kΩ divider → GPIO16 (RX2). DI ← GPIO17 (TX2) direct |
| Bus tap | RJ12 6P6C plugged into the drive’s BUS socket |
RJ12 pinout used (as documented in the community reverse-engineering work):
pin 1 GND
pin 2 GND
pin 3 B-
pin 4 A+
pin 5 +24 V
pin 6 +24 V
Only pins 1 (GND), 3 (B−) and 4 (A+) are connected to the module. The +24 V pins are insulated and unused.
The common ground is connected — this was the single biggest fix in the whole exercise (no bytes at all before it) and it is verified by continuity test between the bus GND wire and the module GND.
ESPHome configuration (relevant part)
yaml
uart:
id: uart_bus
tx_pin: GPIO17
rx_pin: GPIO16
baud_rate: 57600
parity: EVEN
stop_bits: 1
debug:
direction: RX
dummy_receiver: false
sequence:
- lambda: UARTDebug::log_hex(direction, bytes, ':');
modbus:
id: modbus_hcp
uart_id: uart_bus
role: server
# no flow_control_pin — MAX13487E is auto-direction
hoermann_hcp:
id: hcp
logger: baud_rate: 0 so UART0 is free; logs are read over the network.
What I observe
1. The drive only transmits for a few seconds after a mains power cycle
This is the most important behavioural finding, and it invalidated a lot of my earlier testing. On a drive that has been running for a while, the bus is silent — nothing on RX at all. After physically unplugging the drive from the mains and plugging it back in, bytes appear on RX for a few seconds, then stop.
Is this expected? My reading of the protocol is that the drive is the Modbus master and should be polling continuously. A master that stops polling after a few seconds looks like it is scanning for accessories at boot, failing to find any, and giving up.
If that is the case, the question becomes: what does the accessory have to answer during that window in order to stay on the bus? A wrong baud rate would produce exactly this symptom.
2. Parity sweep, all three settings, no valid frame
parity: |
What arrives on RX |
|---|---|
EVEN |
mostly FF, occasional other bytes (e.g. F8:FF) |
NONE |
mostly 00 |
ODD |
mostly 00 |
With A and B swapped: nothing at all on RX, at any parity. (Which is a useful negative — it confirms the line is being read differentially and that A/B are the right way round in the working case.)
After a mains power cycle with EVEN, the bytes are more varied than the idle FF stream — so there is real traffic being sampled — but hoermann_hcp never assembles a frame from it.
3. Termination
A 120 Ω resistor across A/B on my end damped the pattern noticeably but did not make anything decode. I removed it again — the drive appears to terminate its own end and my stub is short.
4. Bus scan on the drive does nothing
Menu 37 → 01 → long press PROG shows bS-Scan and then returns to 37. The ESP32 is never adopted. I have run this both with the ESP32 idle and immediately after a power cycle.
What I have already ruled out
- Missing common ground — was the original fault, now fixed, bytes appeared immediately.
- MAX485 at 3.3 V — out of spec and no failsafe biasing; replaced with the MAX13487E at 5 V.
flow_control_pinmisconfiguration — was commented out while a manual-direction MAX485 was fitted, so the module could never transmit. Now irrelevant (auto-direction part).- Wrong level shifting — RO output is 5 V, divided to ~3.3 V before GPIO16.
- A/B reversed — tested both ways, only one direction yields any bytes.
- Parity — all three tested.
- Testing on an already-running drive — all current results are from a fresh mains power cycle.
What I have not ruled out
- The baud rate. Every figure I have (57600 8E1) comes from reverse-engineering of earlier units. I have no measurement of my own drive.
- A protocol or addressing change on 2025 hardware.
- A required enable somewhere in the drive’s menus before it will accept a bus accessory.
The questions
- Has anyone confirmed 57600 8E1 on a SupraMatic E4 built in 2024–2025? Or measured a different rate?
- Is “transmits for a few seconds after power-up, then silent” the normal behaviour of a drive with no accessory paired, or is it a symptom of the accessory answering with the wrong framing?
- Does anything need to be enabled on the drive (a menu setting beyond
37/bS-Scan) before it will keep an HCP accessory on the bus? - Does
hoermann_hcp/ HCPBridge have a raw-capture or permissive mode that logs anything it receives, including frames it rejects, so I can see how far the parsing gets?
I have a logic analyser on order and will post a measured capture of baud rate, parity and framing once it arrives. If anyone wants a specific capture from this drive in the meantime, ask — I have physical access and can power-cycle it freely.
Happy to contribute whatever I find back to the project; documented results on a 2025-build unit seem to be missing from the existing write-ups.