New OH3 Binding - Midea Air Conditioning (LAN)

Add-ons Bindings
167

is there any fix to get this binding working with OH4 ?

2023-02-24 14:24:04.490 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Midea.items'
2023-02-24 14:24:43.624 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:mideaac__192_168_1_52__16492674433370__net_ac_c018' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING
2023-02-24 14:24:43.638 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:mideaac__192_168_1_52__16492674433370__net_ac_c018' changed from INITIALIZING to UNKNOWN
2023-02-24 14:24:43.744 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:mideaac__192_168_1_52__16492674433370__net_ac_c018 at 192.168.1.52
2023-02-24 14:24:43.745 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:mideaac__192_168_1_52__16492674433370__net_ac_c018' changed from UNKNOWN to ONLINE
2023-02-24 14:24:46.086 [ERROR] [mideaac.internal.handler.CommandBase] - SSWING id 0
2023-02-24 14:24:46.088 [ERROR] [mideaac.internal.handler.CommandBase] - SSWING id 0
2023-02-24 14:24:46.089 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.mideaac.internal.handler.MideaACHandler@29d34959': 'void org.openhab.core.library.types.DecimalType.<init>(long)'
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.processMessage(MideaACHandler.java:1024) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.sendCommand(MideaACHandler.java:943) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.sendCommandAndMonitor(MideaACHandler.java:871) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.requestStatus(MideaACHandler.java:863) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.connect(MideaACHandler.java:729) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler.initialize(MideaACHandler.java:514) ~[?:?]
2023-02-24 14:24:46.091 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:mideaac__192_168_1_52__16492674433370__net_ac_c018' changed from ONLINE to UNINITIALIZED (HANDLER_INITIALIZING_ERROR): 'void org.openhab.core.library.types.DecimalType.<init>(long)'
2023-02-24 14:24:46.091 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'mideaac:ac:mideaac__192_168_1_52__16492674433370__net_ac_c018': 'void org.openhab.core.library.types.DecimalType.<init>(long)'
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.processMessage(MideaACHandler.java:1024) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.sendCommand(MideaACHandler.java:943) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.sendCommandAndMonitor(MideaACHandler.java:871) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.requestStatus(MideaACHandler.java:863) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.connect(MideaACHandler.java:729) ~[?:?]
	at org.openhab.binding.mideaac.internal.handler.MideaACHandler.initialize(MideaACHandler.java:514) ~[?:?]

Status:
UNINITIALIZED
HANDLER_INITIALIZING_ERROR
‘void org.openhab.core.library.types.DecimalType.(long)’

thanks
Thomas

1 Like
168

This is awesome. Installed version 3.4.1 from borazslo. This one works much quicker. Power on/off trigger immediately. 3.3.0 did not work everytime.

Were you able to fix that data length issue

ler.MideaACHandler$ConnectionManager] - Response data is 21 long instead of 25!

I am on openhab 3.4.1

Keep up the good work

170

Your binding works well, sometimes it doesn’t respond the first time something is pressed in the BasicUI, but a second time it usually will, though I do get a heap of the response data errors.

2023-04-29 16:09:32.609 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 26 long instead of 25!
2023-04-29 16:10:03.064 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 35 long instead of 25!
2023-04-29 16:10:03.065 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 35 long instead of 25!
2023-04-29 16:11:02.084 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 26 long instead of 25!
2023-04-29 16:11:32.085 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 26 long instead of 25!
2023-04-29 16:11:52.445 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 35 long instead of 25!
2023-04-29 16:11:52.447 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 35 long instead of 25!
2023-04-29 16:12:36.763 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 26 long instead of 25!
2023-04-29 16:13:07.193 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 26 long instead of 25!
2023-04-29 16:13:07.195 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 35 long instead of 25!
2023-04-29 16:13:07.196 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 35 long instead of 25!
2023-04-29 16:13:50.888 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 26 long instead of 25!

I’ve set the log level for it now to “Fatal” to stop my logs from filling up with them, although I did generate a Trace log that I can send to you if you’d like if it would help to debug what’s causing it.

Thanks!

171

What. does it take to make the swing function work in V3?

I am also a developer, would be willing to help!

172

Hi,
First and foremost Welcome to the community!
As for swing mode in V3 mostly new firmware from the manufacturer only thing it seems can solution that. The swing mode in V3 does not return any values either from this binding or from the website app V2 versions all work fine for swing mode. Also the binding still has some quirks in it that appear when you have a mixed combination of V2 devices and V3 devices. additionally, the binding is not correctly handling all of the response values and not all of the functionality has been coded for many features are still in need of defining.

This binding is still in what could be best defined a R&D or alpha version.
It will also need to be recompiled to support Openhab 4.0 versions.
A few folks @zdanhauser made some progress at fixing @JacekDob original code but only with some partial success.
Feel free to pull down anyone’s version all are up on github and take a swing at it . This entire conversation chain has all the details and links that point back to the original python code the binding was based off.
I also hacked a version to work with OpenHab 4.0 and changed some logging and error handling to address the Response data length 21 issue but that was not a real fix just a noise reducer. not a good build that was worthy of public release.
I will be more then happy to help test any version you create I have both V2 and V3 devices that I can run any tests you need on.

173

Thanks for your message!

I will try to have a look. I have access to multiple V3 devices.

The AC is branded as Mundo Clima, the WiFi access stick is using the Nethome Plus cloud.

I absolutely hate cloud devices, but I could not find a compatible remote access method to the AC without cloud.
Same for the blinds, but that is a different topic.

I really don’t get why so many manufacturers want to force people into their own cloud and do not offer a local solution.

Therefore I am very eager to make this work.
Unfortunately I am very new to OpenHab and I only have access to the devices until the end of this week.
In October again.

It is unlikely, that I will be able o make this work. I guess you put in loads of hours into this binding.
If anyone wants to test something on a V3 device, I can help you with that!

174

I was able to connect to the AC. I also integrated the very nice widget from @zdanhauser Thank you so much for the code!

Regarding the binding itself… it is very unstable. Properties are not updated reliably. Switch it on or off sometimes needs multiple switches. Setting the temperature is a gamble. It jumps randomly between the desired and some old value.

Same vor the operation mode or any other setting.

Do you experience the same issues or is this special to my model? Or maybe I did something wrong in my setup

Any feedback is very much appreciated. Thanks a lot!

175

Hi there. I have no idea which version of code runs at you but mine works fine.since last summer. However sometimes happened these mentioened behaviour.but these are very rare. Also you can play with polling time settings. Try this one. It works and handles seven devices. HSFW Cloud Server

176

Hi,

I just received my MIDEA 26 silent pro WF and am palying around with the binding.
I found Releases · JacekDob/openhab-addons · GitHub and installed the current(?) version snapshot org.openhab.binding.mideaac-3.3.0-SNAPSHOT.jar under usr/share/openhab/addons on my raspberry pi3
(user& owner openhabian openhab)
and assigned it a static IP adress.

as a cloud provider I selcted MSmartHome, where I migrated to, after the ac wanted me to install midea air and added my email and password accordingly.
now I am stuck with an unknown status for the configuration :-/

I am also using openhab for the third day, only … :smiley:

177

Hi,

I try to connect a Senville SENL/24CD mini split in my existing OH 3.4.4 system. The unit should be a re-branded “Midea” device (like many of the budged mini split systems). It comes with a Alexa WiFi stick which is specially designed to use with Amazon Alexa integration (it’s documented, that this WiFi stick does NOT work with their Senville smartphone app but only with Alexa integration! They offer a different App WiFi stick which works ONLY with their Senville App but NOT with Alexa!). I don’t really understand why they are doing it.

I’m bit lost about how everything is related. I think, even the unit is build by Midea, it does not use in any way the Midea cloud (MSmartHome). To connect the unit with Amazon (Alexa) it was not required by me to create first a Senville cloud account nor a Senville login, etc.
I just needed to install the Amazon Alexa Device “Air Conditioner” and choose the brand Senville and it automatically discovered and setup the unit. Now the mini split is connected to my local WiFi router (with a fixed IP address) and I can use the mini split with the Alexa App. So far so good, but my target is to integrate it to OH.

Unfortunately, the OH amazonechocontrol binding does currently not support some of the required Amazon SmartHomeDevice API’s which my mini split unit uses (e.g. the APi’s Alexa.ModeController, Alexa.RangeController, Alexa.ToggleController, etc. are missing). ModeController is required for fan and operation mode, RangeController is required to set the temperature and show the current temperature and ToggleController is required for auto-louver-moving.

So a forum member gave me the hint to try this Midea binding. But I’m not able to get a connection - I think I still don’t understand how the discovery and initial connect should be established.

  • I’ve installed the binding in the latest version 3.3.0_202205312143 and activated TRACE logging.
  • The mini split is connected to my local WiFi router and Alexa App can control the unit.
  • If I do just a “scan” in the MideaAC binding in OH, no device was found. This is the logging result:
2023-08-02 18:45:44.900 [DEBUG] [al.discovery.MideaACDiscoveryService] - Stop scan for Midea AC devices.
2023-08-02 18:45:44.900 [DEBUG] [al.discovery.MideaACDiscoveryService] - Start scan for Midea AC devices.
2023-08-02 18:45:44.900 [TRACE] [al.discovery.MideaACDiscoveryService] - Discovering: 255.255.255.255
2023-08-02 18:45:44.901 [TRACE] [al.discovery.MideaACDiscoveryService] - Broadcast discovery package sent to port: 6445
2023-08-02 18:45:44.901 [TRACE] [al.discovery.MideaACDiscoveryService] - Broadcast discovery package sent to port: 20086
2023-08-02 18:45:49.900 [DEBUG] [al.discovery.MideaACDiscoveryService] - Stop scan for Midea AC devices.
  • When I try to add the Thing manually, I’ve entered the IP address of the mini split and left the port at 6444 and the deviceID at 0 (there is a hint: Leave 0 to do ID discovery).
  • But this does not work and the logging shows:
2023-08-02 18:49:08.863 [DEBUG] [eaac.internal.handler.MideaACHandler] - MideaACHandler config for mideaac:ac:d58490a357 is org.openhab.binding.mideaac.internal.MideaACConfiguration@6d868535
2023-08-02 18:49:08.863 [WARN ] [eaac.internal.handler.MideaACHandler] - Configuration invalid for mideaac:ac:d58490a357
2023-08-02 18:49:08.863 [WARN ] [eaac.internal.handler.MideaACHandler] - Discovery needed, discovering....
2023-08-02 18:49:08.863 [TRACE] [al.discovery.MideaACDiscoveryService] - Discovering: 192.168.99.46
2023-08-02 18:49:08.864 [TRACE] [al.discovery.MideaACDiscoveryService] - Broadcast discovery package sent to port: 6445
2023-08-02 18:49:08.864 [TRACE] [al.discovery.MideaACDiscoveryService] - Broadcast discovery package sent to port: 20086
2023-08-02 18:49:13.864 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'mideaac:ac:d58490a357' takes more than 5000ms.
  • It shows that I have an invalid configuration.
  • I guess, I need at least the deviceId, token and the key.
  • But how can I get deviceId/token/key if I never logged into a cloud to get one?
  • How was Amazon/Alexa able to discover this device without providing this data?

I have a TRACE log from the Alexa amazonechocontrol binding with all the details when the mini split was discovered with Amazon. In these JSON log output I’m able to find a lot of different ID’s, keys etc. but I have no idea if I will be able to extract some of these data to use it in this binding. e.g I have the following data in the “wording” of Amazon/Alexa:

  • Device Serial Number
  • Device Software Version
  • Manufacturer Software Version
  • entityId in hex form like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  • lastSeenDiscoverySessionId in hex form like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  • deviceType: A1QSHH4MZ0WSN
  • applianceKey in hex form like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  • mergedApplianceIds in BASE64 form: AAA_SonarCloudService_xxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx_xxxxxxxxxxxxxxxxxxxxxxxxxxx

I’ve tried to used parts of these numbers as deviceId/tokens/keys in this OH binding, but without success.

I’ve tried a port scan (TCP and UDP) to the IP address where the mini split is connected in my local WiFi. But no open ports are showing (even not 6444 or 6445).

So my questions are:

  • Is it possible to extract the required thing configurations for this binding out of an existing and working Amazon/Alexa connection.
  • If not, how may I get these data?
  • Maybe it’s not possible at all to get my mini split connected with this binding?

Thanks in advance,
Frank

178

Hi,
This openhab binding is based off a python script that was converted to java. Way up in the posts there are a few links to the original python scripts and also few spin off versions. If your device works with them it will most likely work with this binding. All of these approaches expect the OSK 102 or OSK103 dongle (which I checked your manufacturer does have a version but is pricey) I have seen on amazon the nethomeplus version of that dongle for much less ~20 bucks versus your vendor version at around 80 bucks. only other requirement this current version of binding has is you must having paired your a/c with one of the 3 mentioned apps in the binding drop down (nethome plus or original midea app or the new version of the midea app) if any of these 3 online apps was used to set up your unit and if your dongle was a Version 3 it also generated a token and key combo the binding should work. Version 2 dongles do not need the Token and Key just ip address and port (usually 6444). If you can add your device into the nethomeplus app and communicate with it via that app then it likely will work with this binding. For Version 3 once you have retrieved the token and key generated from the any of the 3 mentioned cloud apps communication pairing with the device it (the binding) no longer needs to see the app or connect to the internet.

179

Hi,

thanks a lot, great information!

When you mention version 2, it’s related to OSK102 and version 3 to OSK103 - right? So does this mean, that with an OSK102 it is not required to have a token and a key and I can just use the binding without using one of the 3 methods to retrieve token and key (if it’s already connected to my local WiFi router - which usually must be configured by an app anyway via AP WiFi mode)?

I’ve tried to find your mentioned $20 offer from Amazon (US) but I had no luck. The only offer for OSK102 is around $65 and one with the same price on ebay. I’ve not found any OSK103 offer on one of these platforms - but on the Pioneer HVAC online shop for around $33. Looks like the “old” OSK102 are about the double price compared to the “new” OSK103. Maybe you have a link or how I should search on Amazon to find this cheap offer (I’ve tried OSK102, OSK103 with and without WiFi, Midea, etc.)?

I definitely will try to go this way and want to replace my current Alexa-only WiFi stick with one of the OSK102/OSK103. It sounds a lot more open and more flexible with full OH binding support. Do you know if there may be functional differences between the OSK102/OSk103 (beside the token/key thing)? I’ve red something about that “louver” may not work - is this related if using OSK102 vs. OSK103?

Thanks for your help!

180

Most OSK102 are version 2. All version 2 do not use the encryption so no token and key required. Version 2 will let the louver work version 3 has issues with that. As for brand of dongle so far from what I have seen pretty much any of them will work for the A/C. As a example I have one dongle branded as Pioneer OSK105 it is Version 3 working fine in a Cooper Hunter split A/C. I have 2nd one OSK102 version 2 branded as NetHome working in a different cooper hunter A/C.
I have a 3rd one branded as Cooper Hunter and is Version 2 OSK102 . working in a 3rd split system.
I have a 4th one branded as a NetHome Plus OSK 103 version 3 and working fine on a 4 th Cooper Hunter split A/C.
As for what is on amazon it was past October is the last time I went hunting for one. OSK103 or higher all will be Version3 firmware and require token/key combo. OSK 102 will just need ip and port.
Also, as a note this binding is still very much in development. not all of the items it will display have actually been coded for functionality.
With regard to what you can do with Version 2 and a preconfigured A/C as well as the python script version 2 dongles worked just fine no additional effort needed.
At least for mine when I first used the earliest version of @JacekDob binding he did the awesome original convert from python to Java based on a version 2 unit he has I did not have to change anything.
I also still use original python scripts to talk to both my version 2 and version 3 units to handle some outside of openhab activities as a FYI and they work fine too.
This is a very long thread chain, but it has a huge amount of information if you are willing to read through it all including how to actually look at what the app is saying and how it is talking to your A/C using an android phone or even via an android emulator.

181

Hi All,

I am still here.

I am willing to do some update of binding, but help is so much appreciated, as I am owner of V2 Devices and for me is working so much fine.

The best option is to to do MergeRequest of your modification of my code, so I can provide upgraded binding.

BR

Jacek

182

Hi Justan,

thanks a lot for the details. I’ve just found an OSK102 stick from ecox and ordered 2 of them for $38 each and will give this binding a try. Looking forward to replace the current Alexa-only WiFi stick with this one! I rather like local communication with my OpenHAB devices instead of using cloud based connections.
Now I will dive into the thread from the beginning (as you recommended) to understand more in detail, how everything works!

Frank

183

Quick feedback and update:

Yesterday the OSK102 sticks from ecox arrived and I’ve installed one in my Senville (replaced the original Senville Alexa WiFi stick).

It works great!

After setting the Senville mini split to AP WiFi mode, the stick was found by the Senville mobile app to set the WiFi data (no cloud login required). This app was only required to do this initial WiFi setup.

Because the stick is version 2, I’ve added the thing manually in the OpenHAB UI by entering just the IP-Address (as @Justan wrote, no key and token required) and clicked the “create thing” button. Suddenly the thing has shown to be be online. 11 channels are available for the thing and I’ve done some very successful tests with the following small issues remaining (not a problem for me, but I want to share my findings):

  • swingMode (String) works, but the modes HORIZONTAL and VERTICAL seems to be swapped. My mini split is only able to swing horizontally but it only works if I choose VERTICAL via OH. If I choose HORIZONTAL, it will automatically select OFF.
  • tempUnit (Switch) behaves strange. It’s declared as an OH switch, but it does not stay on. If I switch it on, the temperature unit changes and stays until I change the targetTemperature. As soon as the targetTemperature is updated, the unit changes back. I don’t know how it should work?

One small problem is left which I would really hope to be able to solve:

Usually, I configure all my things and items via OH config files. To do this, I do one short test for every new binding via OH UI to temporary create the thing, check the configuration details, check the list of channels, create an temporary item, etc. When this works, I copy the data form the “Code” view in the UI and the possible channel ID’s and types and manually transfer the information to my thing and item files. Before writing the changes, I delete the temporary items and things which I’ve created via UI for testing. This always worked for me.

But for this mideaac binding, I was not able to create the thing in the thing-file and I can’t find the error (only the UI created thing/item works). I’ve activated TRACE log level for the binding and always get the following error:

...
2023-08-12 19:22:13.410 [DEBUG] [eaac.internal.handler.MideaACHandler] - MideaACHandler config for mideaac:ac:garage1 is org.openhab.binding.mideaac.internal.MideaACConfiguration@72061992
2023-08-12 19:22:13.411 [DEBUG] [eaac.internal.handler.MideaACHandler] - Configuration valid for mideaac:ac:garage1
2023-08-12 19:22:13.411 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.mideaac.internal.handler.MideaACHandler@619c8aa7': null
java.lang.NullPointerException: null
        at org.openhab.binding.mideaac.internal.handler.MideaACHandler.initialize(MideaACHandler.java:488) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor95.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        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) [?:?]
2023-08-12 19:22:13.413 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'mideaac:ac:garage1': null
java.lang.NullPointerException: null
        at org.openhab.binding.mideaac.internal.handler.MideaACHandler.initialize(MideaACHandler.java:488) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor95.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        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) [?:?]
2023-08-12 19:22:38.279 [DEBUG] [deaac.internal.MideaACHandlerFactory] - bundle org.openhab.binding.mideaac:3.3.0.202205311943 (313)[org.openhab.binding.mideaac.internal.MideaACHandlerFactory(373)] : Querying state active
2023-08-12 19:22:38.280 [DEBUG] [al.discovery.MideaACDiscoveryService] - bundle org.openhab.binding.mideaac:3.3.0.202205311943 (313)[org.openhab.binding.mideaac.internal.discovery.MideaACDiscoveryService(374)] : Querying state active
...

When creating the thing in the UI, I see the following working code:

UID: mideaac:ac:garage1
label: Senville mini split 1
thingTypeUID: mideaac:ac
configuration:
  cloud: ""
  password: ""
  ipPort: "6444"
  ipAddress: 192.168.xx.yy
  pollingTime: 10
  promptTone: false
  deviceId: "-129xxxxxxxxxxxx"
  email: ""
  key: ""
  timeout: 4
  token: ""

But when I try the following line in the OH thing file, it does not work and I see the above shown errors in the log:

Thing mideaac:ac:garage1 "Senville mini split 1" @ "rvgarage" [ deviceId="-129xxxxxxxxxxxx", ipAddress="192.168.xx.yy", ipPort="6444", pollingTime=10.0, cloud="", password="", promptTone=false, email="", key="", token="", timeout=4 ]

I’ve tried with only a few config parameters and also with setting all of them. I’ve tried some values as string or as number with or without quotes, I’ve tried to create the channels together with the thing and without, but I can’t get it to work with thing file configuration.

Unfortunately I was not able to find an example for how to create the mideaac thing via thing file.

I’m sure, I’m doing something wrong, but I can’t find the reason?

184

Hi @fmeili1 ,
Glad you were able to get a different dongle that allows Openhab to talk to your A/C.
As for the items you mentioned

The swing mode for my splits use vertical or both my louver goes up and down since it is a wall unit this behavior you are seeing may be different if you are using a floor mount or ceiling mount inside unit.

This item only changes the display on the front of the unit nothing else.
It is a momentary switch thus the reason it turns on and off. Each time it is toggled it changes the state to the opposite unit of measure type. C to F then next toggle F to C but ONLY for the front panel display.
The behavior of the display reverting back to metric each time a command is sent is a known nuisance. There is a long reason behind it but basically the A/C only really speaks metric so sending a new temp setting is actually passed in metric and when the unit responds back via API it is returning a metric value and the call to the display setting is reset to default metric value back so end result is it resets display back to Metric. The openhab regional settings actually drive the real conversion from metric to imperial (within OpenHab) based on what region you have set “unless you overrode them in for entire OpenHab system” Myself I handle this behavior with a simple rule that appends a toggle back to previous state each time I send a command.

This one is a bit different. I will let @JacekDob confirm how or even if he coded for manually defined things created via a config file.
I have not attempted that approach since using Openhab 2 version. As I understood it the desired path forward for OpenHab from 3.x version and above seems to be to move away from that flat file method of configuration to GUI based configuration approach. (Which is a very controversial topic you will see if you search the forum.)
I can tell you this what I seen in the past during testing is the auto discovered things behavior of the binding and respectively things it created do seem to work more reliably then when I have manually defined a thing via the GUI.

185

Are you also talking about upgrading to OH4? I would love to hear that…

186

This binding is a lot more reliable and provide more features compared to the Alexa binding! This was a really useful hint!

Sorry, I’ve mistaken horizontal and vertical louver modes (it’a bit confusing, the “left/right” swing is called horizontal and the “up/down” swing is called vertical - I’ve double checked in the manual). It’s a typical wall mount indoor unit with a manual “left/right” louver and a powered “up/down” louver. Everything works as expected.

Interesting behavior and background information! I think I’ll do the same as you and put that switch back in my rules as well. Until now I was not aware how profoundly a regional environment can influence the behavior of attachments.

I thought that a binding’s implementation is independent of how it is configured (via GUI or config file).

I’m a bit “old fashioned” and I like to have the whole configuration in plain files. My feeling it would be easier in case of a new setup (e.g. after a total crash). Also I see “everything” in the files and don’t need to remember which GUI options and elements I may have chosen while setting something (which maybe was years ago). But it’s just my feeling…

Thanks again for pointing me to this binding! I like it a lot!

187

Yes, I have plans to update to 4.x. But I want to wait until some of the known problems are solved (100% cpu and some other issues mentioned in the community). So I think I will wait about 2-3 month from now to do the 4.x update. I just hope, that the current mideaac binding (3.3.0.202205311943) will still work with the new version.

Maybe this binding will find it’s way in the future to be an official supported OH binding…

1 Like