If I may… I have had the same kind of interrogation.
If you want to have this “entity” node in two different flows, then when the entity is called, you will end up with two different entities in HA.
Just to illustrate with something stupid:
Even if in the configuration of the entity node you force the same name, you’ll end up with two sensors.
Based on the node description, it is kind of logic… However, if you have two flows where you want to use the same entity node, in one you can use “entity” but in the other you have to use “call service” to change its value.
Lastly, if you don’t know which flow will be called first (so you may “call-service” on a none existent node) you end up having a third flow to create “entity” node. And then two flows with call-service to change the value.
At least this is what I am doing in my config. Hope this makes sense
For your example I would use a single sensor node then use link nodes to point to it from other locations.
edit:
Entity nodes (binary sensor, sensor and switch) all register themselves with HA based their node ids. This is why you can’t them subflows and in different locations expecting them to be the same node.
Thanks guys, this is very helpful.
So bottomline is that in fact you cannot use multiple contrib nodes to address the same entity. Instead you have to use replacement constructs like state-change nodes and call-service nodes, as I suspected. Link nodes are another option, thanks for this input, @Kermit.
What is new to me, is the possibility of race conditions. If I understand you correctly @greengolfer, then the order of node processing on startup can lead to the problem that the entity of a contrib node has not yet been created when a state-change or call-service node tries to access it? Using link nodes would clearly solve that problem. But I rarely use them cause IMHO they tend to mess up the flows and make them harder to read. But @greengolfer, how does a third flow solve that race condition? Can you tell which flow is initialized first? Are they initialized left to right in order of the tabs in Node Red? Very interesting indeed.
My understanding is that this “entity node” is created the first time this node is called.
So, depending on the situation, I either end up create a “dummy” flow with an inject node which is called as soon as NR is (re)started (so you are pretty certain it will be the first running) or use the HA API to set the state and properties of an entity and in this case I don’t use the “entity node” at all. If you call the API and set the state of a non existant entity (in HA), it will be created on the spot.
If another flow is making another call to the API, it will update the state of the entity. It is just another way to do things. This was the method I used (and still use) before en “entity node” was developed by kermit.
Since I code in nodejs and have several real-time hardware projects written in it I was not much interested in nodered and also nodered had no way to watch for multiple entity changes and emit when any one or more changed. So I wrote a websocket library myself so I could code in nodejs sans nodered. https://git.kebler.net/UCOMmandIt/uci-ha
So of course I wanted to create my own entities via the websocket but quickly learned that’s not possible. I was thinking I’d have to write an integration in python which wasn’t great since I don’t know that language nor much about HA integration. But then yesterday I see you have this companion integration https://github.com/zachowj/hass-node-red and it’s designed to talk with your websocket client to make new entities!!
So can you give me a couple hints on how to modify your integration and my websocket client library to incorporate that entity creation feature.Or Maybe I should just fork your websocket client and remove the nodered parts and merge in my entity list watcher code??
Either way maybe you’d like to use that entity list watcher code, making a new nodered node with it. https://git.kebler.net/UCOMmandIt/uci-ha/src/branch/master/src/homeassistant.js#L169 The use case that prompted this was a scheduler I’m working on (in nodejs using my websocket client). In that I need to watch for three possible inputs to compute a new scheduled next time. Nodered had no node to handle that. With my code you can watch and emit on as many entities as you want and make as many watchers/lists as well.
Follow my conversation with @swiftlyfalling in this thread, there are several different posts, it should explain the basics of what is needed.
Not sure why you say the NR nodes aren’t able to watch multiple entities. That’s pretty much the base of all the event nodes the ability to trigger on a single entity, a list of entities, or regex that matches entity ids.
As to nodered it’s been more than a year and I haven’t used it since but there was no node that could watch multiple entities on the same node simultaneously and emit if any one or more changed. Say you had to handle something if any one of 4 entities changed state? At least about a year ago there was no node to do that or maybe I just missed the list of entities/regex or that didn’t work the way I needed. You could chain watching/emitting them but that’s not the same. No matter for my purposes at least I’d rather just code my own than use nodered.
I don’t think so. If that would be true, my initial example (with the unwired contrib node) would not create a HA entity, because the node never receives any input and so is never “called”. But it does in fact create an entity.
I guess your timing problems rather stem from using contrib nodes to early. When you do a full deploy you can see contrib nodes going through a cycle of “Connecting” and “Registered”. I guess you tried to trigger them immediately without any delay after a restart / full deploy while they were not yet registered. @Kermit, may you enlighten us on the mechanics behind the scenes?
@Kermit wouldn’t it make sense to derive the unique_ids of the entities of your contrib from the entity_ids? After all we give a “name” in the node settings that becomes a part of the entity_id and thus is meant to uniquely identify the created entity. So generating a unique_id like nodered-contrib-websocket-sensor-mysensorname would uniquely identify this sensor and make it possible to use it from multiple nodes (simply by using the same name and type in the nodes).
I guess I am oversimplifying things here because I don’t know the internal dependencies. Maybe it is simply not possible to open websockets to multiple nodes for the same single HA entity. But it would definitely make the usage of your contrib more intuitive and versatile.
They are registered with HA after a deploy or after a connection to HA is made if they’re not already marked as registered. You can see this from the status text under the node.
I do see several issues having a user with control to set the unique identifier. At the time I felt using link nodes was a pretty standard thing in NR and still do. The one issue I didn’t foresee was using entity nodes within sub-flows. After the initial release, I realized a better route would have been to use config nodes for each type of entity. This would solve both issues, being able to have multiple nodes reference the same entity in HA and be able to use them in sub-flows. Hopefully, at some point, I find time to transfer over to using that system.
I’m getting this error showing up when I deploy in a lot (maybe all) of HA nodes
Malformed JSON in file: /config/node-red//node-red-contrib-home-assistant-websocket.json
Unexpected token c in JSON at position 13334
My HA definition is simple
Recently I have moved from Ubuntu->Hassio to Hassos and restored all the addons excluding NodeRed.
In this case I’ve created the new addon and copied all the files in the nodered folder from the other installation.
I have a problem with version used by node-red plugin of hassio.
I know I can’t upgrade using the palette menu, so I follow an advice from this topic and used
[15:12:41] INFO: Starting installation of custom NPM/Node-RED packages...
+ [email protected]
updated 1 package and audited 876 packages in 22.587s
which seems to be good. BUT, if I look in palette menu, NR still says the sued version is 0.18.0 and I have the button “update to 0.22.3”… and it seems that NR still using 0.18.0 ( for example, sensor node is still called sensor node instead of the new entity node)…
Have I missed something ?
There was a problem with the nodered addon of hassio.
It shows the last version but it was still download old dependencies from it old package.json file… weird…
Uninstalling NR addon, deleting folder, re-install it and copy my nodes make it work…
I’ve installed both node-red and the companion from HACS in Home Assistant. I have a nodered folder in custom components…should work. . When I try to deploy and ENTITY, I keep getting the following message:
Node-RED custom integration needs to be installed in Home Assistant for this node to function correctly. (but it is installed???)
Nodered addon .04.4
Node-Red 6.3.0
name: testA
Server: home assistant
type: sensor
state msg ABC
attribute key TEST xyz
I’m having a bit of a hard time understanding how to use the entity node and might have the wrong idea about it. When I first read about it, I imagined being able to read binary_sensor data from a remote HA instance and use the entity node to populate the master instance with that data. Effectively, a better/more versatile version of MQTT statestream.
But – can one (1) entity node not dynamically create/update multiple sensors? I’d like it to receive multiple incoming messages and create/update a binary_sensor for each. So for every binary_sensor on the remote instance, there will be one on the master instance as well. When I try to use the node for this, it seems to only output one sensor, no matter how many different msg topics I input through it.
I’ve read a bit about how unique node ids are handled in this thread but am not sure if this is impacting my situation.
If I were able to dynamically name each new incoming sensor (I’ve tried lots of combinations of whisker templates in the name dialog, no dice so far) it would allow me to set it and forget it. Any new binary_sensor I created would automatically be populated to the other instance.
Hi, looks like I have an issue with latest version of hass.
It looks like the events listener loose connection to the event after some time.
I have an event from a custom_component: zigate.attribute_updated.
I have a flow starting with this event running for months.
But today I have updated hass from 0.109.x to 0.112.2 and I have an issue.
After some time running, nodered doesnt start the flow anymore when the event is triggered.
If I just move a node and redeploy the flow it’s woking for some time until it stop again.
I have checked on hass side and the event is triggered I can see messages when I listen to it.
Any idea how I can debug this ?
edit: ok I’ve noticed that I was on a deprecated version of nodered container I’ve updated to latest with v1.1.0. I’ll wait to see if it works
edit2: stil got the problem but it looks like it’s not related to nodered. I have added a second events node with “state_changed” an it’s still receiving update after an hour but the events node with “zigate.attribute_updated” not…
Noticed today that my websockets stopped after the update to HA core 0.112.x. After deploying I’m getting “Node-RED custom integration needs to be installed in Home Assistant for this node to function correctly.” and the node says “Registered”. When checking the webhook address it was not created and the integration page don’t show no entity on the Node-Red integration.
