[T0xB8] zone_index cleaning mode does not navigate to specific rooms

[fullur90]

Device model (eg. T0xAC) / 设备型号（例如：T0xAC）

T0xB8

Component version / 插件版本

No response

HA core version / HA版本

2026.7.2

The problem / 问题详情

Description

The zone_index work mode (CLEAN_MODE_CODE = 0x0a) is available in the device mapping and the lua protocol supports a zone_id parameter (byte 20 of the control message). However, when selecting zone_index with any zone_id value, the vacuum starts cleaning but does not navigate to a specific room — it appears to clean the whole house or do nothing specific.

What I tried

• Set work_mode: zone_index with zone_id values: "01" through "07", "1" through "7", letters "A" through "H" (room labels in the MSmartHome app)
• Added zone_id to centralized in T0xB8.py to ensure it is always included in the control payload
• Tested work_mode: area (0x09) with the same zone_id values — same result

Debug logs

The lua runtime correctly receives and encodes the zone_id:
LuaRuntime json_str: {"control": {"work_mode": "zone_index", "zone_id": "01", "work_status": "work"}, ...}
LuaRuntime Result: aa1bb80000000000000222020002000a0200010001000000000000f7
Decoded response: {'zone_id': '1', 'work_mode': 'zone_index', 'work_status': 'work'}

The device acknowledges work_status: work but does not go to any specific room.

Question

What are the correct zone_id values for rooms defined in the MSmartHome app map? Are they simple integers (1-7), or does the device use internal IDs that need to be queried first?

The lua file includes a zone query (query_type: zone, msg[10] = 0x35, msg[11] = 0x03) but this is not implemented in the integration. Would it be possible to:

1. Implement the zone query to retrieve room IDs from the device
2. Expose them as selectable segments in the vacuum entity

Map info

The MSmartHome app shows 7 rooms (A, B, C, D, F, G, H) on the saved map. Room cleaning works correctly from the app.

Entity attributes / 实体属性

device_id: 31885837517970
sn: 0000B8321510VR0W012204106223D80X
sn8: 510VR0W0
model: 510VR0W0
device_type: T0xB8
SN8: 510VR0W0
area: 0
battery_percent: 91
carpet_switch: no
connected: true
control_type: auto
end_time: 08:00
error_desc: no
error_type: no
fan_level: normal
filt_brNet_life_time: 150
filt_brNet_rest_time: 150
have_reserve_task: 1
mop: no
move_direction: none
query_type: disturb
roll_brush_life_time: 200
roll_brush_rest_time: 200
set_status: on
side_brush_life_time: 100
side_brush_rest_time: 100
speak_level: none
speed: low
start_time: 22:00
status_summary_command_source: no
status_summary_device_error: no
status_summary_uv_switch: yes
status_summary_voice_switch: no
status_summary_wifi_switch: no
subtype: 13
user_high_board_communication_error: no
user_high_laser_sensor_error: no
user_high_laser_sensor_shelter: no
version: 2
voice_level: 75
water_level: low
work_mode: area
work_status: sleep
work_time: 0
zone_id: B
device_class: connectivity
icon: mdi:devices
friendly_name: Aspiradora Device Status

Home Assistant Logs / 系统日志

No response

Device LUA file / 设备对应LUA文件

T_0000_B8_510VR0W0_2023050601.lua

Device Plugin file / 设备对应Plugin文件

No response

Official APP Screenshot of Device / 设备在官方APP的控制截图

No response

[sususweet]

@fullur90 Thanks for the detailed report – this is very helpful for understanding the zone_id issue on T0xB8.

One quick request: the Lua file you attached (T_0000_B8_510VR0W0_2023050601.lua) seems to be corrupted or unreadable – I couldn't open it on my side. Could you please re‑upload the Lua file? Make sure it's the actual .lua file from your .storage/midea_auto_cloud/lua/ directory (not a renamed or zipped version), or if you prefer, you can zip it and attach it.

Additionally, if you're comfortable, you can also send your Midea SmartHome app credentials (username and password) to my email sususweetcandy@qq.com – this would allow me to directly query the cloud API for your device, inspect the raw zone/room data, and figure out the correct zone_id mapping. I understand this is sensitive, so you can set a temporary password for debugging and change it back once we're done.

Either way, please let me know how you'd like to proceed – I'm happy to help debug this further.

Thanks again for your contribution!

[fullur90]

T_0000_B8_510VR0W0_2023050601.zip

Thank you very much for your quick response. I attached the .lua file.
The room labels in the app are from letters "A" through "H", if that helps.

Thank you again!

[sususweet]

Thanks for the zip — the Lua is readable now.

Here’s what the protocol shows for 510VR0W0:

1. Wire zone_id is numeric, not the app’s A–H labels. Encode path is msg[20] = tonumber(zone_id) or 0x00. Letters like "B" become 0 and are ignored.
2. Your "01" capture is correct (byte20 = 0x01). The robot starts work, so the mode is accepted — but index 1 still isn’t the room you expect on the saved map.
3. App letters A/B/C… are UI labels. The real IDs have to come from the device map / zone table.
4. Lua can send query_type: "zone" (0x35 / 0x03), but the decode path only handles consumables (decodeQueryParts) — zone list decoding is missing, so we can’t yet expose real room IDs as vacuum segments.

Next debug step that would unblock this: from the official app, start cleaning one specific room, and capture either:

• the cloud control JSON (zone_id / related fields), or
• the raw reply to a query_type: zone request

With that we can map label → numeric ID (or bitmask) and then add a proper room select + segment cleaning in HA.

Until then, please stick to numeric zone_id values only (not A–H). If you already have a successful app capture, paste that payload here and I’ll continue from there.

[fullur90]

Thank you again for the information.

I tried to capture the cloud control JSON by intercepting the app traffic using HTTP Toolkit on Android, but the MSmartHome app blocks it — it detects the SSL certificate substitution and refuses to connect, so no traffic could be captured that way.

Regarding the query_type: zone attempt, I added it to the queries list in T0xB8.py and confirmed in the HA logs that the command is being sent correctly, but the device does not respond:

command: {'query': {'query_type': 'zone'}}
response: {"code":"1306","msg":"The asyn reply does not exist"}

Sending: aa0cb800000000000003350301

transparent/send response: {"code":"3176","msg":"The asyn reply does not exist","data":null}

This suggests the zone/room IDs are not stored on the physical device but on the Midea cloud side. The robot does not respond to this query at all.

Is there another cloud API endpoint that might return the room map or zone IDs directly?

[sususweet]

Thanks for trying the query_type: zone approach and for sharing the raw responses.

The error you received (code: "1306", msg: "The asyn reply does not exist" and code: "3176") indicates that the device did not recognize or accept the query command – it's not a sign that the data is stored in the cloud. In the Midea protocol, async reply does not exist typically means the device doesn't support that particular query type, or the command payload is malformed for this specific firmware. Since you confirmed the Lua sends the query correctly but gets no useful reply, that suggests your robot vacuum's firmware simply doesn't implement the zone table query at all (or uses a different query code).

As for your hypothesis that room IDs are cloud‑only – while it's possible the map data is synced to the cloud, the actual zone IDs needed for control commands are almost certainly derived from the device's internal map, which the cloud may store but the integration doesn't have an API to fetch it directly. Currently, there's no known cloud endpoint that exposes the room‑ID mapping for T0xB8 devices.

Given the current limitations – the device doesn't respond to the zone query, and the official app blocks SSL interception (making packet capture difficult) – there's no straightforward way to proceed with implementing room‑selective cleaning in this integration right now.

I'd suggest the following option:

· If you can find another way to capture the control payload from the official app (e.g., using a router‑level MITM or a rooted device with a trusted CA), please share that capture – it would be invaluable.

For now, I'm afraid we don't have a viable solution for this feature. Thanks again for your patience and your thorough testing.