When I am connected in local LAN deploy takes up to 60 seconds.
When I use VPN (Wireguard) to my router (still in LAN) deploy is less then 1 second
It is quite difficult for me to understand why?
When I install HA from a 2 weeks old backup and upgrade everything then deploy works in LAN as before ⌠Is there any websockets buffer which runs full?
The terminology used can be very confusing, particularly when we are all new to this, and the âover-loadingâ use of the word âserverâ does not help. It can be all too easy to bash out a stock phrase without appreciating that others may not understand a word of it.
A server can mean a computer (doing the job of running a server), a program that is a server, a service offered by a program that mostly does other stuff but has a service API call offering, etc.
I (me personally) would say that you have a physical machine (device/computer) running a program (proxmox) that hosts (as a virtual machine) a Home Assistant instance. I know many call HA a server, but in my mind it is not a server, it is a program that does stuff and just happens to have API services exposed via a WebSocket.
You have indeed installed Node-RED as a HA addon. This runs Node-RED somewhere on your machine, probably in a proxmox containerâŚ
Node-RED (program) runs a server that offers services for not only running the flows but also running the editor. This server is critical to NR operating, both to run the flows and to run the editor (and the dashboard).
Note that the Node-RED editor, which is what the fuss is all about here, is executed as a web-page with JavaScript that runs on whatever machine/device you are using to view the UI editor.
For the NR editor to work it needs to connect back to Node-RED. The problem is that, with all the containers and virtual machines, there is no way to do this. On a real machine running NR, another real machine running the web-browser editor can easily hop over a local network to the ip:port of the NR server.
When Node-RED is an addon it is probably best run using a fully supervised HA, where the supervisor runs up a docker container to run, then another container for HA, then yet another container for NR. The trick here is that the supervisor opens ports on the containers, and provides an ingress / proxy pathway for the outside world to get in to HA and to Node-RED.
Without this pathway, the outside world (Node-RED editor in web browser) cannot see Node-RED server.
So, no pathway is total failure of the NR editor.
A disrupted pathway is partial failure of the NR editor.
Node-RED is a stand alone program and knows nothing about HA. There is a nice set of âHome Assistant WebSocketâ nodes (the blue ones) that do a great job of connecting back to HA, using the HA provided WebSocket.
In Node-RED, individual nodes are just packets of code that run when called. For a node to connect to the outside world requires a âserverâ or âproxyâ. These, in Node-RED, are special configuration nodes. They mostly sit hidden from sight (you canât add them to the flow) but they provide a connection to another computer / device. Common ones in use are for Modbus, MQTT, serial ports, and Home Assistant.
The Home Assistant configuration node, used by the WebSocket nodes, is called âHome Assistant Serverâ but I think of it as a relay between each flow node and HA. This config node sets up an ongoing connection to HA WebSocket, and acts as a server to the nodes (as clients) by calling (as a client) the HA WebSocket (which is a âserverâ).
This HA WebSocket can be overloaded, at which point it stops working.
For you last point, I would say:
By importing (other peopleâs flows) you have unfortunately added in additional copies of the [Node-RED] Home Assistant Server (WebSocket nodes) configuration node.
You only have one Node-RED. You do have many Configuration Nodes, each running a connection to the HA WebSocket.
If you have many flows running and you donât want to disrupt them, then yes disabling the unwanted extra copies of the HA âserverâ configuration node will cause an issue. I guess, like much in life, you have to make a choice between not having a working NR editor, and not upsetting the apple cart. If editing one node at a time to switch the Home Assistant Server is the only way forward, then that has to be the way.
I have the same problem since a few days ago but only when deploying from a Windows machine (W10 or W11) and when connected by Ethernet cable. If i use a WIFI connection from the same Windows machine it works fine. For the record, i didnât change anything on my network neither on my Home Assistant installation. I just upgraded Home Assistant as always do.
If accessing from MAC OS or Linux machine through both ethernet or WIFI works fine.
Very strange indeed.
Thank you for your excellent post. Very informative and it all makes more sense now
I have now completed the cleanup - I am down to only 1x HomeAssistant configuration node. Unfortunately still the same issue with slow deployment and lack of inject node functionality when accessing throught HA sidebar. When connected directly to port 1880 things are a bit better - but not as fast as when using iOS devices. Seems to be browser related as mentioned here.
-----------------------------------------------------------
Add-on: Node-RED
Flow-based programming for the Internet of Things
-----------------------------------------------------------
Add-on version: 18.0.5
You are running the latest version of this add-on.
System: Home Assistant OS 13.0 (amd64 / qemux86-64)
Home Assistant Core: 2024.8.2
Home Assistant Supervisor: 2024.08.0
-----------------------------------------------------------
Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
s6-rc: info: service base-addon-banner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
Log level is set to INFO
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service init-nginx: starting
s6-rc: info: service init-customizations: starting
s6-rc: info: service init-customizations successfully started
s6-rc: info: service init-nodered: starting
s6-rc: info: service init-nginx successfully started
up to date, audited 222 packages in 4s
24 packages are looking for funding
run `npm fund` for details
22 vulnerabilities (1 low, 8 moderate, 13 high)
To address issues that do not require attention, run:
npm audit fix
To address all issues (including breaking changes), run:
npm audit fix --force
Run `npm audit` for details.
npm notice
npm notice New minor version of npm available! 10.7.0 -> 10.8.2
npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.8.2
npm notice To update run: npm install -g [email protected]
npm notice
s6-rc: info: service init-nodered successfully started
s6-rc: info: service nodered: starting
s6-rc: info: service nodered successfully started
s6-rc: info: service nginx: starting
s6-rc: info: service nginx successfully started
s6-rc: info: service legacy-services: starting
[15:25:52] INFO: Starting Node-RED...
s6-rc: info: service legacy-services successfully started
> start
> node $NODE_OPTIONS node_modules/node-red/red.js --settings /etc/node-red/config.js
20 Aug 15:25:53 - [info]
Welcome to Node-RED
===================
20 Aug 15:25:53 - [info] Node-RED version: v4.0.2
20 Aug 15:25:53 - [info] Node.js version: v18.20.3
20 Aug 15:25:53 - [info] Linux 6.6.44-haos x64 LE
20 Aug 15:25:53 - [info] Loading palette nodes
20 Aug 15:25:54 - [info] Node-RED Contrib Theme Collection version: v4.0.8
20 Aug 15:25:55 - [info] Dashboard version 3.6.5 started at /endpoint/ui
20 Aug 15:25:56 - [info] Settings file : /etc/node-red/config.js
20 Aug 15:25:56 - [info] Context store : 'default' [module=memory]
20 Aug 15:25:56 - [info] User directory : /config/
20 Aug 15:25:56 - [warn] Projects disabled : editorTheme.projects.enabled=false
20 Aug 15:25:56 - [info] Flows file : /config/flows.json
20 Aug 15:25:56 - [info] Server now running at http://127.0.0.1:46836/
20 Aug 15:25:56 - [info] Starting flows
[15:25:56] INFO: Starting NGinx...
20 Aug 15:25:56 - [info] Started flows
20 Aug 15:25:56 - [info] [mqtt-broker:ddfd78f2e0902078] Connected to broker: mqtt://localhost:1883
20 Aug 15:26:01 - [info] [server:Home Assistant] Connecting to http://supervisor/core
20 Aug 15:26:01 - [info] [server:Home Assistant] Connected to http://supervisor/core
There is definitely a Windows related issue here though, as I just replicated MiguelPâs experience: a 2 second deploy when connected Ethernet-Desktop-Linux Mint-Firefox and a 120 second deploy when making the same change connected Ethernet-Desktop-Windows 11-Firefox.
There are quite regular posts around the problem: âNode-RED does not work anymore as I canât deploy and/or use the Inject / Debug nodesâ
Unfortunately there is no simple answer (if there are any answers at all) and I am not aware of any formal âfix listâ or debugging tools / approach. This issue does also seem to be associated more with Home Assistant users than in the general Node-RED forum (where NR will be stand-alone and accessed by a regular browser more than as an HA add-on and accessed via the HA menu page).
At the moment, I think the problem relates to one (or more) specific areas being
the browser in which the editor is being executed, and issues with the browser code / caching / JavaScript / the API calls / Node-RED editor code itself. This may be complicated by running the NR Editor inside of the HA webpage.
the HA WebSocket, and issues with overloading due to multiple HA Servers (config nodes), misbehaving contrib-nodes or nodes that require updates
the path from Node-RED editor (browser) to Node-RED server, and issues with proxy, authorisation, virtual machines / containers not having open ports
So far, my âfix it listâ suggestion is
use Node-RED independently and access directly via ip:1880 where possible, if not use Node-RED as an add-on in a fully supervised setup and thus via ingress and the supervisor proxy
use a good browser, and test out other browsers, clear the cache, try other operating systems if possible
check that you are not overloading the HA WebSocket: check you have only one Home Assistant config node, check other server config nodes are up to date, update the palette, try shutting off config server nodes temporarily
check the HA logs and Node-RED logs for errors, check the system CPU load and memory space for HA, supervisor, and Node-RED in case these are out of memory
A specific operating system (Windows) issue may point to Window Defender, or another Anti-Virus software, being too enthusiastic about checking network traffic. I assume this could also apply to network routers with stateful inspection.
That is the limit of my understanding, but hopefully at least breaking the issue into parts and starting a âhow to fixâ list may be of help to others.
Again, any further input towards this, clearly irritating and yet unsolved issue, is openly welcomed!
Iâd add try using a private browsing window. Browsers have been known not to completely clear the cache, the private window will not use the cache. It also should disable 3rd party browser extensions, at least firefox does.
Browsers also have a console, usually by pressing f12. Firefox has a performance recording mode. It will catch all the actions the browser takes. There is a lot of information in there and Iâm not sure what t look at. You could run it on a win 11 and then a working os to compare the differences.
Good suggestion. I just tried using Firefox private window and experienced the slow (2 minute) deploy. So at least in this instance, the issue appears to be more Windows related than browser related.
Geoff, are you aware of any documentation or guide for setting up Node Red independently (i.e., non-Add On)? I can create a NR LCX instance in my Proxmox VM, but donât know how to connect that to my HA. Is there an equivalent to the âHA WebSocket or configuration nodesâ that the Add On provides?
I have two Home Assistant machines, both with Node-RED as add-ons. I also have two Raspberry Pi machines, which have Node-RED included and are both connected back to my HA instances.
The HAâs are run as fully supervised, so the local Node-RED WebSocket (HA Server) config node is easily set up with the âUsing the Home Assistant addonâ checked which then connects to the local NR instance via the Supervisor. Nothing else is required.
To set up any other connection, for example from an Node-RED running as an HA add-on but connected to a different HA machine, or from an independent Node-RED back to an HA machine, you need to add manual configuration - just untick the âUsing the Home Assistant addonâ.
but the gist of this is to generate a long-lived access token in HA (go to your user account when logged in to HA) which is added to the NR Config node. This permits access into HA to the WebSocket.
You only need the base URL for access, and the Token.
If you donât have the WebSocket nodes already in your independent Node-RED, they can be found and added from the palette, just install:
node-red-contrib-home-assistant-websocket
Base url is usually ip-address:8123, but there is a search button next to this field, and using it the config editor will locate all HA servers on the local network for you. This is nice, as if it canât find it/them you know that you donât have the required ports opened.
I donât use VM, but I believe you need to ensure that at least port 8123 on the HA instance can be seen by the LAN.
but I think that it was caused by some change in Windows, because I wasnât able to deploy only from Win PC or virtual machine running on Win PC (using a VirtualBox NAT to that PC) and was able to deploy from Android or from Rpi with Raspbian directly on LAN
Well at least it finally works but I am not gonna lie⌠it cost me a few gray hairs and stomach ulcers :-/
Chiming in here⌠I have sort of the same thing since I pressed update to node-red-contrib-home-assistant-websocket 0.67.2.
Now suddenly I have no status updates in NR anymore wehn accessing the addon via HA as I always do. I do see status updates when going through IP:1880.
According to Kermit it has to do with the addon running in an iFrame. But I donât understand why it suddenly doesnât work anymore after updating the websocket version where it always worked beforeâŚ?
Workaround in panel_iframe.yaml:
</s> <s> node-red:</s> <s> title: NR 1880</s> <s> icon: mdi:sitemap-outline</s> <s> url: http://192.168.1.2:1880</s> <s>
This seems to be non funtioningâŚ
So I was having the issue with the inject and debug nodes. I did not have multiple server configs.
In addition to this the new home assistant tab was not visible (next to debug, context, etc).
I cleared the browser cache, restarted node red, restarted home assistant. Still nothing.
It would work if i went to the ipaddress:1880 in firefox. It would not work when I opened it in chrome.
I have been using chrome to access HA as an app with it pinned to my taskbar. I did open the dev console in chrome and there were a lot of errors.
Solution: opened the nabucasa address in brave. pinned it as an app to my taskbar. debug/inject nodes worked again and I could see the home assistant tab. Finally got it working.
Iâm having the same issue with inject and debug nodes.
Folks on the Node-Red forum think this is a Home Assistant issue, not a node-red one, as it only happens on Home Assistant instances of node-red.
I am also seeing node status missing from subflows that are sending status to flows that call the subflow. Iâm not sure if this is also a Home Assistant issue, but it started at the same time (with the last update to the node-red add-on).