Are you also talking about upgrading to OH4? I would love to hear that…
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!
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
the current binding will not work in 4.xx
It will need to at least be recompiled to add the missing files that 4.x require.
lots of chatter out there on forum as to what those files are .
As I said before in a previous post I took the code and hacked a version to use on 4.x it works ok but since I was also chasing other oddity’s what I created is not really useful to folks for production use. I turned a bunch of things on and hacked many logging statements as well.
If you want to build out a 4.0 version before @JacekDob or @zdanhauser create one for public consumption set up a simple dev environment pull down the code base and recompile it. Other than the missing pom file changes I did not need to change anything else. to get it working on 4.x
here is the link to how to set up a dev environment.
and this is the guide to understand how to modify the binding . At least using Eclipse as IDE anyway.
2 Likes
Just one more question.
I was not able to find a channel which tells me the current running state of the fan and of the compressor. I know that from the thermostat OH integration (Honeywell Z-Wave) of my central heat pump in our house which tells me if it’s currently running (cooling or heating) or just not running (like stand by) and if the fan is running or not. This is independent of the selected mode (cooling or heating).
In the midaac binding, I’ve noticed that if the setpoint temperature has been reached and it’s not longer actively cooling/heating (compressor off?) and the fan is not running (maybe at very low speed), there are no changes in any of the channels to reflect this state.
Is this usual behavior or should this be reported on any of the channels?
Thanks!
Hi,
This is usual behavior. The A/C device does not report back that the compressor run state changed or fan speeds have changed due to the set temp being reached so the binding has nothing to update OpenHab with. Unless a mode change is made or a fan speed change is made by either the remote, the app or a separate script the state shown in OpenHab is what the last status returned based on the bindings polling interval.
Hi,
thanks for clarification!
Btw. the binding is working very reliable with my OH 3.4.4 since I’ve installed it, about 2 weeks ago!
As a side note:
I’ve blocked internet access for the stick and it’s working completely in my local WiFi (without any cloud access). Surprisingly even the Senville Android App is working also completely local (as long as I will be connected to my local LAN).
Just one question about the configuration of the binding. As I’ve mentioned here, the binding works great with a version 2 stick for my Senville mini split - as long as I configure the Thing in the OH GUI. As soon as I try to configure it in the thing-file it does not work (I never had this behavior before with other bindings).
Do you think a file based configuration should work from the bindings implementation? Or is specific functionality for file based configuration missing in the current version of the binding? I don’t know, if there are different code implementations for both ways are required in the binding and maybe only the GUI configuration is implemented or is it a bug?
I would be happy to help to debug and doing tests from my side. Maybe I can also take a look at the code if you may be point to the right direction (which classes and methods are involved for file-base configuration). I know about Java but I don’t know very much about OH binding implementations so far.
Thanks in advance,
Frank
1 Like
Hi @JacekDob, @zdanhauser
do you have already plans to publish a binding version for OH4? Since I have installed two Midea ACs a couple of weeks ago, I’d love to try you binding!
Thx, Christof
3 Likes
Hi
I have setup a dev env for addons 4.0.5. Then added the mideaac addon. Ran the maven insrall.
Copied the jar to addons folder
Binding is not available when trying to add the thing.
Any ideas on how to fix this
Only thing I can think of is either the pom file may not have updated correctly.
Or the extra new files need for 4.0 did not get created.
does your new binding have an addon.xml file?
does the binding show up when you do list from Karaf console cli?
Openhab 4 needs a folder under OH-INF named addon
and a xml file inside it named addon.xml.
which contains something like this inside it.
otherwise the binding will not be availble in 4.0 and above versions.
<addon:addon xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:addon="https://openhab.org/schemas/addon/v1.0.0" id="mideaac" xsi:schemaLocation="https://openhab.org/schemas/addon/v1.0.0 https://openhab.org/schemas/addon-1.0.0.xsd">
<type>binding</type>
<name>MideaAC Binding</name>
<description>This is the binding for MideaAC.</description>
<connection>local</connection>
</addon:addon>
And before someone scolds me yes there is way more that needs to be done to this binding to make it fully 4.0 and above compliant and stable.
All I have listed is what bare min is needed to get it to at least function in openhab 4.0 and above.
Awesome, thanks
The binding is now available.
I have another issue though. Sorry to bother you with this one as well. Maybe you came across this one as well
2023-11-20 07:24:20.389 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.initialize()’ on ‘org.openhab.binding.mideaac.internal.handler.MideaACHandler@169720a7’: Cannot invoke “String.toString()” because the return value of “java.util.Map.get(Object)” is null
java.lang.NullPointerException: Cannot invoke “String.toString()” because the return value of “java.util.Map.get(Object)” is null
at org.openhab.binding.mideaac.internal.handler.MideaACHandler.initialize(MideaACHandler.java:505) ~[?:?]
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.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) ~[?:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
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) ~[?:?]
Thanks
Marinus
Got it working. Scanned for the aircons instead of manual add
I do see this in the logs however.
2023-11-20 07:45:50.572 [ERROR] [ler.MideaACHandler$ConnectionManager] - Response data is 21 long instead of 25!
Regards
Marinus
No, I do not recall seeing that, but it looks like that is right at the point it is validating the configuration of the A/C
@SuppressWarnings("null")
@Override
public void discovered(DiscoveryResult discoveryResult) {
logger.debug("Discovered {}", thing.getUID());
String deviceId = discoveryResult.getProperties().get(CONFIG_DEVICEID).toString();
String ipPort = discoveryResult.getProperties().get(CONFIG_IP_PORT).toString();
Configuration configuration = editConfiguration();
configuration.put(CONFIG_DEVICEID, deviceId);
configuration.put(CONFIG_IP_PORT, ipPort);
updateConfiguration(configuration);
properties = editProperties();
properties.put(PROPERTY_VERSION, discoveryResult.getProperties().get(PROPERTY_VERSION).toString());
properties.put(PROPERTY_SN, discoveryResult.getProperties().get(PROPERTY_SN).toString());
properties.put(PROPERTY_SSID, discoveryResult.getProperties().get(PROPERTY_SSID).toString());
properties.put(PROPERTY_TYPE, discoveryResult.getProperties().get(PROPERTY_TYPE).toString());
updateProperties(properties);
initialize();
}
yep, You have now got back to the same place as what occurs in the 3.4 version of this binding. that is the same message that was discussed earlier in this thread and comes from this part of the code where a change to the binding added this.
// The response data from the appliance includes a packet header which we don't want
data = Arrays.copyOfRange(data, 10, data.length);
logger.trace("Bytes in HEX, decoded and stripped without header: length: {}, data: {}",
data.length, Utils.bytesToHex(data));
logger.trace(
"Bytes in BINARY, decoded and stripped without header: length: {}, data: {}",
data.length, Utils.bytesToBinary(data));
if (data.length > 0) {
if (data.length != 25) {
logger.error("Response data is {} long instead of 25!", data.length);
// return;
}
lastResponse = new Response(data, getVersion(), responseType, bodyType);
try {
processMessage(lastResponse);
} catch (Exception ex) {
logger.warn("Error processing response: {}", ex.getMessage());
}
```Would be awesome if someone could share a jar file that works for OpenHab 4, would love to be able to use my midea devices via OpenHab again
Thanks,
I completely forgot about this. I see in my code for openhab 3 I just commented out that if statement. Not sure if there is a better solution to this. That if statement is a bit pointless though
Do you maybe have a solution that will prevent the binding from disconnecting every couple of minutes?
regards
Marinus
Sorry for the late response. Yes, I’ve been planning it for a while now because not long ago, I also ran into the situation where the OH got updated, and the binding was not available. However, towards the end of the year, I have deadlines for my work, and I haven’t had much free time for this until now.
Hi, I am not going to get into a discussion about what is useless or not.
However, I modified that if statement to do a comparison of a range of data lengths for my units I would see 21 as the value returned almost every time other folks reported 26 or some other recurring length I suspect it is A/C unit or firmware differences maybe even region related but every 30 minutes or so often it would return a bogus length of 17 or 27 or 31 I cannot recall exactly but it was out of the range of 21 to 26 on the length.
so, when that occurs it causes the byte array to get corrupted then it falls into the catch and takes the unit offline.
The if statement you think is useless is used to replace the bad array with the previous good array so that the update would complete and post back a valid response all be it the previous one.
I also added a check to ensure the body type returned a value of 30 otherwise that would also cause the array to be unusable.
are any of these the best fix well no it would be best to figure out why this random decrypt and corrupt array occurs.
I see that @zdanhauser has chimed in as well and perhaps he can offer more clarity as to why it was done the way he did it initially.
As I have said many times the binding works but has some refinement needed.
Hopefully he will have time now to recompile a fully compatible version that supports all of the new openhab 4.1 enhancements as well.
Hopefully, I will have enough free time between Christmas and New Year to deal with it substantively. After all, I will need the OH 4+ binding sooner or later as well.
1 Like