Ladies & Gentkemen,
the PR has been merged, we are part of 2.5.7
The official build could be found here:
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.gree/2.5.7-SNAPSHOT/org.openhab.binding.gree-2.5.7-SNAPSHOT.jar
4 Likes
@markus7017 , you have another happy user here. 
I am using the previous greeair binding since more than a year, it is still running on my OH 2.4 installation, thanks to @JCunha. I was following your work here silently, waiting for my opportunity to upgrade my other location to OH 2.5 and test the new gree binding, your version. This day came last week, and i can gladly report to you, it is working perfectly so far. It’s fantastic how much you progressed with it, improved the code, fixed reconnection issues, added autodiscovery. I offer my help in testing, if it is needed any time in the future (the binding seems to be ready…).
One little correction in the documentation, if i may suggest, assuming that i was using the right location for your development. I used the example code from the readme file (myfiles/gree/README.md at master · markus7017/myfiles · GitHub) and found the type of the mode channel was probably not updated since greeair times. It is number in the example, but string in the channel definition, i changed it in the code (in items file) to string and now working properly (probably because the example is using string also in the sitemap file for aircon mode). You may also want to add v2.5.7 snapshot jar file here, just to have everything at one location for noobs like me.
I hope this binding will become part of the official set, the quality - i’m not a programmer but as far as i can judge - is very good. Thank you very much for your hard work!!!
welcome to the party and thanks for the flowers 
- yes, PR review has been completed so the binding will become part of the upcoming 2.5.7 Addons release
- you are correct the channel definition in the README correct, but the code sample needs a change, will do that
Hello, I have installed 2.5.7 and binding works. I need to remap some small things but is is like that since your last update. I don’t think that there is any issue. If you need some trials with that version just let me know and I do it.
the PR has been merged in between so README is consistent
I use this binding for Sinclair Airconditioner with Wlan-Module and it works perfect.
My air conditioner: https://www.sinclair-solutions.com/en/products/multi-variable-series-r32/wall-mounted-units/6371-mv-h12bif-053031000002470.html
Maybe you can write this on the readme and on the binding-page, that other people also find and can use your binding.
Markus, Team,
I started to experience very strange behaviour of my gree units working with OH using our - if i may say so - binding. The A/C units are regularly going to offline status and go back online almost immediately. I see this behavior since 31st of July, have seen some disconnect before also, but very rarely. Now i have 5 Indoor units, 1 connected to OpenHab v2.5.2 running on my synology Nas at location “A”, the other four are connected to another Synology Nas running OH v2.5.2 at location “B”. Those locations are interconnected by OpenVPN, but they are on different subnets, with routed traffic for other equipments. I dont think this is important from the issue point of view, but wanted to give full picture, who knows… So i started to see very frequent (every 1 to 5 minutes) disconnects and reconnects on location “A” on 31st July, then next day the same started to happen on location “B”. That was few days after i upgraded location “B” from OH 2.4 to 2.5.2, although it was working nicely for few days. At location “A” i made the same upgrade in the beginning of July, and it was working with zero issue until 31st. Thats the reason why i was dare enough to start upgrade at location “B”. Sorry for the long story… the outcome is, that since that time, my four units are disconnecting 5 to 60 minutes but reconnect immediately, some of the AC units are more frequent, the others are less, but all of them doing this. At location “A” i removed the binding completely becuase the reconnect is happening almost every minutes.
I have a rule installed both sides, which is triggered by any status change of the gree things defined. I receive message when it happens with the new status. I have checked wifi connection, and while the gree wifi-kits are all seems to be unstable on wifi, reconnecting to the wifi access point appr once a day, the reconnection in OH is happening much much more frequently. I think this is due to weak implementation of the wifi-kit in the Gree indoor units. People please comment with your experience!
I enabled debug in Karaf, and see this offline online status change also. I changed the refresh rate to 5 sec in thing definition, so i see in debug refresh is happening every 5 sec, but some of the connection attempts fails and the thing goes offline, but get back online in another 5 sec approximately.
As i dont believe we can make the wifi connection more stable (signal is -40 to -50 dbm, noise is -82 to -92 dbm), i thought maybe Markus could change the code a bit and make some retry before reporting things offline. I think you already had plans for this in July. I was using gree binding v2.5.7 until yesterday, then installed v2.5.8 but the issue remained the same.
If i switch off the status monitoring, i dont even realize this and the controls are working ok (sometimes with small delays when it reconnects), so i could disregard this issue, but i hate knowing that something is not working as expected.
I appreciate any comments if you have seen similar problems or if you have idea how to make it better.
your code goes here
Obviously the connection is not reliable. GREE uses UDP traffic, which means a packet loss results in a timeout. Use something like ping over a longer time to check packet loss rate.
I did some measurement before, on location “A” packet loss pinging the AC unit was about 10%. When it happens the same time the binding refreshing the thing data, it reports loss of connection. The question is not why is that (i assume it is gree wifi-kit related, but you can give me better idea if you have), but rather how can we handle it, unless this is only happening at my installations. I hope this is not just my problem, because i am doing my test on two different locations, different wifi access points, and different Gree wifi-kit firmwares (v3.56 and v3.58). The issue is the same for all of my units. So i thought maybe we can adjust the binding a bit to be more tolerant for such low quality connections.
10% packet loss? that’s bad.
Maybe a retry handling could be a work around, but currently I don’t have the time to work on that.
Thank you Markus for your quick reply, your work is appreciated anyway!
Anyone else has similar experience, frequent reconnect (going gree things offline then immediately back to online ) in OpenHAB?
Nice to see this project is alive! I bought the Wifi module for my Daitsu air conditioner that allows me to control it with the Ewpe app. This is just some other branding of Gree, so I installed the 2.5.7 version of this addon. It works nicely actually!
On occasions I get this in the logs:
2020-09-07 01:03:42.713 [hingStatusInfoChangedEvent] - 'gree:airconditioner:f4911e5300e5' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Unable to perform auto-update: I/O exception while updating status (Receive timed out)
2020-09-07 01:03:56.047 [hingStatusInfoChangedEvent] - 'gree:airconditioner:f4911e5300e5' changed from OFFLINE (COMMUNICATION_ERROR): Unable to perform auto-update: I/O exception while updating status (Receive timed out) to ONLINE
I guess the Wifi module times out every now and then, but it’s back 10-15 seconds later. Probably nothing to worry much about.
If you every need any debug/test or whatever, let me know.
Congratulations markus.
fyi: taboneclayton contributed a PR to include the current temperature as new channel. The PR has just been merged and will get into 2.5.9.
Hi Jon, i have also occasional drop in wifi connection but it comes back few seconds later. I think this is caused by the weak wifi radio modul/antenna in the A/C unit, you cant do too much about that. I switched off short preamble on my wifi AP, this improved the situation.
This is a known issue. In fact the communication is UDP-based, so packets might get lost. I need to implement a proper recovery mechanism (e.g. ignore on status poll, repeat on requests). However, we are currently in transition from 2.5 to 3.0 dev environment. 2.5.9 will be released on 20th Sep. After that I could work on this
I’ve update the DEV build, please try this one
(make sure to delete older version than 2.5.9)
This change will implement an improved handling
- ignore up to 3 API errors on status polls
- up to 3 retries on commands
This should be enough to keep the thing online and recover from temporary connection issues
I do not have any connection issue. Everything work seamless. I had before with my Paradox Alarm system due to week wifi signal. I use this build: openHAB 2.5.9 Build #218 Binding is installed from the build. If you need some test I can delete and install DEV version if you like.
Sure, even if you have no issues you could confirm that it still works and check the new currentTemperature channel (requires deleting and re-discover the thing)
Ok i will do.