External Integrations — yr.no

Business Context

Business-Level Definition

yr.no (operated by the Norwegian Meteorological Institute, MET Norway) is a publicly accessible numerical weather forecast service. E-Manazer uses it to display a meteogram widget — a graphical 9-day weather forecast — on the Climate Data tab, one per weather station assigned to the client that has GPS coordinates set.

The forecast is rendered for the geographic location of each assigned weather station (weatherStation.lat / weatherStation.lng), not the client, and gives energy managers contextual information when evaluating consumption or planning for the heating season.

Links: https://api.met.no/weatherapi/locationforecast/2.0/, https://www.yr.no/en

Requirements Definition

• Display a graphical weather forecast for each of the client's assigned weather stations, covering approximately 9 days ahead: temperature, precipitation, wind, pressure, cloud cover, weather icons
• The integration must operate without any server-side component — no entity, no forecast data stored on the E-Manazer side
• If an assigned weather station has no GPS coordinates (weatherStation.lat / weatherStation.lng are null), its widget must not render and the user must receive a clear explanation
• The integration must degrade gracefully — if yr.no is unavailable or returns an error, the widget shows an error state; the rest of the Climate Data tab remains fully functional

Acceptance Criteria

• One meteogram widget renders per assigned weather station with GPS coordinates
• A station with no GPS coordinates shows an explanatory info panel instead of a widget
• A failed or timed-out fetch shows an error panel without affecting the rest of the tab

Loom Link

N/A — not available in the source material.

Technical Context

User Stories / Use Cases

View forecast for an assigned station: A user opens the Climate Data tab for a client → sees one meteogram widget per assigned weather station that has GPS coordinates, rendered as a standalone block between the assigned stations table and the climate data table.

Station without coordinates: A user opens the Climate Data tab; one assigned station has no lat/lng set → that station's widget slot shows an info panel: "This weather station has no GPS coordinates. Coordinates can be set in the weather station detail."

yr.no unavailable: The fetch to api.met.no fails or times out (>10s) → the widget shows an error panel: "Weather forecast is currently unavailable." The rest of the tab remains functional.

UI/UX Design

Not covered in source material beyond the widget states and layout described in Functional Requirements below (a click-through prototype exists per WeatherStation Management; visual and interaction details for this specific widget are not further specified).

Functional Requirements

What yr.no provides

The MET Norway LocationForecast 2.0 API returns a compact JSON for a given set of coordinates containing hourly forecast data: temperature (°C), precipitation (mm), wind speed and direction, pressure (hPa), cloud cover (%) and a weather symbol. Data covers approximately 9 days from the current moment. Access is free and requires no API key; fair use conditions require the application to be identified in the User-Agent HTTP header (see Implementation Notes for a caveat on this).

Behaviour specification

• One widget renders per assigned weather station with GPS coordinates set, on the Climate Data tab of the client page, as a standalone block between the assigned weather stations table and the climate data table
• The input is weatherStation.lat and weatherStation.lng — the coordinates of the assigned weather station, not the client's own coordinates. A client with multiple assigned stations that have coordinates renders one meteogram widget per station.
• The API call is made directly from the browser to api.met.no — the E-Manazer backend never touches the forecast data
• The response is parsed client-side and rendered using the Highcharts library (meteogram layout with wind barbs)
• Weather icons are loaded from CDN: https://cdn.jsdelivr.net/gh/nrkno/yr-weather-symbols@8.0.1/dist/svg/{icon}.svg

Widget states:

Condition	Widget behaviour
weatherStation.lat or weatherStation.lng is null for an assigned station	Info panel: "This weather station has no GPS coordinates. Coordinates can be set in the weather station detail."
Fetch api.met.no succeeds	Render meteogram (Highcharts)
Fetch fails or timeout (>10 s)	Error panel: "Weather forecast is currently unavailable." The rest of the tab remains functional.

Non-Functional Requirements

• Timeout: if api.met.no does not respond within 10 seconds, the widget transitions to the error state

Implementation Notes

• No entity, no DB table — forecast data is never stored in E-Manazer
• No server-side caching — every tab open triggers a fresh browser fetch
• The User-Agent header cannot be set from browser JavaScript — it is a forbidden header per the Fetch standard and browsers silently ignore any attempt to override it (verified during implementation). MET Norway's fair-use identification requirement is therefore satisfied only via the Origin header, which the browser sends automatically on every cross-origin fetch and cannot be suppressed — it exposes the tenant's domain to MET. No explicit application identification is set by E-Manazer code.
• Weather icons are pinned to version @8.0.1 — keep the pin; do not upgrade without a full meteogram regression test
• Highcharts licence — verify compatibility with the project licence before implementation

API Analysis

E-Manazer does not expose any backend endpoint for this integration. The call is made directly from the browser:

GET https://api.met.no/weatherapi/locationforecast/2.0/compact?lat={lat}&lon={lon}&altitude={altitude}

where {altitude} is the assigned weather station's altitude in metres — MET uses it to correct the forecast temperature for elevation.

Used by: Client Management — Climate Data tab.

Domain Model (ER diagram) & Data Attribute Table

No dedicated entity — forecast data is never persisted. Uses weatherStation.lat / .lng / .altitude from WeatherStation Management.

Data

Not covered in source material.

Test Data

N/A — not covered in source material.

Logging

.debug

• Meteogram widget initialised (weatherStationId, clientId, lat, lon)
• yr.no fetch completed: success (number of hourly records in response) / timeout / HTTP error (status code)
• Widget entered error state (reason: null coordinates / fetch error / timeout)

Monitoring

N/A — not covered in source material.

Caching

None — see Implementation Notes above (no server-side caching, fresh fetch on every tab open).

Backward Compatibility and Migration

N/A — not addressed in the source Confluence page; this is new functionality with no EM2 equivalent.

Legal Context

N/A — not addressed in the source Confluence page; migrated as a reference copy without new legal analysis.

Cybersecurity Considerations

N/A — not addressed in the source Confluence page; migrated as a reference copy without new security analysis. Note: the browser sends the tenant's Origin header to a third-party (MET Norway) service on every widget load, and no explicit application identification is set — flagged here for review, not resolved.

Risk Assessment

N/A — not addressed in the source Confluence page; migrated as a reference copy without new risk analysis.

Auditing, Reporting & Measurement

N/A — not addressed in the source Confluence page; migrated as a reference copy without new analysis.

---