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

Biscuit · September 29, 2022, 2:16pm

Maybe I missed the announcement when I was on holiday, but I got quite a surprise two nights ago when I performed a routine update of my Node-RED pallet for the ha websocket nodes.

node-red-contrib-home-assistant-websocket set is now (6 Sep 22) version 0.45.0. Big change for me as the entity node is deprecated and no more, being replaced by a set of four home assistant entity nodes (sensor, switch, button, binary_sensor)

I use the HA entity node extensively to pass values into HA. All these nodes have changed to the new home assistant sensor node, but I could not edit them as my Node RED companion was now out of sync. I had to manually update this by downloading the custom_components/nodered files. This integration is now version 1.1.1.

All now back up and working, however quite a bit has changed.

there are now four separate nodes, covering each entity type
the node set appears in the editor bar under a new section “home assistant entities” (so it went to the bottom of the editor list)
each of the new nodes now has (its own individual) entity configuration node, and that configuration node connects to the HA server node
the entity configuration node can be connected to a device

I have noted already that the new arrangement is a little more particular about names and registering the ‘entity’ with HA. It is necessary to add a device setting before first registration of the entity (changes later require an HA restart to re-register the entity with device). It is important to use the ‘friendly name’ field otherwise the entity ends up with a generic name (and thereby difficult to find). I did have one entity, turned into a sensor node, that vanished in HA, but that seems to be down to the friendly name not being set.

I have an error message plastered all over my new sensor node, but I assume that is just a static warning message. If anyone knows differently, please tell me how to get rid of it!

Question I have yet to answer:

does each ha entity node require a unique configuration node? I believe so, which makes for a lot of extra configuration nodes!
how does the device configuration work? Can I have several entity nodes connected to the same device, and what benefit does this provide?
what does the update config node actually do? I can’t seem to get the example provided to work, but the idea of changing a sensor-node configuration-node configuration from the flow does seem like a solution waiting for a problem.

Kermit · September 30, 2022, 12:02am

This was how the entity node functioned before if the friendly name wasn’t filled in.

This category has been around since the button node was introduced in version 0.41.0.

Yes, each entity will require an entity config. One of the main reasons behind moving to an entity config was to allow entity nodes to be used in sub-flows.

When a node is used in a sub-flow Node-RED creates a copy of the node for each instance. This changes the node id which is used to register the node with Home Assistant. Every time NR is restarted a new node id is generated for that sub-flow instance. This causes a new entity to be registered in Home Assistant.

In the new system, the node id of the config node is used when registering the entity with HA. So it doesn’t matter how many instances of a sub-flow are created only one entity will be registered with HA. This new system also allows you to have multiple points in the workspace where you can update an entity by using two separate sensor nodes pointing at the same entity config node.

Yes, you can assign as many Node-RED created entities to a device as you want. It was mainly added as a feature request but does have the benefit of being able to use the default device automations.

Allows you to update an entity’s friendly name and icon from any flow. This was not possible before unless you manually used the API node. This was also a requested feature.

If you’re running the NR companion component v1.1.1 that banner should not show.

NathanCu · September 30, 2022, 1:46am

Kermit do you know if the updates make it possible to dynamically update the icon property of the updated ‘entities’?

Right now im using some rather complicated entity nodes that have multiple attributes (fed by flow variables) id LOVE if one of these properties was the icon property for dynamic sensors (and I could get rid of an entire swath of template sensors I had to build just to pass icons to Lovelace)

Kermit · September 30, 2022, 1:52am

Yes, you should be able to update any entity’s friendly name and icon using the update config node.

Biscuit · September 30, 2022, 9:36am

Ah enlightenment!
Thank you Kermit - amazing how a few simple words of explanation can be so powerful.

Friendly Name:
Agreed it is necessary (perhaps should not be an optional field). However, one of my existing entity nodes, on conversion (schema update) to the new sensor node, for some reason ended up with a different name and thus vanished from one of my dashboards cards. I put this down to issues with the existing friendly name.

Home assistant entities category:
As I have a long list of node categories, and have not used the button entity, TBH I had missed this. I use the Node-RED setting feature to put HA nodes at the top, so the new stuff went to the bottom. Easily fixed to bring both categories together in the editor.

  // The following property can be used to order the categories in the editor
  // palette. If a node's category is not in the list, the category will get
  // added to the end of the palette.
  // If not set, the following default order is used:
  paletteCategories: [
    "home_assistant",
    "home_assistant_entities",
    "subflows",
    "common",
    "sequence",
    "function",
    "network",
    "parser",
    "storage",
  ],

Entity config node:
Enlightenment! I already understood that sub flows operate ~~slightly~~ differently in that things like context has to be managed as parent-flow. Sub flows must operate like any function call by creating copies just for each instance of the sub flow call. By moving the working part of the HA registration out from the ha_node to an ha_entity_config node, the sub flow engine creates instance copies of the node but not the ha_entity_config node thus avoiding repetitive, duplicative and transitory HA entity registration. Interesting.

So, if my improved understanding is correct -

In the old schema, each entity node (the thing we see and edit in the flow) held the status value. Each ha_node was connected to one HA server config node, so the node (performed the HA entity registration and) pushed the state change to HA directly.

In the new schema (but only for the ha_entity type nodes) the state value (and everything else like icon, name, id) are held in an ha entity config node. This node is then connected to the HA server config node, and acts as an intermediary between the entity node and the HA server node. The ha_entity node updates the ha_entity_config node, the ha_entity_config node communicates with HA server node, HA server node updates the HA registered entity.

So

we have one HA server node, with the appropriate details to maintain an ongoing websocket and API connection with HA.
we have one or more ha_entity_config nodes, all of which connect to the same HA server node. Each ha_entity_config node has details of an individual entity (id, friendly name, icon, state) that is thereby registered and updated with HA
for each ha_entity_config node, we have (zero?) one or more ha_entity nodes that connect to this ha_entity_config node, each of which can separately update the ha_entity_config node details, thus in turn updating the HA entity.

Consequences:

We can now have more than one ha entity type node connected to the same ha_entity_config node (of the same type). This means that the same HA entity can be updated/managed from more than one flow / place / sub flow.
By experimentation I set up two of the new sensor nodes, connected to the same ha_entity_config node. I note that, whilst each sensor node updates the status as it is fired, naturally there is no back connection from ha_entity_config node to the (more than one) sensor node, so visually any one sensor node may show a status that no longer represents the actual HA entity status.

Experimentation:
Can we have an ha_entity_config node without any entity nodes? Answer is yes. Interestingly this leaves an entity in HA that can no longer be updated as there are no entity nodes connected to it.

Can we have an ha_entity_config node just connected to an ha update config node? Answer is yes, which I assume allows for DIY entity updates. Now possible to create a sub flow in which sits just an update config node that updates a connected ha_entity_config node. Effectively a new DIY ‘ha entity node’. I need to see if the update_config node allows for state value updates.

Remaining Problems:

I am sure I am running NR companion v 1.1.1
I followed the documented update procedure to the letter, and have cross checked all the files in custom_components/nodered with the previous version. My ‘manifest.json’ file shows

{
  "codeowners": [
    "@zachowj"
  ],
  "config_flow": true,
  "dependencies": [],
  "documentation": "https://zachowj.github.io/node-red-contrib-home-assistant-websocket/guide/custom_integration/",
  "domain": "nodered",
  "iot_class": "local_push",
  "issue_tracker": "https://github.com/zachowj/hass-node-red/issues",
  "name": "Node-RED Companion",
  "version": "1.1.1"
}

So I am sure I am updated but the error message remains.

Trying to use the new update-config node causes an HomeAssistantError: Unknown command. error.

First step is to have a tidy up and restart HA again. Clearly with this update it is essential to have both the Node RED pallet and the companion integration updated and aligned.

NathanCu · September 30, 2022, 4:47pm

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…
(edit: fixed image)

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

Kermit · October 1, 2022, 1:17am

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.

[{"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"]]}]

Biscuit · October 1, 2022, 11:47am

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.

35e · October 9, 2022, 6:04am

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?

Biscuit · October 9, 2022, 9:32am

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!

35e · October 9, 2022, 1:37pm

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

Kermit · October 10, 2022, 6:30am

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.

nevir · December 23, 2022, 9:09pm

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)

Kermit · December 23, 2022, 9:26pm

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.

Ahriman · February 10, 2023, 10:12pm

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+

sender · April 16, 2023, 9:05am

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?

Biscuit · April 16, 2023, 12:19pm

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.

sender · April 16, 2023, 6:00pm

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):

It is related to node-red:

But nothing is to be found:

Biscuit · April 16, 2023, 7:13pm

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.

sender · April 16, 2023, 7:25pm

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