Pin explicit UIDs on auto-provisioned Grafana datasources

[youzer-name]

Summary

• Add uid: pwd-influxdb-auto to grafana/provisions/datasources/influxdb.yml and uid: pwd-sunandmoon-auto to grafana/sunandmoon-template.yml.
• Without an explicit uid, Grafana auto-assigns one at provisioning time. That can collide (e.g. when a second auto-provisioned Postgres-family datasource is added elsewhere in the stack) or drift across restarts/reprovisioning, breaking dashboard panels that reference a datasource by UID.

⚠️ Upgrade note (please read before merging)

This is a breaking change for existing installs: on next Grafana restart after upgrading, these datasources will get the new pinned UID if they previously had a different Grafana-generated one. Dashboards imported before this change may show "datasource not found" on affected panels until either:

• the dashboard is re-imported, or
• the panel's datasource is manually re-linked to the same-named datasource in the Grafana UI.

Worth a callout in the release notes for whatever version this lands in, so upgrading users aren't surprised. Happy to draft that note if useful — didn't want to presume the versioning/release process by editing RELEASE.md/VERSION myself.

Test plan

• YAML validated (yaml.safe_load) on both changed files
• Manual: confirm Grafana provisions both datasources with the pinned UIDs on a fresh setup.sh run, and that existing dashboards can be re-linked without issue

[jasonacox-sam]

Good proactive fix. Pinning explicit UIDs on auto-provisioned datasources prevents collisions and drift — especially relevant with #830 (TimescaleDB) adding a Postgres-family datasource to the stack.

Both datasource files are covered:

• influxdb.yml → uid: pwd-influxdb-auto ✓
• sunandmoon-template.yml → uid: pwd-sunandmoon-auto ✓

One upgrade consideration for existing users: If someone has already provisioned Grafana with auto-assigned UIDs, adding explicit UIDs here will create new datasource entries on next restart rather than updating the existing ones. Existing dashboards that reference the old auto-assigned UID would need to be re-pointed. Worth calling out in the upgrade notes when this merges — but the fix itself is correct.

— Sam 🌊

[Copilot]

Pull request overview

Pins stable Grafana datasource UIDs for the auto-provisioned InfluxDB and Sun/Moon datasources so dashboard panels that reference datasources by UID don’t break due to Grafana-generated UID drift or collisions.

Changes:

• Add explicit uid: pwd-influxdb-auto to the InfluxDB provisioned datasource.
• Add explicit uid: pwd-sunandmoon-auto to the Sun/Moon provisioned datasource.
• Normalize minor YAML formatting in the Sun/Moon datasource definition (jsonData: spacing).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
grafana/sunandmoon-template.yml	Pins a fixed UID for the Sun/Moon auto-provisioned datasource to prevent UID drift/collisions.
grafana/provisions/datasources/influxdb.yml	Pins a fixed UID for the InfluxDB auto-provisioned datasource to keep dashboards stable across reprovisioning.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jasonacox-sam]

Valid point — and @youzer-name already flagged this in the PR description under the upgrade note. When this lands we'll make sure the RELEASE.md callout covers the re-import/re-link remediation steps for upgrading users. No code change needed here.

[jasonacox]

@jasonacox-sam add to release notes (unreleased)

[jasonacox-sam]

Added to RELEASE.md under a new Unreleased section:

Grafana datasource UID change — auto-provisioned InfluxDB and Sun/Moon datasources now have explicit, stable UIDs (pwd-influxdb-auto and pwd-sunandmoon-auto) instead of Grafana-generated ones. This prevents UID collisions and drift across reprovisioning. Existing installs: after upgrading, Grafana will create new datasource entries with the pinned UIDs. If dashboards show "datasource not found" on affected panels, either re-import the dashboard or re-link the panel datasource to the same-named entry in the Grafana UI. (PR #840 by @youzer-name)

Committed to main — will move under the version header when this PR merges and we cut the next release.

— Sam 🌊

[jasonacox]

Sorry, I've been terribly busy. I'm trying to close out some of these but I'm having heartburn over this one. The golden rule has been "no breaking changes" and we have gone out of our way to help with that. As @youzer-name mentions this woudl impact our entire install base, require them to re-import the dashboard, which is not a standard pattern most people follow (even if the upgrade script mentions it) since most people quickly customize their dashboard.

I appreciate the PR and the point is valid, but we do not see this a prevalent issue or it would have surfaced in issues long before now.

If there is a way to make this non-breaking, or as an opt-in change, then I would support it. Otherwise, I think we stick with the golden rule.

[jasonacox-sam]

@jasonacox — agreed, the breaking concern is real. I checked the dashboard JSONs and they contain hardcoded Grafana-generated UIDs (RSabAvRRzVz, RSabAvRRzZ) alongside the templated ${DS_INFLUXDB...} variables. Roughly half the panels use the hardcoded UID, so those would break on upgrade if we pin new UIDs without also updating the dashboards.

Two paths forward:

1. Make it non-breaking — expand this PR to also replace the hardcoded UIDs in dashboards/dashboard.json and dashboards/dashboard-alt.json with ${DS_INFLUXDB (AUTO PROVISIONED)} / ${DS_SUN_AND_MOON (AUTO PROVISIONED)} variable references. That way the dashboards are UID-agnostic and the pinned UIDs work transparently for both fresh installs and upgrades.

2. Close it — as you noted, this hasn't surfaced as a real problem in issues. The collision risk is theoretical (mostly relevant if Add TimescaleDB (PostgreSQL) as an alternative/parallel datastore #830 TimescaleDB lands), and the golden rule holds.

I'd lean toward option 1 if @youzer-name is willing to take it on — it's a meaningful improvement that makes the dashboards more portable. But if the scope is too much for this PR, closing is the right call. Either way, I'll revert the RELEASE.md addition I made earlier since we're not proceeding with this as-is.

[jasonacox]

@jasonacox-sam The issue is that most people don't replace (or re-install) their dashboard.json during an upgrade because they highly customize them but still want to upgrade the underlying code (pypowerwall proxy server version and any tweaks). Changing the dashboards may still be a good idea but won't help make this a non-breaking change unless I'm missing something.

[jasonacox-sam]

You're right — I was wrong about option 1. Updating the dashboard JSONs in the repo doesn't help if users don't re-import them, and most don't because they've customized their layouts.

The fundamental problem: on an existing install, Grafana already created datasource entries with auto-generated UIDs. Users' dashboards (customized or not) reference those UIDs in every panel. If we pin new UIDs in the provisioning YAML, Grafana updates the datasource entries on next restart — and every panel referencing the old UID goes dark. There's no way to patch that from the repo side without touching each user's grafana.db directly.

The only path to non-breaking I can think of would be a migration step in upgrade.sh that opens grafana.db with sqlite3, finds the current UIDs, and rewrites all dashboard panel references to match the new pinned ones. But that's fragile — it would need to handle every dashboard a user might have imported, and operating directly on grafana.db while Grafana is running is risky.

Given that this hasn't surfaced as a real problem in issues, I agree with sticking to the golden rule. Recommend closing #840.

I've also reverted the unreleased RELEASE.md entry I added earlier.

— Sam 🌊

[jasonacox]

Holding this for now.