Similar to the situation already discussed here I’m trying to pass an addtional integer to the notify.rest integration’s data field to get it included in the outgoing request.
For example, this works fine as priority is passed as a real integer in the JSON data:
When using a template, it breaks as priority is now of type string and ntfy won’t accept the request:
- name: ntfy
platform: rest
method: POST_JSON
data:
topic: home-assistant
tags:
- house
priority: "{{ data.priority if data.priority is defined else '3' | int }}"
title_param_name: title
message_param_name: message
resource: https://ntfy.sh
Which steps would be required to convert the priority value to a proper integer when using a template in a case like this?
Edit: Of course a workaround would be to define multiple instances of notify.rest with different names and priorities, but would be nice to get it working directly.
What happens if you define the entire data dictionary with a template, with priority unquoted? This will fail if data itself isn’t defined: I’m not clear where that is coming from. The is defined trap only works for an existing data but with no priority.
- name: ntfy
platform: rest
method: POST_JSON
data: >
{{ { "topic": "home-assistant",
"tags": ["house"],
"priority": (data.priority if data.priority is defined else 3)|int } }}
title_param_name: title
message_param_name: message
resource: https://ntfy.sh
Note the extra brackets in the priority line: your prior attempt was only int-ing the fallback 3.
What I find puzzling is that I would expect Home Assistant’s native typing to have rendered an integer value for this template:
priority: "{{ iif(true, 3, 1) }}"
Native typing determines the template result’s type by its appearance. In other words, attempts to cast the result’s type using Jinja2 filters (int, float, string, etc) are ultimately overridden by native typing. The result 3 looks like an integer so native typing would cast it as an integer. Yet, you’re seeing it converted to a string "3".
It wouldn’t matter because native typing normally overrides it anyways. However something is amiss here because even the template example I suggested, which clearly reports 3 as its result, ends up as "3".
Same here, and for the exact same reason (ntfy priority). And no matter what I try, the template only returns a string…
[ Edit: I think this might be specific to the REST integration. Looking at the code, the template is processed with parse_result=False. I believe this is what forces the result to be a string, similar to the way legacy_templates worked.
Seems to be specific to the REST integration - see my comment above for details. I really cannot understand why this specific integration behaves differently… hopefully it is just an oversight