Skip to content

Migrating from knightss27-weathermap-panel

Network Weathermap NG is a continuation of the original knightss27/grafana-network-weathermap, archived in 2023. Maps built with the original plugin move across without being redrawn — nodes, links, colours, scales, and layout are all read from the same saved structure.

This page is the complete migration path, including the one step people most often get wrong.


The one rule: never switch plugins from the panel-type picker

Changing the visualization type in the UI destroys the map

Grafana resets a panel's options when you change its visualization type from the picker. Weathermap keeps your entire map — every node, link, and setting — inside those options, so switching this way discards all of it. There is no undo once the dashboard is saved.

Edit the dashboard JSON instead, as described below.


1. Export the dashboard

From the dashboard, use Dashboard settings → JSON Model (or Share → Export) and save the JSON.

Work on a copy

Import the migrated JSON under a new name/UID first and confirm it renders before retiring the original dashboard.


2. Change the panel type in the JSON

Find each weathermap panel and change its type:

{
  "type": "tamirsuliman-weathermap-panel",
  "options": {
    "weathermap": { "nodes": [], "links": [] }
  }
}
Old value New value
knightss27-weathermap-panel tamirsuliman-weathermap-panel

Leave options.weathermap exactly as it is — that object is the map, and this plugin reads the original format directly.


3. Import

Use Dashboards → New → Import and paste the edited JSON. Nodes, links, positioning, colour scales, and visual settings all come across.


This is the only part that may need attention, and since v1.6.7 it usually resolves itself.

Why it happens. Weathermap doesn't store a query's refId — it stores the query's display name, the label you pick from the dropdown in the link editor. NG computes that display name slightly differently from the original plugin in some setups, most commonly when several queries return a same-named column (very typical with the Infinity data source, where every query returns a field called Value). NG disambiguates those with the query's refId/labels; the original didn't. The saved string then matches nothing, and the dropdown looks empty — but nothing was deleted, and the underlying queries are untouched.

What NG does about it. On the first data load after import, the panel re-binds old-style names automatically. The rewrite is deliberately conservative — it only acts on bindings that currently resolve to nothing, only when a legacy name maps to exactly one current series and doesn't collide with a live name, and only once every query has loaded without error. Working bindings and template-variable queries are never touched.

Automatic re-binding covers every place a query name is stored:

Location Fields
Link sides sides.A / sides.Z — query and bandwidth query
Link status statusQuery
Link tooltips tooltipMetrics[].queryA / .queryZ
Node status statusQuery
Node tooltips tooltipMetrics[].query

When it can't decide. If two of your queries produce genuinely indistinguishable names, NG leaves those dropdowns empty rather than guessing. Open the link editor, re-select the query, and save once — the name is then stored in NG's format and stays stable.

Many links to fix by hand?

Open one link editor to see what NG now calls each query, then find-and-replace the old name with the new one throughout the dashboard JSON. The mapping is identical for every link using that query.


What to expect afterwards

Area Result
Nodes, links, layout, colours, scales Carried over unchanged
Link query bindings Automatic since v1.6.7; ambiguous cases need one manual re-select
Minimum Grafana version 11.0.0+ — see the FAQ
Plugin signature Releases from the Grafana catalog are signed

Features added since the fork — traffic animation, BGP neighbour status, polyline links — are all opt-in and default to off, so a migrated map looks the same as it did before until you turn them on.


Still stuck?

Open an issue with a sanitized copy of your dashboard JSON (redact any internal URLs and credentials). Real exported dashboards become regression fixtures, so a report with one attached tends to get fixed and stay fixed.

See also: Getting Started · Links · Data Sources · FAQ