Port to esp-idf

[jkaberg]

Esphome is pivoting away from arduino for several reasons (bad BLE support, big binary sizes etc etc). More information here

Would it be possible to port the solution to esp-idf and drop the arduino dependency?

INFO ESPHome 2025.8.2
INFO Reading configuration /config/garasjedor.yaml...
INFO Updating https://github.com/mapero/esphome-hcpbridge.git@None
WARNING Using `cover.COVER_SCHEMA` is deprecated and will be removed in ESPHome 2025.11.0. Please use `cover.cover_schema(...)` instead. If you are seeing this, report an issue to the external_component author and ask them to update it. https://developers.esphome.io/blog/2025/05/14/_schema-deprecations/. Component using this schema: hcpbridge
INFO Generating C++ source...
INFO Compiling app...
Processing garageport (board: adafruit_feather_esp32s3; framework: espidf; platform: https://github.com/pioarduino/platform-espressif32/releases/download/54.03.21-2/platform-espressif32.zip)
--------------------------------------------------------------------------------
INFO Package configuration completed successfully
Removing unused dependencies...
INFO Package configuration completed successfully
HARDWARE: ESP32S3 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.50402.0 (5.4.2) 
 - tool-cmake @ 3.30.2 
 - tool-esp-rom-elfs @ 2024.10.11 
 - tool-esptoolpy @ 5.0.2 
 - tool-mklittlefs @ 3.2.0 
 - tool-ninja @ 1.13.1 
 - tool-scons @ 4.40801.0 (4.8.1) 
 - toolchain-esp32ulp @ 2.35.0-20220830 
 - toolchain-xtensa-esp-elf @ 14.2.0+20241119
Reading CMake configuration...
Generating assembly for certificate bundle...
Dependency Graph
|-- noise-c @ 0.1.10
Compiling .pioenvs/garageport/src/esphome/components/api/api_connection.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/api_frame_helper.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/api_frame_helper_noise.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/api_pb2.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/api_pb2_service.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/api_server.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/list_entities.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/proto.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/subscribe_state.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/api/user_services.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/binary_sensor/automation.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/binary_sensor/binary_sensor.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/binary_sensor/filter.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/bluetooth_proxy/bluetooth_connection.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/bluetooth_proxy/bluetooth_proxy.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/button/button.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/cover/cover.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/dht/dht.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32/core.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32/gpio.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32/helpers.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32/preferences.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32_ble/ble.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32_ble/ble_advertising.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32_ble/ble_uuid.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32_ble_client/ble_characteristic.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32_ble_client/ble_client_base.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32_ble_client/ble_service.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esp32_ble_tracker/esp32_ble_tracker.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/esphome/ota/ota_esphome.cpp.o
Compiling .pioenvs/garageport/src/esphome/components/hcpbridge/cover/hcpbridge_cover.cpp.o
In file included from src/esphome/components/hcpbridge/cover/../hcpbridge.h:9,
                 from src/esphome/components/hcpbridge/cover/hcpbridge_cover.h:6,
                 from src/esphome/components/hcpbridge/cover/hcpbridge_cover.cpp:1:
src/esphome/components/hcpbridge/cover/../hoermann.h:7:10: fatal error: Arduino.h: No such file or directory

***********************************************************************
* Looking for Arduino.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:Arduino.h"
* Web  > https://registry.platformio.org/search?q=header:%1B%5Bm%1B%5BKArduino.h
*
***********************************************************************

    7 | #include <Arduino.h>
      |          ^~~~~~~~~~~
compilation terminated.
*** [.pioenvs/garageport/src/esphome/components/hcpbridge/cover/hcpbridge_cover.cpp.o] Error 1
========================= [FAILED] Took 25.60 seconds =========================

[burmistrzak]

@jkaberg Possible, yes. But it's not going to happen anytime soon because we depend on the Arduino library emelianov/modbus-esp8266... 😬

[14yannick]

Hi 👋
I’ve been looking into replacing this custom library with native ESPHome components (mainly modbus / modbus_controller) to reduce maintenance and move closer to upstream ESPHome.

Unfortunately it’s not a straightforward drop-in replacement.

The original implementation relies heavily on Function Code 0x17 (Read/Write Multiple Registers) and on request-level logic:

• Different responses are generated based on both write address/count and read address/count
• The response payload is dynamically assembled depending on the exact read/write combination
• Timing/stateful behavior (command start → command end) is tied to subsequent read requests

In ESPHome today:

• modbus_controller does not support FC 0x17 on the server side
• server_registers only support simple per-register read_lambda, without access to:
  • function code
  • read/write lengths
  • combined read/write payload
• There is no server-side equivalent of onRequest() where full Modbus frames can be inspected and answered conditionally

Because of this, the Hoermann protocol can’t currently be modeled correctly using only server_registers and lambdas — the protocol logic lives between registers, not inside a single register.

I’ve experimented with:

• Using modbus_controller as a server
• Reproducing the behavior with multiple server_registers
• Hooking into lower-level callbacks (on_modbus_data)

But without native FC 0x17 server support or a request-level callback, the behavior can only be approximated, not faithfully implemented.

Alternative approaches

• Implementing the protocol directly at the UART level, bypassing ESPHome’s Modbus abstractions entirely and handling raw frames manually.
• Offloading the Hoermann HCP communication to a dedicated MCU, exposing a much simpler interface (UART / I²C / Modbus TCP / etc.) to ESPHome.
  This is also discussed in issue Error code 04 on SupraMatic 4 #15, and might end up being the most robust long-term solution.

So short version:

• ✅ ESPHome Modbus is great for standard client/server register access
• ❌ It’s currently missing the abstractions needed for Hoermann’s combined read/write protocol

Until ESPHome gains:

• Server-side FC 0x17 support or
• A generic “handle Modbus request” callback for servers

…this library (or something very close to it) is still required.

Please share your though how we should go forward

[burmistrzak]

@14yannick Something I also looked into is porting the Arduino library to standard ESP-IDF, which should be possible without a lot of patching. There's seemingly not much Arduino-specific code used, so it's maybe worth an attempt. 😉