Ah enlightenment! ![:sparkler: :sparkler:](https://community.home-assistant.io/images/emoji/twitter/sparkler.png?v=10)
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.