WLW186i/196i (EMS+): cooling won't engage with default Tx mode EMS — switching to EMS+ fixes it

[tubicenNEW]

TL;DR: On Buderus WLW186i/196i heat pumps (BC400, EMS2.0/EMS+), the heat pump refuses to enter cooling mode while EMS-ESP is connected to the bus with the default Tx mode "EMS". Heating and DHW work fine. Switching Tx mode to "EMS+" restores cooling with the gateway connected. Bus ID is irrelevant (confirmed working on 0x0B). Reproduced independently by two users.

Hardware

• Buderus Logatherm WLW186i-12, BC400 + MX400 (me)
• Buderus Logatherm WLW196i-12, BC400 (second user)
• EMS-ESP on the service jack in both cases

Symptom (reproducible)

• Gateway connected, Tx mode EMS: the heat pump never switches to cooling. Heating and DHW are unaffected.
• Gateway physically disconnected from the bus: cooling engages normally within the usual delay.
• In my case both the heating installer and the Buderus service technician independently pointed to the external gateway on the bus as the cause.

Variable isolation (the key part)

• Two users, identical config: Tx mode EMS, Bus ID 0x0B (Service Key), same pump family → both reproduce the blocked cooling.
• The second user then changed only the Tx mode (EMS → EMS+), keeping Bus ID on 0x0B → cooling now works with the gateway connected.
• → The decisive variable is the Tx mode, not the Bus ID. The Service Key address is not the cause.

Working theory (not proven)
The default "EMS" Tx timing targets EMS1.0. On these EMS2.0/EMS+ systems the timing seems marginally off and telegrams are occasionally slightly corrupted. Continuous heating tolerates this, but the one-shot cooling-release handshake (dew-point release → changeover valve → cooling circuit) does not, so cooling silently never engages. "EMS+" waits a bit longer for the bus voltage to settle, the telegrams come through cleanly, and the cooling handshake completes. This would also explain the heating-works / cooling-fails asymmetry.

Notes

• A real RC100H / room thermostat is installed, so no thermostat emulation is involved here.
• Bus ID stayed on 0x0B throughout — cooling works on 0x0B once Tx mode is EMS+.

Questions / possible improvement

• Should "EMS+" (or "Auto") be the recommended Tx mode for WLW176i/186i/196i and Bosch CS5800i/6800i? The current default "EMS" silently breaks cooling on these.
• Is there a known reason the cooling-release telegram sequence would be more timing-sensitive than normal heating/DHW operation?
• Would a short note in the docs/FAQ for these pumps help others avoid this?

I'm keeping my gateway disconnected during the cooling season for now, but I can reconnect and capture a trace log of a cooling request in both Tx modes (EMS vs EMS+) if that would help with diagnosis.

Other Reference:
#2214 (comment)

[proddy]

In theory, if the EMS TxMode is set to "auto" (which is now the default), it will switch over to EMS+ as soon as it detects a telegram type ID that is 2-bytes (>0xFF). Do you see the same issue when using Auto and the latest dev release?