Which mini split do you have? If it's Senville and your system said "work with Alexa" then your osk102 is not compatible with Midia Discovery.
You can contact Senville and swap the wifi stick.
I did the swap with no charge but at the end I went and build the ESP32 stick instead.
More info about the ESP32 stick? What driver do you use for this? I'm planning on buying 2 more Senville mini splits and I'm looking for alternatives to the OSK sticks. I did see the ESPHome sticks but could only determine that this worked with HA only.
Yeah, I am using them in HA.
1 Like
@nclark , just an update on my issue with msmart_ng returning None for token and key.
I received my OSK105 today and it does indeed return a valid token and key - see below:
Entering the token and key into the HE Midea AC local controller device preferences works and HE can now control one of my Cooper and Hunter mini-split AC/Heating devices. Now to buy OSK105s for my other for mini-splits.
At last!
2 Likes
Glad it works!
Apparently the msmart utility does not like the USB Wifi controller from SMARTLIGHT SLWF-01pro (v.2.1). I borrowed a friend of mines Wifi USB since we have the same model and I was able to get it working.
I did find something interesting though setting this up that may be of help if someone comes across an issues with the controller not responding in Hubitat. After setting a static IP address to the Wifi USB dongle and reconnecting under that static IP, when I ran the msmart utility again I noticed that key and token values were changed. I used those new values and everything is working.
1 Like
Did the the temp numbers for F° ever get fixed to get rid of the decimal points?
Also, while I can turn the unit on and off, I'm having a hard time getting the temp settings to work from Hubitat. Even though I set 75.5 on Hubitat, I don't see the temp change on the display of the unit.
Add me the requested feature group for adjusting the thermostat drivers to account for ThermostatOperatingState..
ThermostatMode doesn't really account for the operating state of the unit. It shows the mode "cool" even if the operating state shows "off". I'm playing around using attributes to work around some of my rules to get the AC to work the way I want to. Problem is that I can't even select the ThermostatOperatingState as "off" since it doesn't exist. My only option is to use NOT and one of the states.
This is a garage AC and I'd like it to turn off if any garage door opens and then resume if the unit was running at the trigger of the rule. I'm using a variable to set the operating state at the start of the rule so it knows whether to turn on the AC when the garage doors close.
This support thread appears to be dead and there's alot of issues I can't seem to figure out. Rules aren't running even though they should.
Here's an interestimg issue. The Dashboard tile for the AC will show an ON status even though under the device it shows it's not. This could be the cause of why the rules aren't running.
At this point I am going to have to give up any expectation that I can create rules based on conditions and just relegate this to time control via the app and maybe on and off via Hubitat.
The person that wrote the driver has been MIA since september, people that use it and have had the same problem might be able to help if you are patient, not many users of this driver on here. You also have to understand that the driver is WiFi and uses polling to keep up with what the A/C is doing, the polling is set in the driver preferences and is by default at 60 seconds. So sometimes, it will not be exact and that is just the nature of it.
Also the modes are well indicated and if RM does not show them all, it's might be a bug in RM more than this driver. Might want to post something in the RM section of the community board for help on that.
I can't say that I have had any problems with this driver for what I do with it, it was complicated to get it to work but I finally got it and I'm happy that I can remotely control it because mine is in a garden house on the property that is used for visit.
Sorry I can't help more than this, maybe someone else will chime in?
1 Like
Don't get me wrong, I am grateful that someone took the time to create a driver for Hubitat so we can control it locally. Just sharing my experience so that if anyone new joins they can have an idea what to expect, and those expectations shouldn't be high.
There is no issue with polling. If the AC has been off for hours, it should show that state. Technically it does, it's just not working on the Dashboard tile. When it is running, it just shows "Undefined".
Modes aren't an issue either. I can send the commands just fine. For rule purposes, I can't use mode as a means to set it's state. That falls under Thermostat state. If the AC is operating in Cool mode, it will stay in Cool mode when it's shutoff, but the state changes to off. But there's no off state to choose from when creating a conditional rule that should use it.
I was hoping to get this working on Hubitat so I can leverage other devices to automate mostly on conditions. For me, this is a Garage AC and the doors can open and close at anytime, the doors can remain open for a period of time as well. It would be nice to turn the AC on and off based on the garage door states. Or even a mundane task where it would start cooling when thermostat hits a certain temperature and will cool it down to another temp and then shut off and wait for that high set temp again. These are things I can't do with the Wifi app and was looking forward to getting working on Hubitat.
1 Like
Perhaps this will help you get started. I am primarily concerned with keeping humidity under control because I have a lot of pinball machines and electronics and other stuff in my garage. We live in S. Florida and the humidity can be brutal, especially in the summer.
This is the main rule that turns the unit on/off based on readings from a Sonoff temp/humidity sensor in the garage:
This rule detects any changes in the unit's settings, so if I adjust the temp or mode manually using the unit's remote control, the above rule leaves things alone:
This rule resets the GarageACManualOverride variable overnight, or when we leave the house:
And finally, this rule sets the Garage Is Open variable if either door is opened and stays that way for 5 minutes. This causes the primary rule to shut the unit off while the doors are open, except for short openings.
There may be more elegant ways of doing all this, but it works so I don't mess with it.
1 Like
This sounds like a great solution to my problem. However; I do not understand what to do beyond loading the software using HPM. Firstly, if this is not the place to be asking this question, please direct me where I should go. Nothing on the GitHub page was clear to me. How do you tell the driver how to connect to the Midea Minisplit? If the device software is supposed to "discover" the minisplit units, it didn't happen for me, and I don't see any way to initiate that discovery. I see no place to enter an IP address or anything else. Do you have to edit the code? Any help would be greatly appreciated.
I'm using a wifi adapter for the Mini Split, but if yours came with one, you should be set in that front. I'm not sure on this step, but I downloaded the Midea Air app and set up an account along with connecting my mini split. Once that was done you need to get python 3. Best way is to run it on a Linux system if you can. Windows can work, but you need to run everything from inside the python directory, so in the command line you need to "cd" into the local path of python where you can install and run msmart.
The script I used is msmart-ng. The original script may work but it hasn't had any support for a long time and this is an updated fork.
You run the commands:
pip install msmart-ng
msmart-ng discover
It'll scan your network and should find an IP address that belongs to the Mini Split. It'll display the ID, token and key which is what you need. Copy and paste in notepad for easier transfer to Hubitat.
$ msmart-ng discover
INFO:msmart.cli:Discovering all devices on local network.
...
INFO:msmart.cli:Found 2 devices.
INFO:msmart.cli:Found device:
{'ip': '10.100.1.140', 'port': 6444, 'id': 15393162840672, 'online': True, 'supported': True, 'type': <DeviceType.AIR_CONDITIONER: 172>, 'name': 'net_ac_F7B4', 'sn': '000000P0000000Q1F0C9D153F7B40000', 'key': None, 'token': None}
INFO:msmart.cli:Found device:
{'ip': '10.100.1.239', 'port': 6444, 'id': 147334558165565, 'online': True, 'supported': True, 'type': <DeviceType.AIR_CONDITIONER: 172>, 'name': 'net_ac_63BA', 'sn': '000000P0000000Q1B88C29C963BA0000', 'key': '3a13f53f335042f9ae5fd266a6bd779459ed7ee7e09842f1a0e03c024890fc96', 'token': '56a72747cef14d55e17e69b46cd98deae80607e318a7b55cb86bb98974501034c657e39e4a4032e3c8cc9a3cab00fd3ec0bab4a816a57f68b8038977406b7431'}
In Hubitat, you need to install the Midea controller /driver from Hubitat Package Manager.
Then you need to add a virtual thermostat using the Midea controller driver. Just search midea on the list to find and click on it.
And in Device preferences you enter the info you got back from the msmart-ng script. What I blacked out is what you need to plug in.
That should be it. I would make your mini split IP static (where your router doesn't change it) to keep those settings from ever changing.
1 Like
Thanks for this complete rundown. I see that your discover command resolves two devices. One that has a key & token and one that does not.
I just installed a Midea-alike branded as a Blue Ridge 922BMY which included a US-OSK105 USB bridge to install. I've tried setting it up through the Nethome Plus App and also through the Midea Air App. Both succesful, but when I run msmart-ng discover I see the same results:
(msmart) stack / # msmart-ng discover
INFO:msmart.cli:Discovering all devices on local network.
INFO:msmart.cloud:Using Midea cloud server: https://mp-prod.appsmb.com (China: False).
ERROR:msmart.discover:Code: 3004, Message: value is illegal.
ERROR:msmart.discover:Code: 3004, Message: value is illegal.
INFO:msmart.cli:Found 1 devices.
INFO:msmart.cli:Found device:
{'ip': '192.168.42.3', 'port': 6444, 'id': 151732605913332, 'online': False, 'supported': False, 'type': <DeviceType.AIR_CONDITIONER: 172>, 'name': 'net_ac_5E0C', 'sn': '000000P0000000Q1D8341C0E5E0C0000', 'key': None, 'token': None}
Any thoughts on what to try next to obtain or capture that key/token pair? Maybe I need a different bridge device, or is there some reason the connected mini-split can't be controlled?
Any thoughts or suggests you have would be appreciated!
That error should be resolved if you're using msmart-ng.
My example with two devices was just taken from the github page to show what it should look like.
I'm not versed with what the error codes are and how to fix them but judging from your output, they're seems to be no communication with the Midea api site. You may have some blocking going on preventing it from communicating. Or you're AC isn't connected to the API. The command seems to be working picking up the device itself on your network, token and ID come from the remote API.
I'll chime back in if I find or think of anything else.
Seems like its a problem with msmart-ng and changes to the Midea API. There is a fork that solved this problem for others, but it's recently also broken. I've joined an issue thread at GitHub for the fork and hopefully that developer will be able to resolve.
I'll post back here if I get it going!
1 Like
And just like that, it is fixed:
(msmart) stack /home/dan # msmart-ng discover
INFO:msmart.cli:Discovering all devices on local network.
INFO:msmart.lan:Creating new connection to 192.168.42.10:6444.
INFO:msmart.lan:Authenticating with 192.168.42.10:6444.
INFO:msmart.lan:Authenticating with 192.168.42.10:6444.
INFO:msmart.lan:Authentication with 192.168.42.10:6444 successful. Expiration: 2025-03-25T03:36:30+00:00, Local key: a42edaa0c8950611dce70ffbc216b83f6feae6bf6abf86a0d3fdb40da668c24c
INFO:msmart.cli:Found 1 devices.
INFO:msmart.cli:Found device:
{'ip': '192.168.42.10', 'port': 6444, 'id': 151732605913332, 'online': True, 'supported': True, 'type': <DeviceType.AIR_CONDITIONER: 172>, 'name': 'net_ac_5E0C', 'sn': '000000P0000000Q1D8341C0E5E0C0000', 'key': '**REDACTED BY dewhite04**', 'token': '**REDACTED by dewhite04**'}
Glad you got it working. Probably a temporary communication issue that caused the issue.
