Have you seen the work done in GitHub - kueblc/midea-msmart at support-8370 and GitHub - WMP/midea-ac-py at support-8370 to add support for midea version 3? Would it be possible to use/reproduce it here? What would be the best way to go about it?
This binding is directly based on those pythons scripts. I am not aware about anything besides this.
Thanks for your reply. The [support-8370] branches linked to above contain new code for supporting midea version 3. Have you seen that?
Thx.
I chek it, but unforunatly same error
saw same error as well had to crack open the jar and edit Manifest.MF file to this then it worked javax.measure;version="[1.0,2.3)",javax.measure.quantity;version="[1.0,2.3)" only issue now is when it shows temp as Fahrenheit the value is still displayed as Celsius but at least it works now probably not the right way to really fix it but wanted to see if it worked with my units US cooper hunter mini splits with the osk102 wireless dongle . They both picked right up with no issues as soon as I did discover. Now to figure out how to trigger the turbo mode on a timed manner and my server room will be chilly all the time!
Update: also tested on 3.2.0 snapshot after changing Manifest.MF file and it also works but as expected The temp unit value does not change from Celsius even when toggling the item the unit does pick global value from regional settings but the actual conversion does not apply . 
Hi @justaoldman
you’re right: After I changed the values you mentioned, the binding was installed without an error.
But now I’m with the same error because of device version 3 
Regarding
Please check latest release. Tested on 3.1.0 - Release Build
Thanks for your reply. The [support-8370] branches linked to above contain new code for supporting midea version 3. Have you seen that?
What I see there is a case to install fake-cloud (only if you have protocol version 3).
Can you test it using python scripts or installing test Home Assistant?
I am not sure if it is acceptable to use this fake-cloud.
Hi Jacek,
I spun up a fresh install of 3.1.0(stable) with only adding the NTP binding during initial setup (just to be sure openhab worked) your latest build did install perfectly fine and I was able to do discovery of both my units Add items and toggle Turbo mode off and on with no issue…
Unfortunately the issue with conversion from Celsius to Fahrenheit still occurs. the regional value unit does switch between C and F correctly when I toggle the regional setting but the actual measured value does not correctly calculate the conversion and the binding advanced temperature unit item still does not correctly change the mode on the A/C unit same behavior as previous. As a side note when sending any command to the unit from openhab it switches the unit back to C from F on display until I actually use the remote to change a value. The original toggling of the conversion from C to F was done in the nethome app if that helps to better understand why it is not working or how it got changed on my units originally.
This was discussed before over on HA blogs but not ever mentioned as fixed by original developer you forked from.
Thank you for all your effort on this binding.
If this can all be worked out this is a huge add for the openhab suite (IMHO) because it does address a large market of A/C units that are IOT using OSK102 wifi dongles.
Sadly I do not have a unit with the newer OSK103 version dongle to test out that part of your updates.
Again Thank you so much for your effort on this !! 
Update: Playing with the profile setting from default to follow does allow the display to be changed on the A/C unit from C to F and back . However it still does not update and change the values returned for openhab and still if you send a command such as Turbo on or off it reverts the A/c back to C setting.
In addition to the fake cloud, which can be used with OH as is, these branches also contain significant code changes to support the midea v3 protocol
Justan,
last fix I hope fixed issue with binding installation and running it, can you confirm?
It is not yet impemented C/F conversion. I live in Europe, I don’t need any weird Farenheits 
Nevertheless I can do some improvements, I’ll try and share progress.
Eran,
I was browsing those branches, but I don’t see anything new for version 3, can you point it out?
However it still does not update and change the values returned for openhab and still if you send a command such as Turbo on or off it reverts the A/c back to C setting.
Please check newest release.
It uses same grades as response from device.
Hi Jacek,
Yes I can confirm your last fix did resolve the binding installation issue for the Import-Package: javax.measure; version="[1.0.0,2.0.0)". in both stable 3.1.0 and also 3.2.0 snapshot
I know that the weird Fahrenheit is not used outside US and I do understand it is a small thing in all of the challenges this binding still has to overcome but I was thinking if it was addressed now in the early parts of the code then later as things like setting up schedules and other neat features get added it will not cause grief for us users across the pond.
Thanks again for all your hard work It is appreciated.
I found a OSK103 dongle that may work with my A/C at a reasonable cost and If I can get it to work using the native application from cloud then I will be happy to test any changes you make to address the new Midea 3 version that other folks are having so much issues with.
I will watch for any updates you make that support this OSK102 working version as well.
I did find a US OSK103 dongle for a pioneer branded A/C on amazon for under 30 dollars US I went ahead and ordered it will see if it works on my Cooper Hunter and if it does I will be happy to help test out the needed updates to use the protocol 3 version that other posters have been asking about.
Ok tried out your last update the temperature unit item does toggle correctly in default without having to change profile to follow now. Unfortunately toggling turbo on and off still kicks the unit back to C on A/C display and of course the actual returned values for Temp are still in C
Test harness = clean fresh install of 3.1.0(stable)( only other binding is NTP )
See the switch at midea-ac-py/climate.py at da3afa45a2fd15e1a3c74f95529373f34ed6f5f4 · WMP/midea-ac-py · GitHub
which results in calling midea-msmart/device.py at 981421a50355e6858d291635bb377f1402b624d3 · kueblc/midea-msmart · GitHub
which in turn uses lan.py#L82 (forum only allows me two links in a post…)
Hope this helps.
HI Jacek,
So I was able to install a new module OSK105 but it appears to be the same as the OSK103 using the new version 3 midea protocol as @Eranl mentioned I also stood up the fake server python as the links he mentioned require to isolate the unit from the internet app as the readme on those sites indicate that this is a one user at a time connection approach as I understood it from the huge year long blog over on HA site…
So good part is your latest package will correctly discover these modules and add them in to openhab show on line then as soon as it polls the unit it errors attempting to retrieve the status. enabling the debug log for the binding returns this and repeats as the binding error handling seems to recover correctly and try again. status to online then unknown then offline.
2021-07-21 20:04:39.699 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:mideaac__192_168_1_178__30786325767627__net_ac_0a4c at 192.168.1.178
2021-07-21 20:04:39.699 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler MideaACHandler tried updating the thing status although the handler was already disposed.
2021-07-21 20:04:42.865 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler MideaACHandler tried updating the thing status although the handler was already disposed.
2021-07-21 20:04:43.709 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler MideaACHandler tried updating the thing status although the handler was already disposed.
2021-07-21 20:04:43.966 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler MideaACHandler tried updating the thing status although the handler was already disposed.
2021-07-21 20:04:53.971 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:mideaac__192_168_1_178__30786325767627__net_ac_0a4c at 192.168.1.178
after enabling the python script to substitute the cloud with the repeater and adding the dns and taking away internet I can see it start responding on port 443 back to the fake server and it does stop the OSK103 from going into a reboot every 8 seconds and the 600 seconds of Lan is verified.
We can see the module conversation in the trace then we see the module do a udp broadcast and the entire conversation starts over.
The network trace shows it doing a syn ack and fin
as below
So looking through all the remaining scripts that are using it would appear the reason it is not actually allowing a status retrieval is the new module is expecting credentials to be passed to it
apparently when you set up the module through the app to allow it to connect to the wifi it uses your OSK103 modules MAC address and wifi ssid as the user name and the wifi password as the user password
based on the example below from that git site @Eranl listed so perhaps if we added a class to handle that logon it may not be to horrible to go on from there.
# first take device’s ip and id
# pip3 install msmart; midea-discover
device = ac(‘YOUR_AC_IP’, YOUR_AC_ID)
# If the device is using protocol 3 (aka 8370), you must authenticate with your
# WiFi network’s credentials for local control
device.authenticate(‘YOUR_AC_MAC’, ‘YOUR_WIFI_SSID’, ‘YOUR_WIFI_PW’)
# Refresh the object with the actual state by querying it
device.refresh()
Anyway hope this helps
and as always test harness was clean fresh install of openhab 3.1.0(stable) only other binding was NTP and of course this time a OSK103(5) USB module
sorry for such a long post but wanted to offer as much content to this as possible.
I’m able to run the binding, thanks already for you work!
What I noticed, is that I’ve got a lot of disconnections. Is this also the case in your setups? I’m using 4 indoor units. The wifi network doesn’t show issues (as far as I know):
2021-07-22 08:34:46.350 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:337472c093' changed from ONLINE to OFFLINE
2021-07-22 08:34:46.358 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:337472c093' changed from OFFLINE to UNKNOWN
2021-07-22 08:34:46.603 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:337472c093' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Read timed out
2021-07-22 08:34:46.606 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:337472c093' changed from OFFLINE (COMMUNICATION_ERROR): Read timed out to UNKNOWN
2021-07-22 08:34:46.855 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:337472c093' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Device not responding with its status.
same behavior with disconnects on my side
Check your version.
I have this issues too, because of version3