How It Behaves

How it behaves

The first refresh is slow

A unit doesn't tell you which queries it understands. So on the first refresh() the client tries all of them: basic status, new protocol values, self cleaning, energy, humidity, runtime, service data groups and both capability frames.

Every query the unit ignores is tried twice and costs two response timeouts (5 s each by default) before it's skipped. With several unsupported queries the first refresh can take up to a minute.

The client remembers what was skipped for its whole lifetime, and capabilities are only read once. From the second refresh on, only queries the unit actually answers go out, and a refresh takes well under a second.

• resetProtocolProbe() forgets the skipped queries and reads the capabilities again on the next refresh. Only needed if the unit was busy during the first one.
• Keep the client alive between refreshes instead of creating a new one each time, or you pay the probing cost again.

The basic status query is never skipped. If the unit doesn't answer it, refresh() throws MideaException.Timeout.

Commands are optimistic

When you send a command, the client takes the new values into its state right away, then overwrites them with what the unit confirms.

The reason: every basic command carries the full state. Without the optimistic update, a second command sent quickly after the first would be built from the old state. Send "mode = cool" and then "temperature = 22", and the second command would carry the old power = off and switch the unit back off.

If no confirmation arrives within the response timeout, the call doesn't fail. The requested state stays until the next refresh shows what the unit really did.

Modes and presets

• Selecting a mode always switches the unit on, like the mode button on the remote.
• Selecting a mode clears the dry flag, because it can stop some units from leaving dry mode.
• Leaving DRY mode sets the fan to auto, unless you set a fan speed in the same command.
• Comfort, eco, boost, sleep, frost protection and power saving exclude each other. Selecting one switches the others off.

These rules come from midea-local.

Threads

• All network methods are synchronized. Several threads can share one client; their calls run one after another.
• Use one client per unit. Many Wi-Fi modules accept only one TCP connection.
• Listeners run on the thread that processed the update.

Reconnects

If a call fails with a network error, the client closes the connection, reconnects and retries the call once. Only if that fails too does the exception reach you, and isAvailable() becomes false. Authentication errors are not retried.

Logging

The library logs through java.util.logging. Set the de.mirranet.midea logger to FINEST to see every frame sent and received:

Logger log = Logger.getLogger("de.mirranet.midea");
log.setLevel(Level.FINEST);
ConsoleHandler h = new ConsoleHandler();
h.setLevel(Level.FINEST);
log.addHandler(h);

The command line tool does the same with --debug.

Next: Protocol overview