search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
70.47k stars 29.41k forks source link

Setup of platform opentherm_gw is taking over 10 seconds. #16739

Closed bartandeweg closed 5 years ago

bartandeweg commented 5 years ago

Home Assistant release with the issue: 0.78.0

Last working Home Assistant release (if known): None: New platform

Operating environment (Hass.io/Docker/Windows/etc.): Hass.io

Component/platform: OpenTherm Gateway

Description of problem: Can't get my opentherm gateway up and running using Hassio. Got the following errors in my log: Mybe @mvn23 knows what is going on

2018-09-20 09:53:27 WARNING (MainThread) [homeassistant.components.climate] Setup of platform opentherm_gw is taking over 10 seconds. 

2018-09-20 09:53:27 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py", line 342, in _async_add_entity
    await entity.async_added_to_hass()
  File "/usr/local/lib/python3.6/site-packages/homeassistant/components/climate/opentherm_gw.py", line 66, in async_added_to_hass
    await self.gateway.connect(self.hass.loop, self._device)
  File "/usr/local/lib/python3.6/site-packages/pyotgw/pyotgw.py", line 55, in connect
    await self.get_reports()
  File "/usr/local/lib/python3.6/site-packages/pyotgw/pyotgw.py", line 170, in get_reports
    OTGW_DEFAULT_TIMEOUT, loop=self.loop)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

  - platform: opentherm_gw
    device: /dev/ttyAMA0

Traceback (if applicable):

Additional information: Had the OTGW working on my VERA. It's connect via an serial to ethernet connection.

mvn23 commented 5 years ago

Thanks for the report. Are you running Home Assistant on a Raspberry Pi? If so, this may help. Please report back if that solves your issue so we can update the documentation.

bartandeweg commented 5 years ago

I've used the PI all in one installer of Hass.io. None of the commands is found. This can be that i'm using SSH as from an addon? Maybe i'm in a addon container and should enable SSHing to the Raspberry itself?

My other USB devices (ZWAVE STICK, or Smart Meter) are working jut fine by the way.

mvn23 commented 5 years ago

I'm trying to get my hands on a rpi for testing, but it may take a while. Also, I have the USB version of the gateway so I can not reproduce your situation 100%. In the meantime, maybe someone who is more familiar with hass.io can take a look at this? A quick search has taught me that there is at least one other issue with hass.io and the ttyAMA0 port on the rpi, see https://github.com/home-assistant/hassio/issues/370

bartandeweg commented 5 years ago

Thanks for your reply. I did take a look at topic home-assistant/hassio#370 and tried the solution mentioned there. Switched to USB1 and it works like a boss!

bartandeweg commented 5 years ago

Bummer. After updating to version 0.80.0 the error is back again. Still connected to ttyUSB1

Error doing job: Task exception was never retrieved

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py", line 352, in _async_add_entity
    await entity.async_added_to_hass()
  File "/usr/local/lib/python3.6/site-packages/homeassistant/components/climate/opentherm_gw.py", line 66, in async_added_to_hass
    await self.gateway.connect(self.hass.loop, self._device)
  File "/usr/local/lib/python3.6/site-packages/pyotgw/pyotgw.py", line 55, in connect
    await self.get_reports()
  File "/usr/local/lib/python3.6/site-packages/pyotgw/pyotgw.py", line 170, in get_reports
    OTGW_DEFAULT_TIMEOUT, loop=self.loop)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
mvn23 commented 5 years ago

That's strange to say the least, as there has been only 1 small change in another part of the code between 0.78 and 0.80 as far as this platform and its dependencies go. There are some staged changes for 0.81 already and I currently have 1 PR waiting for approval and another one ready to go as soon as the first one is accepted. In the mean time I will work on improved error handling, so hopefully we can at least get some more useful error messages in the future. Would you be willing to test some code when I get to work on this? Unfortunately everything is working fine for me, so I can only test induced error conditions ;) As for your current problem, I'm sure you have tried a full reset of the pi and the gateway, right?

Edit: If it helps, this error only occurs when the connection to the device can be made successfully, but the device does not reply with the expected responses.

bartandeweg commented 5 years ago

Found the problem. After again a total reboot of the pi also my DSMR did not work anymore. Which is also connetect thru an USB. Strangely my ports shifted. So i now have an tty/USB2 on board and had to change the OTGW to this instead of USB1 and my DSMR to USB1 instead of USB0.

No problem to test code before pushing this to the release track.

One more questrion: Do you have roadmap in your head for this platform?

mvn23 commented 5 years ago

Looks like you need some udev trickery to get everything in a fixed path, but I don't know how easy that is with Hass.io. I was actually hoping to test some unknown error condition, but it turns out there isn't one anymore ;) As for the roadmap:

However, due to Hacktoberfest, the reviewers are rather busy so PR approval is taking some time. I am hoping to get sensors and binary_sensors approved for 0.81, but I can't guarantee anything.

pascalbuijs commented 5 years ago

I have a similar error with version 0.81. Hass.io 138. I used the following config.

opentherm_gw:
    device: socket://192.168.1.240:6638
    climate:
        name: Thermostat
        precision: 0.5
        floor_temperature: True
    monitored_variables:
        - room_setpoint
        - room_temp
        - otgw_about

After connecting it to domoticz, disconnect it and restart Home Assistant it is working untill the next restart. When i connect both via the OpenTherm monitor relay server i see that the Home Assistant sends different messages to the gateway then domoticz. 192.168.1.250 is my domoticz server see log below. Can it be that something is missing in the code why some people having trouble connecting? 

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/homeassistant/components/opentherm_gw.py", line 75, in connect_and_subscribe
    await gateway.connect(hass.loop, device_path)
  File "/usr/local/lib/python3.6/site-packages/pyotgw/pyotgw.py", line 52, in connect
    await self.get_reports()
  File "/usr/local/lib/python3.6/site-packages/pyotgw/pyotgw.py", line 165, in get_reports
    ret = await self._wait_for_cmd(cmd, value)
  File "/usr/local/lib/python3.6/site-packages/pyotgw/pyotgw.py", line 690, in _wait_for_cmd
    loop=self.loop)
  File "/usr/local/lib/python3.6/asyncio/tasks.py", line 362, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

21:16:01.374959 00000010/00000000,65.90,00000011/00000011,100.00,0/0,19.84,0.00,0.00,19.86,58.10,0.00,0.00,0.00,60/40,75/20,60.00,90.00,65535,65535,65535,65535,24400,27960,58440,1768
21:16:25.983555 Command (via relay server, from 192.168.1.99:38248): PR=A
21:16:26.068606 PR: A=OpenTherm Gateway 4.2.5
21:16:26.323120 Command (via relay server, from 192.168.1.99:38248): PR=B
21:16:26.476946 PR: B=17:59 20-10-2015
21:16:26.504812 Command (via relay server, from 192.168.1.99:38248): PR=C
21:16:30.976201 Command (via relay server, from 192.168.1.250:57674): SC=21:16/1
21:16:31.016611 Command (via relay server, from 192.168.1.250:57674): PR=G
21:16:31.020283 Command (via relay server, from 192.168.1.250:57674): PR=I
21:16:31.023356 Command (via relay server, from 192.168.1.250:57674): PR=O
21:16:31.026522 Command (via relay server, from 192.168.1.250:57674): PS=1
21:16:31.133361 SC: 21:16/1
21:17:00.984261 Command (via relay server, from 192.168.1.250:57674): SC=21:16/1
21:17:01.024754 Command (via relay server, from 192.168.1.250:57674): PR=G
21:17:01.026871 Command (via relay server, from 192.168.1.250:57674): PR=I
21:17:01.030510 Command (via relay server, from 192.168.1.250:57674): PR=O
21:17:01.033689 Command (via relay server, from 192.168.1.250:57674): PS=1
21:17:01.131401 SC: 21:16/1
21:17:30.991973 Command (via relay server, from 192.168.1.250:57674): SC=21:17/1
21:17:31.032094 Command (via relay server, from 192.168.1.250:57674): PR=G
21:17:31.034837 Command (via relay server, from 192.168.1.250:57674): PR=I
21:17:31.038842 Command (via relay server, from 192.168.1.250:57674): PR=O
21:17:31.042474 Command (via relay server, from 192.168.1.250:57674): PS=1
21:17:31.204347 SC: 21:17/1
21:17:31.246211 PR: G=00
21:17:31.250105 PR: I=00
21:17:31.256272 PR: O=t20.00
21:17:31.259584 PS: 1
21:17:31.422474 00000010/00000000,66.00,00000011/00000011,100.00,0/0,19.84,0.00,0.00,19.86,57.66,0.00,0.00,0.00,60/40,75/20,60.00,90.00,65535,65535,65535,65535,24400,27960,58440,1768
21:18:01.007108 Command (via relay server, from 192.168.1.250:57674): SC=21:17/1
21:18:01.046344 Command (via relay server, from 192.168.1.250:57674): PR=G
21:18:01.048083 Command (via relay server, from 192.168.1.250:57674): PR=I
21:18:01.052357 Command (via relay server, from 192.168.1.250:57674): PR=O
21:18:01.056005 Command (via relay server, from 192.168.1.250:57674): PS=1
21:18:01.177083 SC: 21:17/1
mvn23 commented 5 years ago

Thanks for the info. Looks like Domoticz isn't getting all the answers it's hoping for all the time either (every PR= message should be answered with a PR: message). It's probably less picky about it though. I've ordered an ESP8266 yesterday to see if I can reproduce the problem, that should make debugging a lot easier.

pascalbuijs commented 5 years ago

Thanks for your reply. Hoping for a solution. This is the only obstacle left in moving from Domoticz to Homeassistant. If i can do someting let me know.

balloobbot commented 5 years ago

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 :+1:

bartandeweg commented 5 years ago

Works for me now. Running stable