Each unit is polled in the background by the midea-ac client:

What	When
Full refresh	every pollInterval seconds (default 30). Published every time, even if nothing changed
Heartbeat	every 10 seconds in between. Keeps the connection alive and picks up changes the unit reports on its own
Changes from the remote or the app	published at the next heartbeat, so within about 10 seconds
After a command	right away, as soon as the unit confirms it
On request	any message on <base>/<device>/get

A shorter pollInterval doesn't make remote control changes show up faster; the heartbeat already catches those. It mainly refreshes the sensor values (room temperature, energy) more often.

On the first refresh after the start, the client tries every optional query (energy, humidity, service data, capabilities) to find out what the unit understands. Each one the unit ignores costs two response timeouts before it's skipped. The first state can take up to a minute to appear. After that a refresh takes well under a second.

Commands sent during that time wait until the refresh is done. The details are in the midea-ac wiki.

A basic command always carries the unit's complete state. The client takes the new values over immediately and then replaces them with what the unit confirms. That way a second command right after the first doesn't undo it.

If no confirmation arrives, the command doesn't fail: the requested values are published, and the next refresh shows what the unit really did.

Commands for a unit are queued and run one after another on that unit's own thread. A slow or unreachable unit never blocks the MQTT connection or the other units.

• When a unit stops answering, <device>/availability switches to offline, and no further state is published for it. The client keeps reconnecting in the background; when the unit is back, availability returns to online and state publishing resumes.
• When the bridge is stopped cleanly, it sets every device and bridge/status to offline.
• When the bridge crashes, the broker sets bridge/status to offline through the last will (after about 45 seconds, 1.5 × keep-alive). Device availability keeps its last value, so check both topics.

The bridge uses a clean session. After a reconnect it subscribes again to the command topics and re-publishes bridge/status, availability, state and capabilities of every unit, so retained values are correct even if the broker lost them.

Commands published while the bridge was disconnected are lost; there is no queue.

If the broker isn't reachable at startup, the bridge retries every 10 seconds before starting the units.

A retained set would be executed again on every reconnect. The bridge therefore drops retained messages on set and get and logs a warning. See MQTT topics.

Many Wi-Fi modules accept only one TCP connection. Don't control a unit from midea2mqtt and Home Assistant's midea integration (or another bridge) at the same time, and don't run two bridges with the same unit. The Midea app is fine; it talks through the cloud.

The unit takes a moment to report a started self cleaning cycle. For at least 30 seconds after selfClean was set, reports that still show the old value are ignored.