Summary
With Alarmo configured as a master + multiple areas, one keypad button-press causes Alarmo to fire alarmo_command_success once per area plus twice for the master. This blueprint's event_command_success / event_arm_failure handlers have no entity_id filter, so every one of those events triggers a fresh arm_mode confirmation publish back to the keypad — all with the same transaction ID — and the keypad audibly beeps once per frame it processes.
Reproduction
Alarmo with N areas under one master (e.g. N=4), UEHK2AZ0/XHK1-UE keypad on this blueprint. Press disarm once.
Evidence
Raw MQTT capture of <set_topic> for one disarm press, transaction ID redacted as NNN:
mode:disarm transaction:NNN
mode:disarm <- from to_state_disarmed, no transaction field
mode:disarm transaction:NNN
mode:disarm transaction:NNN
mode:disarm transaction:NNN
mode:disarm transaction:NNN
Root Cause
AlarmoMasterEntity.async_alarm_disarm in the Alarmo integration fans a disarm out to every area and fires EVENT_DISARM / alarmo_command_success for the master (twice — once via its base-class call, once again after the area loop) and once per area.
This blueprint doesn't filter by ```trigger.event.data.entity_id``.
Suggested Fix
Add to both event_arm_failure and event_command_success top-level conditions:
- condition: template
value_template: '{{ trigger.event.data.entity_id == alarmo_entity_id }}'This still leaves the master's own double-fire (same entity_id, same context_id); fully collapsing to one confirmation needs an idempotency guard keyed on context_id / transaction (e.g. an input_text helper storing the last-handled transaction, checked/updated under mode: queued to avoid a race between the two near-simultaneous master events).
Environment
- Alarmo custom_component 1.10.19
- Blueprint v1.1
- Keypad UEHK2AZ0
- universal_electronics_inc.ts in zigbee-herdsman-converters
Summary
With Alarmo configured as a master + multiple areas, one keypad button-press causes Alarmo to fire
alarmo_command_successonce per area plus twice for the master. This blueprint'sevent_command_success/event_arm_failurehandlers have noentity_idfilter, so every one of those events triggers a fresharm_modeconfirmation publish back to the keypad — all with the same transaction ID — and the keypad audibly beeps once per frame it processes.Reproduction
Alarmo with N areas under one master (e.g. N=4), UEHK2AZ0/XHK1-UE keypad on this blueprint. Press disarm once.
Evidence
Raw MQTT capture of
<set_topic>for one disarm press, transaction ID redacted asNNN:Root Cause
AlarmoMasterEntity.async_alarm_disarmin the Alarmo integration fans a disarm out to every area and firesEVENT_DISARM/alarmo_command_successfor the master (twice — once via its base-class call, once again after the area loop) and once per area.This blueprint doesn't filter by ```trigger.event.data.entity_id``.
Suggested Fix
Add to both
event_arm_failureandevent_command_successtop-level conditions:This still leaves the master's own double-fire (same
entity_id, samecontext_id); fully collapsing to one confirmation needs an idempotency guard keyed oncontext_id/ transaction (e.g. aninput_texthelper storing the last-handled transaction, checked/updated undermode: queuedto avoid a race between the two near-simultaneous master events).Environment