core
core copied to clipboard
home-assistant
Allow Gree AC Setup with IP adress instead of autodiscovery
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
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 closeCloses the issue. -
@home-assistant rename Awesome new titleChange the title of the issue. -
@home-assistant reopenReopen the issue. -
@home-assistant unassign greeRemoves 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)
![home-assistant[bot] avatar](https://avatars.githubusercontent.com/in/97978?v=4 "Published by a pub.dev verified publisher"){kind=small}
+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.
[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
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. 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.
+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 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.
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.
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.
![issue-triage-workflows[bot] avatar](https://avatars.githubusercontent.com/u/13844975?v=4 "Published by a pub.dev verified publisher"){kind=small}
I would really appreciate it if this bug could be fixed as well. I'm using HA in a docker container in bridge mode
+1 for this, the custom component that I used before supported this and would be nice to have it in core too.
+1 here too ( using macvlan networks in docker swarm is not very stable )
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.
@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:
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
