Case Sensitive issue in Zone and look-up list

[SirGoodenough]

Ground Rules
Before you report a 'Bug', you need to make sure you have read the accompanying *.md file or Community Exchange post main file completely and followed all the settings required there.
This is important as if these instructions are not followed, you will likely have a bad day and be forced to contact me for help. Not that I don't want to help, but personal interaction takes me a while to respond and is generally non-productive.

Issues are not a place to ask questions, see the Discord links below for that. This is for broken things. If you are not sure, PLEASE go to Discord and ask the question first.

If you have a general question, I prefer them to be asked on Discord. Ping me in the channel, I don't often respond to DM's... @SirGoodenough

I also monitor the Blueprint Exchange post related to each Blueprint and will respond there.

There are 3 places on Discord that I monitor, in preference order:

My personal Discord HA Channel: https://discord.gg/EqtsKMHAhv
DrZzs Blueprint channel: https://discord.gg/jvk7yEFyX3
Homa Assistant Blueprint Channel: https://discord.gg/jPPvqsWwzh

Do if you think you found a bug where the text points you wrong, or something is just broken, continue here. If you have a Feature Request, see the other Issue Template...

Describe the bug
I was experiencing the same thing. It turned out to be the case-sensitive nature of YAML, and the condition deciding Home <> home. https://community.home-assistant.io/t/person-alert-blueprint/542209/8?u=sir_goodenough

To Reproduce
Steps to reproduce the behavior:
On Discord here: https://discord.com/channels/693125294957133844/693156036214915082/1105419979827974165

Expected behavior
Home pulled from the zone matches Zine in the users status

Screenshots
If applicable, add screenshots to help explain your problem.

What version of the blueprint has the issue?
2023-03-01.1

What was the version of Home Assistant Core?

What type of installation are you running?

YAML snippets INCLUDING the Script or Automation that you built to call the blueprint
(use 3 backticks before and after your code to format it properly)
See here for example: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks

Additional context
Add any other context about the problem here.
PR created containing proposed code.

[SirGoodenough]

will close with #9 (comment)

[Valiante]

To expand on the above, I found I was receiving notifications for all zones except home. It transpired the autoconfigured "Home" zone had an all-lowercase name (home) but its friendly name was capitalised (Home). These seemed to be uneditable either in the UI or configuration.yaml.

As a result, the action to Determine if there was an actionable event was returning false, because YAML is inherently case-sensitive. The condition '{{ to_state in friend_zone }}' and other similar conditions were returning false negatives (because when arriving home, to_state would be "home" but friend_zone contains all the zone friendly names, including "Home").

To mitigate this, I converted each relevant variable to lowercase on declaration, so regardless of how the zone names are stored, the conditions will no long be case-sensitive. The relevant section of updated code in Person_Alert_Blueprint.yaml (now merged into the master branch) is below:

variables:
  people2monitor_var: !input people2monitor
  zone2monitor_var: !input zone2monitor
  friend_zone: >
    {% set ns = namespace(zone=[]) %}
    {% for z in zone2monitor_var %}
    {% set ns.zone = ns.zone + [states[z].attributes.friendly_name | lower] %}
    {% endfor %} 
    {{ ns.zone }}
  to_state: '{{ trigger.to_state.state | lower }}'
  from_state: '{{ trigger.from_state.state | lower }}'

Note the addition of | lower to each variable/array involved in the condition.