core: Gree integration - devices become unavailable but not on the native app
The problem
Gree devices often become unavailable and unreachable, however the same devices appear fine on the native Gree app. It happens randomly and on different devices.
For some reasons it seems the app has the capability to still find them while the integration doesn’t.
Note: both HA and devices are on the same VLAN
What version of Home Assistant Core has the issue?
2022.3.8
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Supervised
Integration causing the issue
Gree
Link to integration documentation on our website
https://www.home-assistant.io/integrations/gree/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
2022-04-04 12:47:02 ERROR (MainThread) [homeassistant.components.gree.bridge] Timeout trying to bind to gree device: Device: XXXXXX @ 192.168XXXXXX (mac: XXXXXXXXXXX)
2022-04-04 12:48:22 ERROR (MainThread) [homeassistant.components.gree.bridge] Error fetching gree-XXXXX data: Device gree-XXXXXX is unavailable
Additional information
No response
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 1
- Comments: 105 (6 by maintainers)
Is it possible to add support for adding gree devices by entering manual IP instead of discovery? The discovery doesn’t work for me and I have no option but to use the custom integration of gree (which works with manual IP) instead of the built-in integration.
So if people will have the same issue: I went to Settings, System. Network, unchecked auto-configure and there, end enabled both interfaces manually. Then the integration works again.
In the meantime for anyone who the auto discovery doesn’t work and wants a workaround, I added an hardcoded code for my use case: I added await self.send({“t”: “scan”}, (“192.168.30.21”, 7000)) in the function search_on_interface the file discovery.py, And now it works for me, though i will have a problem when updating and i will need to re-add this code again probably.
I hope manual ip support will get added soon as it may fix a lot of issues for a lot of people.
Still an issue.
Le dim. 9 juill. 2023 à 14:07, issue-triage-workflows[bot] < @.***> a écrit :
Yes. You probably blocked your units off from the internet and they’re trying hard to phone home and failing. After a couple of days they will reset their network settings to factory.
You need this:
https://github.com/emtek-at/GreeAC-DummyServer
Than you need to redirect the requests to your fake server. Easy to do if you’re running PiHole or AdGuard Home in your network.
There hasn’t been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Could you guys disable your internet connection or drop all outgoing WAN connections from your HVAC at the firewall and see if it triggers the problem?
I had this same “unavailable” log entry for a couple of minutes each single morning. Turns out, according to my RIPE Atlas probe, that my ISP was going down at the same time.
So I disabled all outgoing connections from the unit to the internet and my logbook immediately started filling up with “unavailable” entries every 120 seconds. Every other 120 seconds it was available again.
I have a rather crude automation that checks the status of the thermostat every 60 seconds and either turns on or off the HVAC, so the unit is probed quite often.
Looks like the unit locks up at 2 minute intervals when it can’t reach it’s Chinese cloud service, then becomes available again.
I’m no programmer, but probably increasing some probing timeout in the integration would stop this logbook spam.
greeclimate 1.3.0 was released with some improvements to the broadcast and discovery, I’m not 100% certain this will address all issues raised, but might improve discoverability for some users. Should come as a bug fix soon.
It’s something I would like to do sooner then later, support manually adding devices with this integration, however it’s just a matter of when I will have time time to tackle this.
Hi guys, I have(had) the same issue with Gree HVAC. The issue is, that mounted wifi adapters in GREE devices are crap and lose packets. Build-in GREE integration detect devices using broadcasting and if any packets are lost by HVAC… home assistant switch device into offline. In this scenario the best way could be send multiple packets before switch device info offline. Another issue is with greeclimate library. As I mentioned… GREE lose packets… and that library return communication error if hvac doesn’t respond, so finally even after any operation on demand (e.g. turn on) device could go to offline. I written (to get to know python and HA development API) new python library and custom integration which solve that issues: https://github.com/matizk144/greeFullForHA Project is draft and under tests, but if it’ll work stable… official GREE integration could be updated with fixes which I proposed in my library
This solved my issue, thank you!
How to add device if integration does not recognise it even it’s connected to wifi and native app?
2 MAC adresses on gree climate devices???
I have a TPLINK deco mesh system on the pension. All devices are renamed (ex: tasmota room 01, ot climate room 01…), and all with own IP from the start. I discovered some ESP devices on the network. For example ESP_9E302D
After a google search: https://github.com/tomikaa87/gree-remote/issues/16
For now: blakclisted (3 from 6). And waiting.
Can You check your network???