Show alert message till I dismiss the alarm (even the trigger is still unchanged)

[RobertoPuraVida]

I do have a question I could not find a "quick" solution for.
I understand the "permanent" message is showed up as long as an state is true and can't be dismissed.
A non-permanent message is showed either for a certain time or as long as the state is true (and I can set a snooze-time)

I like to have an alert message (permanent) till I dismiss it. As an example: I get an alert for an earthquake. The magnitude is the trigger.
The alert is showing up, fine. But I can not dismiss (because the trigger is the magnitude of the very last earthquake) when set to PERMANENT. And if I get the alert as "non-permanent", I can only snooze for a certain time (but not "delete" the alert.

Yes, I can build helpers etc. But is there an easier way (without Helpers) in Alertticket card?

[djdevil]

Hi @RobertoPuraVida, great use case — and exactly the kind of scenario the card should handle natively!

Added in v1.3.9.2 as a new dismiss action type.

Assign it to any tap/hold/double-tap slot on the alert:

alerts:
  - entity: sensor.last_earthquake_magnitude
    theme: emergency
    message: "Earthquake {state} detected"
    tap_action:
      action: dismiss

How it works:

• Tap the card → alert is hidden immediately
• The dismiss is tied to the entity's current last_changed timestamp, stored in localStorage
• When the entity fires a new state change (new earthquake, new doorbell press, etc.) → the dismissed record is automatically cleared and the alert reappears
• Persists across page reloads, no helpers required

Also selectable directly in the visual editor under the Tap / Hold / Double-tap action dropdowns.

---

☕ If this card saves you time, consider buying me a coffee — it keeps the updates coming!

[RobertoPuraVida]

Thank you very much for the new action type!! Super fast reaction. I have already changed my alarms. Unfortunatelly, it doesn't work every time. Sometimes I have to tap 3-5 times till the message disappears. I don't know why.

[djdevil]

Thanks for reporting this, @RobertoPuraVida!

The root cause is a browser quirk on mobile: when no e.preventDefault() is called on the touch event, the browser's scroll-detection can fire pointercancel instead of pointerup — silently dropping the tap before the action runs. This was happening specifically for dismiss because the prevention was only applied when a hold action was also configured.

Fixed in v1.3.9.3 — preventDefault() is now always called on touch interactions, so every tap is reliably captured regardless of which actions are configured.

---

☕ If this card saves you time, consider buying me a coffee — it keeps the updates coming!