If it was home-assistant-websocket package issue then only HA related nodes would be affected. Thus it shouldn’t affect native NR nodes.
Also I would expect those HA nodes stop working at all.
I initially understood that everything works except you cannot see statuses/debug messages on all nodes.
If HA nodes don’t work at all, then yes, likely web-socket package or NodeRed Companion addon (see HACS) might require an update.
I’ll try to update my NR during the weekend, then I will be able to tell if I can reproduce this issue.
Thanks, you are correct, everything works, I just can’t debug / see status. I updated to HA 2021-06-1 today to see if that would help, but it didn’t - only broke my Developer Tools - Service node! So I think I better backtrack.
Has anyone found a resolution to this? I was able to reboot HA to get my debugs to show sometimes but then yesterday, the status messages disappeared. All of the nodes still work I just can’t see the status or debug messages.
Oh wow that does give some feedback and also some clues! I get an error: “Communication send error: Error: WebSocket is not open: readyState 3 (CLOSED)”
made a backup of my flows - using the hamburger → export all flows
uninstalled Node Red - using Supervisor
used the samba share addon to remove (actually renamed) the ‘Node Red’ folder in config using windows explorer
re-installed Node Red using Supervisor
imported all my flows
at this stage Node Red complained about a BUNCH of missing Node Types:
I tested and my debug was back, my flows were responding albeit some were missing due to these missing nodes, so I
removed my flows by deleting them one by one
installed the missing node types
imported all my flows
Guess what… the websocket error was back! So I can only guess that it is one of those nodes causing this. I will rebuild it again… with all the missing nodes and then step through my multiple flows to update them were I can trying to avoid any of those node type plugins… bit of a pity as I quite liked some of them, but I noticed a lot of them have not been maintained so if it’s older than 6 months I will find another way.
I’ll let you know the outcome, hopefully this helps someone?!
Once everything is removed and then reinstalled, add one call service node. Then add your ha server with a long lived token instead of clicking the addon option. Scrub the old servers from your flows here.
Hi guys so this has been a RIGHT chore… but I am now getting there, and close to marking this as SOLVED!
Thanks @Mikefila for your suggestion, unfortunately this solution is no good for me, stripping out lat-longs makes it an even bigger job! I have too many flows relying on lat long info (BigTimer etc) I did however notice in the config node: (here after I cleaned it)
there used to be literally hundreds of home assistant servers… why is that!? I deleted them from there. I then as per @Mikefila 's suggestion try to set up a server using a brand spanking new long access token, but for whatever reason that would not work (I am using the latest HA on RPi4b with SSD with the normal Supervisor type install as well as the latest NodeRed). My nodes just had a yellow circle and said connecting without ever resolving. So I ticked the box saying I am using the Home Assistat Addon as a new server.
I had the issue of LOTS of Palette Node references persisting in my JSON even though I removed all nodes in flows relating to them and uninstalling them from the pallet manager. I resorted to manually removing them out of my JSON and then re-importing my flows again.
For some reason all my HA nodes have now got themselves confused and are not linking to the new server correctly, to fix this I just have to open, click on the server close it and hit deploy… It is the only server left but somehow it seems you need to open and close it to bind it. This is a pain as I have literally got hundreds…
I have updated one of dozens of flows and it is now working as before, Debug, Feedback the works!
So to recap - there seems to have been various issues:
some of the palette nodes were causing conflicts with the node red ha websocket
I had palette nodes that were not maintained by the creators so cutting out the dead wood was possibly a good thing
I somehow had hundreds of HA servers / duplicates in my config - still no idea how but I manually removed them - as a result I have to manually bind each node to the remaining server…
Do you import flows from the internet? They can contain server information. The link to the scrubber is what you need, before importing someone else’s flow, scrub it.
No I don’t tend to import other people’s flows. No idea how I managed to get so many entries for servers, they were all the same. Good to know about the scrubber should I ever need to import from someone thanks!
Ok so this is still not happy… after a lot of wasted time, I am considering rolling back once again.
I still see in my logs:
28 Jul 17:07:35 - [info] [server:Hass.io] Connecting to undefined
28 Jul 17:07:35 - [info] [server:Hass.io] Connected to undefined
28 Jul 17:12:41 - [warn] Communication send error: Error: WebSocket is not open: readyState 3 (CLOSED)
28 Jul 17:12:44 - [warn] Communication send error: Error: WebSocket is not open: readyState 3 (CLOSED)
Not sure why my server is ‘Undefined’ and the websocket issue is back
This is some sort of auth/ssl error. The fact you can’t get a long lived token access token to work is probably part of the problem. Maybe focus on that. I’m wondering if running from an ssd has anything to do with it.
It worked perfectly before and still does if I roll back to an earlier version ( Same as @hollladiewaldfee above), as per my notes above and various others on this thread and elsewhere on the net this behaviour started after an update a few months ago. I have now managed to get the long lived token to work… will give it some time to see if it behaves.
At the minute the old server is still somewhere in my JSON, I deleted it via the GUI but the logs show a mess relating to the deleted server:
I guess I will have to get my hands dirty with the raw JSON again.
Besides the crazy logs, everything else works perfectly after the steps I’ve shown and now with the long token it seems the websocket issue is staying away… bit difficult to check with the thousands of log entries, but I’ve been keeping an eye out and I’ve not spotted it yet.
Thanks for your input, it sure got me on the right track to figure this out!
