I've recently started to notice some of my midea units (I have four) not consistently adjusting based not he schedules I set. So, I took a look at the logs and, after they've been running flawlessly for months, all of a sudden they are throwing lots of errors. Any idea what could be causing this? My hub has also been unresponsive sometimes and I've had to reboot it. I'm also getting intermittent hub load notifications.
I got my new USB from Senville, MSmart saw it immediately, all connected fine.
However, when I run midea-discover, the Python script throws an exception when it hits the MiniSplit... If I give it an IP that's not the mini-split, it does not.
Any ideas how to get around this and get the ID, Token, Key?
Python exception:
NFO:msmart.cli:msmart version: 0.2.5 Currently only supports ac devices, only support MSmartHome and 美的美居 APP.
INFO:msmart.cloud:Using Midea cloud server: https://mp-prod.appsmb.com/mas/v5/app/proxy?alias= False
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.11/bin/midea-discover", line 8, in <module>
sys.exit(discover())
^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/click/core.py", line 1157, in __call__
return self.main(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/cli.py", line 51, in discover
found_devices = loop.run_until_complete(discovery.get_all() if ip == '' else discovery.get(ip))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/asyncio/base_events.py", line 650, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/scanner.py", line 193, in get_all
await self._process_tasks(tasks)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/scanner.py", line 199, in _process_tasks
[self.result.add(task.result()) for task in tasks]
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/scanner.py", line 199, in <listcomp>
[self.result.add(task.result()) for task in tasks]
^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/scanner.py", line 50, in support_test
_device = await self.support_testv3(account, password)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/scanner.py", line 65, in support_testv3
token, key = await loop.run_in_executor(None, gettoken, udpid, account, password)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/scanner.py", line 255, in gettoken
Client.login()
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/cloud.py", line 143, in login
self.get_login_id()
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/cloud.py", line 132, in get_login_id
response = self.api_request(
^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/cloud.py", line 121, in api_request
return self.api_request(endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/cloud.py", line 121, in api_request
return self.api_request(endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/msmart/cloud.py", line 123, in api_request
raise RecursionError()
RecursionError```
This error has been popping up for a lot of people, and it looks like a bug with the discovery utility. One possible workaround is discussed here: Midea Mini Split Wifi Support - #172 by LukeJWalker
Thank you... The MSmart uninstall/reinstall worked like a charm. I got the token, key, etc.
EDIT: I thought I had an issue as I could read the token,key,etc. but the Hubitat Driver would timeout... It was a Unifi Firewall rule that clamps down the IoT network. Allowed the midea packets to Hubitat and it worked.
@tomw : Really dumb question: How do tell if the Midea AC Controller is on or off in a rule?
I looked at Thermostat > Thermostat State and see several states, except off.
I then look at Custom Attribute >ThermostatOperatingState, and too do not see off as option.
However, when I look at the device, I see under current states "themostatOperatingState: off".
The only RM5 thing I see that gets close is Thermostat Mode, which has an "off" choice, but it never evaluates to off regardless if the AC is running or not.
I appreciate the help / I know I am missing something really small.
I too have unifi Wi-Fi. Can you give any details on how you resolved the issue? I have my Hubitat hub on the same network as the Midea units.
I have anything that doesn't need to access personal data off on seperated VLANs, home automation being just one. Then, for stuff like this Midea unit, our induction cooktop, Amazon, etc. I such devices again from the home automation network, so they can only respond to something initiated from Hubitat, etc. I didn't want someone to reachout from something like the Midea device, get into some automation hub, lock our doors, turning everything on, risking fire with the fireplace, cooktop, etc.
As a test with the Midea stuff when it would connect but give lots of timeouts, I placed it in the same VLAN as Hubitat to see if I could get it to work... It did. Also, I looked back through the logs just now and see no timeouts since I made the change... Not a one for days.
I have it on my to-do list to put it back in segregated VLAN away from Hubitat and other home automation hubs (Lutron, Phillips), and play with the rules until it works like it did in the same VLAN. If the change is allowing the Midea to initiate connections, I will seriously consider plugging in the Alexa USB, put it in the fully-untrusted VLAN, and not use Hubitat integration.
BTW, how do you tell in a rule if the unit is off (more details in my previous post)? I feel I am missing something really simple.
If you have UniFi OS 3.1.xx and Network 7.4.xx try out "traffic Management" instead of "firewall & security" It's much easier to deal with and understand.
I read through the thread and an unclear of the work-around to tell if the unit is on or off. Could you tell me what is working for you -- namely, how to tell in a Rule if the Midea unit is actually on or off?
I saw the discussion of "thermostatOperatingState" showing either on/off on the device, but that's not supported by the rule machine. Another said to use the RM5 ThermostatMode; however, it returns whatever was last used -- and not if the unit is on or off.
Thanks,
Marty
Same here. I've changed line 575 in the driver to:
events += [name: "thermostatMode", value: resp.power_state == "off" ? "off" : translateMode(resp.operational_mode?.toInteger(), "integer")]
I'll post back after I've tested this for a while.
Line 576 is incorrect I believe, as "on" and "off" are not permissible values for thermostatOperatingState as listed here: Driver Capability List | Hubitat Documentation
@tomw Any thoughts on this?
Hello,
I hope that you will be able to help me as I have no idea what Im doing wrong. I have air-conditioner Rotenso Teta - my understanding is that the solution will be work also for this vendor, is that correct? Going further I have installed midea-discovery tool + required packages on my pi. The problem is that when I issue midea-discovery command Im getting error :
Im not sure if this is because of rotenso which is not supported or due to the fact that that the device is not added to SmartHome application even I read that this is not necessary.
The device has static Ip address assigned.
I also checked Midea Platform plugin from Homebridge - 0 devices found
Any suggestion are more than helpful. @tomw ?
Thank you
Hi all! I'm trying to tell the Midea to "check if temp > 77. If so, and if Midea mode is cool, then activate turbo."
A: will this rule work do you think?
and
B: Is there a way I can check if turbo is not active? It seems to be a "condition" and not a poll-able state, however, if you go to Lanai A/C (my midea device), the refresh button brings up a Turbo Mode status of on or off. So where - in rule machine - would this be?
Also, I don't see a way to poll temp of Midea device. It's not listed when you choose devices for "temperature". So I am using another (ecobee) device in the room.
Thanks!
@tomw Any thoughts on this? Thx
Well finally got my US-OSK103 key from eBay and installed it on my Senville Aura mini-split that I installed a few months ago. Installed the Senville app and all went perfectly.
Did not feel like getting one my Pies out of the PiePile, so decided to go with a Windows Python install and was fast regretting it after installing the msmart package that is referenced in the first posts. Kept getting a bunch of errors RecursionError message.
After a quick search on the internet, found a discussion on github about this error and a link about a new version of the discovery tool here...
Found that someone else mentioned this new tool when I posted the link, but this should be changed somewhere more easily found, with this new package installed, everything was done in a few minutes. Now I have all the numbers needed to get this thing working.
Plugged all the numbers in the driver by @tomw and everything populated as soon as I saved the settings. Just wanted to thank you Tom for this great driver but please change your link for the discovery tool in the firsts posts and maybe even add it in the driver so we have a direct link to it for future installs
PS I did use Powershell in admin mode just in case with the old and new discovery tool, so not sure it this is necessary as the old discovery tool was giving me the same errors in the regular command prompt window?
Whe I use midea-discover I'm getting this:
INFO:msmart.cli:*** Found a device: {'name': 'net_ac_E833', 'ssid': 'net_ac_E833', 'ip': '192.168.xx.xx', 'port': 6444, 'id': 3xxxxxxx7, 'version': 3, 'token': None, 'key': None, 'type': 'ac', 'sn': '000xxxxxxxxxxxxxxx0000', 'model': '00Q1A', 'support': False, 'run_test': True}
So I get the ID, but no token and no Key.
Also I had to modify the python code in msmart to skip cloud authentication.
If I'm to authenticate, I couldn't find how to pass username and password in any of the instructions.
I just can not get the discover command to work... I just get the Command/object not found response.
Durrng install of msmart (or msmart -ng) I get a warning of :
"Defaulting to user installation because normal site-packages is not writeable"
WARNING: Ignoring invalid distribution ~smart (Location path)
I have been trying to on and off for months to get my OSK102 mini-split Wifi devices to work with HE.
When I run media-discover with these parameters:
midea-discover -a /Nethome Plus account email/ -p /Nethome Plus account password/ -i 192.168.86.39
The device is found and I get a reply but no token or key (same as @elfege on Oct 21)
The full reply is:
INFO:msmart.cli:msmart version: 0.2.5 Currently only supports ac devices, only support MSmartHome and 美的美居 APP.
INFO:msmart.cli:*** Found a device: ←[94m←[1m{'name': 'net_ac_D097', 'ssid': 'net_ac_D097', 'ip': '192.168.86.39', 'port': 6444, 'id': 12094627963354, 'version': 2, 'token': N
one, 'key': None, 'type': 'ac', 'sn': '000P0000000Q1BC0F2BABD0970000', 'model': '00Q1B', 'support': True, 'run_test': True} ←[0m
Also, regardless of what Nethome Plus account credentials I enter (bogus or correct) I get the same reply from midea-discover.
I did not see a reply for @elfege similar problem. Can anyone help with this issue.
Also some basic questions about token and key. Where are they generated, is it the WiFi device or is it the back end at Nethome Plus or somewhere else. If they come from Nethome Plus then it looks like media-discover is not connecting with my account since I get the same results regardless of the values I enter for my Nethome Plus credentials.
Any help is greatly appreciated.
I was having the same problems with the first link in this thread about the discovery tool, but after some searching I found a newer version that worked right away. Check out this post from me a few messages up
@nclark thank you for your reply. I tried the new msmart-ng discover utility and it certainly worked more easily and reliably. I get the results below which still shows None for the token and key
However on reading the information from the msmart-ng link it shows a reply where token and key are None and also where token and key are populated . There is also the comment Save the device ID, IP address, and port. Version 3 devices will also require the
token
and key
fields to control the device. which implies that the token and key are Wifi device version dependent. Since my devices are OSK102 it looks like they do not provide tokens and keys so it looks like the previous midea-discover tool was working correctly albeit more cumbersome to use.However the HE custom Midea AC local controller driver requires a token and key. I tried modifying the driver code to make token and key optional but then the driver broke at parts of the code where token and key were expected.
So I have ordered a new OSK105 device and hopefully that will provied a token and key that I can fill into the HE device preferences.
I will update this issue after I get the new WiFi device.
Thanks again.
Sorry to hear that, since I never used a 102 version I really can't give you any help on your assumptions about it. Maybe someone else with the 102 can chime in ?
Good luck!