Ok I check it now. Anyway I just finished the trace log of previous one. So I upload and check this one within a few minutes.Gree_Debug_Log_20200916.log (75.3 KB)
It seems that it works now. See the logs. I tried auto discovery, add thing from inbox.
Controlled from sitemap. Interesting that it is not refreshing in the android app, but I think it is a general problem of the app itself. Iām experiencing it with other devices as well. Current temperature is undef. I donāt know how this channel should behiave.
Gree_Debug_Log_20200916_2.log (79.2 KB)
v2.5.9.202009160552 is working again here, no problem when switching on/off. Markus, should we retest all functions?
yes please
All functions are working including Google integration. I canāt check Current Temp and horizontal swing channels as these functions are missing from my device.
I confirm currentTemperature is working. I also dont have horizontal swing possibility, the rest seems to be ok.
Give me 1-2 days to run it and i will report back the wifi connection stability also.
Hi Markus, an hour ago i had disconnect, here is the openhab.log relevant part:
2020-09-17 17:48:08.460 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Executing automatic update of values 2020-09-17 17:48:20.588 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Unable to perform auto-update: I/O exception while updating status (Receive timed out) 2020-09-17 17:48:32.623 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Unable to perform auto-update: I/O exception while updating status (Receive timed out) 2020-09-17 17:48:44.658 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Unable to perform auto-update: I/O exception while updating status (Receive timed out) 2020-09-17 17:48:56.693 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Unable to perform auto-update: I/O exception while updating status (Receive timed out) 2020-09-17 17:48:57.452 [INFO ] [arthome.model.script.Gree monitoring] - TF AC OFFLINE 2020-09-17 17:49:01.740 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Re-initialize device 2020-09-17 17:49:01.743 [DEBUG] [.internal.discovery.GreeDeviceFinder] - Sending scan packet to 192.168.88.250 2020-09-17 17:49:15.795 [INFO ] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Thing initialization failed: Unable to bind to device 2020-09-17 17:49:20.811 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Re-initialize device 2020-09-17 17:49:20.815 [DEBUG] [.internal.discovery.GreeDeviceFinder] - Sending scan packet to 192.168.88.250 2020-09-17 17:49:34.856 [INFO ] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Thing initialization failed: Unable to bind to device 2020-09-17 17:49:39.873 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Re-initialize device 2020-09-17 17:49:39.875 [DEBUG] [.internal.discovery.GreeDeviceFinder] - Sending scan packet to 192.168.88.250 2020-09-17 17:49:48.420 [INFO ] [arthome.model.script.Gree monitoring] - TF AC ONLINE
I had no more issues, not even a single retry in the past 24 hours. I think the binding is working well, A/C has been reconnected 51 second later automatically, i am satisfied with this, nothing to do with the binding in my opinion.
The biggest problem as far as i see is a typo here:
2020-09-17 14:11:54.561 [DEBUG] [ng.gree.internal.handler.GreeHandler] - f4911e765d0e: Issue command ON to channe power
An ālā is missingā¦ 
nice, well done
ok, I think typo has not a high prioš¤Ŗ
Are you blocking Internet access for those units to prevent the China talk?
No, typo is bottom low priority indeed. 
Just pretending how good tester i am. lol
I am not blocking internet communication to the A/C, still using the Gree App, it is useful sometime. I have 3 OH locations, only one can be linked to openhab cloud, and this one in question is not that one. When i am away, i can use vpn to log in and manage my devices, but just to handle A/C, the Gree App is quicker.
what does the GREE app provides you could not achieve with OH. Maybe we could add that.
PS: A good tester is half of a good release
Ok, i did not want to bother you with the details, but if interestedā¦
I have 3 geographic locations, where i run OpenHAB. The locations are interconnected with OpenVPN. Each locations has a separate OH server, just to be sure it continues running even if internet connection breaks between the sites. The issue is that OpenHAB cloud cannot be connected to multiple OH instances. I connected the most important site to the OH cloud, the rest operates on their own. I have still several ways to use them, created a touch screen to drive certain things (lamps, heating etc), and many function works automatically, without the need to have manual control.
Still it would be fantastic to connect all the 3 sites to the OH cloud, i could connect them together with event bus, and create a new sitemap to show them all, but i have no experience with it and found too complicated when i checked how to do it. Would be also an increased complexity to maintain later, if i change something on one site, i would have to be more careful not to break the event bus connections.
From the Gree App i can connect to the 2 sites - where i have Gree units - quickly and switch on/off the A/C when needed. Sometime it is useful. Probably i could do the same with OH event bus, one day i may try, but i would rather prefer to be able to connect all sites individually to OH cloud and be able to select which sitemap i want to use, regardless of where are they running physically. I am afraid itās more a core function to implement, this binding is perfect on its own.
I see those options
a) Implement proxy items on site 1, the rule triggers actions on site 2 and 3 using the REST API
b) you could use MQQT to do the proxying
c) most meaningful - how I do it:
- build a HABpanel (HTML-based) for each instance
- configure a VPN connection from you mobile to your home network
- then you could just launch the HABpanel you want to use (accessing the different instances)
Benefits
- The VPN makes it transparent, you have full control on the network layer
- HTML is compact and fast, communication is secured
- no need to use the openHAB App nor openHAB Cloud connector
- you could block the Internet access for the units
- Same HABpanels work locally or remote
I defiantly not use the GREE App and block the Internet access. Keep in mind the A/C units could act as proxy to provide them full access to your local network.
All solution could work that you suggested.
a) I could make it with proxy ( i call them āfakeā ) items, but if i want to have full control, it means 100 proxy items, i am not willing to manage this quantity in my code.
b) MQTT is an easy option, if i connect few items its not a big work, but on each site i have 50+ items, would be a long programming excercise with lot of maintenance later if i want to change. If i want to control only my A/Cs on one sitemap, this will be the way i implement it.
c) This is how it works now, i just use BasicUI instead of HABpanel. All my sites are interconnected with OpenVPN, so anywhere i sit down, i can launch BasicUI of any OH instance and do what i want with the defined sitemaps.
The issue comes when i am on the way. I have to connect to the appropriate VPN on my phone, then i have to launch my browser, type in the address of my BasicUI, it takes about 1 minute, maybe im slow. Not too much, but doing the same with Gree App is 5 seconds. Huge difference if i want to change the A/C while driving. 
I like the OpenHAB app on my phone, quick and easy to use. So for the A/C, maybe i will add the switch button via proxy item soon. The rest would be too much.
You are right, the A/C can run any program, and i cannot control what they are doing, but all my A/C are sitting on a subnet (separate for IoT devices) which is firewalled from my main network. They can only reach their local OH server, nothing else.
So, time to start playing with OH3
Binding was working before with OH3. So Iām sure that it will be fine. At the moment Zwave is not working in OH3. I will start to try after it is fixed.
Hi @markus7017,
quick question about autodiscovery.
Iāve just changed my network setting and moved smart home things to different VLAN, but OH server remains in previous one.
VLAN for IoT is 192.168.100.0/24
VLAN with OH server is 192.168.200.0/24
I can ping to all those things across both VLANs.
I guess that autodiscovery works only in the subnetwork where OH is installed, isnāt it?
I can of course add my Gree manually, but just wanted to have your confirmation
Thanks in advance!
Yup, the binding uses the default interface n the OH network config to send broadcasts finding the units. Maybe I could add a config option to the binding settings to chose a different ip subnet if required