I just updated to OH5.1.3 and got my hands on the Midea AC binding. I followed the config-steps of the doc and README, which got me the token and key from the “cloud” via my email address and password.
Unfortunately the binding still says Invalid Key.
How to debug this from here on? I’m ready to help.
There have some reports about the MSmartHome cloud having issues. One option is to use the default settings for Nethome plus. The other option is to get a debug log during the cloud process. There is also an option to get the token and key from a python app, but that shouldn’t be needed.
I read about the issue with MSmartHome and as it was not what I was seeing I thought it was OK.
Nevertheless I tried NetHome now. I could connect to the AC using the IoS APP. Using the credentials in OpenHAB leads to the same problem: I get a token and a key, but OH says Invalid Key. Back to start…
I found the msmart-ng-script, which discovered the device on the local network and puts out the key and token. Inserting them to openhab fails the same way as before.
Obviously, something new. For background did you discover the device with a scan or use textual? I’m assuming a new device too. What is the name of the IOS app?
EDIT: I have been a little concerned about API changes and my ability to reverse engineer it.
can you set your Midea binding to trace and then disable then reenable the thing? and share the output please
How to enable tracing? In the binding UI?
Never mind, found it.
2026-04-06 16:46:53.898 [DEBUG] [nternal.connection.ConnectionManager] - Disconnecting from device at 192.168.1.35
2026-04-06 16:46:53.899 [TRACE] [nternal.connection.ConnectionManager] - Connecting to 192.168.1.35:6444
2026-04-06 16:46:53.903 [DEBUG] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.35 requires authentication, going to authenticate
2026-04-06 16:46:53.903 [TRACE] [nternal.connection.ConnectionManager] - Key: be004bc5da744227adae2103819664167ab421ea113246a4a1fe22b50f9541e9
2026-04-06 16:46:53.904 [TRACE] [nternal.connection.ConnectionManager] - Token: 7b669b5dfa0f0bca3defd9cc0945674bf3dc93d29d7a799f77abb02a6c6478d726ab2dbf7cbe9dbbddd104d53290b963fc32908921b4d25d085c34fd077306f8
2026-04-06 16:46:53.904 [TRACE] [nternal.connection.ConnectionManager] - Cloud NetHome Plus
2026-04-06 16:46:53.905 [DEBUG] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.35 authenticating
2026-04-06 16:46:53.905 [TRACE] [g.mideaac.internal.security.Security] - Size: 64
2026-04-06 16:46:53.906 [TRACE] [g.mideaac.internal.security.Security] - Header: 837000402000
2026-04-06 16:46:53.906 [TRACE] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.35 writing handshake_request: 83700040200000037B669B5DFA0F0BCA3DEFD9CC0945674BF3DC93D29D7A799F77ABB02A6C6478D726AB2DBF7CBE9DBBDDD104D53290B963FC32908921B4D25D085C34FD077306F8
2026-04-06 16:46:53.933 [DEBUG] [nternal.connection.ConnectionManager] - Response received length: 72 from device at IP: 192.168.1.35
2026-04-06 16:46:53.934 [TRACE] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.35 response for handshake_request length:72
2026-04-06 16:46:53.935 [WARN ] [g.mideaac.internal.security.Security] - AES decryption error: InvalidKeyException: Illegal key size
2026-04-06 16:46:53.936 [TRACE] [g.mideaac.internal.security.Security] - Payload: E30A1FB71E475AA398A2A2A6373B524423DFF07664B708BB5C074DD0ED7A4D9D
2026-04-06 16:46:53.937 [TRACE] [g.mideaac.internal.security.Security] - Sign: 923EEA12E4A4993ADA6AE9A3B3DA408D20A03D395564E940F5B9E034005C894F
2026-04-06 16:46:53.937 [TRACE] [g.mideaac.internal.security.Security] - SignLocal: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
2026-04-06 16:46:53.938 [TRACE] [g.mideaac.internal.security.Security] - Plain:
2026-04-06 16:46:53.938 [WARN ] [g.mideaac.internal.security.Security] - Sign does not match
ChatGPT thinks this is a Java problem due to the 72-bytes response and the following AES error.
FWIW: I’m using the docker-image version 5.1.3: image: “openhab/openhab:5.1.3”
Should I switch to another version?
search the forum there was a setting that has to be enabled for docker to have proper cyphers for use in OpenHab and https been a while and I am on a mobile so don’t have link in front of me.
You can also test if the script you ran to retrieve key and token works to change or retrieve any settings from the A/C if that script works outside of “docker openhab” then you know that your issue is docker related configurations.
I don’t have time right now, but I think this is the root. The code returns [0] in this case, that throws off the handshake match. 72 is the correct bytes.
try {
cipher.init(Cipher.DECRYPT_MODE, key);
} catch (InvalidKeyException e) {
logger.warn("AES decryption error: InvalidKeyException: {}", e.getMessage());
return new byte[0];
From my unit sign and local sign need to match.
2026-04-06 10:29:43.004 [DEBUG] [nternal.connection.ConnectionManager] - Response received length: 72 from device at IP: 192.168.0.246
2026-04-06 10:29:43.005 [TRACE] [nternal.connection.ConnectionManager] - Device at IP: 192.168.0.246 response for handshake_request length:72
2026-04-06 10:29:43.006 [TRACE] [ing.midea.internal.security.Security] - Payload: 86B60635253BDF1A89972D31F26CD4A2DB8C8BB28B80441D8436E84B145E8E17
2026-04-06 10:29:43.007 [TRACE] [ing.midea.internal.security.Security] - Sign: EB9A867A35A995540EB67F21B6D182D1562EF4CADE16B3A6F34723F56EB06CFF
2026-04-06 10:29:43.007 [TRACE] [ing.midea.internal.security.Security] - SignLocal: EB9A867A35A995540EB67F21B6D182D1562EF4CADE16B3A6F34723F56EB06CFF
2026-04-06 10:29:43.007 [TRACE] [ing.midea.internal.security.Security] - Plain: 408E8FDA324F81E8F37683EF4A1684EEAA4A05EDF6BA86ED061406ECA8EC07EC
I was missing the CRYPTO_POLICY=unlimited environment variable in my docker-compose-file.
It is referenced on the openhab-docker-site, but I was using my old one when upgrading not taking enough care.
This has to be set in the docker-compose.yml.
Sorry for the off topic but if these ac are midea based you could always replace the dongle and use the smlight ones (I use 5 at my home.) they are fully local, esphome based, and we have a binding for OpenHAB. I’d be happy to share more info if anyone cares but I don’t want to make a big off topic here 