Hi mate.
In playing with my state filter additions I believe I have found a bug. I will try to refer to only your original 0.10 gist. I believe new snapshots can cause the zone filter to be bypassed incorrectly.
This section below starts at line 285
zone_filter: "{{ not zone_only or entered_zones|length > 0 }}"
stationary_moved: "{{ event['after']['position_changes'] > event['before']['position_changes'] }}"
zone_only_changed: "{{ zone_only and (entered_zones|length > 0 and not last_zones|length) }}"
entered_zones_changed: "{{ zones|length > 0 and (zones|select('in', entered_zones)|list|length > 0 and not zones|select('in', last_zones)|list|length) }}"
update: "{{ new_snapshot and not loitering and not presence_changed and not zone_only_changed and not entered_zones_changed }}"
- alias: "Notify on loitering or significant change"
choose:
- conditions: "{{ loitering or (not home and zone_filter and (new_snapshot or presence_changed or stationary_moved or zone_only_changed or entered_zones_changed)) }}"
zone_filter is true simply by having the toggle enabled and any item in the associated list.
Due to the conditions (last line above) a new snapshot can trigger an update without zone_only_changed or entered_zones_changed actually changing.
It is resulting in traces like this were the initial notification is not sent because the zone filter is correctly applied however subsequent snapshot updates to result in a notification dspite the required zones never being entered.
my proposal is to edit the zone_filter line from:
zone_filter: "{{ not zone_only or entered_zones|length > 0 }}"
to
zone_filter: "{{ not zone_only or entered_zones|length > 0 and zones|select('in', entered_zones)|list|length > 0 }}"
This should cause the condition to remain false unless a required zone has been entered unless i am misunderstanding something.