Allow Gree AC Setup with IP adress instead of autodiscovery

[bernikr]

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

[home-assistant[bot]]

Hey there @cmroche, mind taking a look at this issue as it has been labeled with an integration (gree) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `gree` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Change the title of the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign gree` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

gree documentation gree source _{^{(message by IssueLinks)}}

[galoi9]

+1

[chvancooten]

+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.

[cmroche]

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.

[agorgl]

Relevant to #82858, would love to see this!

[Mokson]

[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 Changing scanning mask to 255.255.0.0 would resolve the issue I guess

[agorgl]

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)

[Mvanmierlo]

Yes same issue here, and I am strugling to get a second Interface on my Container but so far no luck. Neither was enabling Mdns repeater on my router / firewall. Guess discovery is done via a Layer 2 broadcast and confined to the only VLAN my HA container is running. As the Gree Wifi module is kinda keen on phone home I moved it to my (non internet connected) IOT VLAN preventing China from listening in but lost my HA connectivity.

[george-oniceag]

+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.

[niziak]

+1 After some days of working it stops discovering my Gree WiFi. There is a issue in WiFi adapter and it stops responding to broadcasts scans. Unicast scan works well so providing option to setup IP address manually will be great feature.

After some days of works this command works:

echo -n "{\"t\": \"scan\"}" | nc -w 1 -u 192.168.177.186 7000

and this stops working

echo -n "{\"t\": \"scan\"}" | nc -w 1 -b -u 255.255.255.255 7000

Just after fresh reconnect to WiFi (either router or gree restart) both commands works.

[Mokson]

Has anyone volunteered to extend this integration? :)

[agorgl]

Not yet :(

[Mokson]

This custom component works for me https://github.com/RobHofmann/HomeAssistant-GreeClimateComponent

[KiralyCraft]

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.

[andymarden]

+1

[issue-triage-workflows[bot]]

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.

[Dzhuneyt]

Almost one year in, this is still a valid issue that needs a fix.

[resitan]

+1 for this, would be great to see a solution

[jeremiesigrist]

I would really appreciate it if this bug could be fixed as well. I'm using HA in a docker container in bridge mode

[koskila]

+1 for this, the custom component that I used before supported this and would be nice to have it in core too.

[wangeris]

+1 as well

[BartOpitz]

+1 here too

[WernerRH21]

+1 as well

[george-oniceag]

+1 here too ( using macvlan networks in docker swarm is not very stable )

[v-rejected]

+1

[issue-triage-workflows[bot]]

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.

[agorgl]

Not stale

[Andro-Marian]

Is this fixed?

[cmroche]

@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.

[schneemaier]

It would be great to use Ip addresses instead of autodiscovery. It would probably solve the issue I see with my Gree devices:

Bedroom klima turned off 2:55:47 PM - 1 hour ago
Bedroom klima became unavailable 2:54:47 PM - 1 hour ago
Bedroom klima turned off 2:41:37 PM - 1 hour ago
Bedroom klima became unavailable 2:40:37 PM - 1 hour ago
Bedroom klima turned off 2:09:25 PM - 2 hours ago
Bedroom klima became unavailable 2:08:25 PM - 2 hours ago
Bedroom klima turned off 2:00:15 PM - 2 hours ago
Bedroom klima became unavailable 1:59:15 PM - 2 hours ago
Bedroom klima turned off 1:39:05 PM - 2 hours ago
Bedroom klima became unavailable 1:38:05 PM - 2 hours ago
Bedroom klima turned off 1:05:55 PM - 3 hours ago
Bedroom klima became unavailable 1:04:55 PM - 3 hours ago
Bedroom klima turned off 12:41:45 PM - 3 hours ago
Bedroom klima became unavailable 12:40:45 PM - 3 hours ago
Bedroom klima turned off 10:36:32 AM - 5 hours ago

[lupusx]

+1

[corvis]

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.

[agorgl]

@cmroche Did you manage to take a look? I tried a similar solution to the one @corvis proposes above in the past and this seems to do the trick

[jaku2019]

Hello, thanks for sharing the fix.

@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.

[corvis]

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 self.discovey = with the one from my snippet: self.discovery = CustomDiscovery(DISCOVERY_TIMEOUT)

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.

[jaku2019]

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 self.discovey = with the one from my snippet: self.discovery = CustomDiscovery(DISCOVERY_TIMEOUT)

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. https://github.com/rapi3/HA-OS-Gree

[wosiu]

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:

• https://github.com/home-assistant/core/issues/127796
• https://github.com/cmroche/greeclimate/issues/61. So definitely +1 to the ability of providing static IP manually.