-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenTherm Gateway serial connection issue #101518
Comments
Hey there @mvn23, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) opentherm_gw documentation |
Connection drops are common on the WiFi version of the gateway. Unfortunately we never identified a real root cause. The log message is a known bug in You could try to flash different firmware on your WiFi chip (I assume an ESP8266 variant?) to see if it helps. As long as the firmware can pass through the raw serial data to the network it should work, but there have been some problems with specific releases in the past. |
Don't connect multiple things to the gateway at the same time. See also the warning in the docs. |
Thanks, yes I know this. Only HA is connected nothing else. |
You may want to double check that. Something other than Home Assistant is trying to set the clock on our gateway. Otmonitor for example does this by default I believe. |
Thank you, I checked all other sources and nothing else is trying to use OTGW. What else should be enabled allowing Climate.Dietrch (name in my case) to start Flame in When I did this using physical thermostat (SALUS WQ610 RF) it works, and Climate.Dietrch in HA reflects exact setting of that thermostat (WQ610 RF's target temperature change is visible instantly in Climate.Dietrch ). Flame is started. |
I tried to find a pattern with
however it happens 5 to 8 times per 24h with random SC values. Nothing else is connected to OTGW, just HA. |
This may be caused by the firmware you're using. Nodo-shop refers to this firmware on their website, which also interprets the protocol and sends some commands to the gateway (the changelog refers to |
Thank you for your reply. Can you tell me which (if any other) firmware should be OK for this OTGW from Nodo-shop? |
Edit: I found the issue. The root cause was me disallowing egress traffic from the gateway so it could not access the NTP server. I suspect I may be affected by this issue. I've also been using OTGW from Nodo Shop since last year, and it worked flawlessly through fall and winter. Yesterday, I realized the rooms were not heating up, so I began to investigate (I'm using it in Standalone mode). I haven't been able to pinpoint the issue yet, but I'm starting to believe it may be related to socket disconnections. In my case, the entities don't reach the point where they become unavailable, but the CH setpoint resets to 0 after a minute. I have the latest firmware now, but I only upgraded when I noticed the resets. |
I haven't tested any specific firmware, but anything that passes the serial data without altering or adding any data should work.
This is a feature, not a bug. It was introduced in OpenTherm Gateway firmware 5.2 as a safety precaution. See also the changelog and the command documentation.
If you want the CH setpoint to persist, please create a timer to repeat the command every minute (or less). |
@mvn23, I fixed the problem by allowing egress traffic from the gateway (to access ntp server). However, I wasn't aware that you need to repeat the setpoint in standalone mode; I thought it would maintain the setpoint as long as the socket is open. I believe the Nodo firmware abstracts this for Home Assistant, since I don't need to repeat the setpoint myself |
Can you tell what firmware works in your HW?
A connection to my local NTP server (instead of default external) is enabled now. Can you point me how to override the thermostat temperature (WQ610 physical device) to start boiler heating using HA?
Does anyone used DEV version of WeMos D1 Mini FW using https://github.com/rvdbreemen/OTGW-firmware/tree/dev In reboot_log.txt of "FSexplorer ESP" I found:
Maybe this is some hint for developer ... |
I believe you can't use standalone mode if you have a thermostat plugged. In the standalone mode I just call
|
I have a gateway with a wired ethernet module, so no ESP firmware.
I don't see that particular thermostat in the OpenTherm Gateway equipment matrix. To override the room setpoint on the thermostat it needs to support message ID 9. You can use otmonitor to check that by looking in the
Where the timestamp will of course be different. The rest of the line should be the same.
This is not related to Home Assistant. If you experience problems with unexpected reboots of your gateway with that firmware, please report it to https://github.com/rvdbreemen/OTGW-firmware |
Thanks for your answers. Summarizing: there is no known solution to fix the:
|
The problem
Hello,
I see the following report in the log while OpenTherm gateway is trying to communicate to the HW, when setting are read or write.
During this all OpenTherm's sensors became "unavailable", and then after few seconds they back to live again.
Hardware is connected to HA using socket://localip:25238 over WiFi.
Generally OpenTherm gateway works, but such log is generated from time-to-time
What version of Home Assistant Core has the issue?
core-2023.10.0
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
OpenTherm Gateway
Link to integration documentation on our website
https://www.home-assistant.io/integrations/opentherm_gw/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Logger: homeassistant Source: util/async_.py:121 First occurred: 09:35:11 (1 occurrences) Last logged: 09:35:11 Error doing job: Exception in callback SerialTransport._call_connection_lost(None) Traceback (most recent call last): File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run self._context.run(self._callback, *self._args) File "/usr/local/lib/python3.11/site-packages/serial_asyncio/__init__.py", line 417, in _call_connection_lost self._serial.close() File "/usr/local/lib/python3.11/site-packages/serial/urlhandler/protocol_socket.py", line 104, in close time.sleep(0.3) File "/usr/src/homeassistant/homeassistant/util/async_.py", line 164, in protected_loop_func check_loop(func, strict=strict) File "/usr/src/homeassistant/homeassistant/util/async_.py", line 121, in check_loop raise RuntimeError( RuntimeError: Detected blocking call to sleep inside the event loop. Use `await hass.async_add_executor_job()`; This is causing stability issues. Please report issue
Additional information
No response
The text was updated successfully, but these errors were encountered: