Closed Wummeke closed 5 years ago
Hi all, I've updated my Hass in Docker to version 0.82.0 and now there is no (stable) connection to my OTGW anymore. Last working version for me was 0.81.6.
my OpenTherm Monitor still receives the stream fine over telnet connection.
dev-info output:
Timed out waiting for command: PR, value: I. Are you connecting to the OpenTherm Gateway? 10:54 util/async_.py (ERROR) Unknown message in command queue: OpenTherm Gateway 4.2.5 10:54 util/async_.py (WARNING)
To follow up, I believe it is something within HA... The OT Monitor log shows 'PR: I=11' every ten seconds or so. This indicates that HA is sending commands to the gateway and the gateway in turn receives and acknowledges the request. However, HA does not receive or handles the messages.
@joep2000 your log indicates that your gateway has rebooted unexpectedly while HA was waiting for a response to a PR=I
command. Nothing I can do about that. The periodical PR: I=11
messages you're seeing are there because your GPIO pins have been configured with a function other than 0. Polling is the only way to keep an eye on their state, but I may optimize this in a future version (no polling if configured always high/low). If you don't see related errors in HA's log this is expected behavior and the messages are being handled.
@mvn23: how come that adding debug level to logger and restarting HASS made it to work?
it's working now, TT changes the thermostat value and the only 'errors' in log I can see are:
Unknown message in command queue: Medium power
Unknown message in command queue: Low power
But it's working. Strange as hell, as I didn't do anything new...
I guess it is a matter of synchronisation. Sometimes when disconnected I can restore the connection by restarting HASS, and sometimes by restarting the OTGW/ESP combination.
Just quick update: I've restarted HASS dozens of times (reconfiguration to OT component from external-MQTT). Not a problem even once so far.
I've meanwhile updated to 0.82, and migrated from ResinOS to HassOS. Reporting seems to be stable now, until the OTGW/NodeMCU reboots (the watchdog auto-reboots it from time to time), after which the connection is lost and a restart of home assistant is required.
I didn't try rebooting otgw/nodemcu itself yet...
the OTGW/NodeMCU reboots (the watchdog auto-reboots it from time to time), after which the connection is lost and a restart of home assistant is required.
I'm working on an auto-reconnect on inactivity feature, but it's difficult to test on a stable connection while I'm away from home (happens quite a lot). Can't you disable the watchdog in the mean time? Neither the gateway nor the NodeMCU should not require any reboots...
@mvn23 thing with TC vs TT - seems to show up after I changed setpoint on thermostat, it's not relevant in UI anymore (not updated), even tho boiler started working and it's status (heating) is proper in HASS
@mvn23 thing with TC vs TT - seems to show up after I changed setpoint on thermostat, it's not relevant in UI anymore (not updated), even tho boiler started working and it's status (heating) is proper in HASS
That bug was fixed in #18286
Even from otmonitor I often mis a response for given commands. So i doubt that this is a HA issue. It looks as if I time my command between two "data-bursts" the response comes back. As if commands not getting queued or something. Just a noob observation ;)
Ok, now after few days and restarting HASS it 'lost' connectivity to (not restarted) OTGW.
It looks as if I time my command between two "data-bursts" the response comes back.
This is what I am suspecting as well, that transmitting and receiving at the same time causes problems. I took some time to implement retry/reconnect logic in the library to work around this. New code can be found at the retry_reconnect branch of pyotgw, so feel free to test. If it's a success I will push an update soon.
so feel free to test. If it's a success I will push an update soon.
I definitely want to but I’m not sure if I have the opportunity coming days/weekend. If I do, I’ll let you know. Anyway, great that you took the effort to tackle this issue. Appreciate it very much!
What is the way to test? Copy the pyotgw.py, protocol.py and vars.py from github over the existing ones in site-packages/pyotgw folder, and restart HA?
That's what I do when testing for longer periods.
Seems like it works. Got this in my logfile:
Dec 07 02:13:24 pi hass[31520]: 2018-12-07 02:13:24 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: T. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:31 pi hass[31520]: 2018-12-07 02:13:31 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: W. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:37 pi hass[31520]: 2018-12-07 02:13:37 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: I. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:40 pi hass[31520]: 2018-12-07 02:13:40 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: O. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:40 pi hass[31520]: 2018-12-07 02:13:40 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: A. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:43 pi hass[31520]: 2018-12-07 02:13:43 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: S. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:45 pi hass[31520]: 2018-12-07 02:13:45 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: L. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:46 pi hass[31520]: 2018-12-07 02:13:46 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: W. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:48 pi hass[31520]: 2018-12-07 02:13:48 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: P. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:49 pi hass[31520]: 2018-12-07 02:13:49 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: I. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:54 pi hass[31520]: 2018-12-07 02:13:54 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: R. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:54 pi hass[31520]: 2018-12-07 02:13:54 ERROR (MainThread) [pyotgw.pyotgw] Timed out waiting for command: PR, value: O. Are you connecting to the OpenTherm Gateway?
Dec 07 02:13:56 pi hass[31520]: 2018-12-07 02:13:55 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Dec 07 02:13:56 pi hass[31520]: Traceback (most recent call last):
Dec 07 02:13:56 pi hass[31520]: File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
Dec 07 02:13:56 pi hass[31520]: result = coro.send(None)
Dec 07 02:13:56 pi hass[31520]: File "/home/pi/opt/homeassistant/lib/python3.5/site-packages/pyotgw/pyotgw.py", line 98, in connect
Dec 07 02:13:56 pi hass[31520]: await self.get_reports()
Dec 07 02:13:56 pi hass[31520]: File "/home/pi/opt/homeassistant/lib/python3.5/site-packages/pyotgw/pyotgw.py", line 270, in get_reports
Dec 07 02:13:56 pi hass[31520]: status.update({OTGW_SB_TEMP: float(sb_temp)})
Dec 07 02:13:56 pi hass[31520]: ValueError: could not convert string to float: 'OpenTherm Gateway 4.2.5'
But OTGW is still connected!
That's a very strange error to say the least. It may indicate an unexpected reset of the gateway. I added some debug logging to the retry_reconnect branch. Could you update and enable debug logging for the library?
logger:
default: warning
logs:
pyotgw.pyotgw: debug
pyotgw.protocol: debug
I'm testing retry_reconnect too. First observation - it was able to 'reconnect' itself to proper data, when normal restarts of HASS didn't help. Will see how it goes further.
I also really appreciate your work. Would like to have it stable as controller. :-)
Thanks for the update! Now it makes it hard to recognize when there was a connectionproblem, due to the huge amount of debug logs and the system reconnects itself... How can I find if and when the problem has occured?
It will throw one or more WARNING
messages in the log if a command has to be resent due to an erroneous response, or the usual TimeOut
if it gets no response at all.
If it detects inactivity on the connection, it will throw DEBUG
messages like Reconnecting to serial device on <path>
. I just realized maybe it should throw a WARNING
there as well...
It will throw an ERROR
if it fails to connect.
What showed in log (no debug tho). It looks like it managed to reconnect, as it seems to still work.
ERROR:
Could not connect to serial device on socket://x.x.x.x:xxxx. Will keep trying. Reported error was: Could not open port socket://x.x.x.x:xxx: timed out
ERROR:
Error doing job: Task was destroyed but it is pending!
Ok, finally have some time to try this, but... Don't know how to copy the 3 files to hassio. Tried to replace the files in /usr/local/lib/python3.6/site-packages/pyotgw
while in the container. But after a restart I belief they have been replaced with the original ones. If I do a find from outside the container I see 3 occurences of the files. Twice with a path like /var/lib/docker/overlay2/3d06......8ab9518/diff/usr/local/lib/python3.6/site-packages/pyotgw/
and once with /var/lib/docker/overlay2/3d06......8ab9518/merged/usr/local/lib/python3.6/site-packages/pyotgw
. Do I replace any of those files? Anyone care to learn me something ;)
I'm testing it for few days already. Is it possible that while it has connection/reconnection issues, the component makes whole async overloaded with task and other components may also have problems? I think it's causing some kind of hiccups of performance or other sensors refreshing issues which I didn't have before (like darksky or synologydsm on local network)
Is it possible that while it has connection/reconnection issues, the component makes whole async overloaded with task and other components may also have problems?
I'll look into this soon.
I am running with the debug version for a while now:
pi@pi:~ $ journalctl -b --no-pager | grep -i watchdog
Dec 19 17:17:28 pi hass[14998]: 2018-12-19 17:17:28 DEBUG (MainThread) [pyotgw.protocol] Watchdog triggered!
Dec 19 20:34:40 pi hass[16118]: 2018-12-19 20:34:40 DEBUG (MainThread) [pyotgw.protocol] Watchdog triggered!
Dec 20 14:45:08 pi hass[16118]: 2018-12-20 14:45:08 DEBUG (MainThread) [pyotgw.protocol] Watchdog triggered!
Dec 21 05:19:57 pi hass[25580]: 2018-12-21 05:19:57 DEBUG (MainThread) [pyotgw.protocol] Watchdog triggered!
Dec 21 12:09:06 pi hass[29188]: 2018-12-21 12:09:06 DEBUG (MainThread) [pyotgw.protocol] Watchdog triggered!
Some are relating to times when I was restarting HASS, but others did not.
So what other information do you like to get?
Any warnings, errors and all output from pyotgw would be great. That will be a lot of data, so please use hastebin or similar.
I do not like to share my complete log on the internet, but no problem to send it you. Are you the same mvn23 at Tweakers? I can send you a pm over there.
Are you the same mvn23 at Tweakers?
The very same.
May be reopened due to a bug in the updated lib. Working on a patch.
Home Assistant release with the issue: 0.79.3
Last working Home Assistant release (if known): None
Operating environment (Hass.io/Docker/Windows/etc.): I am running Home Assistant from Docker
Component/platform: https://www.home-assistant.io/components/climate.opentherm_gw/
Description of problem: Component does not work basicly. I sometimes have to reboot Home Assistant a few times to get the component going:
and When it finally works, it stops working after a few minutes. When I try to change the temperature an error is added to the log:
My openthermgateway is connected to a nodeMCU with ESP Easy running ser2net.
Problem-relevant
configuration.yaml
entries and (fill out even if it seems unimportant):Additional information: Here a log of a 'successful' connection after reboot and then almost imediately a crash of the component when I try to set a temperature: