The Node-RED ha entity node is deprecated in favour of four individual home assistant entity nodes (Sep 2022)

Can confirm this appears to work now previously setting the icon property to string containing an mdi:icon didn’t seem to work or was problematic at best. Now…

Guess which entity has been updated in code to inject the icon property I want…image
(edit: fixed image)

This will eliminate the need for a couple dozen template sensors!

1 Like

All looks right.

No, you can only update the friendly name and icon from the update config node

Between that error which means the websocket endpoint hasn’t been created in HA and the alert bar above the node says you’re needing 1.1.1. I would say it’s not loaded in HA. Did you reboot HA after updating the custom component?

You can run this flow which will return the version of the NR component running in HA.

image

[{"id":"a25205a0a3854bb6","type":"inject","z":"c89d915bdff0f798","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":412,"y":80,"wires":[["ea8b441154d1945d"]]},{"id":"49f4ca33c05a294c","type":"debug","z":"c89d915bdff0f798","name":"debug 20","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":700,"y":80,"wires":[]},{"id":"ea8b441154d1945d","type":"ha-api","z":"c89d915bdff0f798","name":"","server":"","version":1,"debugenabled":false,"protocol":"websocket","method":"get","path":"","data":"{\"type\": \"nodered/version\"}","dataType":"jsonata","responseType":"json","outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"results"}],"x":562,"y":80,"wires":[["49f4ca33c05a294c"]]}]
1 Like

Thank you - your responses to my post are much valued.

Thanks for the flow - just what I needed. Yes, it was stuck on 1.0.4, and I simply could not see why. A lot of playing around this morning found the answer and another ‘Ahh-Duh!’ moment.

Out of an abundance of caution (past experience) I aways rename folders as ‘OLD …’ to keep a copy. Worked for me when I updated another custom_component, so I did the same here, old folder and a new nodered folder. Naturally I restarted Node-RED, the integration (reload / delete / reinstall) and HA restart (several times). Funny thing was that the python cache was still being updated but in the (renamed) old folder. I could not understand why HA was following the old folder.

Renamed old folder again, then got an error in HA on restart that it could not start Node-RED custom component (name of old folder) and bingo - the answer. HA must go through the custom_component folder, and load each component it finds based on the names of the individual folders. Keeping a copy of the older folder caused the loader to read the wrong folder. Duh.

I did follow the instructions to the letter, but they are clearly for anyone loading Node-RED companion for the first time, and not someone like me trying to update!

When updating a custom_component folder, do not leave old copy folders in custom_components!

Got there in the end thank you.

will updating to this latest version of node-red-contrib-home-assistant-websocket mean i MUST update all my entities to the new arrangement (which would be a huge task…) or will the existing system still work for a bit?

Yes you must update your entity nodes (to new sensor nodes) but no, the system mostly does it for you.

I had about 65 HA entity nodes.

When I updated Node-RED

  • the pallet entity node became deprecated. It goes grey, cannot be edited, and moves to its own pallet group
  • existing flows continued to work
  • a ‘blue box’ message appears, click to update nodes to new schema

When I clicked on the ‘update nodes to new schema’

  • all the entity nodes were changed to the new type of node (sensor/binary sensor etc) depending on the original entity node type setting
  • new ‘entity node configuration’ nodes appeared in the configuration node section, one for each new sensor
  • all the necessary settings were created automatically

A deploy was required to effect the changes

The outcome

  • the only issue I had was one entity/sensor that became unavailable in a HA dashboard. Easily fixed, I put this down to friendly name issues during the automatic schema update.
  • all the new automatically generated entity configuration nodes are called ‘sensor config for …’ which does mean that mostly I can’t see the actual sensor node name part in the side bar. In time I may hand edit the new sensor config node names, but this is a nice to have and not essential

I started this thread because I was rather taken aback with the change as it was unexpected and, to be honest, a bit overwhelming at first, and I hope that by posting a little information beforehand this can offer reassurance for those of us who have a lot invested in our Node-RED flows!

1 Like

thanks @Biscuit, that’s helpful-- but i’ll still wait until i have a day free before taking the plunge!

Just wanted to add a correction. You actually don’t need to update the entity nodes. As long as you don’t need to edit them and don’t use the “update all nodes” button. The nodes will continue to function as they did before the update.

1 Like

The downside of this approach is that (I think?) we cannot parameterize entity nodes any more (e.g. I want a subflow where each instance of the subflow creates its own switch entity)

Every time that subflow was to be deployed, e.g. normal deploy, NR reboot, a new entity would be created and the old one would be orphaned.

I had problems with /data/node-red-contrib-home-assistant-websocket.json file (malformed) I deleted it and then the new version works. I updated from 0.44.0 to 0.48.1. I see that the problems is when update to 0.45.0+

Bump… I used to have 5 ha-entity-config nodes.

I was playing around and deleted 2 of them. But 1 is not “seen” by the companion integration of nodered being deleted. It is really gone in node red. Also in the configuration nodes settings…

then I tried to add a new ha-entity-node an I saw the deprecated message. I have also seen the new sensor node.

At this point I am not yet going to change due (time).

But how come I deleted an old ha-entity-config node not being marked in HA for deletion?
(yes I have rebooted HA en node-red, reload integration etc.)

EDIT: hm it seems I am using the correct node:


But why is it called ha-entity-config in the configuration nodes?

I am not sure - do you realise that you are now dealing with two different and separate nodes?

As far as I understand this (I am only a user…)

The ‘sensor-node’ is the bit you see in your Node-RED flow. You are editing this node in your picture.

The ‘ha-entity-config’ is a separate type of node that you don’t see in the flow, but this holds the settings required to create and update the entity in HA (using the HA websocket server). You are showing these nodes in the right-hand config window.

  • the old arrangement, deprecated, had both the flow bit and the configuration bit in the same node (used to be ha-entity node)
  • the new arrangement has, in effect, two associated (connected) nodes. The visible bit (sensor-node), and the back-end configuration bit (ha-entity-config node)

We now need both, and they are associated or connected together in the ‘Entity config’ edit box.

When the ha entity configuration node does its job, a new entity is registered (created) in HA.
The configuration nodes work for different types of entities - so these are called ‘ha-entity-config’ nodes as they hold the configuration for creating and updating the entity in HA. For a sensor node, the associated configuration node will be for a sensor entity. For a button node, the associated configuration node will be for a button entity.

If you go into the config window, you will see the ha-entity-config nodes, and each node shows you how many sensor-nodes it is being used by.

If you delete an ha-entity configuration node, then the entity will also be deleted in HA. This does not work the other way around.

If you delete a sensor node from a flow, then the associated configuration node remains behind, but shows ‘0’ (or decrements) as the number of nodes it is used by.

You appear to have only two ‘ha-entity-config’ nodes. One is used by 1 sensor node, the other by 2 sensor nodes, so those two nodes (in your flows) are updating the same sensor entity in HA.

I don’t think that it is possible to delete an ‘ha-entity-config’ node except by using the delete option in the ha-entity-node edit box. And yes, if you delete an ‘ha-entity-config’ node then it is deleted. This may then leave the ‘sensor-node’ behind, but without a connected configuration it will not have an entity in HA.

I totally get what you mean.

What is strange is that I now have 5 entities in HA of which 4 I can trace in node red. the 5th I cannot find. It does not show up in any search in any flow (or all).

It used to be a (new) sensor node with a ha-entity-config (config bit). Both are deleted but still it is present in HA… I really don’t now why…

It also has no history (except teh rboot HA/node-red one):
image

It is related to node-red:
image

But nothing is to be found:
image

The HA config nodes register a new entity with HA. When a new (Node-RED) entity has been created in HA, deleting the config node and then redeploying usually removes the entity, however sometimes these entities get orphaned and are left in HA with no connection back to the integration that created them. This, apparently, was the issue with the old entity nodes when used in sub flows.

Usually orphaned entities will show up in the settings > devices > entities list with an error status, and, in most cases, can be deleted there.

In my case HA does not allow me to delete it…

There are several posts in the forum regarding how to solve issues with deleting entities.

If you do not have this entity in any HA entity configuration node, and you do not have it in any of the old HA entity nodes, and you do not have any HA API nodes set up to create this entity, then it should be orphaned and will eventually show up as such.

The usual statements of rebooting HA etc apply, as does clearing the browser cache, especially for Chrome.

I looked again… now it’s gone :man_shrugging:

I’m also not getting entities or devices to appear in my HA, and seem to be running the latest installations of everything (but also getting the banner about the version).


HACS:
image

The integration (I don’t know why it called itself ‘name’):
image

Running the flow to return the component version shows A WebSocket request requires a 'type' property in the data object. in the debug console.

Node-Red is running as an addon, config secret is set, nothing obviously wrong in the logs:

 Add-on: Node-RED
 Flow-based programming for the Internet of Things
-----------------------------------------------------------
 Add-on version: 14.1.5
 You are running the latest version of this add-on.
 System: Home Assistant OS 10.1  (amd64 / qemux86-64)
 Home Assistant Core: 2023.5.2

I get many repetitions of this in the Node Red logs:

10 May 23:09:12 - [info] [server:Home Assistant] Connecting to http://supervisor/core
10 May 23:09:12 - [info] [server:Home Assistant] Connected to http://supervisor/core
10 May 23:09:13 - [info] [server:Home Assistant] Connection closed to http://supervisor/core
10 May 23:09:13 - [info] [server:Home Assistant] Connection closed to http://supervisor/core
10 May 23:09:13 - [info] [server:Home Assistant] Connecting to http://supervisor/core
10 May 23:09:13 - [info] [server:Home Assistant] Connected to http://supervisor/core

My HA setup is a VM running only HA:

I do get a sensor to say ‘connected’, but it doesn’t appear in HA:
image

I have rebooted HA (and rebooted the whole VM), uninstalled/reinstalled Node Red (including wiping its config directory) no difference.

Any ideas on how I could debug this?

Thanks in advance!

I can read from an HA entity to Node-Red without any trouble

Progress (in terms of eliminating root causes anyway) – installing a separate node red instance on another server and connecting via HTTP worked immediately.

This led me to using the HTTP connection (ie manual setup vs ‘I am using the addon’) and that works for me.