clean_V2 start mowing command always times out on GOAT A2500 RTK (class: neiwny)

[rschoolm]

Checks

• I have read the above text and I'm aware of the situation
• I have searched the existing issues and no issue is describing my issue
• I'm not creating an issue to add support for a new device/model.
• I have installed the latest version

The problem

The GOAT A2500 RTK is recognized by the integration and partially functional,
but the start mowing command never executes. Every clean_V2 start attempt times
out — the robot never acknowledges it. Return to dock works. Battery polling works
with a full successful round-trip response from the robot, confirming it is online
and reachable. Only the start mowing command fails.

The MQTT layer logs "Command clean_V2 does not support p2p handling (yet)" on
every attempt, suggesting the model's hardware definition is incomplete or the
wrong command is being used for this device.

This appears related to the same clean_V2 / p2p handling gap documented in
issue #852 (GOAT A1600 RTK) and issue #1467 (GOAT O800 RTK).

On which deebot device (vacuum) you have the issue?

Ecovacs GOAT A2500 RTK (class: neiwny, firmware: 1.13.32)

Which version of the deebot-client are you using?

2026.5.3

Country

United States

Continent

North America

Anything in the logs that might be useful for us?

DEBUG [deebot_client.authentication] Success calling api url=https://portal-na.ecouser.net/api/iot/devmanager.do
... cmdName: clean_V2, act: start, type: auto ...
response={'ret': 'fail', 'errno': 500, 'debug': 'wait for response timed out'}

WARNING [deebot_client.command] No response received for command "clean_V2". 
This can happen if the device has network issues or does not support the command

DEBUG [deebot_client.mqtt_client] Command clean_V2 does not support p2p handling (yet)

--- Contrast with getBattery, which succeeds: ---

DEBUG [deebot_client.authentication] Success calling api ... cmdName: getBattery ...
response={'ret': 'ok', 'resp': {'header': {'fwVer': '1.13.32'}, 
'body': {'code': 0, 'msg': 'ok', 'data': {'value': 100, 'isLow': 0}}}}

DEBUG [deebot_client.event_bus] BatteryEvent(value=100)
DEBUG [deebot_client.event_bus] AvailabilityEvent(available=True)

Additional information

The robot is fully reachable — getBattery, firmware reporting, availability, and
return-to-dock all work correctly. The failure is isolated to the start mowing
command only.

The pattern matches the findings in issue #852 where the clean_V2 command is sent
via REST but the robot expects clean via MQTT p2p with a matching content.type
payload. PR #1475 may be relevant as a starting point.

I am happy to capture additional MQTT debug logs if that would help add support
for this model.