Tariffs: Add pvnode Solar Forecast API V2

[GerdZanker]

New Tariff for pvnode Solar forecast API version 2 using a site ID instead of individual lat, lon, az, ... values and therefores easy to configure via Web UI.

Fix #31132

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• In the requirements.description texts there are a couple of typos (forcast → forecast, leicher → leichter), consider fixing these to keep the template descriptions polished.
• In the jq expression you unconditionally append "Z" to .timestamp and then parse it with fromdateiso8601; if the API already returns a timezone designator this could produce invalid timestamps, so it may be safer to rely on the API’s full ISO8601 timestamp as-is or normalize it more defensively.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the `requirements.description` texts there are a couple of typos (`forcast` → `forecast`, `leicher` → `leichter`), consider fixing these to keep the template descriptions polished.
- In the `jq` expression you unconditionally append `"Z"` to `.timestamp` and then parse it with `fromdateiso8601`; if the API already returns a timezone designator this could produce invalid timestamps, so it may be safer to rely on the API’s full ISO8601 timestamp as-is or normalize it more defensively.

## Individual Comments

### Comment 1
<location path="templates/definition/tariff/pvnode-v2.yaml" line_range="11" />
<code_context>
+      An API key is required (free plan available with +1 day forecast).
+      **Attention**: The free plan only allows 40 queries per month. These queries must be from only one location (lat, lon). Location is saved on first request and can not be changed afterwards, otherwise a 403 response is sent.
+    de: |
+      [pvnode V2 API](https://pvnode.com) liefert 15-Minuten PV Vorhersagen per REST API Version 2 mit Standort-ID und leicher Konfiguration über Web-App
+      Ein API-Key ist erforderlich (kostenloser Plan mit +1 Tag Vorhersage verfügbar).
+      **Achtung**: Mit dem kostenlosen Plan sind lediglich 40 Abfragen/Monat erlaubt. Diese Abfragen dürfen nur von einem Standort (lat, lon) sein. Der Standort wird bei der ersten Abfrage gespeichert und kann danach nicht mehr angepasst werden, andernfalls wird eine 403 Antwort gesendet.
</code_context>
<issue_to_address>
**nitpick (typo):** Typo in the German description ('leicher' → 'leichter').

Please change "leicher Konfiguration" to "leichter Konfiguration" to fix the spelling in this user-facing text.

```suggestion
      [pvnode V2 API](https://pvnode.com) liefert 15-Minuten PV Vorhersagen per REST API Version 2 mit Standort-ID und leichter Konfiguration über Web-App
```
</issue_to_address>

### Comment 2
<location path="templates/definition/tariff/pvnode-v2.yaml" line_range="11" />
<code_context>
+      An API key is required (free plan available with +1 day forecast).
+      **Attention**: The free plan only allows 40 queries per month. These queries must be from only one location (lat, lon). Location is saved on first request and can not be changed afterwards, otherwise a 403 response is sent.
+    de: |
+      [pvnode V2 API](https://pvnode.com) liefert 15-Minuten PV Vorhersagen per REST API Version 2 mit Standort-ID und leicher Konfiguration über Web-App
+      Ein API-Key ist erforderlich (kostenloser Plan mit +1 Tag Vorhersage verfügbar).
+      **Achtung**: Mit dem kostenlosen Plan sind lediglich 40 Abfragen/Monat erlaubt. Diese Abfragen dürfen nur von einem Standort (lat, lon) sein. Der Standort wird bei der ersten Abfrage gespeichert und kann danach nicht mehr angepasst werden, andernfalls wird eine 403 Antwort gesendet.
</code_context>
<issue_to_address>
**issue (review_instructions):** There is a German spelling error ("leicher" → "leichter") in the description, which breaks wording quality/consistency with the rest of the templates.

Please correct the typo in the German description here: "leicher Konfiguration" should be "leichter Konfiguration".

This keeps the wording quality in line with the other template descriptions under `templates/`.

<details>
<summary>Review instructions:</summary>

**Path patterns:** `templates/**/*.yaml`

**Instructions:**
Verify that the changes comply to the rules defined in templates/README.md. Also check consistence (wording) with other files inside templates directory.

</details>
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[GerdZanker]

• In the jq expression you unconditionally append "Z" to .timestamp and then parse it with fromdateiso8601; if the API already returns a timezone designator this could produce invalid timestamps, so it may be safer to rely on the API’s full ISO8601 timestamp as-is or normalize it more defensively.

Yes, this need attentition, because API definition and implementation will differ depending on timezone

• API: Timestamps are in the site's local timezone
• Impl: always Z timezone

[sutixp]

Had contact with pvnode about their changes between V1 and V2 of API.
Here is the important part of the response:

`Im kostenlosen Tarif kann man heute + morgen abfragen. Das heißt, du bekommst zwei volle Tage.

Die Prognose wird einmal pro Tag berechnet und dann im Cache gespeichert. Das heißt, wenn du ein zweites Mal oder noch häufiger abfragen solltest, erhältst du dieselben Daten nochmal. Für Nutzer im kostenlosen Tarif ist es daher sinnvoll, weiterhin bei einer Abfrage pro Tag zu bleiben.

Die 250 Cache Anfragen haben wir eingeführt, weil einige Nutzer dennoch häufiger abgefragt haben, dann aber in die Limits des Plans reingelaufen sind. Um dies zu verhindern speichern wir die Prognose bei uns, sodass man sie jeder Zeit erneut abfragen kann.

Die Prognose wird zum Zeitpunkt der Abfrage berechnet. Der optimale Zeitpunkt hängt daher von der genauen Integration ab. Bisher haben Nutzer mit stündlichen Updates häufig um Mitternacht abgefragt, es ist aber jede andere Zeit möglich. Die zu Grunde liegenden Daten werden im Hintergrund alle 10 Minuten aktualisiert.

Im Light oder Plus Tarif wird die Prognose stündlich oder alle 10 Minuten neu berechnet. Das sollte im Bestens Fall wieder in der Integration einstellbar sein.`

Description should be modified accordingly, as it only copied from V1 at the moment.
Ideally (if possible) , the daily query should be timed so that it is not performed at the end of the day, to get a good prediction of the current day (in my opinion the best time would be around sunrise).

[naltatis]

Suggested change

	de: Vorhersagetage (Free Plan = 1).
	de: Vorhersagetage

The free info should go into help: section (short sentence). This also affects the v1 api template.

[GerdZanker]

Description should be modified accordingly, as it only copied from V1 at the moment.
Ideally (if possible) , the daily query should be timed so that it is not performed at the end of the day, to get a good prediction of the current day (in my opinion the best time would be around sunrise).

Hi @sutixp, the description is updated and hopefully reflects the most important parts.
If you can give me a hint how to do a timed query I can give it a try, but currently I have no idea how to solve this.

My next step is to solve the difference between local time and UNC time with jq.

[andig]

@GerdZanker Github wants „fix“ instead of „implements“ to link and auto-close issues.

[darwindaume]

Hi guys - thanks a lot for picking up the V2 API so quickly after release. If it helps, I can give you access to the 7-day forecast, nowcasting and other features during the implementation phase to test the integration in full. Just let me know via email (darwin@pvnode.com).