Can You share me /private message/ full output since discovery, through obtaining key and token from cloud?
Do you have multiple devices in Cloud?
Jacek
Thanks for the V3 update.
I have however some trouble being able to get a correct token as the OpenHAB binding states that the retreived token is invalid.
For some reason I’m also not able to get the devices connected to the MSmartHome app itself.
Even midea-discover is letting me down as soon as I try to retreive the data with the account - password combination set. (It does show the AirConditioning units without entering a user - pass but it won’t return a token then). When entering the account credentials it returns that the account is invalid even when it has been made yesterday, saving the credentials in a notepad.
The weird thing about midea-discover complaining about the user credentials is that when I use these same credentials in OpenHAB to add an AC, I immediately get a notification on the app that a login occured on another device?!
Is this troubles that are with the MSmartHome app / cloud or could this have other causes?
To get Token+Key you need to have devices visible in MSmartHome (not MideaAir!!!).
I don’t know what could be problems.
midea-discover can show you devices, as it scans local network, but email+password is necessary for Token+Key retrieval from cloud.
Jacek
1 Like
Hi Folks,
Let me clarify a few things.
First sorry for such a long post but wanted to include as much relevant information in one place as I could. Also, hopefully avoid repeated questions around the same topics over and over.
The prerequisites for making one of these Version 3 A/C units work with the awesome binding Jacek has created.
- The A /C unit must already be configured and connected and pingable on the same wireless LAN your Openhab install has access to.
- If your unit is using a model ##OSK103 or Higher USB module (or embedded wireless module and has the OSK 103 or higher firmware depends on the unit) it is a still a Version 3, (encrypted communication) and you must have a token and key to be able to communicate with the configured device.
- During the A/C discovery or configuration process within OpenHAb you need to provide the token and key. If you know them already you can manually enter them and then save and the unit will start responding to OpenHab pollings.
If you do not have the token and key already you will need to obtain them to enable functionality.
Your options are,
A. you provide a valid user name and valid password for the MSmarthome cloud app (not Midea-air or any other version). This is because the URL to the cloud app coded into the discovery section of the binding is connecting to that API server (MSmarthome’s API server) to query for the token and key combo.
B. You do a trace and obtain them using methods and tools like I outlined in a August 2021 post above.
C. You down load the python script from the GitHub MacZhou site as @Jacek mentioned above and I also linked to back in August 2021. run the pip install and midea discover.exe It has 2 options use Mac’s built in MSmarthome account or provide your valid MSmarthome account username and password. UPDATE The built in account Mac Zhou hard coded does not seem to work now as it previously did. So now it appears you must add the devices to your own account using the app before it will display token and key!
Then It will then return a valid set of the token and key pair as well.
Note the token and key will change each time you run it due to part of the parameters used to create the token and key use the current time of the request as part of the creation.
Any of the matched token and key pair you get will work fine and can be reused over and over and should work just fine on multiple V3 A/C units you may have on your local network. There is also a example.py on that site that you can populate and tweak to confirm your units work correctly outside of OpenHab. Note: This will require you to have a version of Python installed 3.9 or higher version BTW. - If you are using the username password approach to obtain your token and key your Openhab instance must have internet access and be able to resolve URL’s to IP’s (DNS must be working on that subnet)(how to tell? easy just try to ping google.com if it resolves to a IP and responds on the device that is only connected on the same subnet as your Openhab it has a valid DNS lookup available and internet access.) This is required to allow the binding to connect to the MSmarthome cloud app and be able to retrieve a token and key. Please note this is absolutely required for this username password solution to work and obtain the required token and key the Version 3 A/C needs to use the binding and for successful communications in OpenHab!
Again it only uses that username and password the first time to get token and key once token and key are populated you could remove the username and password field and the binding will still work fine.
Some additional history…
Recent changes from Midea Air (OEM manufacturer of all these devices ) included a rebranding effort for the Cloud App in the March - April 2022 timeframe this of course triggered a rewrite of the discovery process to use the MSmarthome app for obtaining the token and key.
(early versions back when this Version 3 solution was first being developed a MideaAir account and a customized version of the base app was used and worked fine to sniff the traffic and obtain a token and key).Again I fully detailed that process way up in this post around the August 2021 time frame
This entire solution was all based on a python script that was ported from a ruby script see GitHub history and some of my previous posts in the blog from a year ago if you want more details on the history.
@Jacek 's binding is based off of those early works and his awesome skill to convert them to a Java app and make the binding used for OpenHab.
5. The token and key are generated from a core frame work part of the cloud based application written by the OEM A/C manufacturer(MideaAir) however many resellers rebrand the A/C as well as the application and customize it to match the specific models they sell. This is why there are so many different applications that will work online with your A/C device. Again because they all use the same core framework to create the token and key needed to establish communications with your device from the internet. via their version of the cloud app hosted on their own web API servers and with usernames and passwords set up only for their website. why? (think advertising and other revenue generating items the reseller can market to the user while using their custom version of the app)…
You DO have to have the A/C actually added to the MSmarthome cloud APPand have a valid MSmartHome username and password AND ACCEPTED the Disclaimer (check box) and **logged into the app at least one time and got the app to the point it is prompting you to ADD Device !!!
This solution has been tested extensively and if the above criteria is met it works perfect every time. The issues I have seen posted since this V3 release seem to all point back to not meeting the basic criteria I outlined at the beginning of this post. the binding will tell you invalid token if it can not resolve the URL or log into the MSmarthome app (because it was not fully activated) or Openhab instance has no internet access.
There are a few gotchas
The token and key are case and SPACE sensitive as well as the password.
The token and key are “always editable and actively checked each time the polling occurs” so if you invertedly change one or the other after the initial discovery it will break communications.
The username and password are only used that first time you discover or if you reset the device ID back to 0 it may retry easier to delete the thing and rediscover IMHO.
The A/C unit will reset the wireless connection every 2 minutes if it cannot do the phone home check for firmware updates from OEM you will see the wireless indicator on the A/C turn off then back on and in OpenHab you will see it turn from green(online) to red(offline)or even sometimes show as (comm error) then go back to green(online) again. This all occurs on a ~ 2 minute interval BTW. This only occurs if the A/C unit loses internet connectivity when it attempts to connect back the OEM web site If internet access is stable and working it does not occur(trouble shooting hint for intermittent issues 
) debug log will also show this when reviewed.
There is a way to fix that if you are running a closed network after setting up token and key but I will leave that for you to read about on the Github site or if someone wants it just reply to this post and I will take the time to explain it as well.
A few final thoughts /trouble shooting tips or considerations.
Some wireless routers have a limit on the number of devices that can be connected at the same time consider that if you are seeing random issues with the A/C unit dropping connection even with super strong signal.
A device that has a manually configured static IP address that is within your DHCP IP range will also cause IP conflicts and connectivity issues if the DHCP server attempts to assign that IP to a device.
If your router has the ability to "reserve an IP and reassign that IP to a specific MAC address it is always better to configure it that way instead of a hardcoded IP setting. “note dhcp usually provides more than just the IP mask and gateway and DNS settings and for most newer wireless routers it may also dynamically provide route configurations as well such as between the guest wireless network and the main wireless and lan network.as well as the different wireless bands the multiple radios in your router may have.” Try and consider that when setting a hard coded static configuration as well. At the very least make sure you use a IP out side of the configured DHCP IP assignment range for manually configured network settings…
If you set your subnet Mask to a custom value that is different from the one your router is using for assignments in DHCP you may have issues with discovery as the broadcast IP may not match and failures can occur during the multicast phase of discovery this is a good site to help you figure out that possible configuration issue. IP Subnet Calculator
If your wireless router is located too close to the A/C unit, it may saturate the wireless transceiver in the A/C and cause it to act erratic.
Hopefully what I have posted is helpful as well assists in clearing up some of these reported issues.
Oh as a FYI I also tested this on the new Openhab 3.3.0 latest snapshot version still in development and the binding works perfectly there as well.
Updated Side note There is a fork from the MAC ZHOU project that has been coded to use either the NetHomePlus or MideaAir or the migrated SMarthome app account if you already have your devices in one of those apps you could also use to retrieve a token and key.
I tested it and the token and key from it using my NethomePlus account also seemed to work with the binding.
that github repo is here.
1 Like
Hi Wesley,
It sounds like you may possibly have a few different issues occurring.
First can you post the output from your Midea-discover?
Feel free to obscure the sensitive data such as username password and IP but show the command you used to run the Midea-discover.
Also can you make sure you are using a fully installed and have a correctly configured environment for your python 3.9?
if possible can you show a screen shot of the state in the MSmarthome app you are when you log into it? (again obscure any creds or other sensitive data). And also what message you get when you attempt to ADD Device?
Can you verify that the wireless network you have your A/C units on as well a your OpenHAb set up are able to resolve to Google.com and ping and get a valid reply response to it
If have already checked and reviewed all of that and it tests good. then have you tried a power cycle of the A/C unit? unplugged the A/C mains (or turned off the breaker if it is hard wired) and let it sit with no power for a few minutes (5 minutes at least) to allow the stored power in the A/C controllers power supply capacitors to bleed off) then power it back on. I have seen issues where the wireless module in the A/C gets into a bad state and the only way to clear it is to remove power from the entire A/C unit (hard boot)
Could you also reset your password on the MSmarthome app as well?
I had an issue with it not liking the password I used during initial setup but it did not prompt me that I had failed to meet the password requirements yet it let me on the app the first time and acted like it had accepted it. After I closed the app on my phone and the next time I went to log in it told me I had a invalid password. I had to do a password reset in the online app and wait (about 10 minutes) for the e-mail with broken english to allow me to reset it).
One last thing I forgot to mention. The app does not like having or even seems to allow more then 1 person logged in onto the account at a time unless you have added them as a Shared family member and scanned the little QR code. So make sure you are not logged into the online app on your phone or tablet (close it completely after logging out) at the same time you are doing the discovery or running the midea-discover python script
Hi Justan,
Thanks for the feedback and the options to try.
I’ve made a new account prior to using the MSmarthome app and changed up the password in the process of trying to connect the AC units but they refuse to work in the MSmartHome app.They did previously work in the Midea Air app as the previous home owner had them connected there. I’ve been using this app up until switching as I found the existence of this binding.
The devices are on my main network and are all pingable. From my main desktop I pinged my phone, the AC units and Google succesfully.
Device ping
AC is connected to the WiFi
I normally follow the recommended steps of powering down the AC units, powering them, pressing the LED button 7 times and then adding the device. The MSmartHome app connects to the AC, passes the data and then should pass the second step (I have it in crappy translated dutch and it states AC is networked?!?). guessing it should say something like checking AC connection. It does give a message that it cannot connect to the server, but that happens when it is still connected to the AC and switches up to the main network. After a while of hanging in the second step i get an error code: 114169
Connecting to AC and transfering data
Error while connecting
So in short, when trying to add the AC units to the MSmartHome app they seem to not pass the second step after the WiFi data is sent to the AC units.
Could this be due to the AC units previously being connected via Midea Air? If so is there a way to reset the OSK-103 usb? I’m not sure if the AC is still connected to the WiFi even though a little while back I’ve deleted them there together with my whole Midea Air account, or that they’ve connected due to using the MSmartHome app.
I did the midea-discover routine via SSH on my openhab PI together with username and password and it returned the following data: midea-discover
As a sanity check I did reinstall and used the Midea Air app yesterday and the AC units seem to be able to connect via that and can be controlled via this app. I’ve noticed that it currently is able to migrate everything over to the new MSmartHome app so I tried that also. The AC units seem to transfer over to the MSmartHome app but always stay offline for some reason.
Hi Wesley,
From what I understand if you power cycle the A/C unit and then do the 7 key press routine it switches the OSK-103 module into AP mode at that point it has entered edit mode and all new settings will overwrite previously save values when the save function is called from the App if it fails to get that then the timeout period expires and the USB module goes back o what it had previously saved. I have not seen a process to completely return the OSK103 module back to “factory reset” I am not saying there is not a way to do it of course just that I have never seen it documented anywhere in all of my research and testing.
I have moved A/C units to multiple different router and subnets and Online accounts and app versions (NethomePlus, MideaAir (original) polar king Pioneer and several others in my quest to get an App that I liked from the Play store. During All of my testing and experiment’s every time I do any change of any of those apps or network hardware as soon as I have completed the Online apps setup process it has always worked fine.
I have both multiple Version 2 A/C’s and a Version 3 A/C unit and none of them have had issues with me reconfiguring them to anything I want as long as Internet DNS firewall and basic network settings on the wireless router are correct.
Can you please try pinging this? mp-prod.appsmb.com
For me in the states when I ping that I see it resolve to this US MP but I am in US obviously
PS C:\Users\Justan> ping mp-prod.appsmb.com
Pinging mp-us-prod.appsmb.com [35.167.88.132] with 32 bytes of data:
Reply from 35.167.88.132: bytes=32 time=87ms TTL=23
Reply from 35.167.88.132: bytes=32 time=87ms TTL=23
Reply from 35.167.88.132: bytes=32 time=87ms TTL=23
Reply from 35.167.88.132: bytes=32 time=87ms TTL=23
Ping statistics for 35.167.88.132:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 87ms, Maximum = 87ms, Average = 87ms
so I would expect yours to resolve to a European MP
and provide results.
This still appears to be either an issue with resolving DNS for your A/C devices or Firewall related.
The fact your phone also seems to have issues connecting to the app when it turns off the cellular and attempts to communicate with the internet app via your wireless network also seems to indicate that as well.
Notice in your pic where the phone has failed to talk to server you are no longer on 4G and only showing wireless (which is expected because that is how the online app validates the OSK103’s modules configuration is correct The app also attempts to communicate to the internet API server only using wireless from your phone.).
l think once you have determined what is blocking your devices from communicating with the new online Msmarthome app URL you will also be able to add them in OpenHab binding.
The fact that even after you migrate them to the new app and that works but the units never come Online in the new app however as you state they work fine in the OLD MideaAir app seems to indicate either a DNS lookup issue or a firewall blocking the communications.
Update and FYI I posted some updates to my previous long post including a alternate python solution that still seems to use the MideaAir account like you have working already. you might give that a shot as well to see if it gives you any sucess.
Okay I’m starting to see what is wrong now.
As I tried to ping the regular mp-prod.appsmb.com the pining fails with a timeout as result.
but when I manually ping the US IP address I get a response.
This is my fault as in the past (where the V3 binding was not yet properly working) I tried to implement the midea fake-cloud to see if I could get it working that way. I found in my router that I redirected these IP addresses coming from mp-prod.appsmb.com to my PI with the fake cloud running.
I’ve never gotten this to properly work so I kinda neglected this looking for another solution. Just have to figure out how to get these IP addresses working again, as deleting these rules and rebooting the router and rebooting the PC didn’t fix this yet…
Programming is a better skill for me than networking I guess 
Thanks for the help anyway. I’ll keep posted on my further findings for when it is up and running.
Yep that makes sense DNS resolve… 
for winders box from admin prompt this should do it ipconfig /FlushDNS
for linux here is a link to address it there depending on which way you set it up foryour PI
Also on your winders pc make sure you did not do a late night desperate hack of the windows/system32/drivers/etc host file…
or the host file in nux box also been there too…
Done that a few times and completely forgot about it and fought the next day trying to figure out why a web app I was bashing up did not take my changes… 
Okay, Few things that I’ve found currently:
- I’ve removed the mentioned static re-routes so I should be able to connect again.
- I still can’t ping the device, but the strange thing is when I put the available IP addresses for mp-prod.appsmb.com in wireshark the web browser seems to navigate to these no problems
— Quick note to add here: I’ve asked a friend of mine to ping the address and he had the same issue for some reason, not being able to ping the address, but putting this in the browser greets you with an nginx page - I’m also able to add the devices into the MSmartHome app now that the rules have been removed
OpenHAB isn’t yet a 100% coorperative in adding the AC units automatically, but after retreiving the token and key manually via midea-discover [user] [pass] the issues sorted out!
They are finally online
Again @justaoldman Thank you so much for your help
and @JacekDob for the amazing work on the V3 binding
Release notes (202205312143):
- Added “Midea Air” and “NetHome Plus” Cloud Providers for key and token retrieval
When updating the binding do I need to remove my ac things and re-add them?
Normally you can just update the binding without the need of re-adding the devices.
I’ve updated the binding without any issues
Hi there! Thank you for your development. 202205312143 is the first build which more or less works for me. I have 2 different USB sticks for 2 Midea GD AC. I can use them via NetHome Plus app. One of them tells its fw version is “1.0.7”, the other one says “V15029082115”. Once i installed the jar i could control both devices without problem through Openhab openHAB 3.3.0, Build #2651 . However some minutes later i no longer able to control them. Things are online, devices can be pinged. According to tcpdump Openhab and the device can talk but my AC does not respond. When i re-initialize all the things again my ACs respond again. Any idea? Thank You!
Hi,
Can you start with a few things like disabling one of the 2 units in Openhab and see if the issue still occurs?
enable the debugging logs and posting them before and during the unresponsiveness condition would also be helpful.
If possible, could you spin up a 3.2 stable version and see if you still have issue (just to eliminate any sneaky stuff that 3.3 which is still in development may have induced and was not tested for. We only did basic function and install test for 3.3 during this last round of validations for @JacekDob but as a fyi I have had multiple version 2 and version 3(firmware 1.05) units in my Openhab (3.2 stable version to be clear) running for over 2 months now nonstop (as I had his first beta to test) and not seen anything like what you are describing.
Thanks, i’ill do all the suggested steps then revert soon.
Hello @ JacekDob
I have the same disconnect error also with the latest binding.
2022-06-25 20:02:13.094 [TRACE] [ler.MideaACHandler$ConnectionManager] - Performing connection check for mideaac:ac:ed1fc05010 at IP 192.168.1.130
2022-06-25 20:02:13.095 [TRACE] [ler.MideaACHandler$ConnectionManager] - Checking status of connection for mideaac:ac:ed1fc05010 at 192.168.1.130
2022-06-25 20:02:13.097 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Connection check OK for mideaac:ac:ed1fc05010 at 192.168.1.130
2022-06-25 20:02:13.098 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Requesting status update from mideaac:ac:ed1fc05010 at 192.168.1.130
2022-06-25 20:02:13.100 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Writing to mideaac:ac:ed1fc05010 at 192.168.1.130 bytes.length: 104, bytes: 5A5A011168002000000000000116051914020D00DA370000000B00000000000000000000000000006B000A76E27EED2C3647E57D8602DF8BCBF7768F08CFC4A915F6A95869572232C7E78B048CFC4AAC3AAAD750056BE1E836DF418B8FEACE3389F3A50DECB91E5E
2022-06-25 20:02:13.102 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response received length: 312
2022-06-25 20:02:13.103 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response bytes: 5A5A011168004400500100000000000000000000DA370000000B00000000000000000000030000001B058C7EB462369681A02F085B9079ADD4A866DDE9BA839255DDF6ADF37BE5C3A12E5DE16FA62124877968C7E03DC93AA5F154F5ECCF10F68AB3F4D406E150635A5A011168004000520100000000000000000000DA370000000B000000000000000000000100000006BC339B4B376DA0791C7FFB5A23B6AE4756883935D280DA8B29EE97B576776922E0046C11A737A417D6FFAEBC02F6B4CD1A3D0AEAD7AE4DDB0BF3AC57DDAE545A5A011168004000540100000000000000000000DA370000000B00000000000000000000010000001A504AE3D41487E0D4157A5E921D76EC4BDFB3E16E33D88768CC4C3D0658937D8BB1B887FC81BD411474A6E4FE23A2C570BB5F9D984D058481B7B10D2ABA2D1C
2022-06-25 20:02:13.105 [TRACE] [ler.MideaACHandler$ConnectionManager] - Bytes decoded and stripped without header: length: 242, data: A00E40667F7F000000000000001E00000000000000714B0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0193C5B7971ED236F890A0ADB742DB5851204A7D6EBE77FDAD2A53D2242B68081C15E7E08AA3173021626628769460BA70E1C7E00BD73E4EDA3BBE7098B5779D1B254B209B38367A18C5708A9ACA404414C149207A819C5FB519A22EE375B05FCEA1FE4DE42E98188E967EEAA4B818D7F1F03CAFCE0B5746BD1CDB478EF22E9F91CA0F970E473D879A61B939629248500B3B717CEF5481F9AFB6DC11184C7270AA2BAC00000000000304A300000000000000000000000000000000000000000000000000000000000000E29D
2022-06-25 20:02:13.106 [TRACE] [ng.mideaac.internal.handler.Response] - PowerState: false
2022-06-25 20:02:13.107 [TRACE] [ng.mideaac.internal.handler.Response] - ImodeResume: true
2022-06-25 20:02:13.108 [TRACE] [ng.mideaac.internal.handler.Response] - TimerMode: false
2022-06-25 20:02:13.109 [TRACE] [ng.mideaac.internal.handler.Response] - ApplianceError: false
2022-06-25 20:02:13.110 [TRACE] [ng.mideaac.internal.handler.Response] - TargetTemperature: 16.0
2022-06-25 20:02:13.111 [TRACE] [ng.mideaac.internal.handler.Response] - OperationalMode: COOL
2022-06-25 20:02:13.112 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed byte: 66
2022-06-25 20:02:13.113 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed byte masked: 66
2022-06-25 20:02:13.115 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed value: 102
2022-06-25 20:02:13.115 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed: AUTO
2022-06-25 20:02:13.116 [TRACE] [ng.mideaac.internal.handler.Response] - OnTimer: enabled: false
2022-06-25 20:02:13.117 [TRACE] [ng.mideaac.internal.handler.Response] - OffTimer: enabled: false
2022-06-25 20:02:13.117 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode byte: 00
2022-06-25 20:02:13.118 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode byte masked: 00
2022-06-25 20:02:13.119 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode value: 0
2022-06-25 20:02:13.119 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode: OFF
2022-06-25 20:02:13.120 [TRACE] [ng.mideaac.internal.handler.Response] - CozySleep: 0
2022-06-25 20:02:13.120 [TRACE] [ng.mideaac.internal.handler.Response] - Save: false
2022-06-25 20:02:13.121 [TRACE] [ng.mideaac.internal.handler.Response] - LowFrequencyFan: false
2022-06-25 20:02:13.121 [TRACE] [ng.mideaac.internal.handler.Response] - SuperFan: false
2022-06-25 20:02:13.122 [TRACE] [ng.mideaac.internal.handler.Response] - FeelOwn: false
2022-06-25 20:02:13.122 [TRACE] [ng.mideaac.internal.handler.Response] - ChildSleepMode: false
2022-06-25 20:02:13.123 [TRACE] [ng.mideaac.internal.handler.Response] - ExchangeAir: false
2022-06-25 20:02:13.123 [TRACE] [ng.mideaac.internal.handler.Response] - DryClean: false
2022-06-25 20:02:13.124 [TRACE] [ng.mideaac.internal.handler.Response] - AuxHeat: false
2022-06-25 20:02:13.124 [TRACE] [ng.mideaac.internal.handler.Response] - EcoMode: false
2022-06-25 20:02:13.125 [TRACE] [ng.mideaac.internal.handler.Response] - CleanUp: false
2022-06-25 20:02:13.125 [TRACE] [ng.mideaac.internal.handler.Response] - TempUnit: false
2022-06-25 20:02:13.126 [TRACE] [ng.mideaac.internal.handler.Response] - SleepFunction: false
2022-06-25 20:02:13.126 [TRACE] [ng.mideaac.internal.handler.Response] - TurboMode: false
2022-06-25 20:02:13.127 [TRACE] [ng.mideaac.internal.handler.Response] - CatchCold: false
2022-06-25 20:02:13.127 [TRACE] [ng.mideaac.internal.handler.Response] - NightLight: false
2022-06-25 20:02:13.128 [TRACE] [ng.mideaac.internal.handler.Response] - PeakElec: false
2022-06-25 20:02:13.129 [TRACE] [ng.mideaac.internal.handler.Response] - NaturalFan: false
2022-06-25 20:02:13.129 [TRACE] [ng.mideaac.internal.handler.Response] - IndoorTemperature: null
2022-06-25 20:02:13.130 [TRACE] [ng.mideaac.internal.handler.Response] - OutdoorTemperature: -25.0
2022-06-25 20:02:13.131 [TRACE] [ng.mideaac.internal.handler.Response] - Humidity: 30
2022-06-25 20:02:13.135 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed byte: 66
2022-06-25 20:02:13.138 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed byte masked: 66
2022-06-25 20:02:13.140 [TRACE] [ng.mideaac.internal.handler.Response] - FanSpeed value: 102
2022-06-25 20:02:13.141 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode byte: 00
2022-06-25 20:02:13.142 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode byte masked: 00
2022-06-25 20:02:13.143 [TRACE] [ng.mideaac.internal.handler.Response] - SwingMode value: 0
2022-06-25 20:02:13.148 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.core.library.types.QuantityType.<init>(QuantityType.java:168) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.processMessage(MideaACHandler.java:986) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.sendCommand(MideaACHandler.java:887) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.requestStatus(MideaACHandler.java:814) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.checkConnection(MideaACHandler.java:1061) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.lambda$0(MideaACHandler.java:622) ~[?:?]
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) [?:?]
Hi,
I have done with all the suggested steps.
- Removed all the things and tried to control them one by one, did not work.
- I went back OH 3.2, did not work
- Debug log did not show me any useful
It seems to me just like it would lose its registration with the cloud service and could not be able to renew/reconnect automatically. It always happens in between 15-45 mins. After disable/enable process, the specified device can be controlled again.
Do you have any further idea?
Thank You very much!
Hi,
I will defer to @JacekDob to see if he has any suggestions to offer from his side but for me without being able to reproduce the issue you are seeing and not having any of your logs to comb through for clues, I really do not have any other ideas to offer you at this point.
After retrieving Key+Token from cloud, binding is not using any cloud connection at all.
So what do you mean “it would lose its registration with the cloud service and could not be able to renew/reconnect automatically”?
Jacek