Timeout of all vsh devices with Node-Red 4.0.2

[namirda]

Bug Description

I have been using vsh for some time now on Node-Red v3.1.11 in a docker container. Works great - thanks.

Today I tried to update to my flows to Node-Red V4.0.2 and now all my vsh nodes have the status

ERROR ETIMEDOUT Periodically Retrying

The log file is full of lines like :

3 Aug 13:25:18 - [info] [vsh-connection:xxx@xxx.com] MQTT: publish to topic vsh/vsht-1d38eb10-dc54-4296-95c5-f7780f16e39a/changeReport: {"template":"TEMPERATURE_SENSOR","endpointId":"vshd-f7149c0d8a33ac0b","properties":[{"namespace":"Alexa.TemperatureSensor","name":"temperature","value":{"value":21.5,"scale":"CELSIUS"},"changed":true}],"correlationToken":"","causeType":"PHYSICAL_INTERACTION","vshVersion":"4.4.1","userIdToken":""}
3 Aug 13:25:40 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: error: {"code":"ETIMEDOUT"}
3 Aug 13:25:40 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: error: {"code":"ETIMEDOUT"}
3 Aug 13:25:40 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: connection closed
3 Aug 13:26:42 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: error: {"code":"ETIMEDOUT"}
3 Aug 13:26:42 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: error: {"code":"ETIMEDOUT"}
3 Aug 13:26:42 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: connection closed

Apart from the Node-Red update, nothing has changed in my setup.

I also note that when I dblclk on any vsh node to see the config, I see that my plan is set to "UNKNOWN" rather than "PRO" but when I look at the connection config I still see "PRO" along with a list of all my devices

When I downgrade back to Node-Red V3.1.11 then everything is working again.

Thanks for any advice

To Reproduce

Deploy VSH virtual device node in Node-Red V4.0.2

Expected behavior

It should work the same as with previous Node-Red versions.

Virtual-Smart-Home Version

4.1.2

Node-RED Version

4.0.2

Node.js Version

20.15.1

Plan

PRO

Thing-ID

vsht-1d38eb10-dc54-4296-95c5-f7780f16e39a

[csuermann]

Hi @namirda,

Thanks for reaching out! I could not reproduce this issue with Node-RED 4.0.2. Could you please share the exact Docker command(s) you are using?

[namirda]

Thanks for looking into this. I was able to reproduce the issue with a very simple configuration.

I created a fresh docker-compose file containing the following:

version: "3.7"

services:
  node-red:
    image: nodered/node-red:latest

    environment:
      - TZ=Pacific/Auckland

    ports:
      - "1877:1880"

    volumes:
      - /docker/testred/data:/data

where /docker/testred/data was an empty directory. After 'docker-compose up' I get a new empty workspace as expected.

I then added your 'node-red-contrib-virtual-smart-home' to the palette, dragged a 'virtual device' onto the empty workspace and followed your instructions to use the same Amazon connection as for my regular flows by logging into my Amazon account and entering a code. All seemed to go OK and the connection details were filled as expected. I also selected 'debug' for the connection. After deploying the flow, the 'vsh device' node shows the status "ERROR ETIMEDOUT Periodically retrying".

The log of the run looks like this:

Pulling node-red (nodered/node-red:latest)...
latest: Pulling from nodered/node-red
a258b2a6b59a: Already exists
acc68e5f4ed0: Already exists
26adbb8128d0: Already exists
7a3df4625baf: Already exists
4badac3b1cd3: Pull complete
9f6982cd3800: Pull complete
a89c3f502eab: Pull complete
4f4fb700ef54: Pull complete
8950f9001169: Pull complete
281fa3936baf: Pull complete
f7c44440802e: Pull complete
e58e941eaf58: Pull complete
b1ee9d75536a: Pull complete
c2e05f2a8c21: Pull complete
6622298fa62c: Pull complete
2d5af24db662: Pull complete
0cd61beab722: Pull complete
Digest: sha256:fa8fbcf2ddc1e1b2cdea3c1e6d027413f583956fc499289c432650a3ea03c10b
Status: Downloaded newer image for nodered/node-red:latest
Creating testred_node-red_1 ... done
Attaching to testred_node-red_1
node-red_1  | 5 Aug 03:31:17 - [info]
node-red_1  |
node-red_1  | Welcome to Node-RED
node-red_1  | ===================
node-red_1  |
node-red_1  | 5 Aug 03:31:17 - [info] Node-RED version: v4.0.2
node-red_1  | 5 Aug 03:31:17 - [info] Node.js  version: v20.15.1
node-red_1  | 5 Aug 03:31:17 - [info] Linux 6.1.30-rockchip64 arm64 LE
node-red_1  | 5 Aug 03:31:18 - [info] Loading palette nodes
node-red_1  | 5 Aug 03:31:23 - [info] Settings file  : /data/settings.js
node-red_1  | 5 Aug 03:31:23 - [info] Context store  : 'default' [module=memory]
node-red_1  | 5 Aug 03:31:23 - [info] User directory : /data
node-red_1  | 5 Aug 03:31:23 - [warn] Projects disabled : editorTheme.projects.enabled=false
node-red_1  | 5 Aug 03:31:23 - [info] Flows file     : /data/flows.json
node-red_1  | 5 Aug 03:31:23 - [info] Server now running at http://127.0.0.1:1880/
node-red_1  | 5 Aug 03:31:23 - [warn]
node-red_1  |
node-red_1  | ---------------------------------------------------------------------
node-red_1  | Your flow credentials file is encrypted using a system-generated key.
node-red_1  |
node-red_1  | If the system-generated key is lost for any reason, your credentials
node-red_1  | file will not be recoverable, you will have to delete it and re-enter
node-red_1  | your credentials.
node-red_1  |
node-red_1  | You should set your own key using the 'credentialSecret' option in
node-red_1  | your settings file. Node-RED will then re-encrypt your credentials
node-red_1  | file using your chosen key the next time you deploy a change.
node-red_1  | ---------------------------------------------------------------------
node-red_1  |
node-red_1  | 5 Aug 03:31:23 - [info] Starting flows
node-red_1  | 5 Aug 03:31:23 - [info] Started flows
node-red_1  | 5 Aug 03:32:06 - [info] Stopping flows
node-red_1  | 5 Aug 03:32:06 - [info] Stopped flows
node-red_1  | 5 Aug 03:32:06 - [info] Updated flows
node-red_1  | 5 Aug 03:32:06 - [info] Starting flows
node-red_1  | 5 Aug 03:32:06 - [info] Started flows
node-red_1  | 5 Aug 03:33:08 - [info] Stopping flows
node-red_1  | 5 Aug 03:33:08 - [info] Stopped flows
node-red_1  | 5 Aug 03:33:08 - [info] Updated flows
node-red_1  | 5 Aug 03:33:08 - [info] Starting flows
node-red_1  | 5 Aug 03:33:08 - [info] Started flows
node-red_1  | 5 Aug 03:33:09 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: attempting connection: a1pv0eq8s016ut-ats.iot.eu-west-1.amazonaws.com:8883 (clientId: vsht-9b9a58d8-8607-4251-bf5b-52ae83e7a7a1)
node-red_1  | 5 Aug 03:33:11 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: error: {"code":"ETIMEDOUT"}
node-red_1  | 5 Aug 03:33:11 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: error: {"code":"ETIMEDOUT"}
node-red_1  | 5 Aug 03:33:11 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: connection offline
node-red_1  | 5 Aug 03:33:11 - [info] [vsh-connection:xxxx@xxxx.com] MQTT: connection closed
^CGracefully stopping... (press Ctrl+C again to force)
Stopping testred_node-red_1 ... done

Finally, when I modify the exact same docker-compose file to pull Node-Red V3.1.11 then everything works as normal.

Thanks for any hints!

[csuermann]

Thanks for providing these details!

My hunch is that the issue might stem from Node.js v20, used by Node-RED v4, which changed some network-related defaults. Try adding the following line to the environment section of your Docker Compose file:

- NODE_OPTIONS=--no-network-family-autoselection

[namirda]

Your hunch is correct - that fixed it!!

Will it be required to add those node_options to all node-red instances containing vsh nodes from NRV4 onwards?

[csuermann]

Glad to hear my hunch was correct! 🎉

Will it be required to add those node_options to all node-red instances containing vsh nodes from NRV4 onwards?

The -no-network-family-autoselection directive restores the behavior which used to be the default in Node.js versions <20. Having said that, it shouldn't be needed unless your local router or ISP has problems connecting to IPv6 networks.