test mode not selecting correct card Alert Ticker Card v1.3.3

[jazzarmac]

Hi @djdevil
not getting the correct card displaying in preview when switching on test. Can you have a look please, thanks

Just downloaded V1.3.4 still same issue

[djdevil]

HI @jazzarmac can you send a video of this bug?

[jazzarmac]

https://github.com/user-attachments/assets/f9275187-6f17-4a7d-b43e-e79f3e16269b
Here you go

[jazzarmac]

Hi @djdevil did you manage to get a look at this by any chance?

[djdevil]

hi @jazzarmac I copied your configuration and tested the test mode to select each warning and I didn't find any problems. You should delete the card and copy the configuration again to see if it works, perhaps during some update the viewing mechanic was blocked.

[jazzarmac]

Hi @djdevil tied what you suggested above , but no difference. What i have notice is the priority setting. If i set it to 1 it displays the correct card, if i change it to any other priority than 1 it displays the incorrect card.

Recording.2026-07-08.205428.mp4

[djdevil]

Hi @jazzarmac — the priority clue nailed it, thank you.

Root cause: alerts are sorted by priority before rendering. When test mode first jumped to the previewed alert it cached the sorted-array position and skipped re-evaluation on subsequent updates. When you changed the priority, the sorted order shifted — but this._currentIndex still pointed to the old position, now occupied by a different alert. Priority 1 always appeared correct because position 0 happened to match the default index.

Fixed in v1.3.6 — test mode now re-resolves the target alert's position in the sorted array on every update, so changing priority, message, theme, or any other property immediately reflects in the preview.

[jazzarmac]

Hi @djdevil .Have updated, reset front end cache in HA app, hard rest chrome , still the same I'm afraid, see below.

Recording.2026-07-09.173207.mp4

[djdevil]

Hi, thanks for the follow-up!

I can't reproduce this on my end after the v1.3.6.2 update — could you help me narrow it down?

First, please confirm the version is actually loaded:
Open your browser DevTools → Console and paste:

document.querySelector("alert-ticker-card")?.constructor?.version
It should return "1.3.6.2". If it returns an older version, the new file isn't being served yet.

If the version is correct, a deeper cache clear:
HA's Lovelace caches JS very aggressively. Try:

In HA → Developer Tools → Template → restart the frontend resource manually, or bump the resource URL query string (e.g. ?v=2)
In Chrome: Settings → Privacy → Clear browsing data → Cached images and files (full clear, not just the HA app refresh)
Try an Incognito window — this rules out extension interference and confirms whether it's a cache issue
If it still happens after a confirmed fresh load, please share:

Which priority values you're testing (e.g. going from priority 1 → 2 → 3)
How many alerts you have configured and whether they have conditions set
A minimal YAML config that triggers the bug so I can replicate it on my end

[jazzarmac]

Hi @djdevil i get this when i follow your instruction

[djdevil]

Sorry — that command doesn't work either since the card wasn't registering its version in window.customCards. Fixed in the next build.

For now, the reliable way to check your loaded version:

Open DevTools → Sources tab
Find alert-ticker-card.js in the file tree (under your HA domain)
Press Ctrl+F → search for CARD_VERSION
The value next to it is your loaded version
Or paste this in the Console to see which URL/file is loaded:

performance.getEntriesByType("resource").find(r => r.name.includes("alert-ticker-card.js"))?.name

If the file has a query string like ?v=1 that you haven't bumped, the browser is still serving the old cached version. Change it to ?v=2 in Settings → Dashboards → Resources and hard-reload.

[jazzarmac]

seem to have 2 entries both show the same version number

[djdevil]

Root cause: your config has a group: true alert (the waste bins). In test mode, the preview logic was resolving the alert's position before the grouping pass. The grouping pass then collapses those 4 waste entities into 1 slide, shifting every alert that comes after it. _currentIndex was pointing to a pre-grouping position but _activeAlerts had already been updated to the post-grouping array — so the wrong alert appeared. Priority-1 alerts happened to sort before the waste group and were never shifted, which is why they always displayed correctly.

Fixed in next v1.3.7 — the preview index is now resolved after the grouping pass on the final array, so the position is always consistent with what's actually displayed.

[jazzarmac]

Thanks @djdevil all sorted . Not sure why that alert was grouped ! Thank you for your time and help