That version just fixed the body type. If you are still willing to test, I added a new OH4 jar that should handle when multiple responses are received. I noticed in your original log that the unsolicited response was included along with the poll and only one was read. Also since your device was the first example of humidity reporting (either solicited or unsolicited) I added a one-time humidity poll when using REFRESH on a channel. Based on the rarity of humidity reporting, adding a scheduled poll isn’t warranted IMO.
For now
Assuming you linked both humidity channels (target-humidity & humidity) to items, I’d like to know what they look like. I’m expecting one is fixed and the other moves around.
Would like a debug that captures the handling of the body type -96 now to validate it is working as intended. Look for a line like this at the start; Response received length: 300 from device at IP: 192.168.1.105
Would like a debug when sending a REFRESH on any linked channel i.e MideaAC_IDHumidity.sendCommand ("REFRESH")
Also still wondering in the Screen Display channel works on your device to turn the LED on and off.
Thanks in advance.
NOTE: Anyone else that has these two flags in the Midea AC thing properties section could test the jar if interested. There is a slight concern from the documentation of these features that they might vary by model.
yes, it seems to work like that. target remains the same and current humidity is updated frequently when device is powered. I started persistence for it, so I can send a graph later
I still saw a warning type -95 but no -96. here is the log
2025-07-12 08:14:08.511 [DEBUG] [eaac.internal.handler.MideaACHandler] - Handling channelUID humidity with command REFRESH
2025-07-12 08:14:08.512 [DEBUG] [nternal.connection.ConnectionManager] - Disconnecting from device at 192.168.1.105
2025-07-12 08:14:08.521 [DEBUG] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.105 requires authentication, going to authenticate
2025-07-12 08:14:08.521 [DEBUG] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.105 authenticating
2025-07-12 08:14:08.578 [DEBUG] [nternal.connection.ConnectionManager] - Response received length: 72 from device at IP: 192.168.1.105
2025-07-12 08:14:08.578 [DEBUG] [nternal.connection.ConnectionManager] - Authentication successful
==> /var/log/openhab/events.log <==
2025-07-12 08:14:08.509 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Midea_Air_Conditioner_Humidity' received command REFRESH
==> /var/log/openhab/openhab.log <==
2025-07-12 08:14:09.579 [DEBUG] [nternal.connection.ConnectionManager] - Connected to IP 192.168.1.105
2025-07-12 08:14:09.579 [DEBUG] [nternal.connection.ConnectionManager] - Writing to 192.168.1.105 bytes.length: 104
2025-07-12 08:14:09.580 [DEBUG] [nternal.connection.ConnectionManager] - Input stream empty sending write org.openhab.binding.mideaac.internal.handler.CommandBase@698707ca
2025-07-12 08:14:11.080 [DEBUG] [nternal.connection.ConnectionManager] - Response received length: 150 from device at IP: 192.168.1.105
2025-07-12 08:14:11.080 [DEBUG] [nternal.connection.ConnectionManager] - Response length: 104 IP address: 192.168.1.105
2025-07-12 08:14:11.081 [DEBUG] [nternal.connection.ConnectionManager] - Bytes in BINARY, decoded and stripped without header: length: 25, data: 11000000 00000000 01000101 01100110 00000000 00000000 00000000 00111100 00000000 00000000 00000000 01100100 11111111 00100000 00000000 00000000 00000000 00000000 00000000 01000000 00000000 00000000 00001000 10101011 00001111
2025-07-12 08:14:11.081 [DEBUG] [ng.mideaac.internal.handler.Response] - Power State: false
2025-07-12 08:14:11.081 [DEBUG] [ng.mideaac.internal.handler.Response] - Target Temperature: 21.0
2025-07-12 08:14:11.081 [DEBUG] [ng.mideaac.internal.handler.Response] - Operational Mode: COOL
2025-07-12 08:14:11.081 [DEBUG] [ng.mideaac.internal.handler.Response] - Fan Speed: AUTO
2025-07-12 08:14:11.081 [DEBUG] [ng.mideaac.internal.handler.Response] - On Timer: enabled: false
2025-07-12 08:14:11.081 [DEBUG] [ng.mideaac.internal.handler.Response] - Off Timer: enabled: false
2025-07-12 08:14:11.082 [DEBUG] [ng.mideaac.internal.handler.Response] - Swing Mode: VERTICAL
2025-07-12 08:14:11.082 [DEBUG] [ng.mideaac.internal.handler.Response] - Sleep Function: false
2025-07-12 08:14:11.082 [DEBUG] [ng.mideaac.internal.handler.Response] - Turbo Mode: false
2025-07-12 08:14:11.082 [DEBUG] [ng.mideaac.internal.handler.Response] - Eco Mode: false
2025-07-12 08:14:11.082 [DEBUG] [ng.mideaac.internal.handler.Response] - Indoor Temperature: 25.0
2025-07-12 08:14:11.082 [DEBUG] [ng.mideaac.internal.handler.Response] - Outdoor Temperature: 0.0
2025-07-12 08:14:11.082 [DEBUG] [ng.mideaac.internal.handler.Response] - LED Display: true
2025-07-12 08:14:11.082 [DEBUG] [ng.mideaac.internal.handler.Response] - Target Humidity: 64
2025-07-12 08:14:11.083 [DEBUG] [nternal.connection.ConnectionManager] - Disconnecting from device at 192.168.1.105
2025-07-12 08:14:11.106 [DEBUG] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.105 requires authentication, going to authenticate
2025-07-12 08:14:11.106 [DEBUG] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.105 authenticating
2025-07-12 08:14:11.159 [DEBUG] [nternal.connection.ConnectionManager] - Response received length: 72 from device at IP: 192.168.1.105
2025-07-12 08:14:11.159 [DEBUG] [nternal.connection.ConnectionManager] - Authentication successful
2025-07-12 08:14:12.159 [DEBUG] [nternal.connection.ConnectionManager] - Connected to IP 192.168.1.105
2025-07-12 08:14:12.160 [DEBUG] [nternal.connection.ConnectionManager] - Writing to 192.168.1.105 bytes.length: 104
2025-07-12 08:14:12.160 [DEBUG] [nternal.connection.ConnectionManager] - Input stream empty sending write org.openhab.binding.mideaac.internal.handler.CommandSet@f0a0589
2025-07-12 08:14:13.661 [DEBUG] [nternal.connection.ConnectionManager] - Response received length: 150 from device at IP: 192.168.1.105
2025-07-12 08:14:13.661 [DEBUG] [nternal.connection.ConnectionManager] - Response length: 104 IP address: 192.168.1.105
2025-07-12 08:14:13.662 [DEBUG] [nternal.connection.ConnectionManager] - Bytes in BINARY, decoded and stripped without header: length: 25, data: 11000001 00100001 00000001 01000100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00001011 11001011 00101111
2025-07-12 08:14:13.662 [DEBUG] [nternal.connection.ConnectionManager] - Energy/Humidity response detected with bodyType 0xC1.
2025-07-12 08:14:13.662 [DEBUG] [eaac.internal.handler.EnergyResponse] - Total Kilowatt Hours: 0.0
2025-07-12 08:14:13.662 [DEBUG] [eaac.internal.handler.EnergyResponse] - Current Amperes: 0.0
2025-07-12 08:14:13.663 [DEBUG] [eaac.internal.handler.EnergyResponse] - Power Watts: 0.0
2025-07-12 08:14:13.663 [DEBUG] [eaac.internal.handler.EnergyResponse] - Total Kilowatt Hours BCD: 0.0
2025-07-12 08:14:13.663 [DEBUG] [eaac.internal.handler.EnergyResponse] - Current Amperes BCD: 0.0
2025-07-12 08:14:13.663 [DEBUG] [eaac.internal.handler.EnergyResponse] - Power Watts BCD: 0.0
2025-07-12 08:14:13.663 [DEBUG] [nternal.connection.ConnectionManager] - Disconnecting from device at 192.168.1.105
2025-07-12 08:14:13.741 [DEBUG] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.105 requires authentication, going to authenticate
2025-07-12 08:14:13.742 [DEBUG] [nternal.connection.ConnectionManager] - Device at IP: 192.168.1.105 authenticating
2025-07-12 08:14:13.803 [DEBUG] [nternal.connection.ConnectionManager] - Response received length: 72 from device at IP: 192.168.1.105
2025-07-12 08:14:13.804 [DEBUG] [nternal.connection.ConnectionManager] - Authentication successful
2025-07-12 08:14:14.804 [DEBUG] [nternal.connection.ConnectionManager] - Connected to IP 192.168.1.105
2025-07-12 08:14:14.805 [DEBUG] [nternal.connection.ConnectionManager] - Writing to 192.168.1.105 bytes.length: 104
2025-07-12 08:14:14.805 [DEBUG] [nternal.connection.ConnectionManager] - Input stream empty sending write org.openhab.binding.mideaac.internal.handler.CommandSet@324f6351
2025-07-12 08:14:16.306 [DEBUG] [nternal.connection.ConnectionManager] - Response received length: 150 from device at IP: 192.168.1.105
2025-07-12 08:14:16.306 [DEBUG] [nternal.connection.ConnectionManager] - Response length: 104 IP address: 192.168.1.105
2025-07-12 08:14:16.307 [DEBUG] [nternal.connection.ConnectionManager] - Bytes in BINARY, decoded and stripped without header: length: 25, data: 11000001 00100001 00000001 01000101 00110000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00001101 10110010 00010101
2025-07-12 08:14:16.307 [DEBUG] [nternal.connection.ConnectionManager] - Energy/Humidity response detected with bodyType 0xC1.
2025-07-12 08:14:16.307 [DEBUG] [eaac.internal.handler.EnergyResponse] - Humidity from Poll: 48
and finally the led: when I connect a switch item it works as expected: turns the display and all LEDs off so that the device is completely dark
One last thing: I upgraded to OH5M3. I still used your OH4 version as I assumed that the other doesn’t have the humidity feature. Both versions seem to work though.
@Larsen
Thanks a bunch Quick review= Mostly successful confirmations
Channels reflect what I hoped.
Partial success in that a valid byte response seems to be received, but -95 is new one. Will need to investigate. Could you get a debug when the -96 bodytype is processed? I want to confirm that bodytype is handled (and that it can be handled in a multiple response scenario). Look for Response detected with bodyType 0xA0 (I think it is working because you are getting a variable humidity but want to see the binary string and the debug messages).
Refresh works as expected
LED works as expected
I did update the OH5 version with everything from the OH4 test version, so they are the same. I thought since you were testing on OH4, I would leave the non-humidity jar in case of issue. I’m running that version (OH5), so if okay, I can just update that one. I was making a special version for OH4 since many are still on that.
One more test with the jar that you have. I’m suspecting you can change the target-humidity. (I set this up since your capability said humidityManualSet.) Add a widget and try something modest like 60 or 70. I did put limits of 32 and 80.
Thanks again.
EDIT: Added a OH5 snapshot for OH5 that should handle -95 bodyType. (I hope that is it for new types !). No real impact from what has already been discussed. What it appears, in retrospect, is that between the unsolicited 0xA0 and 0xA1 messages your device essentially sends all the data contained in a poll command. Not sure what frequency is defined for the unsolicited ones. Anyway, would like to see a debug with this type handled, just to check the code.
It is not exactly AC season in the Northern Hemisphere, but I did finally get a Midea AC binding officially approved for inclusion in OH addons for the 5.1 release. If you are using one of the many versions from this post, no reason to change immediately if you don’t want to. However, going forward having an official Midea AC version should help future-proof as OH evolves. Besides some internal code restructuring dictated by the OH review, this version follows the original contribution closely. It also picks up some features found in the HA version like default token/key discovery, property discovery (to see what your device says it supports) and energy polling (if supported)
It is currently available only in OH5.1 snapshots, but I added three standalone jars that contain the final merged version that should work with 5.1.x, 5.0.x and 4.3.x here (they did work locally for me). If transitioning from another version provided in this thread you will have to delete and re-add your AC thing.
I am planning to open a new Midea AC thread (without the OH3 label) with the OH5.1 release (in Dec 2025) because the issues in this thread dating back to February 2021 are either resolved or not applicable.
wow, that’s coincidence! Just installed my Midea Xtreme Save Blue and it works just fine with 5.0.2 (just uploaded the jar into the addons folder). It took quite a long time to add all items to an equipment (also the “advanced” ones), but they’re all set.
a few questions (sorry, didn’t read the whole thread):
is it normal, that both commands and reads are set at the polling rate (e.g. 60s)
the lowest the unit can go ist 16°C, the binding only allows for/shows 17°C? plus
in the App I can also use a bunch more functionality. Is there a chance to get those added to the binding? They’re not really must-haves, but if those would be available would be awesome.
also: humidity won’t show values (they are also not shown in the App) and the energy-items are slightly off to my energy meter readings, but I guess, they’re also coming from the device itself.
the polling rate default is 60s but can be adjusted. Commands are ad hoc, only when triggered by item/channel change. Maybe I don’t understand?
2, 3 &4 The documents I had, and my device manual shows 17°C. Check the properties under the Thing UI. There is a command to the device about what is supported. If the device advertises support for 16°C, I can see what I can do to override. Also are the app functions shown there too? Conversely, not all binding functionality is supported by the device. For instance, my device doesn’t support humidity or LED turn off.
does the binding directly connect to the AC or does it use the same API as the App does?
I ask, because since yesterday I can’t connect to the AC anymore:
I I’ll restart the Thing
2025-12-27 11:24:35.809 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:MideaAC' changed from OFFLINE (COMMUNICATION_ERROR): java.net.NoRouteToHostException: No route to host to UNINITIALIZED
2025-12-27 11:24:35.819 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:MideaAC' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2025-12-27 11:24:36.574 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:MideaAC' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2025-12-27 11:24:36.576 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:MideaAC' changed from INITIALIZING to UNKNOWN
2025-12-27 11:24:42.706 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:MideaAC' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): java.net.NoRouteToHostException: No route to host
also the App says the AC is offline?
… so either my PiHole filters out some calls since a gravity update of some kind (I don’t see anything blocked either for the AC-IP, nor if I open the App. So perhaps it’s some kind of cache issue?
or: there’s a problem with the cloud API atm?
The binding connects directly to the device across your local LAN, but the app requires internet access. I have run the binding with my router blocking the internet access of the device, but the app doesn’t work then. If both are out does the device have power?
the AC itself works just fine via IR-remote. And it also appears in my router and regularly uses module.appsmb.com for updates I guess…
But what I read since elsewhere, the USB-Wifi stick doesn’t work reliable. Sometimes it’ll lose connections. So I’ll be getting a “SLWF-01” Stick (~20 €). That’s an ESP32 with ESPHome running on it, which runs completely independently from the cloud services. You’ll lose the App functionality, but the ESPHome should provide with all functions locally. I’ll update here, if I’ve got it running.
I am running the midea binding on openhab version 5.2 using a debian linux build just fine no issues
Are you running in docker by chance ? if so the cyrpto_security has to be set to unlimited for this binding to work correctly.
Other wise please set binding logging to debug and post your logs.
Or read through the above posts and use the python script to test you can talk to the unit outside of openhab is best advice I can offer at this point.
fwiw - I didn’t want to use the cloud-API so I bought the SLWF-01pro dongle (20 € IIRC). This one replaces the Wifi-Dongle from Midea. It can be configured via ESP-Home and works perfectly. What it lacks currently is information on filters, a timer or some debug information. Which is fine for me, because I figured the integrated temp sensor is not very accurate, the ESP-home version can use the “follow me” option and I can send temperatures from a correctly placed temp sensor inside the room and the AC will use that as reference.
The cloud is not needed to control the A/C. I have my device local IP address blocked from the internet by the router and everything works fine. Also, the default log-in to get the token and key doesn’t require any personal information and is requested via the local OH server IP, not the device IP.
Of course, the MSmartHome won’t work with the local IP blocked, but you can use myopenhab for control if needed.
@elbanana I agree with @justaoldman the cause is likely the security. The message you are seeing is the first method that uses the higher (V3) security in a handshake during initialization. Everything up to that point is just using the built-in V2. For example, in docker
I checked the Java environment on my setup. My openHAB 5.2.0 is running inside a Proxmox LXC container (using OpenJDK Temurin-21.0.11). I inspected the active Java process parameters, and -Dcrypto.policy=unlimited is already set and loaded by default:
Since unlimited crypto policy is already enabled in this Proxmox LXC setup, it seems the initialization/handshake failure might be caused by something else.
Any further ideas on what could be blocking the V3 handshake?
TBH I’m not sure at this point. Not familiar with Proxmox, but I know others use it, so it should be okay. I’d suggest a trace level at this point, and something might pop out.
Edit: This is what mine looks like: I blanked out the token key
I activated TRACE logging via UI, and found the exact point of failure during authentication:
DEBUG …ConnectionManager Device at IP: 192.168.1.32 requires authentication, going to authenticate
TRACE …ConnectionManager Key: 8ae894f334540bd9…...d814be36
TRACE …ConnectionManager Token: 69593E2C9583207A…434FF5C70AD
TRACE …ConnectionManager Cloud MSmartHome
DEBUG …ConnectionManager Device at IP: 192.168.1.32 authenticating
TRACE …ConnectionManager writing handshake_request: 83700040200001FE…
DEBUG …ConnectionManager Response received length: 13 from device at IP: 192.168.1.32
DEBUG …ConnectionManager Authentication response unexpected data length (13 instead of 72)!
The device returns a response length of 13 instead of 72, which causes the connection manager to abort authentication. Is this response code (13 bytes) indicating an invalid Token/Key pair, or a different protocol version for newer MSmartHome firmware? Or is something wrong with the device itself?
I seem to recall MSmartHome updated their version of the online app. As well as did some stuff related to the api string at one point even.
You might try reconfiguring your AC to be a member of Nethome plus app and see if it works.
Or you could try testing the python script way up in the posts to see if it works using your current token and key that should give you a better understanding if it is binding specific issue. or a bad token key combo.
Changing to different online app is nothing more than putting A/C back into pairing mode and using Nethome plus App to set it up instead of MSmarthome it should then generate a new token key pair that is based on how Nethome Plus App wants it to work.
The python app is here. Also, long shot, what is your thing UID? EDIT: I want to verify if this is an “ac”. There are other Midea AC, with “cc”, “c3” etc. If it says midea_device it is not “ac”
So I deleted the thing I had, installed the Nethome plus app. Put the AC in pairing mode and connected it (with success) to the app. Returning to OH, found the device already in the inbox of things, created thing as seen down here. Did not change a thing. Populated Key and Token directly, but device continues to not work, trace/debug is equal to the one I posted earlier.
Not sure why but there were two lines missing (size and header) from your trace log. Did you delete them? They come from the encode8370 routine. If that is not run the handshake request won’t get a proper response. I’m not sure yet how a handshake response gets written without that. Is your handshake request length 72 bytes (144 characters)? It looks okay to start.
EDIT: just noticed something else (security not my expertise was written early on), the handshake request should contain the token. the header is 837000402000 plus 0 for handshake plus a three character count (0xfff), then the token 64 bytes for 72.
Quick review= Mostly successful confirmations
!). No real impact from what has already been discussed. What it appears, in retrospect, is that between the unsolicited 0xA0 and 0xA1 messages your device essentially sends all the data contained in a poll command. Not sure what frequency is defined for the unsolicited ones. Anyway, would like to see a debug with this type handled, just to check the code.
