You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Im running Home-Assistant and Node-Red on top of K8s. Node-Red is connecting to HA over K8s service.
When i forcefully kill node on which HA is running, websocket connection hangs in some weird state.
Its not receiving new events, and unable to publish anything. After some time NR detects connection failure and establish new one.
In below log i killed HA node arround 10:14, new HA instance was spawned ~10:17 - but NR->HA WS connection was restored 10:30.
17 Oct 10:10:25 - [info] [server:Home Assistant] Connected to http://home-assistant.smart-home:8123
17 Oct 10:16:31 - [error] [api-render-template:Get unavailable sensor] Error get-template: connect ETIMEDOUT 10.43.183.41:8123
17 Oct 10:17:30 - [error] [api-render-template:Get unavailable sensor] Error get-template: connect ETIMEDOUT 10.43.183.41:8123
17 Oct 10:18:30 - [error] [api-render-template:Get unavailable sensor] Error get-template: connect ETIMEDOUT 10.43.183.41:8123
[...]
17 Oct 10:30:02 - [info] [server:Home Assistant] Connection closed to http://home-assistant.smart-home:8123
17 Oct 10:30:02 - [info] [server:Home Assistant] Connecting to http://home-assistant.smart-home:8123
17 Oct 10:30:02 - [info] [server:Home Assistant] Connected to http://home-assistant.smart-home:8123
Connection to HA is terminated on K8s service (this is why it didnt noticed HA failure).
To better/faster detect WS failures can we add keepalive to node-red-contrib-home-assistant-websocket?
If we can just sent ping every N seconds, and after X failures forcly close connection - we should be able to recover much faster from this kind of issue.
I would love to help with implementation, but JS/TS is little black magic for me :) If i can help in testing or anything just ping me and i will be happy to do so.
To Reproduce
On my environment:
Run HA+NR on K8s
Connect NR to HA WS over K8s service
Kill node on which HA is running
Spawn new HA POD
Probably same can be tested without K8s, just using simple LB between NR and HA but im not sure.
Expected behavior
NR able to detect WS failure much faster.
Screenshots
No response
Example Flow
No response
This package's version
0.34.0
Is Node-RED running in Docker?
Yes
Node-RED version
2.0.6-12
Node.js version
v12.22.6
Additional context
No response
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Describe the bug
Im running Home-Assistant and Node-Red on top of K8s. Node-Red is connecting to HA over K8s service.
When i forcefully kill node on which HA is running, websocket connection hangs in some weird state.
Its not receiving new events, and unable to publish anything. After some time NR detects connection failure and establish new one.
In below log i killed HA node arround 10:14, new HA instance was spawned ~10:17 - but NR->HA WS connection was restored 10:30.
Connection to HA is terminated on K8s service (this is why it didnt noticed HA failure).
To better/faster detect WS failures can we add keepalive to
node-red-contrib-home-assistant-websocket
?I see that
home-assistant-js-websocket
is already exposingping
method - https://github.com/home-assistant/home-assistant-js-websocket/blob/fdbeeee943e7f89f80db84ce2a42a41db9120be3/lib/connection.ts#L221If we can just sent ping every N seconds, and after X failures forcly close connection - we should be able to recover much faster from this kind of issue.
I would love to help with implementation, but JS/TS is little black magic for me :) If i can help in testing or anything just ping me and i will be happy to do so.
To Reproduce
On my environment:
Probably same can be tested without K8s, just using simple LB between NR and HA but im not sure.
Expected behavior
NR able to detect WS failure much faster.
Screenshots
No response
Example Flow
No response
This package's version
0.34.0
Is Node-RED running in Docker?
Yes
Node-RED version
2.0.6-12
Node.js version
v12.22.6
Additional context
No response
The text was updated successfully, but these errors were encountered: