Allow Gree AC Setup with IP adress instead of autodiscovery #83048
Comments
|
Hey there @cmroche, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) gree documentation |
|
+1 |
|
+1 on this one, configuration should fall back to IP address entry if no devices are discovered IMO. Can't be too hard to implement? Would be willing to give this a try for a PR, but I've never worked on Hass integrations before so if @cmroche is willing and able that would be ideal. |
|
I think this is a good idea as well, since there are natural limitations to the broadcast discovery that gree devices use. I however I am unlikely to develop this feature myself in the near future, and welcome contributions if you are still interested in trying @chvancooten The only caveat for me is that full auto-discovery should remain a functional option, this will also likely need work in the underlying device library, but I maintain that as well and can facilitate reviews and merges. |
|
Relevant to #82858, would love to see this! |
|
[greeclimate.discovery] Listening for devices on 255.255.255.255 My HA container is in 192.168.96.x subnetwork and ACs are on 192.168.1.x |
|
I do not believe that this would solve the problem, as I think that discovery is broadcast based which will not work on container subnets (like k8s ones) that are probably using NAT for their traffic. A way to specify IP address and direct connection details would be a much better solution for these cases as it is also tested and it works (see my similar relevant issue) |
|
Yes same issue here, and I am strugling to get a second Interface on my Container but so far no luck. |
|
+1 I have the same issue. Cannot connect to appliance on my IOT VLAN. I will try to add a macvlan network to the container to see if that can solve it. |
|
+1 After some days of works this command works: echo -n "{\"t\": \"scan\"}" | nc -w 1 -u 192.168.177.186 7000and this stops working echo -n "{\"t\": \"scan\"}" | nc -w 1 -b -u 255.255.255.255 7000Just after fresh reconnect to WiFi (either router or gree restart) both commands works. |
|
Has anyone volunteered to extend this integration? :) |
|
Not yet :( |
|
This custom component works for me https://github.com/RobHofmann/HomeAssistant-GreeClimateComponent |
|
One solution would be to run a broadcast bridge on your router. I have built this bridge that runs on an OpenWRT router - It can be compiled statically, but it is not the most elegant otherwise: https://github.com/KiralyCraft/GREEBridge I've hardcoded the IPs, but you should be able to easily change them. Here is the IP of the GREE device: https://github.com/KiralyCraft/GREEBridge/blob/main/GREEBridge/main.c#L41 And here is the IP of the sender (HA's IP): https://github.com/KiralyCraft/GREEBridge/blob/main/GREEBridge/main.c#L45 Home assistant's broadcasts will be detected by this bridge, reaching it on port 7000. It then bounds itself to port 7001 on the other side (IoT LAN) and forwards the message to the specified IP. Then, the GREE device replies to the IoT side of the router, on port 7001, with a request that goes back (directed) to HA on the port the request originally came from. The code only works with one GREE device so far. Feel free to extend it if you wish; Hope this helps a bit with the problem. |
|
+1 |
|
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. |
|
Almost one year in, this is still a valid issue that needs a fix. |
|
+1 for this, would be great to see a solution |
|
I would really appreciate it if this bug could be fixed as well. |
|
+1 for this, the custom component that I used before supported this and would be nice to have it in core too. |
|
+1 as well |
|
+1 here too |
|
+1 as well |
|
+1 here too ( using macvlan networks in docker swarm is not very stable ) |
|
+1 |
|
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. |
|
Not stale |
|
Is this fixed? |
|
@Andro-Marian Not yet, but I have a few other tasks to complete / fix before coming to this issue, give it a couple weeks though and I will try to add support for this feature. |
|
It would be great to use Ip addresses instead of autodiscovery. It would probably solve the issue I see with my Gree devices: |
|
+1 |
|
I managed to make it work for my setup (HA and ACs are on a separate VLANs with strict firewall in between). So after looking at the source code of the discovery flow I noticed that the primary entrypoint method "scan" which does all the discovery expects a list of broadcast addresses to send discovery package to (which won't work in vlan environment ). However if you override broadcast addresses with exact AC IPs it should work without any further modifications of the component. The quick and hacky solution which I crafted for myself (maybe will be useful for someone): # gree/__init__.py
class CustomDiscovery(Discovery):
STATIC_ENTITY_IPS: list[str] = [
"10.32.10.3", "10.32.10.4", "10.32.10.5", "10.32.10.6"
]
async def scan(self, wait_for: int = 0, bcast_ifaces: list[IPv4Address] | None = None) -> list[DeviceInfo]:
return await super().scan(wait_for, [IPv4Address(x) for x in
self.STATIC_ENTITY_IPS] if self.STATIC_ENTITY_IPS else bcast_ifaces)
class DiscoveryService(Listener):
"""Discovery event handler for gree devices."""
def __init__(self, hass: HomeAssistant) -> None:
"""Initialize discovery service."""
super().__init__()
self.hass = hass
self.discovery = CustomDiscovery(DISCOVERY_TIMEOUT)
.....I think it shouldn't be hard to update config flow to optionally allow entering IPs. |
|
Hello, @corvis Could you explain how to apply it? I've created gree folder in custom_components and copied all official gree integration files there. Then I've added your code to the init.py. Unfortunately the integration doesn't find my HVAC. I've checked on the gree HACS component and the HVAC is found there without any problem. |
|
Make sure you're not just coping my code as is but modify but integrate it into existing one. CustomDiscovery class - just copy at the very top of the file and replace IP addresses with yours. Than, in existing DiscoveryService locate init method and replace one single line starting with That should do a trick. If it doesn't you may want to rename the integration you copied to make sure it doesn't interfere with the stock one. In this case you will need to rename a folder (e.g. "gree" -> "gree_custom") and update manifest. |
Wow, thanks a lot! In the meantime I found a fork, which allows to set up IP via GUI. |
|
I think, other then separate subnets, I think another reason for broken autodiscovery (the broadcast thing in the integration), is if one has a firewall in the middle. More details:
|
|
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. |
|
+1 |
|
Still waiting on a solution here please let me know if you need any testing (I am not a coder so unable to help to adjustment of the code) |
and others
The problem
I have a WiFi enabled portable AC that is compatible with the gree integration. However I want to put this device on my iot wifi and subnet. This however breaks the auto discovery as the gree integration uses broadcasts to communicate with the devices instead of direct connections.
When using this gree2mqtt bridge I am able to enter the ip address of the device and control it through it.
I think it would be nice if the configure dialog of the gree integration would optionally allow you to input an ip address or host name for users with more advanced network configurations instead of relying on subnet broadcasts.
What version of Home Assistant Core has the issue?
2022.11.5
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
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?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: