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.
1 Like
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
So pulled the git repos that @eranl mentioned down built out the python module and tested it with the provided example.py script (updating the required values as the readme stated on my 2 systems one that has the OSK102 module (version 2) and the other that I just swapped out to a OSK103 module(version 3) as a FYI Both modules versions are able to control my A/C’s perfectly via the nethome app
Here are the results:
The python script presents the same authentication error on the version 3 as shown below.
_python>py example.py
DEBUG:msmart.lan:Attempting new connection to 192.168.1.178:6444
DEBUG:msmart.lan:Sending to 192.168.1.178:6444 8370004020000000cb797646b987c3a7ea738b0249889542b2c7626e92e44a214e418740a8cc9be4f3a033232646ff32150f8baede3f3381cd583538d96e95e8ad94191e374ee2a2
DEBUG:msmart.lan:Received from 192.168.1.178:6444 83700005200fa5a54552524f52
Traceback (most recent call last):
File “c:\HOLD_python\example.py”, line 12, in
device.authenticate(‘The A/C unit Module MAC address_changed this for post in discussion’, the wifi_SSID ‘, 'The wifi password-these values where correct changed for post discussion’)
File “c:\HOLD_python\msmart\device.py”, line 43, in authenticate
self._authenticate()
File “c:\HOLD_python\msmart\device.py”, line 46, in _authenticate
self._lan_service.authenticate(self._mac, self._wifi_ssid, self._wifi_pw)
File “c:\HOLD_python\msmart\lan.py”, line 68, in authenticate
self._authenticate()
File “c:\HOLD_python\msmart\lan.py”, line 80, in _authenticate
raise error
File “c:\HOLD_python\msmart\lan.py”, line 76, in _authenticate
tcp_key = self.security.tcp_key(response, self._key)
File “c:\HOLD_python\msmart\security.py”, line 90, in tcp_key
raise Exception(‘authentication failed’)
Exception: authentication failed
So it does not work at least with my version 3 module anyway.
Now with my version 2 module A/C unit
the example.py produces this out with the values updated for my version 2 module.
c:\HOLD_python>py examplev2-test.py
DEBUG:msmart.lan:Attempting new connection to 192.168.1.51:6444
DEBUG:msmart.lan:Sending to 192.168.1.51:6444 83700040200000002b1085a54d59e775955f73195e379ad5d859c03b4a222fd0d7f526d19e2bdefad33f57a02997147946c243c068200b2e84c4e4865a3562d36dafcb73e70d24d6
INFO:msmart.lan:Couldn’t connect with Device 192.168.1.51:6444
Traceback (most recent call last):
File “c:\HOLD_python\examplev2-test.py”, line 12, in
device.authenticate(‘was correct changed for post to discussion’, ‘was correct changed for post to discussion’, ‘was correct changed for post to discussion’)
File “c:\HOLD_python\msmart\device.py”, line 43, in authenticate
self._authenticate()
File “c:\HOLD_python\msmart\device.py”, line 46, in _authenticate
self._lan_service.authenticate(self._mac, self._wifi_ssid, self._wifi_pw)
File “c:\HOLD_python\msmart\lan.py”, line 68, in authenticate
self._authenticate()
File “c:\HOLD_python\msmart\lan.py”, line 80, in _authenticate
raise error
File “c:\HOLD_python\msmart\lan.py”, line 76, in _authenticate
tcp_key = self.security.tcp_key(response, self._key)
File “c:\HOLD_python\msmart\security.py”, line 92, in tcp_key
raise Exception(‘unexpected data length’)
Exception: unexpected data length
Then I Ticked out the authentication call in the example.py
#device.authenticate(‘Was the correct values YOUR_AC_MAC’,Was the correct values ‘YOUR_WIFI_SSID’, ‘Was the correct valuesYOUR_WIFI_PW’)
And the example worked fine to talk to a version 2 module.
c:\HOLD_python>py examplev2-test.py
DEBUG:msmart.packet_builder:Finalize request data: aa20ac00000000000003418100ff03ff000200000000000000000000000006f274
DEBUG:msmart.lan:Attempting new connection to 192.168.1.51:6444
DEBUG:msmart.lan:Sending to 192.168.1.51:6444 5a5a0111680020000000000028060a1016071514a51b0100000e00000000000000000000000000006b000a76e27eed2c3647e57d8602df8bf295fcc1f4b9ce80e506ab2a879fe3c5a8a539f3ded2b04298069292e4ad666e941e6610630bf955dbcc31b74ce36681
DEBUG:msmart.lan:Received from 192.168.1.51:6444 5a5a011158002080000000000000000000000000a51b0100000e00000000000000000000010000009e3222526fb4221d812148bdd3e76a4b0fa0858e4b9c8309faaef3e0919c74250d1e32ecf2e8a3469a25bd2b345043f3
DEBUG:msmart.device:update from 192.168.1.51, 15331962861477: aa1eac00000000000003c00149507f7f00000000007179000000000000be33
DEBUG:msmart.command:Appliance response data: c00149507f7f00000000007179000000000000be33
{‘id’: 15331962861477, ‘name’: ‘192.168.1.51’, ‘power_state’: True, ‘prompt_tone’: False, ‘target_temperature’: 25.0, ‘operational_mode’: <operational_mode_enum.cool: 2>, ‘fan_speed’: <fan_speed_enum.High: 80>, ‘swing_mode’: <swing_mode_enum.Off: 0>, ‘eco_mode’: False, ‘turbo_mode’: False, ‘indoor_temperature’: 31.0, ‘outdoor_temperature’: 35.5}
DEBUG:msmart.packet_builder:Finalize request data: aa23ac0000000000000240c3495003ff003000000000000000000000000009000000f563
DEBUG:msmart.lan:Sending to 192.168.1.51:6444 5a5a011168002000000000001f090a1016071514a51b0100000e00000000000000000000000000006933eda55d9f2daa2155b695450065925c6f3654452c169c38c790ddb302d6d7a0b2d9369ddf5faaf75d67f7328c2ad83609bbbe0dbe988967f447205d6707d4
DEBUG:msmart.lan:Received from 192.168.1.51:6444 5a5a011158002080000000000000000000000000a51b0100000e00000000000000000000010000000f7686a7505927fa12e49e832825d35f073139f23d5642000d8a3473988c5ab26bbbcc079887de484a9dd3a884103a37
DEBUG:msmart.device:update from 192.168.1.51, 15331962861477: aa1eac00000000000002c00149507f7f00000000007179000000000000be34
DEBUG:msmart.command:Appliance response data: c00149507f7f00000000007179000000000000be34
{‘id’: 15331962861477, ‘name’: ‘192.168.1.51’, ‘power_state’: True, ‘prompt_tone’: True, ‘target_temperature’: 25.0, ‘operational_mode’: <operational_mode_enum.cool: 2>, ‘fan_speed’: <fan_speed_enum.High: 80>, ‘swing_mode’: <swing_mode_enum.Off: 0>, ‘eco_mode’: False, ‘turbo_mode’: False, ‘indoor_temperature’: 31.0, ‘outdoor_temperature’: 35.5}
So clearly for a version 2 this worked ok with out trying to use the extra authenticate that version 3 requires.
So unless what I am seeing or I am doing is a incorrect test . The updates that @eranl asked about do not seem to really work at least with my version 3 module.
Perhaps someone else can also try and see whether it works for them on a version 3.
@justaoldman thank you very much for your verification of those python scripts and such a detailed description.
This is exactly what I ask everyone who has module with version 3. So if anyone is able to communicate with a device version 3 with any kind of scripts (python or any other) I can try to improve implementation to handle it.
I own only modules with version 2 and on the other hand I don’t see anywhere confirmed scripts working with version 3.
Jacek
@justaoldman
Does it mean that currently binding generally handles correctly Fahrenheits (besides this turbo mode)?
Can you describe test case? I can set up Fahrenheits using Midea Android App, but it seems that my remote controller does not support Fahrenheits and I cannot reproduce it.
On the other hand I improved implementation to use measure framework, I will share it soon.
Jacek
Hi Jacek,
So after looking through all of the various folks different approaches the entire F to C comes down to this
The item to change from F to C only to change the display on front of unit and not the display on remote control( there is no button on remote to toggle it you have to hold down both the temp up and temp down buttons at same time to change its display)
the api expects the target temp to be returned in C .5 increments.
So for any values to be displayed in F the C value would have to be multiplied by 1.8 and 32 added.
The current behavior of openhab when setting the regional settings allows for choosing metric or imperial(US) this applies across all units of measure (as I am sure you know ) so for example if your regional setting was set on metric then the inside temp would display say as 26C but if you change your regional setting to Imperial(US) then the inside temp would display as 26F the unit measure is converted but the actual value is not calculated What should happen if the binding was seamlessly integrated is if the openhab regional setting is set to metric the the values in the binding would display the value of 26C but if the regional setting of openhab was set to Imperials(US) then the binding would do the calculation and the value would display as 79F The temperature unit item from the A/C should track the regional setting selected in openhab ie if regional value is metric then the temperature unit should be set to OFF and if openhab regional value is set to Imperial(US) then the temperature unit value should be set On and it should always read that setting based on what openhab regional setting is set to. that setting (the remote control gets its value based on what it is selected in (pushing both Arrorw up and arrow down buttons and holding them till remote changes )regardless of the A/C unit current value so its will also change the A/C unit Display based on what you have set the remote too on its next command to change a temp setting on the unit.This of couse is exspected since a remote control is a transmitter only not a reciever thus it has no way to listen to what the A/C is already set too.
And of course the follow me button or as the binding calls it “Feel own” simply toggles the A/C to listen for a response from the remote control that is sent every 5 seconds and the remote sends a temperature reading from the sensor in the side of the remote control also the A/C unit reads that temp sensor as inside temp instead of the temp sensor that is in front of the filter under the lid where the USB module get plugged in (which the ENG teams call the return air path sensor)
so if the binding was in fact to be fully integrated with openhab it would pick up the regional setting in openhab and toggle that temperature unit value accordingly and of course calculate the correct adjusted value based on the setting.
Now with all that said it would still have to convert it back to C to speak to the A/C unit regardless as the API expects all values to be in C value at .5 increments.
Also currently each time you send a call to the A/C unit it turns off the Temperature unit setting regardless of witch ever value you are setting turbo fan speed set temp all behave the same in this regard in openhab.
Hopefully my long winded reply has answered what you’re asking.
Hello Jacek,
My error still persist.
I installed latest version of binding.
When i send any command from OH connection brakes.
2021-07-24 10:12:14.219 [TRACE] [ler.MideaACHandler$ConnectionManager] - Performing connection check for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at IP 192.168.1.130
2021-07-24 10:12:14.221 [TRACE] [ler.MideaACHandler$ConnectionManager] - Checking status of connection for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:12:14.224 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Connection check OK for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:12:14.226 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Requesting status update from mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:12:14.228 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Writing to mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130 bytes.length: 104, bytes: 5A5A01116800200000000000011506180A0C0E00DA370000000B00000000000000000000000000006B000A76E27EED2C3647E57D8602DF8B3F4EE2ECC7958BEB7CDE1C8E4D35B902A8F076B4772087D783B4E55608F449D0A8AFBE8EB534216F6DF9008D9B8AAF8B
2021-07-24 10:12:14.230 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response received length: 312
2021-07-24 10:12:14.231 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response bytes: 5A5A0111680044000C6C00000000000000000000DA370000000B0000000000000000000003000000BA06092943112241407A816BE70385DBE3E2960E3E4CCB394314C496882D53797A6D2FD0AA2DBAC5227E569B8730A9F57F1CF1F9A0546642E38698E30B1CDD0B5A5A0111680040000E6C00000000000000000000DA370000000B000000000000000000000100000006BC339B4B376DA0791C7FFB5A23B6AEA49E8EF2426A7C2B25EBEAD72403EE554D361C26BFC7A077A31715626DD8A296674CD8ACA486DF083D7CB760439BB9915A5A011168004000106C00000000000000000000DA370000000B00000000000000000000010000001A504AE3D41487E0D4157A5E921D76EC4BDFB3E16E33D88768CC4C3D0658937D8BB1B887FC81BD411474A6E4FE23A2C59CCC5BB649D22D28740B36BA5A7C8A3A
2021-07-24 10:12:14.233 [TRACE] [ng.mideaac.internal.handler.Response] - Bytes decoded and stripped without header: A01B40147F7F003300000000001E0000000000000045890F0F0F0F0F0F0F0F0F0F0F0F0F0F0F8FC542F38058CEB183FE18F839773990BBAE5A6CA7AC217FB98B7D1838FC23921C15E7E08AA3173021626628769460BA70E1C7E00BD73E4EDA3BBE7098B5779DF01538681C918083FB7A56352D38DA5DC747D53A1A6CB3F3FE8C7FA5BE7A58D20E551714F466058D286D20A08C23AD4173E4858E61E0D3A8A422898EA50666F1B1C596BB4057A5A3E88A7BEEC74093AC0B3B717CEF5481F9AFB6DC11184C7270AA2BAC00000000000304A300000000000000000000000000000000000000000000000000000000000000E2
2021-07-24 10:12:14.235 [TRACE] [ng.mideaac.internal.handler.Response] - PowerState: true
2021-07-24 10:12:14.236 [TRACE] [ng.mideaac.internal.handler.Response] - ImodeResume: false
2021-07-24 10:12:14.237 [TRACE] [ng.mideaac.internal.handler.Response] - TimerMode: true
2021-07-24 10:12:14.239 [TRACE] [ng.mideaac.internal.handler.Response] - ApplianceError: false
2021-07-24 10:12:14.240 [TRACE] [ng.mideaac.internal.handler.Response] - TargetTemperature: 16.0
2021-07-24 10:12:14.241 [TRACE] [ng.mideaac.internal.handler.Response] - OperationalMode: COOL
2021-07-24 10:12:14.245 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed: SILENT
2021-07-24 10:12:14.247 [TRACE] [ng.mideaac.internal.handler.Response] - OnTimer: enabled: false
2021-07-24 10:12:14.248 [TRACE] [ng.mideaac.internal.handler.Response] - OffTimer: enabled: false
2021-07-24 10:12:14.252 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode: HORIZONTAL
2021-07-24 10:12:14.253 [TRACE] [ng.mideaac.internal.handler.Response] - CozySleep: 0
2021-07-24 10:12:14.254 [TRACE] [ng.mideaac.internal.handler.Response] - Save: false
2021-07-24 10:12:14.255 [TRACE] [ng.mideaac.internal.handler.Response] - LowFrequencyFan: false
2021-07-24 10:12:14.256 [TRACE] [ng.mideaac.internal.handler.Response] - SuperFan: false
2021-07-24 10:12:14.257 [TRACE] [ng.mideaac.internal.handler.Response] - FeelOwn: false
2021-07-24 10:12:14.258 [TRACE] [ng.mideaac.internal.handler.Response] - ChildSleepMode: false
2021-07-24 10:12:14.259 [TRACE] [ng.mideaac.internal.handler.Response] - ExchangeAir: false
2021-07-24 10:12:14.260 [TRACE] [ng.mideaac.internal.handler.Response] - DryClean: false
2021-07-24 10:12:14.260 [TRACE] [ng.mideaac.internal.handler.Response] - AuxHeat: false
2021-07-24 10:12:14.261 [TRACE] [ng.mideaac.internal.handler.Response] - EcoMode: false
2021-07-24 10:12:14.262 [TRACE] [ng.mideaac.internal.handler.Response] - CleanUp: false
2021-07-24 10:12:14.263 [TRACE] [ng.mideaac.internal.handler.Response] - TempUnit: false
2021-07-24 10:12:14.264 [TRACE] [ng.mideaac.internal.handler.Response] - SleepFunction: false
2021-07-24 10:12:14.265 [TRACE] [ng.mideaac.internal.handler.Response] - TurboMode: false
2021-07-24 10:12:14.266 [TRACE] [ng.mideaac.internal.handler.Response] - CatchCold: false
2021-07-24 10:12:14.266 [TRACE] [ng.mideaac.internal.handler.Response] - NightLight: false
2021-07-24 10:12:14.271 [TRACE] [ng.mideaac.internal.handler.Response] - PeakElec: false
2021-07-24 10:12:14.273 [TRACE] [ng.mideaac.internal.handler.Response] - NaturalFan: false
2021-07-24 10:12:14.274 [TRACE] [ng.mideaac.internal.handler.Response] - IndoorTemperature: null
2021-07-24 10:12:14.276 [TRACE] [ng.mideaac.internal.handler.Response] - OutdoorTemperature: -25.0
2021-07-24 10:12:14.277 [TRACE] [ng.mideaac.internal.handler.Response] - Humidity: 30
2021-07-24 10:12:14.289 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.processMessage(MideaACHandler.java:653) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.sendCommand(MideaACHandler.java:568) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.requestStatus(MideaACHandler.java:530) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.checkConnection(MideaACHandler.java:718) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.lambda$0(MideaACHandler.java:476) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
==> /var/log/openhab/events.log <==
2021-07-24 10:12:14.286 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MideaAC_Targettemperature' changed from 25 °C to 16 °C
2021-07-24 10:23:57.131 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'MideaAC_Power' received command ON
2021-07-24 10:23:57.135 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'MideaAC_Power' predicted to become ON
2021-07-24 10:23:57.139 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MideaAC_Power' changed from OFF to ON
2021-07-24 10:23:57.408 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Disconnecting from mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:23:57.416 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Starting connection monitor job in 10 seconds for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:23:57.408 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Broken pipe (Write failed)
2021-07-24 10:24:07.418 [TRACE] [ler.MideaACHandler$ConnectionManager] - Performing connection check for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at IP 192.168.1.130
2021-07-24 10:24:07.420 [TRACE] [ler.MideaACHandler$ConnectionManager] - Checking status of connection for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:24:07.421 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Connection check FAILED for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:24:07.423 [TRACE] [ler.MideaACHandler$ConnectionManager] - Connecting to mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130:6444
2021-07-24 10:24:07.438 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:24:07.439 [DEBUG] [eaac.internal.handler.MideaACHandler] - Changing status of mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b from OFFLINE class="highlight commError">(COMMUNICATION_ERROR) to ONLINE
2021-07-24 10:24:07.441 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Cancelling connection monitor job for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:24:07.444 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Writing to mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130 bytes.length: 104, bytes: 5A5A01116800200000000000011506180A180700DA370000000B00000000000000000000000000006B000A76E27EED2C3647E57D8602DF8B3725CB1253F3ADBD10A3C5652579B549338096D0C415A92454C415B932CEEB781966138A31B81E66CF316595A4B6DF1E
2021-07-24 10:24:07.442 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b' changed from OFFLINE (COMMUNICATION_ERROR): Broken pipe (Write failed) to ONLINE
2021-07-24 10:24:09.322 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response received length: 104
2021-07-24 10:24:09.323 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response bytes: 5A5A011168002080000000000000000000000000DA370000000B00000000000000000000010000004CE95CB8222F35C26517FA44890B2356C72664226E014DDC28AAD0ABBCEAB0AB4F57E5C3BF38C7238BBFD92DAAE57F305C9F3CE67CCE074128CB27E2FAE6026D
2021-07-24 10:24:09.324 [TRACE] [ng.mideaac.internal.handler.Response] - Bytes decoded and stripped without header: C00149147F7F003300000064620D00340000001E000000078F
2021-07-24 10:24:09.325 [TRACE] [ng.mideaac.internal.handler.Response] - PowerState: true
2021-07-24 10:24:09.326 [TRACE] [ng.mideaac.internal.handler.Response] - ImodeResume: false
2021-07-24 10:24:09.327 [TRACE] [ng.mideaac.internal.handler.Response] - TimerMode: false
2021-07-24 10:24:09.327 [TRACE] [ng.mideaac.internal.handler.Response] - ApplianceError: false
2021-07-24 10:24:09.328 [TRACE] [ng.mideaac.internal.handler.Response] - TargetTemperature: 25.0
2021-07-24 10:24:09.329 [TRACE] [ng.mideaac.internal.handler.Response] - OperationalMode: COOL
2021-07-24 10:24:09.330 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed: SILENT
2021-07-24 10:24:09.330 [TRACE] [ng.mideaac.internal.handler.Response] - OnTimer: enabled: false
2021-07-24 10:24:09.331 [TRACE] [ng.mideaac.internal.handler.Response] - OffTimer: enabled: false
2021-07-24 10:24:09.332 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode: HORIZONTAL
2021-07-24 10:24:09.333 [TRACE] [ng.mideaac.internal.handler.Response] - CozySleep: 0
2021-07-24 10:24:09.335 [TRACE] [ng.mideaac.internal.handler.Response] - Save: false
2021-07-24 10:24:09.336 [TRACE] [ng.mideaac.internal.handler.Response] - LowFrequencyFan: false
2021-07-24 10:24:09.337 [TRACE] [ng.mideaac.internal.handler.Response] - SuperFan: false
2021-07-24 10:24:09.337 [TRACE] [ng.mideaac.internal.handler.Response] - FeelOwn: false
2021-07-24 10:24:09.338 [TRACE] [ng.mideaac.internal.handler.Response] - ChildSleepMode: false
2021-07-24 10:24:09.339 [TRACE] [ng.mideaac.internal.handler.Response] - ExchangeAir: false
2021-07-24 10:24:09.340 [TRACE] [ng.mideaac.internal.handler.Response] - DryClean: false
2021-07-24 10:24:09.341 [TRACE] [ng.mideaac.internal.handler.Response] - AuxHeat: false
2021-07-24 10:24:09.341 [TRACE] [ng.mideaac.internal.handler.Response] - EcoMode: false
2021-07-24 10:24:09.342 [TRACE] [ng.mideaac.internal.handler.Response] - CleanUp: false
2021-07-24 10:24:09.342 [TRACE] [ng.mideaac.internal.handler.Response] - TempUnit: false
2021-07-24 10:24:09.343 [TRACE] [ng.mideaac.internal.handler.Response] - SleepFunction: false
2021-07-24 10:24:09.343 [TRACE] [ng.mideaac.internal.handler.Response] - TurboMode: false
2021-07-24 10:24:09.344 [TRACE] [ng.mideaac.internal.handler.Response] - CatchCold: false
2021-07-24 10:24:09.345 [TRACE] [ng.mideaac.internal.handler.Response] - NightLight: false
2021-07-24 10:24:09.346 [TRACE] [ng.mideaac.internal.handler.Response] - PeakElec: false
2021-07-24 10:24:09.346 [TRACE] [ng.mideaac.internal.handler.Response] - NaturalFan: false
2021-07-24 10:24:09.347 [TRACE] [ng.mideaac.internal.handler.Response] - IndoorTemperature: 25.4
2021-07-24 10:24:09.348 [TRACE] [ng.mideaac.internal.handler.Response] - OutdoorTemperature: 24.0
2021-07-24 10:24:09.348 [TRACE] [ng.mideaac.internal.handler.Response] - Humidity: 13
2021-07-24 10:24:09.353 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Starting connection monitor job in 10 seconds for mideaac:ac:mideaac__192_168_1_130__12094627919834__net_ac_5c3b at 192.168.1.130
2021-07-24 10:24:09.368 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MideaAC_Targettemperature' changed from 16 °C to 25 °C