Support for setAreaParameter to control zone-specific settings (O1200 LiDAR Pro)

[monsivar]

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 have installed the latest version

The feature you want to suggest

The current deebot_client integration relies on global commands like number.cut_direction, which are not effective for newer models like the Goat O1200 LiDAR Pro. This model requires zone-specific parameter management.Technical Details:
I have analyzed the communication between the Ecovacs App and my Goat O1200 and identified that the machine uses the setAreaParameter command to control settings on a per-zone basis. The payload structure for changing settings in a specific zone is as follows:

{ "areaID": "2", "mowHeightLevel": 10, "cutMode": 7, "obstacleHeight": 1, "angle": 136 }

Proposed Feature:
I would like to request that the integration exposes a service (e.g., ecovacs.set_area_parameter) that allows setting these parameters for individual zones. This would enable users to programmatically control: angle (Clipping angle) mowHeightLevel (Clipping height) Log Evidence:
The following command was successfully sent by the app to update the settings for Zone 2:
iot/p2p/setAreaParameter/.../q/qhdn/j payload: {"body":{"data":{"areaID":"2","mowHeightLevel":10,"cutMode":7,"obstacleHeight":1,"angle":136}}... Why this is important:
Without this, it is currently impossible to automate zone-specific settings in Home Assistant, forcing users to rely on the manual app interface for changes that could otherwise be handled by automations.

LOG:
`// Command sent from the app to the mower to update Zone 2
2026-05-26 23:41:57.568 DEBUG (MainThread) [deebot_client.mqtt_client] Got message: topic=iot/p2p/setAreaParameter/.../q/qhdn/j, payload=b'{"body":{"data":{"areaID":"2","mowHeightLevel":10,"cutMode":7,"obstacleHeight":1,"angle":136}},"header":{...}}'[cite: 5]

// Device confirmation report containing parameters for all zones
2026-05-26 23:41:57.614 DEBUG (MainThread) [deebot_client.mqtt_client] Got message: topic=iot/atr/onAreaParameter/.../j, payload=b'{"header":{...},"body":{"data":{"areaParameters":[{"areaID":"2","mowHeightLevel":10,"cutMode":7,"obstacleHeight":1,"angle":136},{"areaID":"3","mowHeightLevel":4,"cutMode":7,"obstacleHeight":1,"angle":180},...]}}}'[cite: 5]`

[monsivar]

I created a custom component in Home Assistant so i can change the sones and start it from a Node Red flow:

Command for starting to cut zones:
payload: { entity_id: "lawn_mower.r2d2", command: "clean", params: { act: "start", content: { type: "spotArea", value: "1,2" // Klipp sone 1 og 2

flow NodeRED.json

goat_proxy.zip

[monsivar]

Just an update! I did some further testing and network logging today to map out the remaining core functions for the GOAT mower (Edge Mowing / Border Rotate and Return to Dock).

It turns out both of these follow a very specific payload structure via p2p that the current deebot_client doesn't seem to format correctly for mowers yet.

1. Edge Mowing / Border Rotate
   To start an edge cut for specific zones, the app sends a clean command, but requires the zones to be prefixed with reid: and separated by semicolons inside a content object.
   Topic: iot/p2p/clean/...
   Payload:

{ "act": "start", "content": { "type": "borderrotate", "value": "reid:1;reid:2;reid:3;reid:4" } }

Note on state: When this starts, the mower sends an onCleanInfo event with motionState: "working" and content: {"type": "borderrotate"}.

2. Return to Dock (Charge)
   To send the mower back to the station, the app sends a charge command with the action go.
   Topic: iot/p2p/charge/...
   Payload:

{ "act": "go" }

By injecting these exact payloads directly into the execute_command function via a proxy, the mower responds perfectly. Hoping this helps in mapping the CleanV2 and Charge classes for the GOAT series! Let me know if you need any testing done on my end.