"socket.timeout: timed out" on home assistant 0.96

[priov]

Hi,

I will appreciate your help to understand why it's not working.

This is climate.yaml:

• platform: gree name: Tadiran host: 192.168.1.132 port: 7000 mac: 'xx:xx:xx:xx:xx:xx' //removed it target_temp_step: 1

home_assistant.log: 2019-07-18 15:52:31 INFO (MainThread) [custom_components.gree.climate] Setting up Gree climate platform 2019-07-18 15:52:31 INFO (MainThread) [custom_components.gree.climate] Adding Gree climate device to hass 2019-07-18 15:52:31 INFO (MainThread) [custom_components.gree.climate] Initialize the GREE climate device 2019-07-18 15:52:31 INFO (MainThread) [custom_components.gree.climate] Retrieving HVAC encryption key 2019-07-18 15:52:31 INFO (MainThread) [custom_components.gree.climate] Fetching(192.168.1.132, 7000, 10, {"cid": "app","i": 1,"pack": "<REMOVED_IT>","t":"pack","tcid":"341513bbf39d","uid": 0}) 2019-07-18 15:52:43 ERROR (MainThread) [homeassistant.components.climate] Error while setting up platform gree Traceback (most recent call last): File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 126, in _async_setup_platform SLOW_SETUP_MAX_WAIT) File "/usr/lib/python3.7/asyncio/tasks.py", line 416, in wait_for return fut.result() File "/usr/lib/python3.7/asyncio/coroutines.py", line 120, in coro res = func(*args, **kw) File "/home/homeassistant/.homeassistant/custom_components/gree/climate.py", line 112, in async_setup_platform GreeClimate(hass, name, ip_addr, port, mac_addr, timeout, target_temp_step, temp_sensor_entity_id, lights_entity_id, xfan_entity_id, health_entity_id, powersave_entity_id, sleep_entity_id, hvac_modes, fan_modes, swing_modes, encryption_key, uid) File "/home/homeassistant/.homeassistant/custom_components/gree/climate.py", line 155, in __init__ self._encryption_key = self.GetDeviceKey().encode("utf8") File "/home/homeassistant/.homeassistant/custom_components/gree/climate.py", line 227, in GetDeviceKey return self.FetchResult(cipher, self._ip_addr, self._port, self._timeout, jsonPayloadToSend)['key'] File "/home/homeassistant/.homeassistant/custom_components/gree/climate.py", line 210, in FetchResult data, addr = clientSock.recvfrom(64000) socket.timeout: timed out

Many thanks!

[RobHofmann]

It gives a timeout. This means your Home Assistant can't reach 192.168.1.132:7000. So either the network configuration is preventing this or you entered some information wrong.

In other words: from the Home Assistant perspective, nothing is listening on the AC side.

[priov]

Thanks. I was sure that the below line is an evidence that there is communication

custom_components.gree.climate] Fetching(192.168.1.132, 7000, 10, {"cid": "app","i": 1,"pack": "","t":"pack","tcid":"341513bbf39d","uid": 0})

[RobHofmann]

No that means its trying to send something :)

    def FetchResult(self, cipher, ip_addr, port, timeout, json):
        _LOGGER.info('Fetching(%s, %s, %s, %s)' % (ip_addr, port, timeout, json))
        clientSock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        clientSock.settimeout(timeout)
        clientSock.sendto(bytes(json, "utf-8"), (ip_addr, port))

Above is the code what gives your output. As you can see, the sending code is after the log code.

[RobHofmann]

I'm closing this for now. let me know if you need more help.

[dragonflyuk]

I am seeing the same issue. But only intermittently. As an axample I have an automation that switches the AC light on, then turns the unit off. This morning the light turned on,but the unit remained on because of a socket time out.

[RobHofmann]

Does it work all the time with the app (i think its called "ewpe" or something like that) for you?

This shouldnt happen. Sounds like something that might be a hardware issue.

[dragonflyuk]

Never had a problem with ewpe, but then also rarely used it, didn't like the damn thing. Never had the problem with the previous add-on which went through mqtt. My thoughts are it's glitch, dropped WiFi packet or something. Is it possible to maybe retry, then wait a few seconds and wait again. The fact the light command worked immediately before suggests it's only momentary.

[RobHofmann]

hmm do you have an delay between the first and the second request? my script looks something like this:

ac_zolderkamer_cool:
  alias: Koelen
  sequence:
  - service: climate.set_hvac_mode
    data:
      entity_id: climate.zolderkamer_ac
      hvac_mode: 'cool'
  - delay:
      milliseconds: 500
  - service: climate.set_temperature
    data:
      entity_id: climate.zolderkamer_ac
      temperature: 21
  - delay:
      milliseconds: 500
  - service: climate.set_fan_mode
    data:
      entity_id: climate.zolderkamer_ac
      fan_mode: 'quiet'
  - delay:
      milliseconds: 500
  - service: climate.set_swing_mode
    data:
      entity_id: climate.zolderkamer_ac
      swing_mode: 'Fixed in the upmost position'

Above script works like a charm. When I remove the delays, sometimes some commands don't get registered by the AC. This might solve your issue.

My assumption is that the AC is too busy handling the 2nd request if you fire it too fast, because it's still handling the first.

[dragonflyuk]

That would make sense, however I've just been into my automation to make the changes you suggest, but the failed command was the first command, and the second command succeeded. I have however made the changes you suggested. I wonder if the wifi on the unit has gone to sleep or something, and is woken up by the first command but not fast enough to respond correctly.

[RobHofmann]

Please do some additional testing. Did this happen once or more than once?

I'm still guessing either a hardware or a network issue, since other users don't seem to have this issue. I have 2 models myself and they work like a charm without timeouts.

Let me know if you find additional information.

[dragonflyuk]

It has happened more than once, but is only intermittent, which I realize makes it a about the worst possible sort of issue to pin down. I agree it is most likely a network issue, however as it's so intermittent would it be possible to trap the exception, and retry at least once?

[RobHofmann]

A retry is simply a workaround. I'd rather solve this at the root of the issue than applying a patch which will be applied to all the users (also the ones who don't have any issue with this).

Feel free to fork this repo and apply the retry for yourself, but i'd rather not add it to this main repo.

[dragonflyuk]

I can see your point of view, I'll keep an eye things see if I can spot a pattern.

[dragonflyuk]

I did get a cluster of these this morning from several devices. Doesn't really help with the diagnosis as far as I can work out

Update for climate.bedroom_downstairs_ac fails 5:04 AM custom_components/gree/climate.py (ERROR) - message first occured at 4:01 AM and shows up 4 times Update of climate.bedroom_downstairs_ac is taking over 10 seconds 5:04 AM main.py (WARNING) - message first occured at 4:01 AM and shows up 4 times Error doing job: Task exception was never retrieved 5:00 AM custom_components/gree/climate.py (ERROR) Update for climate.kitchen_ac fails 4:35 AM custom_components/gree/climate.py (ERROR) Update of climate.kitchen_ac is taking over 10 seconds 4:35 AM main.py (WARNING) Update for climate.bedroom_upstairs_ac fails 3:48 AM custom_components/gree/climate.py (ERROR) Update of climate.bedroom_upstairs_ac is taking over 10 seconds 3:48 AM main.py (WARNING)

[RobHofmann]

It simply tells you that home assistant can't reach the AC.

Can mean 3 things which I can think of:

• Home Assistant is running on a slow device and fails to handle the request/response
• Your network has issues which gets you this result
• Your AC is slow/unresponsive and can't handle the request/response

The first is fairly easy to test. Do any other TCP/UDP connections to other devices/services (also HTTP etc) work? Then its probably not the first.

The second is a little harder, but you could try to ping the device (not sure if ping is on). Also Gree uses the UDP which does not guarantee that your packets are delivered, so its harder to test (afaik). You could do some googling into this. You could also try to ping & connect to other endpoints within your network with high speed to see if packets are dropping.

If you have the first and second option working, this will be fairly easy. If other devices in your network work fine from your computer (so packets are delivered) and your home assistant can connect to other services fine, then the issue is probably AC related. Maybe a faulty hardware board?

In other words: a lot can go wrong and you need to do some further testing.