Vitoconnect - Verbesserte Version

[stefanru]

Hi Claus,

kannst du mir mal ein Log der API Daten schicken?
Dazu machst du einmal ein set <Device> logResponseOnce.
Dann müsstest du im FHEM Log Verzeichnis ein Datei: resource_<Serial>.json finden.
Das ist genau die Antwort der Viessmann API. Wann da nichts kommt hat Viessmann die API verändert und lieferte diese Werte nicht mehr oder nur gegen Aufpreis.
Aber lass uns da erstmal nachschauen.

Gruß,
Stefan

[aaameyer]

Hallo Stefan,
seit dem 17.11.2025 bekomme ich keine Daten mehr von meiner PV-Anlage. Anscheinend hat Viessmann den v1 API Endpunkt abgeschaltet. Auf meiner FHEM Instanz konnte ich das Problem recht schnell fixen und würde gerne die Community daran teilhaben lassen. Daher habe ich einen PR in Github erstellt und würde mich freuen wenn Du diesen anschauen und testen kannst (nicht dass ich da was mit anderen Geräten als PV-Anlagen kaputt gemacht habe, bisher scheint der EOL bei den anderen Usern nicht aufgefallen zu sein). Wenn das passt, würde ich mich freuen wenn der Fix im offiziellen SVN einzug findet.

Hier die Fehlermeldung aus dem FHEM log:

Code Auswählen Erweitern

vitoconnect - unbekannter Fehler: Bitte den Entwickler informieren!
vitoconnect - statusCode: 410 errorType: GONE message: This endpoint has been deprecated and is no longer available. Sunset date: 2025-11-17T12:00:00.000Z Replacement: GET /iot/v2/equipment/gateways error: undef reason: undef

Hier die vitoconnect_0.err:

Code Auswählen Erweitern

$VAR1 = {
          'extendedPayload' => {
                                 'replacement' => 'GET /iot/v2/equipment/gateways',
                                 'sunsetDate' => '2025-11-17T12:00:00.000Z'
                               },
          'statusCode' => 410,
          'message' => 'This endpoint has been deprecated and is no longer available. Sunset date: 2025-11-17T12:00:00.000Z Replacement: GET /iot/v2/equipment/gateways',
          'errorType' => 'GONE',
          'viErrorId' => 'req-f41cfd394bd5476e92b50fbca7711041'
        };


[stefanru]

Hi Aaameyer,

hab's mir kurz angeschaut sieht gut aus.
Dieser Change von V1 nach V2 ist wohl untergegangen.
Die neuen Namen gefallen mir auch besser 
Werde es die Tage übernehmen.
Muss aber auch noch etwas mit reinmergen, deshalb brauche ich ein bisschen.

Vielen Dank schonmal, ich gebe hier bescheid sobald ich es drin habe.

Gruß,
Stefan

[combog]

Hallo Stefan,
wollte dir grad die gleiche Fehlermeldung schicken wie Aaameyer. Dann freue ich mich auf deine Problemlösung.
Gruß
Claus

[stefanru]

Ok, fix ist im Git und im SVN.
Morgen könnt ihr es aus dem SVN holen indem ihr FHEM updated.
Wollt ihr es schon heute müsst er es von GIT holen.

Neue Version ist: 1.0.0   
Nicht weil ich denke es ist nun besonders, sondern weil die nummern 0.X.X aufgebraucht waren

Viele Geüße,
Stefan

[wieral]

Guten Morgen Stefan,

ich habe soeben ein Update auf die neuste Version "30565 2025-11-28 15:38:16" durchgeführt.

Folgendes ist mir aufgefallen.

- Ich nehme an, dass du im Logfile jeweils von

   heating.power.consumption.dhw.day.asSingleValue
   heating.power.consumption.heating.day.asSingleValue
   heating.power.consumption.total.day.asSingleValue
   
   die Daten der jeweils letzten 7 Tage ausliest. Kann es sein, das "date" um jeweils 1 Tag verschoben ist?
   
   Beispiel:
                                           
   2025.11.29 10:48:34.454 3:  viessmann - candidate i=1 date=2025-11-27 "date=2025-11-28?" 23:59:59 val=24.7 lastTS=1764284399

        Dies erscheint mir ebenfalls für die jeweiligen "asSingleValue" der Fall zu sein.

        Falls ich falsch liege, entschuldige ich mich hiermit gleich.
   
- Wie kann ich die Ausgabe im Logfile stoppen?

Vielen Dank für deine tolle Arbeit und Modul.

Viele Grüße Ralf

[stefanru]

Hi Ralf,

danke für die Meldung.
Da ist noch das Debugging mit verbose 3 drin.
Mache ich raus, morgen gibt es eine neue Version ohne Debugging.
Du kannst auf Verbose 4 stellen wenn du es jetzt gleich weghaben willst.

Wegen des Datums, das sieht für mich aber gut aus.
Ich nehme die Verbrauch Strings und das zugehörige ValueReadAt, dieses gibt an bis wann die Werte geliefert wurden. Dann erzeuge ich asSingleValue für jeden vollen Tag mit Zeit 23:59. Das ganze geschieht nur wenn der Tag nicht schon geschrieben wurde.
Somit kann man auf asSingleValue loggen und hat eindeutige saubere Werte auch wenn die API nur einmal alle 7 Tag liefert.

Bitte schau mal dass ich mich nicht vertue, bei mir sieht es passend aus.
Ich habe z.B.
heating.power.consumption.dhw.day 0.5,3.7,3.8,3.9,5,3.2,2.3,2.6
heating.power.consumption.dhw.dayValueReadAt 2025-11-28T14:32:28.066Z

Also am 28.11. hat die API die Daten geliefert.
Heißt 28.11. = 0.5 (kein kompletter Tag wird nicht gelogged)
27.11. =3.7
26.11. = 3.8
usw.
Mein Log sagt das auch so:
2025.11.29 13:22:42 3: VitoCal250AH - candidate i=1 date=2025-11-27 23:59:59 val=3.7 lastTS=1764284399
2025.11.29 13:22:42 3: VitoCal250AH - candidate i=2 date=2025-11-26 23:59:59 val=3.8 lastTS=1764284399

Danke fürs melden und Nachschauen, morgen ist das loggen wieder entfernt.

Gruß,
Stefan

[wieral]

Hi Stefan,

vielen Dank für deine schnelle Antwort und Hilfe.

Das Debugging ist jetzt raus.

Noch einmal zurück zur Berechnung des jeweiligen "asSingleValue".
Hier ein Auszug des noch laufenden Debug:

heating.power.consumption.heating.day   0.2,24.7,30.1,36.6,36.7,44.9,52.4,49.1    2025-11-30 09:20:21
heating.power.consumption.heating.day.asSingleValue    30.1                       2025-11-27 23:59:59

Auch erhielt ich die gleichen Daten nach dem heutigen Update.
Wie du siehst, steht bei mir immer noch der Wert vom 27.11.2025 im Reading.
Vermutlich führte dies bei mir zu irritationen.

Aus meiner Sicht kein Problem, da ich die Tageswerte aus den jeweiligen heating.power.consumption......year berechne.
Dieses Reading Update funktioniert bei mir über Viessmann noch.

Gruß
Ralf

[stefanru]

Hi Ralf,

die API liefert die Werte verzögert, also nicht jeden Tag, aber der Zeitstempel wird bei jeder Lieferung geupdated.
Du kannst also nicht den Zeitstempel von
heating.power.consumption.heating.day als referenz der Werte nehmen sondern musst
heating.power.consumption.dhw.dayValueReadAt als Zeitstempel der Meldung der Powerwerte nehmen.

Poste mal dieses Reading heating.power.consumption.dhw.dayValueReadAt.

Das sollte deine Verwirrung erklären.

Gruß,
Stefan

[wieral]

Hi Stefan,

danke für deine Bemühungen.

Hier das Reading:
heating.power.consumption.heating.day   0.2,24.7,30.1,36.6,36.7,44.9,52.4,49.1   2025-11-30 09:20:21

Gruß Ralf

[stefanru]

Hallo Ralf,

sorry vieleicht habe ich es nicht gut genug erklärt.

Das reicht wieder nicht ich brauche:
heating.power.consumption.heating.day                 <--- Werte Liste
heating.power.consumption.heating.dayValueReadAt      <--- Tag des ersten Wertes der Werte Liste
heating.power.consumption.heating.day.asSingleValue   <--- Aktuellster Wert (entspricht Tag des ersten Wertes der Werte Liste -1)

Da die API nicht regelmäßig liefert ist das dayValueReadAt das Datum auf das es ankommt, nicht das des Readings.

Gruß,
Stefan