Add Duco bypass mode select

[korneo51]

Summary

Adds a Duco bypass mode select to the ESPHome Duco component.

The existing bypass sensor exposes the physical bypass opening through register 0x1009. This adds a separate writable select for the bypass control mode discovered and validated on a DucoBox Energy Comfort installation:

• AUTO -> 0x100A = 0
• CLOSED -> 0x100A = 1
• OPEN -> 0x100A = 2

Read uses fn=0x24 with payload {0x00, 0x10, 0x0A}.
Write uses fn=0x24 with payload {0x01, 0x10, 0x0A, value, 0x00, 0x00, 0x00}.

Usage

select:
  - platform: duco
    name: Duco Mode
    bypass_mode:
      name: Duco Bypass Mode

Validation

• Verified with a standalone ESP32 firmware against a DucoBox Energy Comfort:
  • OPEN sets 0x100A=2 and physical bypass register 0x1009 reports 100.
  • CLOSED sets 0x100A=1 and 0x1009 reports 0.
  • AUTO sets 0x100A=0 and lets the Duco internal logic decide the physical position.
• The Python component file was syntax-checked locally with py_compile.

No existing mode select behavior is intended to change; bypass_mode is optional.

[kokx]

This looks pretty good! Have you validated this on your own Duco? (I need to learn to read)

Also, I'm curious, how exactly did you discover this specific way to set the bypass mode?

[korneo51]

Hi, Yes, I validated it on my own DucoBox Energy Comfort D325 and it works reliably. I did not use the ESPHome component directly for the test. With Codex, I built a small standalone ESP32 firmware using the same UART protocol/reverse-engineering approach, then exposed a temporary web UI to read/write candidate registers. How we found it: - Your component already exposed `0x1009` as the physical bypass position. - With Codex, I first sniffed the bus while changing the bypass mode from the Duco display. The visible event was not directly enough to identify the command, but it pointed us toward the bypass-related area. - We then scanned/read nearby registers around `0x1000..0x1020` while setting the bypass from the display to `OPEN`, `CLOSED`, and `AUTO`. - `0x1009` tracked the physical position: - open -> `100` - closed -> `0` - `0x100A` was the stable mode value: - `AUTO` -> `0` - `CLOSED` -> `1` - `OPEN` -> `2` After that we tested writing those values back to `0x100A` with the same register write format used for comfort temperature-like writes. The Duco accepted the writes, the bypass physically moved, and reading back `0x100A` and `0x1009` confirmed the expected state. So the PR is based on field validation on my D325, not just a guess from the register scan. All the reverse-engineering workflow, firmware changes, scan tools, and PR preparation were done together with Codex. Le ven. 29 mai 2026 à 21:22, Pieter Kokx ***@***.***> a écrit :

…

***@***.**** commented on this pull request. This looks pretty good! Have you validated this on your own Duco? Also, I'm curious, how exactly did you discover this specific way to set the bypass mode? — Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=BUE2IQ24JFKDWOFWZZ7PNSD45HPQ5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMZZGIZDINJSGEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4392245210>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUE2IQ4S5YQ2VFG6EKDCQVL45HPQ5AVCNFSM6AAAAACZS4UISKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DGOJSGI2DKMRRGA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BUE2IQ2JT3ZWDA446BN422L45HPQ5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMZZGIZDINJSGEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/BUE2IQ7BYRF7WOELC5VN7RL45HPQ5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMZZGIZDINJSGEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>