Template in message makes the card flicker

[Callidus2000]

Hi,
first at all: great work, very helpful card.
But templating gives me a headache ;-)
I've got alarm entitie with the {name} like 'Garage Door State Volvo'. I'd like to implement the message to include only the 'Volvo' part to display "Garage door Volvo is open for 5min".

I was able to achieve this by using
Garage door {{ '{name}'|replace('Garage Door State ', '') }} is open for 5min
but the card then starts to flicker.

BTW: I had expected to use a template like {{ name | replace('Garage Door State ', '') }}

[richsimpson]

I notice the card might flicker once, when it shows a template, initially but not a constant flicker. More it shows the template in full then as it gets the answer it then flickers and shows the real value.

Not sure if this is same thing described differently, or the original post means its constant flicker?

[Callidus2000]

Hi,
I mean constant flickering, in different intervalls.

[djdevil]

Hi, thanks for the report and kind words — glad the card is useful!

Found the bug. When a message contains {{ }} template syntax alongside {name} (or {entity}, {state}), the card pre-substitutes those placeholders with real values before sending the template to HA's renderer — so {{ '{name}'|replace('Garage Door State ','') }} becomes {{ 'Garage Door State Volvo'|replace('Garage Door State ','') }} before the WebSocket call. That's intentional and produces the correct result, but it creates a cache key that differs from the raw alert.message string.

The problem: _syncTemplates() runs on every HA state update and cleans up "stale" subscriptions by comparing subscription keys against the raw template strings in the config. The pre-substituted key never matches — so on every update, the cached result was deleted, the next render showed the raw {{ }} expression, a new WS subscription was fired, and the card flickered when the response arrived. Repeat indefinitely.

Fixed in the upcoming v1.3.1: _syncTemplates now preserves any subscription that already has a cached WS result, so only genuinely unused subscriptions (no cached result, not in the current config) are cleaned up. The flicker stops after the first successful WS response.

As a tip for the future: you can also write {name} directly in the non-template part of your message and skip the Jinja2 workaround entirely:

Garage door {name} is open for 5min
The card resolves {name} to the entity's friendly name natively — no WebSocket round-trip needed, no flicker, and you can still rename the entity from the card's editor.

[Callidus2000]

Works somehow... The flickering is gone, but if multiple alerts are shown and I select "the next one" it always skips back to the first (it's the template one).

[djdevil]

Hi! Thanks for the follow-up report — you found a real bug introduced by the #113 flicker fix.

Root cause: in test mode, _computeActiveAlerts was checking _preview_index on every HA state update (which fires continuously). Since _preview_index was pointing to alert #0 in the editor, any time you manually navigated away , the very next state update would see the mismatch and silently force _currentIndex back to 0. This happened so fast it looked instantaneous.

Fix (next release):

The preview-index jump now only fires when the editor actually changes the selected preview alert — not on every state update. Manual navigation with the arrow buttons is no longer overridden.
As a secondary fix, state: "{{ }}" template triggers are now included in the subscription keep-alive set, so alerts using template-based conditions no longer disappear momentarily between state updates (which could also reset the index via the clamp logic).

Both fixes will be included in the next release. Thanks for the detailed report! 🙏

[djdevil]

Test the last version 1.3.2

[Callidus2000]

Seems to do the trick, thanks.