Bug: Card ignores config changes written via the standard Lovelace `lovelace/config/save` API

[pasqua80]

Environment*

• Home Assistant Core: 2026.7.4
• Drag & Drop Card (frontend): v2.0.8
• Drag & Drop Card Backend: v0.1.8
• Installed via HACS (/hacsfiles/Drag-And-Drop-Card/drag-and-drop-card.js)
• Dashboard mode: storage (UI-managed), affected card config: storage_key: "layout_PAD", auto_save: true, container_size_mode: "fixed_custom"

Summary

When I update the config of a card nested inside a custom:drag-and-drop-card by calling Home Assistant's standard lovelace/config/save WebSocket command (the official API any external tool/script uses to edit a dashboard), the change is correctly persisted in the dashboard's stored Lovelace config — I verified this by reading it back immediately after with lovelace/config. However, the running card keeps rendering the old/stale content indefinitely, even in a brand-new private/incognito browser window that had never loaded the dashboard before. The only way to make the change actually appear is to open that specific nested card's own "Edit in YAML" dialog inside the Home Assistant UI and save it from there.

Steps to reproduce

1. Create/open a dashboard using custom:drag-and-drop-card with auto_save: true and a storage_key set.
2. Add a nested card (e.g. an entities card) to it via the normal dashboard editor.
3. Using an external tool (not the drag-and-drop-card's own UI), call the standard lovelace/config/save WebSocket command to update that nested card's config (e.g. add new entities to its entities list), targeting the dashboard's url_path.
4. Confirm via lovelace/config that the change is present server-side (it is).
5. Load the dashboard in the browser — even a fresh private/incognito window that never had it open. The nested card still renders the OLD content.
6. Open that nested card's own "Edit in YAML" (three-dot menu on the card) inside the HA UI, paste the exact same updated YAML, and save from within that dialog.
7. The change now appears correctly and persists.

Expected behavior

A change written through the standard Lovelace config API should be reflected the next time the dashboard loads, the same as it would for any native/built-in Lovelace card.

Actual behavior

The card appears to keep its own separate persisted source of truth (tied to storage_key, likely handled by the backend integration Drag & Drop Card Backend v0.1.8, given there's a dedicated backend update entity), rather than treating the standard dashboard's cards array as authoritative after initial load. External changes to the dashboard's stored config are silently ignored by the running card until a save is triggered from inside the card's own UI. There is no error or warning anywhere — the API call reports success, and reading the config back confirms the change, which makes this confusing to debug.

Additional data points from my investigation

• I checked frontend/get_user_data with key "layout_PAD" (matching the card's storage_key) for my admin account — it returned null, so the layout doesn't seem to be stored there under that literal key, at least not for that user.
• The stale content persists even in a fresh incognito window that never loaded the dashboard before, which rules out browser-side caching (localStorage/IndexedDB/service worker) and points to some other persisted state — most likely server-side, via the backend integration — that only gets updated through the card's own internal save action, not by changes to the underlying Lovelace dashboard storage.
• The card ships with its own backend HACS component (Drag & Drop Card Backend, v0.1.8) in addition to the frontend module — this is presumably where the separate persisted layout/content lives.

Why this matters

Anyone managing Home Assistant dashboards programmatically (backups, git-versioned configs, scripted deployments, custom tooling) will have their changes to any drag-and-drop-card silently fail to apply — with no error — unless they specifically re-open and re-save that exact card from its own native editor.

Things that might be worth checking

1. Where exactly the backend integration stores per-card layout/content, and whether it's keyed independently from the dashboard's canonical Lovelace config.
2. Whether the card could reconcile/prefer the incoming dashboard cards config over its own stored state on load when they diverge — or at least expose a "resync from dashboard config" action.
3. Whether the card listens for a lovelace_updated (or similar) event to invalidate/refresh its internally cached layout, instead of only refreshing after its own internal save actions.

Happy to provide more detail (raw dashboard config JSON, network trace, etc.) if useful.

[Prosono]

Hi! I will look into this

[Prosono]

Hi @pasqua80,

Thank you for the very detailed investigation — I think you are looking in the right direction.

The backend snapshot was being treated as the source of truth for both the layout and the nested card content. This meant that changes written through lovelace/config/save could be present in Lovelace, but still be overwritten by the older backend copy when the dashboard loaded.

I’ve now changed this so that the backend remains responsible for the layout — positions, sizes, tabs, etc. — while Lovelace is treated as the source of truth for external changes to the nested card configurations.

Could you please test this again after updating to the next release? Ideally, repeat the same steps from your report:

1. Change a nested card through lovelace/config/save.
2. Confirm the change using lovelace/config.
3. Reload the dashboard or open it in a new private window.
4. Check that the updated card appears without opening and saving its YAML editor.

Please let me know whether it works correctly in your setup. Your original report was extremely helpful in tracking this down!

[pasqua80]

Thanks for the fast turnaround! I re-tested with the version currently installed via HACS (Backend v0.1.9, Frontend v2.0.10, both dated 2026-08-29 — the latest available). Two separate findings, neither matching the expected behavior yet.

Methodology / who did what: The API-level testing (calling lovelace/config/save, reading back lovelace/config, reading/writing the backend's /api/dragdrop_storage/{key} endpoint, opening the raw WebSocket connections) was carried out by an AI coding assistant (Claude, Anthropic — the "Claude Sonnet 5" model, via the Claude Code CLI) that I'm using to script against my Home Assistant instance's REST/WebSocket API in Python. The physical/on-device steps — powering the wall tablet off, opening the dashboard in a new Safari window and in a Private Browsing window, checking what actually rendered on screen, clearing Safari's stored website data — were all done by me by hand, since those obviously require a real browser/device and can't be scripted from the AI's side. I'm relaying the combined results here. Below I've marked each step with [API] (done by the assistant via script) or [browser] (done by me by hand) so it's clear which is which.

1. The core repro still fails — and now fails earlier than before

I repeated the exact steps from the original report, this time controlling carefully for any browser involvement:

1. [API] Changed a nested card's config (added a title field to an entities card) via lovelace/config/save.
2. [API] Immediately read back lovelace/config — the title field was already gone.
3. [API] To rule out a race condition, checked again 3 times using brand-new WebSocket connections, ~3 seconds apart, with no browser ever opening the dashboard in between.
4. [API] All 3 checks came back without the title field.

So in this version, the change doesn't even survive in the dashboard's own stored Lovelace config — previously (per my original report) it did survive there, and only the rendered card ignored it. Now it appears to be reverted essentially immediately, before any frontend ever loads the page. This points to something server-side (the backend integration, or a listener reacting to the Lovelace config write) actively overwriting the nested card content back to its own stored copy, rather than the frontend simply preferring a stale cached copy on render.

To rule out any client involvement entirely (see finding #2 below — clients can hold stale state in ways that are easy to mistake for a server-side issue), I repeated the test once more with every possible client eliminated:

5. [browser] Powered the wall-mounted tablet that normally displays this dashboard fully off.
6. [browser] Opened the dashboard from a brand-new Private Browsing window that had never touched it before.
7. [browser] Visually confirmed the title was missing on screen.
8. [API] Confirmed the title field was also missing in both lovelace/config and the backend's /api/dragdrop_storage/{key} at that same moment.

So this isn't a rendering/caching issue on any client I can identify; the stored data itself reverts.

Happy to provide the exact WebSocket payloads/timestamps if useful.

2. Separate finding: stale data survives even a full browser restart, but not Private Browsing

While testing, I ran into a related but distinct issue: at one point 6 cards (added over several editing sessions) disappeared from the live dashboard after an API-driven change. Investigating this, I found:

• [API] Restoring the correct data via the backend's /api/dragdrop_storage/{key} endpoint worked immediately when checked via API.
• [browser] Opening the dashboard from a brand new Safari window (not a leftover tab — Safari itself had been fully quit beforehand) still showed the stale/old state, which then got auto-saved back, wiping the restore again (confirmed [API] right after by re-reading /api/dragdrop_storage/{key}).
• [browser] Opening the same URL in a Private Browsing window showed the correct, up-to-date state.
• [browser] After manually clearing Safari's stored website data for the HA origin (Website Data removal, not just quitting the app), a normal window then also showed the correct state and stopped reverting it.

This suggests the frontend card is holding onto some persisted client-side state (cache, IndexedDB, or similar) tied to the origin that survives a full browser quit/relaunch, and is not just an in-memory/live-tab issue as I first assumed. Combined with finding #1, it looks like there may be two separate reconciliation problems: one server-side (backend vs. Lovelace config) and one client-side (persisted browser cache vs. whatever the server now holds).

Let me know if a network trace or the raw dragdrop_storage payload from this session would help narrow it down.

[pasqua80]

Update after installing v2.1.0 (frontend) / v0.1.9 (backend, unchanged) — two separate results.

Methodology: as a heads-up, the API-level testing below (WebSocket calls to lovelace/config/lovelace/config/save, and direct reads of the backend's /api/dragdrop_storage/{key} endpoint) is done by an AI coding assistant (Claude, via Claude Code) that I use to script against my own Home Assistant instance. The browser-side steps (reloading the dashboard, checking on my tablet, exporting HAR files, checking the console) are done by me by hand on my own devices. I'll mark steps [API] or [browser] below.

1. The data-loss / stale-overwrite problem appears fixed
   While testing the original issue, I separately ran into cards disappearing after an API-driven config change — turned out to match issues with storage key/layouts #39 almost exactly (stale Lovelace state getting written back over the stored layout, different clients/tabs fighting each other, layouts scrambling on refresh). After updating to v2.1.0 and re-importing a known-good backup of my layout ([API], via /api/dragdrop_storage/{key}), the data has stayed stable and correct across multiple reloads, on multiple devices, without reverting. So that part of issues with storage key/layouts #39's fix seems to be working for me too. Thanks for tracking that down.

2. My original repro still fails, unchanged
   I re-ran the exact test from my original report, now on v2.1.0:

[API] Changed a nested card's config (added a title field to an entities card) via lovelace/config/save.
[API] Immediately read back lovelace/config — the title field was already gone.
[API] Checked the backend's /api/dragdrop_storage/{key} directly — also missing there.
Card count/other data was unaffected (still the correct 36 cards, matching finding #1 above) — so this isn't the same stale-overwrite bug from #39. It looks like nested-card-config changes made via lovelace/config/save still don't get picked up/persisted at all, exactly as in my original report.
So to summarize where things stand: v2.1.0 fixed the layout/data corruption issue, but the original ask — "a change written through the standard Lovelace config API should be reflected the next time the dashboard loads" — is still not happening in my setup. Happy to run any specific test you'd like, or share the raw

;)

[Prosono]

Hi @pasqua80,

Thank you for testing v2.1.0 and confirming that the data-loss issue is fixed. Your original lovelace/config/save issue appears to be separate, so I’d like to trace the exact API sequence before making further storage changes.

Could you please provide the following from one test run?

1. The complete WebSocket payload sent to lovelace/config/save, including url_path and config.
2. The complete response from that save request.
3. The following lovelace/config request and its response.
4. The response from /api/dragdrop_storage/{key} after the test.
5. Timestamps for each request, preferably including seconds or milliseconds.
6. Any relevant Home Assistant log entries from the same period.

Please remove access tokens, personal URLs and other sensitive information before sharing.
The reason I’m asking is that the backend integration does not listen for or modify Lovelace configuration—it only stores data sent directly to its own endpoint. Therefore, a Lovelace change disappearing before any dashboard client loads suggests there may be another save request, a url_path mismatch, or something else in the API sequence.

The raw requests should help us identify exactly where the change is being lost without risking another storage regression.
Thanks again for the detailed investigation!

[pasqua80]

Hi @Prosono,

Sorry for the delay getting back to you on this. Here's the requested test data.

Same methodology as before: [API] steps run via Claude Code against my own instance's WebSocket API, [manual] steps done by hand. This time I used a fresh, disposable test card (custom:button-card, inert - show_name: false, no real functional wiring) on a low-stakes tab, and added a brand-new name field to it so the change is unambiguous and can't collide with anything real.

Requested test data
1-2. lovelace/config/save request/response (url_path and token redacted):

// request (id/url_path/token redacted)
{"type": "lovelace/config/save", "url_path": "", "config": { /* full unchanged dashboard config, one card's inner "card.name" changed to "TEST_PROBE_1788762529" */ }}

// response
{"success": true, "result": null}
3. Immediate lovelace/config readback:

Request sent: 08:28:50.124
Response received: 08:28:50.144 (20ms later)
Target card's name field: "TEST_PROBE_1788762529" — present, matches what was just saved.
4. /api/dragdrop_storage/{key} right after:

Request sent: 08:28:50.145
Response received: 08:28:50.208
Same card's name field: absent - the backend copy has no idea this field exists (expected, since I never wrote to its own endpoint).
5. Re-checked both again after +5s, no client ever loaded the dashboard in between:

lovelace/config: name field still present, unchanged (08:28:55.299)
/api/dragdrop_storage/{key}: still absent, unchanged
6. HA logs for this window: nothing at all - no entries anywhere near this timestamp in system_log/list, consistent with your and my earlier findings that this fails silently.

Interesting difference from my original report
In this run, the Lovelace-side write did not revert - not immediately, and not after 5 seconds with no client involved. That's a different outcome than my original repro (where the change was gone almost immediately, before any browser ever loaded the page).

The one thing I can think of that differs between this test and my original one: I'm not 100% sure whether a browser/tablet tab had this specific dashboard open and rendering at the time of my original test vs. this one. Given auto_save / auto_save_debounce: 800 sound like frontend-side settings, my new working theory is that the revert might be caused by an actively rendering client periodically writing its own (backend-sourced, stale w.r.t. Lovelace) in-memory copy back over Lovelace - rather than something purely server-side reverting unconditionally. If no client currently has the card open/rendering, an API-driven Lovelace change seems to survive; if one does, it may get overwritten on that client's next auto-save cycle.

I can test this specific variable directly if useful - repeat the exact same steps while deliberately keeping a browser tab open and focused on the dashboard throughout, vs. with the dashboard fully closed everywhere - and report back which one reverts.

Bonus data point (unprompted, found while looking for a safe test card)
Just from normal use - no API/external tool involved at all - I duplicated an existing card through the card's own native editor (used the duplicate action on an existing card, then overwrote its YAML content with different content - not the "add new card" flow). Checking lovelace/config right after: that duplicated/edited card is not present in Lovelace's embedded copy at all, even though it renders correctly and is definitely in /api/dragdrop_storage/{key}. Separately, Lovelace's embedded copy still contains a card that no longer exists in the backend at all (removed a while ago). So the two stores are already meaningfully diverged just from routine use, independent of any external API involvement.

I also tested the plain "add new card" button (not duplicate) to see if this is specific to duplicating: it surfaced a distinct bug in the YAML editor's save (the type/entities defaults from the card picker don't get fully replaced by pasted YAML) - filing that separately so it doesn't muddy this thread, will link it here once posted.

Happy to run the client-open-vs-closed variant above, or anything else that would help narrow it down further.