Javascript not executing in nested service_data keys

[hilburn]

Probably not the best phrasing for the title but it's the closest to get my point across

The absolutely simplest rule I've put together that demonstrates this fully is:

- name: rooms
  elements:
    - room.kitchen
    - room.living_room
  hover_action: false
  hold_action:
    action: call-service
    service: notify.persistent_notification
    service_data:
      title: Testing
      data:
        notification_id: ${element.id}
      message: ${"Room " + element.id}

What this should do is force a maximum of 1 notification per element as the notification_id returning element.id will cause the notification to override any previous notifications with that same ID
However, it instead uses the string literal '${element.id}' as the notification_id, causing it to override any previous notification from any element, regardless of what its element.id is.
The message key parses the javascript correctly

I've found the same effect parsing JS for sub-keys with other commands, and found no difference when it comes to using multiline js with returns rather than the ${} syntax

[exetico]

1. Does the notification renders on your desktop, with the code you provided? If so, what ha-floorplan and Home Assistant version are you using?
2. Did you provide the same snippet, as you're currently using in Home Assistant? (follow up to point no. 1). Please provide the code you used to generate the notification with ha-floorplan (and not though other integrations or similar, if that's the case)
3. Why do you need ha-floorplan to trigger notifications in the first place? It doesn't really sound like a job for ha-floorplan, so I'd like to know why.

[exetico]

1. But does your own example fire the event? I'm not asking about what's not working with your custom data. I mean, the notification itself, called through ha-floorplan, does that show up after you're holding the element in the SVG? On my system, it's not even triggering the notification. Please revisit your original code, and let me know if you're able to use the same code, to trigger another notification in your browser, within the hold_action :).

2. It sounds like you've provided a minimal code, but possible didn't test it in ha-floorplan. Am I right? Else, I'd need to check my own test-system.

Thanks for the details.

Please think about the https://xyproblem.info/ I've mentioned in the first discussion. You're flagging a possible bug here, but don't give me the background story, of what's you're actually trying to do :-) Thank you for mentioning the actual problem in point no 3.

[hilburn]

1. for the 3rd time now yes. It triggers the action properly to a point - the error is that it DOES NOT render the javascript in the notification_id key correctly
2. You are not right, I have tested this extensively.
   To make things clear - here, a screen recording of me firing the notification by clicking on 2 of the defined rooms, including the room.living_room notification overwriting the room.kitchen notification which it is unable to do
   https://imgur.com/a/K3vMACV

And not everything is an XY problem. What I want to do is be able to is return an element.id into a sub-key. Many services/actions require this data format to work correctly. This is the minimal dependency example I am able to generate to demonstrate the problem

[exetico]

Bare with me. It must be something internally on my test-instance. I'll take a look at that, once I find time to dig into it.

Mentioning the actual use-case still helps for other reasons, like other persons trying and use honeycomb, or things like that. But, we agree; the use-case you provided was just fine :-)

Update: Apparently, is has been a long way. A bit too long. My example did contain a entity, which your example didn't. I ended up using a mock-up I had for both a entity and a element, but didn't notice that I forgot to remove the entity-part of the code. I'm sorry about that.

[exetico]

Here's a working example with the suggested | > solution. I know it's not 100% clear that it's possibly to do it like that, but that's how we're allowing you to parse data through with the data property. We're still "stuck" in the "service_data" area, but at least we're not trying to remove anything from a action/service call like this, and therefore, it's possible to do like this.

              tap_action:
                action: call-service
                service: notify.persistent_notification
                service_data:
                  title: Testing
                  data: |
                    > console.log("element.id", element.id);
                    return {"notification_id": element.id}
                  message: ${"Room " + element.id}

There's other ways, too. But I think that's plenty for you, after I've read last couple for message. If we talking about experience, you must be in top 10 % of the ha-floorplan users 😄.

[exetico]

And btw! Let me know how it goes with the honeycomb menu. There's a few discussions about honeycomb menus in general, and I personally starting looking at that, too. But, sadly I've not found the proper amount of time to make my new floorplan (the one provided in our "Modern Floorplan" does not match the current house I live in, anymore 😢 🏠 😆)

But I'm struggling to find time to make it...

[hilburn]

Thank you so much - it's working now with that

I was able to remove my temporary solution which was a single room per rule with a static "climate_id", and then alias/anchoring the yaml for the honeycomb_menu, which was not pleasant!
Have a little bit more fiddling to do - as the plan was to actually use the XY slider for temperature, and i'd like to show a background on any "active" preset mode for the room, but that's all fairly easy now it knows what climate entity to talk to!