Change user ID to Friendly name in Automation

Configuration
,
#1

Hi all, sorry if this has been previously covered. I couldn’t find anything on it. If it has, feel free to direct me.

I have the following automation:

My purpose is to send notifications to the companion app when my garage door is open. Some of the entities aren’t the final ones because I’m still testing it. Also, I’m really new to the native HA automation system, so this may not be the most elegant way of doing things.

I’ve got the automation working the way I want it for the most part, but I noticed that I can get context information from an event I’m watching that is triggered from a notification sent to the companion app. I’d like to add that information to my “Garage Door Notifications have been disabled by {{trigger.event.context}}” message. I’ve already taken a stab at that as you can see, but I’m only getting the user ID information, which obviously isn’t “human readable”. It just comes through as

"Garage Door Notifications have been disabled by Context(user_id='<long string of numbers/letters>........"

I would like to change this to show just the name of the user. For example:

"Garage Door Notifications have been disabled by <My name>."

I’m pretty sure this can be done using if then statements in a template at minimum, I’m just not very good with the templating system and I’m hoping there is a more elegant way. Any thoughts?

How to show name of user who triggered event?
#2

If each user has a person entity then this should work:

{% set p = states.person | selectattr('attributes.user_id', 'eq', trigger.to_state.context.user_id) | list %}
{{ p[0].attributes.friendly_name if p | count == 1 else 'unknown' }}

If users don’t have a person entity then I’m not aware of a means to cross-reference their name from their user_id.

2 Likes
#3

That would work perfectly. All of my users are associated with person entities.

I’m not entirely sure how to implement that though. I tried replacing

            data:
              message: >-
                Garage Door Notifications have been disabled by
                {{trigger.event.conext}}
              data:
                ttl: 0
                priority: high

with

          - service: notify.mobile_app_matt_s_pixel_5
            data:
              message: >-
                Garage Door Notifications have been disabled by
                {% set p = states.person | selectattr('attributes.user_id', 'eq', trigger.to_state.context.user_id) | list %}
                {{ p[0].attributes.friendly_name if p | count == 1 else 'unknown' }}
              data:
                ttl: 0
                priority: high

but I’m thinking that I can’t really do that as this notification doesn’t seem to be working after that change. Can you please give me a little more guidance on how to implement this?

1 Like
#4

I believe the failure is due to how my example refers to the Trigger State Object (a.k.a. the trigger variable).

Your automation has three triggers, the first and second are State Triggers, referring to the same input_boolean, and the third is an Event Trigger listening for mobile_app_notification_action. The following is designed to work with a State, Template, or Zone Trigger because all have a “to_state” as documented here (Templating).

trigger.to_state.context.user_id

If your automation is triggered by the Event Trigger, all references to trigger.to_state will return nothing for the simple reason that the returned object doesn’t have to_state (it has event). In other words, it should be:

trigger.event.context.user_id

However, that will fix one thing but break another. If the automation is triggered by the input_boolean, then trigger.event will be undefined.

To handle both types of triggers, the template will first need to check if trigger.platform is event.

See if this work any better (remember, you cannot test this by manually executing the automation):

          - service: notify.mobile_app_matt_s_pixel_5
            data:
              message: >-
                Garage Door Notifications have been disabled by
                {% set uid = trigger.event.context.user_id if trigger.platform == event else trigger.to_state.context.user_id %}
                {% set p = states.person | selectattr('attributes.user_id', 'eq', uid) | list %}
                {{ p[0].attributes.friendly_name if p | count == 1 else 'unknown' }}
              data:
                ttl: 0
                priority: high
4 Likes
User Action Log
#5

Oh!!! I missed that event to to_state change. That makes perfect sense!

Also, in this case, just changing the trigger line to event rather than to_state is sufficient because the way that this automation works, the context will only ever be needed if it is triggered by an event. The state changes won’t activate this particular notification.

One final question: is there anyway to take that user information and pass it along in a turn_off service? That way if I use the notification action to close the door, it actually shows up in the history as who did it. See example below: The most recent action was initiated by the notification action where as all the other ones were done through the front end.

image
image399×522 17.7 KB

#6

If you mean something like this then no; service calls don’t support overriding the user_id.

  - service: switch.turn_off
    data:
      entity_id: switch.whatever
      user_id: long-winded_identifier_goes_here
#7

Yeah, that is what I suspected. Oh well. Thanks for all the help!!!

#8

You’re welcome!

Please consider marking my first, or second, post with the Solution tag. Only you, the author of this topic, can do that. It will automatically place a check-mark next to the topic’s title which indicates this topic is resolved. This helps other users find answers to similar questions.

#9

Okay, so I’d love to do that, but I can’t figure out how! lol.

I found Tinkerer’s How to help us help you - or How to ask a good question post on here, which lists the way to mark a solution as hitting the hamburger menu and then selecting the checkmark box.

I don’t see that though. Did they change the method for selecting a post as a solution at some point?

image
image734×498 20.2 KB

#10

Now that you mention it, I believe it’s because the topic is in the Blueprints category. The Configuration category allows for marking Solution posts but for some reason the Blueprints category doesn’t (maybe the admins overlooked to enable the feature when the category was created).

I suppose you could try removing the Blueprints category and see if that makes the Solution tag appear in the post (this topic isn’t truly about blueprints but simply templating).

#11

That did it! Yeah I debated whether the blueprints tag was really applicable or not. Now I know. :slight_smile:

#12

Thanks for confirming that was the problem. I will contact a moderator and ask to have the Blueprints category permit the Solution tag. The category that doesn’t need it is Blueprints Exchange.

#13

Done :+1:  

1 Like