From 1d9028b8e5eaa7299d5ad47688f46987b4911ff4 Mon Sep 17 00:00:00 2001 From: pridmen <15156664+pridmen@users.noreply.github.com> Date: Sun, 17 May 2026 01:51:03 +0300 Subject: [PATCH] daikin_madoka: bump inter-query delay from 50 ms to 200 ms in update() When two BRC1H controllers are paired through one ESP32 (e.g. a single BLE proxy serving multiple bedrooms), 50 ms between the back-to-back CMD_GET_* queries in update() is too tight: chunked notifications from the two devices interleave, and process_incoming_chunk_() trips on 'Another packet with the same chunk ID is already in the buffer' followed by 'Dropped XX BLE events due to buffer overflow'. 200 ms (the value SET_SETTING_STATUS / SET_FAN_SPEED already use) is enough to let one device finish responding before the next query goes out. Total update cycle goes from ~250 ms to ~1 s, well within PollingComponent's default 60 s interval, so no noticeable polling slowdown. Verified on two BRC1H + one m5stack-bleproxy. --- esphome/components/daikin_madoka/daikin_madoka.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/esphome/components/daikin_madoka/daikin_madoka.cpp b/esphome/components/daikin_madoka/daikin_madoka.cpp index 283fe0a96ac7..2aafaef4dc71 100644 --- a/esphome/components/daikin_madoka/daikin_madoka.cpp +++ b/esphome/components/daikin_madoka/daikin_madoka.cpp @@ -213,7 +213,7 @@ void DaikinMadoka::update() { std::vector all_cmds{CMD_GET_SETTING_STATUS, CMD_GET_OPERATION_MODE, CMD_GET_SETPOINT, CMD_GET_FAN_SPEED, CMD_GET_SENSOR_INFORMATION}; for (auto cmd : all_cmds) { - this->query_(cmd, std::vector{0x00, 0x00}, 50); + this->query_(cmd, std::vector{0x00, 0x00}, 200); } }