Ok, thanks. I try figuring out what does “already connected” means in this particular case. @atyec89 got the same error. I’ll revert soon.
I thank you for your commitment
Background: Recently installed Cooper & Hunter split AC with the WiFi dongle. Searching internet found this (and many other split ACs) are manufactured by Gree or Midea. Did download WiFi app from Cooper & Hunter first (Apple Store) and worked. In email exchange with Cooper & Hunter about integrations, they suggested NetHome Plus as better able to integrate with Alexa, etc. This also works, but not with OH.
With OH, I tried using the Gree binding first with no success and then started searching the OH forum for Midea and found this thread and one other of interest. Used the Python program referenced in that thread and posted above (around 220 on Jan 7) successfully but could not see how to use the output in OH (see below). Then tried the latest binding in this thread (details below). Hopefully the observations will help with the binding development or with a first time user.
General observations: (note did not read through all the posts, so likely missed somethings.)
Python app
Used my WSL test environment to run the python program and get the TOKEN and KEY. Encountered some problems about the PATH$ but was able to resolve with MS Copilot.
midea-beautiful-air-cli discover --account ACCOUNT --password PASSWORD --address IP –credential
OUTPUT from App
id 000000P0000000Q1B88C295643BC0000/151732605161920
id = 151732605161920
addr = 192.168.0.246
s/n = 000000P0000000Q1B88C295643BC0000
model = Air conditioner
ssid = net_ac_43BC
online = True
name = AirCon_43BC
running = False
target = 18.0
indoor = 20.0
outdoor = 22.5
fan = 102
mode = 2
purify = False
eco = False
sleep = False
frost = False
comfort = False
F = True
error = 0
supports= {'eco': 1, 'heat_8': 1, 'mode': 1, 'fan_swing': 1, 'electricity': 1, 'filter_reminder': 0, 'strong_fan': 1}
version = 3
token = TOKEN
key = KEY
Also was able to use the set command the turn it on and change the setpoint.
midea-beautiful-air-cli set --ip 192.168.0.246 --token TOKEN --key KEY --running True
midea-beautiful-air-cli set --ip 192.168.0.246 --token TOKEN --key KEY --target-temperature 17.0
Midea Air Conditioning (LAN) binding
Added the last binding in this thread (post 255). Added the TOKEN and KEY from the Python app. Left the Cloud provider, email and password blank. Disabled the Reauthorization. Everything seemed to work initially.
I noticed a lot of event traffic on the developer tool bar so tried to change the polling time to 600 seconds. The next time I checked the device was UNKNOWN and I was concerned the TOKEN and KEY were the problem as possibly expired?. The log entries at the DEBUG level (with the bytes as BYTES).
2024-05-04 20:40:51.556 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Disconnecting from mideaac:ac:5fe6116d01 at 192.168.0.246
2024-05-04 20:40:51.566 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 1 time(s)
2024-05-04 20:40:51.567 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 2 time(s)
2024-05-04 20:40:51.568 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:5fe6116d01 at 192.168.0.246
2024-05-04 20:40:51.569 [DEBUG] [eaac.internal.handler.MideaACHandler] - Changing status of mideaac:ac:5fe6116d01 from UNKNOWN(NONE) to ONLINE
2024-05-04 20:40:51.570 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Device mideaac:ac:5fe6116d01@192.168.0.246 require authentication, going to authenticate
2024-05-04 20:40:51.574 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Device mideaac:ac:5fe6116d01@192.168.0.246 authenticating
2024-05-04 20:40:56.614 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response received length: 72
2024-05-04 20:40:56.616 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response bytes: BYTES
2024-05-04 20:40:56.619 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Authentication successufull
2024-05-04 20:40:57.621 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Writing to mideaac:ac:5fe6116d01 at 192.168.0.246 bytes.length: 104, bytes: BYTES
2024-05-04 20:41:02.624 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response received length: 150
2024-05-04 20:41:02.625 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response bytes: BYTES
2024-05-04 20:41:02.626 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Response length: 104
2024-05-04 20:41:02.654 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Starting connection monitor job in 10 seconds for mideaac:ac:5fe6116d01 at 192.168.0.246
2024-05-04 20:41:02.659 [DEBUG] [eaac.internal.handler.MideaACHandler] - MideaACHandler config for mideaac:ac:5fe6116d01 is org.openhab.binding.mideaac.internal.MideaACConfiguration@19d7e40
2024-05-04 20:41:02.662 [DEBUG] [eaac.internal.handler.MideaACHandler] - Configuration valid for mideaac:ac:5fe6116d01
2024-05-04 20:41:02.663 [DEBUG] [eaac.internal.handler.MideaACHandler] - IPAddress: 192.168.0.246
2024-05-04 20:41:02.665 [DEBUG] [eaac.internal.handler.MideaACHandler] - IPPort: 6444
2024-05-04 20:41:02.667 [DEBUG] [eaac.internal.handler.MideaACHandler] - ID: -129742371548736
2024-05-04 20:41:02.668 [DEBUG] [eaac.internal.handler.MideaACHandler] - Version: 3
2024-05-04 20:41:12.656 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Connection check OK for mideaac:ac:5fe6116d01 at 192.168.0.246
2024-05-04 20:41:12.658 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Requesting status update from mideaac:ac:5fe6116d01 at 192.168.0.246
2024-05-04 20:41:12.660 [DEBUG] [ler.MideaACHandler$ConnectionManager] - Writing to mideaac:ac:5fe6116d01 at 192.168.0.246 bytes.length: 104, bytes: BYTES
2024-05-04 20:41:12.662 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: Cannot read the array length because "bytes" is null
at org.openhab.binding.mideaac.internal.Utils.bytesToHex(Utils.java:23) ~[?:?]
at org.openhab.binding.mideaac.internal.security.Security.encode_8370(Security.java:231) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.sendCommand(MideaACHandler.java:1000) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.requestStatus(MideaACHandler.java:966) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.checkConnection(MideaACHandler.java:1262) ~[?:?]
at org.openhab.binding.mideaac.internal.handler.MideaACHandler$ConnectionManager.lambda$0(MideaACHandler.java:713) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
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:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
I had other things to do, so did not investigate further, but changed the polling time back to 10 seconds.
The next day, with an OH restarts (for other reasons) everything is ONLINE. Logs were at INFO level
2024-05-05 09:58:49.059 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 1 time(s)
2024-05-05 09:58:49.062 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 2 time(s)
2024-05-05 09:58:49.065 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:5fe6116d01 at 192.168.0.246
2024-05-05 09:58:53.923 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'mideaac:ac:5fe6116d01' takes more than 5000ms.
And today
2024-05-06 08:41:00.979 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 1 time(s)
2024-05-06 08:41:00.981 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 2 time(s)
2024-05-06 08:41:00.984 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:5fe6116d01 at 192.168.0.246
2024-05-06 08:41:06.003 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'mideaac:ac:5fe6116d01' takes more than 5000ms.
Again overall it is working for my Cooper & Hunter split AC, but my guess is there is some interaction I don’t yet understand between the polling frequency and the device becoming unknown. Also the WARN message from the good startups indicate it takes a while for the device to come online. I sometimes get that WARN message with other bindings during OH startups as a lot of action is occurring. This is running on an Rpi3b.
Java Error during new installation
- I have a fresh openhab 4.1.2 on debian 12.
- I have copied the org.openhab.binding.mideaac-4.1.0-SNAPSHOT.jar (from zdanhauser, Apr21) to /usr/share/openhab/addons/
- mideaac bindig has installed fine …
- msmart-ng works fine as well
But when I try to create a new thing (with IP, DevicID or 0, Token, Key ), the new thing remains “UNINITIALIZED” with HANDLER_REGISTERING_ERROR
16:56:35.081 [ERROR] [.core.thing.internal.ThingManagerImpl] - Exception occurred while calling thing handler factory 'org.openhab.binding.mideaac.internal.MideaACHandlerFactory@1e6365e7': MideaACHandlerFactory could not create a handler for the thing 'mideaac:ac:04a575ae60'.
java.lang.IllegalStateException: MideaACHandlerFactory could not create a handler for the thing 'mideaac:ac:04a575ae60'.
at org.openhab.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:131) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.doRegisterHandler(ThingManagerImpl.java:531) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.registerHandler(ThingManagerImpl.java:512) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.registerAndInitializeHandler(ThingManagerImpl.java:927) ~[?:?]
at org.openhab.core.thing.internal.ThingManagerImpl.setEnabled(ThingManagerImpl.java:1009) ~[?:?]
at org.openhab.core.io.rest.core.internal.thing.ThingResource.setEnabled(ThingResource.java:609) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.6.2]
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.6.2]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.6.2]
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.6.2]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.6.2]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.6.2]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:304) ~[bundleFile:3.6.2]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234) ~[bundleFile:3.6.2]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:520) ~[bundleFile:4.0.4]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:279) ~[bundleFile:3.6.2]
at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.52.v20230823]
at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:100) ~[bundleFile:?]
at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:320) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.52.v20230823]
at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.52.v20230823]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.52.v20230823]
at java.lang.Thread.run(Thread.java:840) [?:?]
16:56:35.085 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'mideaac:ac:04a575ae60' changed from UNINITIALIZED (HANDLER_REGISTERING_ERROR): MideaACHandlerFactory could not create a handler for the thing 'mideaac:ac:04a575ae60'. to UNINITIALIZED (HANDLER_MISSING_ERROR)
What am I missing? Thanks for your help!
Hello,
my config is OpenHab 4.1.2 on ubuntu 22.04. I tryed this binding, version 4.1.0.
I have two midea AC split. The older one use v2 protocol and seems it works with no issue.
The newest one use the v3 protocol. With this one I also have the OFFLINE/error, and the “Response data is not 25 long!” message.
Did I do something wrong?
I can change some values/config if it can help to find the cause.
Below some logs.
Thank you for your committment. It is a great work.
2024-05-21 17:15:17.073 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:15:34.074 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:15:51.075 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:16:08.563 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:16:25.563 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:16:42.564 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:16:59.564 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:17:17.946 [INFO ] [eaac.internal.handler.MideaACHandler] - Changing status of mideaac:ac:mideaac__192_168_1_125__18151693380281__net_ac_2c0a from ONLINE(NONE) to OFFLINE(COMMUNICATION_ERROR)
2024-05-21 17:17:45.197 [INFO ] [eaac.internal.handler.MideaACHandler] - Changing status of mideaac:ac:mideaac__192_168_1_125__18151693380281__net_ac_2c0a from OFFLINE(COMMUNICATION_ERROR) to OFFLINE(COMMUNICATION_ERROR)
2024-05-21 17:17:45.454 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 1 time(s)
2024-05-21 17:17:45.455 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 2 time(s)
2024-05-21 17:17:45.455 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:mideaac__192_168_1_125__18151693380281__net_ac_2c0a at 192.168.1.125
2024-05-21 17:18:00.455 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:18:18.209 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:18:35.210 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:18:52.960 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:19:11.537 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:19:28.537 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:19:46.123 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:20:03.123 [INFO ] [eaac.internal.handler.MideaACHandler] - Changing status of mideaac:ac:mideaac__192_168_1_125__18151693380281__net_ac_2c0a from ONLINE(NONE) to OFFLINE(COMMUNICATION_ERROR)
2024-05-21 17:20:31.562 [INFO ] [eaac.internal.handler.MideaACHandler] - Changing status of mideaac:ac:mideaac__192_168_1_125__18151693380281__net_ac_2c0a from OFFLINE(COMMUNICATION_ERROR) to OFFLINE(COMMUNICATION_ERROR)
2024-05-21 17:20:31.819 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 1 time(s)
2024-05-21 17:20:31.820 [INFO ] [ler.MideaACHandler$ConnectionManager] - Socket connection exception already connected. Try reconnection 2 time(s)
2024-05-21 17:20:31.820 [INFO ] [ler.MideaACHandler$ConnectionManager] - Connected to mideaac:ac:mideaac__192_168_1_125__18151693380281__net_ac_2c0a at 192.168.1.125
2024-05-21 17:20:46.820 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:21:03.821 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:21:20.822 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
2024-05-21 17:21:37.822 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is not 25 long!
Hi all
I don’t understand what midea air conditioner v2 and v3 mean?
Is MIDEA AURORA 3 MSAX-09N8D0-C Inverter supported?
V3 has encryption, V2 does not.
Yes, with my AC V3 I can also query/set the AC status with ‘midea-beautiful-air-cli’ using the TOKEN/KEY.
i have same problem, did you risolved it?
No, I’m sorry. I’m unable to control the AC split V3 with openhab at the moment.
Is this the latest version or is there a newer one than this?
I’ve been modifying the Midea binding code provided to me by @justaoldman for personal use. My original goal was to increase the polling frequency from 10 seconds. This was to reduce local Wi-Fi traffic and align with the OH default rrd4j persistence strategy. While testing locally and some testing also by @justaoldman and @Davide_Cencini differences in device responses and capabilities were uncovered. IMO that is going to make it difficult for one binding to cover all the bases for Midea (and Midea clones) split ACs. So, I’m going to offer up my beta version as an alternative to the one above. If your device is working fine on the @zdanhauser binding, great, no reason to change.
Besides the polling process, if supported by the device and the response bytes are in the expected order, the swing, sleep and turbo switches can be set. These all work for me on my recent V3 device (April 2024). The response byte restriction has been relaxed to greater than 21, instead of exactly 25 as this is one difference uncovered between devices. Data is only currently only read by the binding from the first 20 bytes anyway.
The current version is on my OH-addons fork as a release here. I have only tested on OH4.1 and OH4.2 milestones up to 3. Also have only used NetHome as a cloud provider to get key and token.
If starting from scratch, place the jar in the addons folder and skip to 5. If coming from another version, I’d advise the following 1) Unlink items from the Midea device(s) and delete the things 2) remove the other jar from the addons folder and stop OH 3) use the karaf openhab-cli clean-cache and place the new jar in the addons folder 4) restart OH (this could take longer than normal with the clean-cache) 5) Do an inbox scan with the Midea binding for devices. 6) After accepting go to the UI page and add your cloud provider information and save 7) Ideally the device should pull the key and token (V3) and come online. Then relink your items to the channels.
I’m not an expert either with Java or OH (OH is a retirement hobby), but I’ll try my best to address any issues. Hopefully I won’t regret this 
. Please provide a debug log using the OH forum code fences icon “</>” and an explanation of what was going on.
2 Likes
I have continued to update the MideaAC jar since the original post. The latest is today. This is a recap ;
Most of the effort has been behind the scenes to comply with the OH developer guidelines (to my level of understanding them). One thing of note for V3 owners, to remove the fixed references in the code to the MSmart app, your Cloud App needs to be noted. The email and password are still optional if you already have the token/key and do not plan on changing them. At this point the code looks pretty compliant, however, I haven’t submitted the PR.
As to content, in addition to the features above, I have the ECO mode and the ON OFF timers working (for me at least). I’m not sure what ECO does in COOL mode except set the FAN to AUTO and the temperature to 24 C, but the indoor AC evaporator LED flashes ECO, so that’s something .
One quirk to note is related to setting the temperature. Because it takes about 2 seconds for a command to be processed, if changing more than one degree it is best to use a widget or rule that goes directly to your desired temperature " A One and Done Strategy". Rules triggered by CRON or mode (Sleep, Work, Vacation, etc) work fine. The label card with command options works well. Next best is the slider card but change the advanced settings to “only send command on release” and a 2000 ms command interval. At this point I would avoid the stepper because a new command is sent with every click. When I use that for testing, I have to remember to pause between clicks or problems can occur.
Edit: Closed the above issue as the stepper card now works “OK” with the August 20 version (made a slight tweak). However, if changing many degrees, still recommend other options.
1 Like
Is it possible to turn off the LED light via the binding too?
With older versions I had the issue that it sometimes randomly lost the connection to the unit. Is that part more stable now as well?
Is there a updated jar file that I can test?
The original work said that was possible, but it doesn’t work on my unit. I noted in the first paragraph, that there is some variation between Midea protocol models.
The code is going to keep trying to reconnect. A lot depends on your Wi-Fi traffic and possible interference. Since I moved my router a little further from the microwave, I maybe lose one Poll a day (out of 1440).
The link is the “release here” two posts up
That would be really awesome if you could turn the midea binding into an official one.
I plan to do the same with the balboa binding (never did that before)
So maybe I’m going to ask you for a little advice. My only success till now was to install the eclipse environment…
1 Like
From the python HA integration for Midea ACs I leveraged the code to possibly add the LED off option in the OH java binding. The jar is at the link above (labeled LED off test). The reason I kept it separate is that I can’t fully test it. I have verified it doesn’t break anything 
.
My testing issue was the AC needs to support that feature via LAN. Mine only works the “LED off” from the IR controller. If you (or anyone else) try this, I’d appreciate any feedback.
Also, in the write-up I noted a python program msmart-ng that will return your AC LAN capabilities using your OH token, key and id. You do need to install it, however.
As I could not find any information about this brand, I would like to share my experience:
Kaisai AC works great with this binding, thx a lot @apella12
In my case, Kaisai KWX-09, NetHome Plus cloud provider, Version 3 AC.
LED for my model is not turning off through openHAB, only through physical remote.
1 Like
Updates: The official review of the binding is delayed. The reviewer has been busy with another project. I haven’t complained as it is not really the AC season in the northern hemisphere (although these units also provide heat). Prior to the delay the binding was partially reviewed and modified.
The post above prompted me to put the partially reviewed jar on the release link above. If you are using an earlier version successfully, it is probably not worth the hassle to update. There are some breaking changes to comply with 2024 OH standards on naming and there could be others before “Official”. However, if starting new, it could make the ultimate transition to an official version easier. It is a 5.0 snapshot but compiled to work with Java 17 (on OH4.3). The only change of note in the newer version is a little more robust handling of polling retries. I have the AC isolated from the internet. That requires polling retries to work seamlessly. If you have the AC on the internet, it won’t matter much.
Thanks, but the core of the binding has been developed by many others. I’ve fixed a few things, but mostly just trying to get this to official status.
Any AC device that works with NetHome Plus will work with this binding (at least so far ).
Thx to all contributers, keep up the good work.
1 Like