How to automatically retrieve device name from entity_id?

Third party integrations Node-RED
8

You’re relying on devices too much. Why do you even need that? The entity_id is what is needed in HA, not the devices. :slight_smile:

If you ever have a broken device or you need to change something, the device_id will change as well, whereas the entity_id doesn’t. It is not the best idea to work with devices in HA. :wink:

What is it in the end, what you want to achieve? Send a message to Telegram(?) to show you the state an entity is in? That should work easier if you just use the entity_id and the friendly name. You are putting load on your system that isn’t necessary…going through a list with all your entities… :woozy_face:

9

I am trying to send a message to the HA app.
But the entity_id contained as “topic” only makes sense to me but not my wife. And since some entities are just “shelly25_ks8j3kel9” not even I know which Shelly device that is.

So I would need the friendly name or device name that tells me “living room lights are on”. Rather than “shelly25_kdoe83ken: on”.

10

You should have that “shelly_whatever” in your developer tools in HA as an entity. There should be the friendly_name.

Go to developer tools and look after that shelly. It should be in there, together with the friendly_name as an attribute.

11

Yes, but then I need to manually look up which device has changed everytime I get a message from HA.
I want to get a simple message like “Washing machine is finished” and not a cryptic string that forces me to open HA UI and check developer tools.

So somehow I need to get Node Red to know that friendly name based only on the entity_id as Node Red only works with the entity_id.
Otherwise Node Red cannot send me a useful message.

EDIT:
I have opened a thread also in the Node Red forum at How to search for string and cross-check - General - Node-RED Forum in case either of you are members there also. I thought the searching might now be a more Node Red specific problem now than a HA problem. At least now that @CentralCommand solved my initial problem :slight_smile:

12

You don’t have to look up the name in developer tools, the friendly name is in the message data. If you have an events: state node then you can grab the friendly name of entity that changed at msg.data.new_state.attributes.friendly_name. You can also add custom attributes to the entity using HA’s customization options if you want to add a label for the thing specifically to use in your telegram messages and then access that the same way.

1 Like
13

Maybe the problem is the ‘catch’ command. I just saw that the editor states that the optional catch binding is only available in ES10.

14

While I completely agree with you, unfortunately this does seem to be slowly changing. The reason I made that subflow at all was because I encountered a device trigger. If an integration creates device triggers then the events created only have a device ID, nothing else. So if you want to leverage them in your Node RED flow then you have to either stash the device IDs you care about or have some way of looking up info on devices to see if this is the one you wanted.

This is also true for areas. If you wanted to have a flow that did something with all devices in an area then you have to be able to look up area info. And most of the time the device is what is in an area so you have to be able to walk through devices to find the entities.

Fortunately we’ve dodged the worst of this so far since device actions are just service calls. You never need the device ID there you can always just use the service call directly and future proof yourself. Hopefully that doesn’t change but no way to be sure.

15

Yes, I agree.
Sometimes one just tries to find a clean and independent solution that works for every possible use case.

What I am now wondering (entity friendly name is working btw!, thank you), is if I can also pass along the initial node name?
So if i name the node according to the string I want to display in the message, can i somehow pass this name on or read the name in the function node?

16

Like the name you put for the node in Node RED? Not aware of any way to do that. But why not just add the name you want to use to the message object with a change node or something? Or wrap the shared logic up in a subflow and add a configuration for message to send that you can set for each place you want to use that subflow.

17

Yes, like node.name but from the parent node and not the current node.

If I am not mistaken, then I would need to add a change node to each entity:state node. So I would need one entity:state node plus one change node each.

If I have a universal function node (which is what I was going for), then I have one function node and one notification node for all entity:state nodes.
So for each new entity I want to monitor I only need to add that specific event:stae node and connect it to the universal function node.

18

I totally ignored the NodeRED part of the question, sorry. I don’t use it so i can’t be of any help here.

But nonetheless, why do this with NodeRED? This is a simple as can be automation, nothing fancy. If a state changes on deviceX, send a message to CompanionApp with the trigger named…

Something like this:

automation:
  - id: Shelly Button1
    alias: Shelly Button1
    trigger:
      platform: state
      entity_id: "sensor.shellyX"
      from: "unavailable"
    action:
      - service: mobile_app_my_phone
        data_template:
          message: "Shelly {{ state_attr('trigger.entity_id', 'friendly_name') }} seems to have a problem."
          title: "Something's off with a Shelly"

This is not tested and just written down, so maybe there are some indentation errors, but to show the idea… :wink:

19

Why not just change the entity_id of the entity to what you need?
That is what I would do.

20

@Hellis81 : Because the entity_id is part of a whole bunch of entities belonging to the same device. I would like to keep them all in the same naming scheme.

@paddy0174 : I was thinking about making “simple” automations instead. But for me the syntax there is similarly unclear and I was hoping to start with something small in Node Red and then be able to make the flows more complex. Something that might make normal automation codes less manageable.
Because with Node Red I can simply add one node into an existing flow whereas in automations I have to make the full code for every single one.

And I don’t quite understand the syntax in the automations. So e.g. if I wanted to send the new state, would it be

message: [{{ state_attr('trigger.entity_id', 'friendly_name') }} , {{ state_attr('trigger.entity_id', 'state') }}]

?
Or is it wrong. And why/when do I need double brackets {{}} and when can I just use state.attr.friendly_name?

I really need to find a decent source of information for the syntax of HA and of Node Red. Youtube tutorials are just not helping and most information on the HA homepage seems to assume that all syntax is basically known. Maybe I need to do a fresh search for this.
Python, VBA, etc. seem much more straight forward to me.

21

How many of these device/entities do you need to make translations for?

You could just add an associative array/list in the function node.
Pseudo:

array  = ['entity_id' = 'living room light', 'other_entity_id' = 'some other light']

message = array[entity_id] + ' is now ' + msg.topic;
22

As I said, NodeRED is not for me, I personally find it to complicated. In my case an automation does the job. :slight_smile: But that’s me, everybody has to find it’s own method to work with HA. :slight_smile:

The documentation is not the best (in terms of readability and “find-what-you’re-looking-for”), but it is a start.
Trigger: Automation Trigger - Home Assistant
Trigger variables: Automation Trigger Variables - Home Assistant <= what trigger entries are available
Templating: Templating - Home Assistant <= here you find how, where and why to use templates (meaning the brackets are explained there)

Under the templating docu see the examples at the end of the page. :wink:

23

The brackets is templating. Home Assistant uses Jinja 2 pretty much everywhere so that’s what you’re seeing there. The Jinja engine processes strings like that and anything which isn’t in brackets is just treated as plain old text. Anything in brackets is processed as detailed their in their docs. Home Assistant also has a guide specifically on templating within HA here.

Node RED does something similar btw. It seems like you are dropping into function nodes a lot which is fine but often just ends up requiring a lot more coding work on your part. You can accomplish quite a lot without function nodes at all by combining other nodes into flows and leveraging jsonata for small bits of processing. That is the templating engine Node RED has chosen. It’s quite powerful but not as approachable as Jinja in my opinion, there’s a bit too many “unique to jsonata” operators. But you can do a lot with a little if you take the time to go through their docs and the built in tester for jsonata expressions is fantastic.

Patrick just listed out above most of the other docs I was going to link for explaining the trigger object in such in Home Assistant so I won’t repeat.

For the node red side I could link docs but for now I’ll just say the debug node should be your best friend. You can drop it in and attach it at literally any point in your flow and print out the entire message object as Node RED sees it. That is more helpful then any documentation for figuring out what you can work with at that point. And then you can can copy that json into an Inject node and make isolated test cases until things work the way you want to.

This functionality of being able to isolate, test and iterate on small pieces of a large complex automation is probably the single reason I do most of my automation in Node RED. That and its easier to see the big picture when you have a piece of functionality that spans multiple automations/scripts since you can organize all of them into one flow/tab.

24

Thank you all for the great links. I have started reading them and will try to learn a bit more about the syntax used.
I do like the idea of being able to write the code rather than relying on the abilities of a UI. I do the same for other languages, but jinja and json are not mine (yet :wink: ).

By the way, I tried

message: "Shelly {{ state_attr('trigger.entity_id', 'friendly_name') }} seems to have a problem."

and it sent

Shelly None seems to have a problem."
25

Hi,
just as an update, despite me being the only noob here :smiley:

    data_template:
      message: >-
        {{ trigger.to_state.attributes.friendly_name }}: {{
        trigger.to_state.state }}

This is the correct syntax to get the friendly name of the entity that triggered the notification.

4 Likes
26

So, I have to say I like the idea of direclty using code rather than Node Red. It seems more straight forward.
I will be opening a new thread about automations looking for some help with my syntax. I am a bit “stuck” with my code right now. HA isn’t accepting it and hence not saving it as automation.
I have opened a new thread here in the forum Syntax questions for automations

I have to say, I feel much more comfortable “coding” it myself even though I am still learning about the correct syntax. So much easier in other languages :smiley:

2 Likes
27

hey,

this is pretty cool. thanks much for sharing.

one question, the area_id for entities don’t seem to populate but they do populate for devices. is this expected?

thank you.