Vitoconnect - Verbesserte Version

[stefanru]

@JWRu,

ok verstehe.
Wenn du willst kann ich dir mal ne Testversion machen wo auch die "isExecutable": false Parameter zur Auswahl stehen.
Dann könntest du testen was passiert wenn du ihn trotzdem ausführst.
Ich denke es wird abgelehnt von der API aber wer weiß.

Du kannst auch ab Zeile 1505 einfach diesen Block löschen und das Modul neu laden.

Code Auswählen Erweitern

                    if ($item->{commands}{$commandName}{isExecutable} == 0) {
                    Log(5,$name.", -vitoconnect_Set_New $commandName nicht ausführbar");
                     next; #diser Befehl ist nicht ausführbar, nächster
                    }

Gruß,
Stefan

[JWRu]

Wenn du willst kann ich dir mal ne Testversion machen wo auch die "isExecutable": false Parameter zur Auswahl stehen.

Vielen Dank - das ist nicht nötig.
Bin mal wieder unterwegs und versuche es rein interessehalber nächste Woche nach dem Löschen des Blocks.

[JWRu]

Ich habe die Zeilen auskommentiert und das Modul neu geladen:

Code Auswählen Erweitern

2025.10.08 14:59:43 1: Heizung_Vitoconnect,vitoconnect_action: set Heizung_Vitoconnect heating.circuits.0.operating.modes.active.value 1, Fehler bei Befehlsausfuehrung (1/20):  :: {
  "viErrorId": "00-944bc21e4054fab6f6ca7a346982bac0-d27ac78804935e74-00",
  "statusCode": 400,
  "errorType": "DEVICE_COMMUNICATION_ERROR",
  "message": "Device communication error",
  "extendedPayload": {
    "httpStatusCode": "BadRequest",
    "code": "400",
    "reason": "VALIDATION_ERROR",
    "details": "The parameter mode=\"forcedReduced\" does not meet the constraints {\"type\":\"string\",\"enum\":[\"dhw\",\"dhwAndHeating\",\"standby\"]}: Value 'forcedReduced' is not within allowed values: dhw, dhwAndHeating, standby"
  }Die API unterstützt den Befehl also anscheinend nicht mehr.

[JWRu]

Ich erhalte seit einigen Tagen (nach einem Update/Restart von FHEM) morgens bis ca. 2:00 Uhr und teilweise abends diese Meldungen:

Code Auswählen Erweitern

2025.10.12 20:14:59 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.12 20:16:30 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.12 20:16:30 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.12 20:18:01 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.12 20:18:01 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.12 20:19:31 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.12 20:19:31 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.12 20:21:01 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!Am Intervall habe ich nichts geändert - das stand unverändert auf 90. Das müsste nach meiner Rechnung knapp 1000 API-Calls pro Tag ergeben.
Ich habe das Intervall jetzt mal auf 120 geändert.

P.S. Die URL für das Developer-Portal in der FHEM-CommandRef stimmt nicht mehr.
Die neue lautet https://developer.viessmann-climatesolutions.com/

[stefanru]

Hi JWRu,
das ist aber seltsam.

Ich habe 2 Devices am selben Account beide mit 140er Intervall und es gibt keine Probleme.
Setzt du viele Set Befehle ab? Diese kosten auch API Calls.

Durch die Änderung die noch nicht ganz ausgereift ist versucht er bei Misserfolg eines Set Befehls diesen 20 mal.
Hier will ich die Fehlercodes noch besser auswerten und die Wiederholungen nur bei Fehlern machen die sich auch lösen können und nicht bei API Fehlern die sich nicht durch Retries lösen.

Mit 90er Intervall solltest du auf jedenfall durchkommen. Man hat 1450 API Calls per day.
Du verwendest mit 90 nur 960.
Etwas Overhead könnte es durch relogins geben aber ein Intervall von 70 geht bei mir und es ist noch Raum für set Befehle.
Das beschränkt sich aber vielleicht auf 5 - 10 pro Tag bei mir.

Welche Version des Moduls verwendest du gerade und wieviele Set BEfehle machst du pro Tag?
Hast du ein Device das am Account API Calls macht?

P.S.: URL ist angepasst, danke!

Gruß,
Stefan

[JWRu]

Hi Stefan,

ich verwende 98_vitoconnect.pm:v0.9.2-s30296/2025-09-15 und habe in den letzten Tagen überhaupt keinen set-Befehl genutzt.

Heute Nacht gab es wieder (diesmal im 2-Minuten Takt) die Meldungen:

Code Auswählen Erweitern

2025.10.15 00:37:57 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.15 00:37:57 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.15 00:39:57 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.15 00:39:57 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.15 00:41:57 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.15 00:41:58 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
.....
2025.10.15 01:56:08 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.15 01:56:08 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.15 01:58:08 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
2025.10.15 01:58:08 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!Um 2:00 Uhr hören die Meldungen dann ganz auf (da läuft bei mir ein tägliches configDB-Backup) und es gibt seitdem keinerlei Log-Einträge von vitoconnect mehr.
Seltsam ist auch, dass zu jedem Zeitpunkt die Meldung zweimal auftaucht.
Nachdem ich gestern das Intervall auf 120 Sekunden gestellt habe, habe ich mir mal die Anzahl der API-Calls auf meiner Developer-Seite notiert ("Use of API transaction").
Bis heute Morgen habe ich trotz des 2-Minuten-Intervalls im Mittel fast einen API-Call pro Minute verbraucht.
Ich habe dann auch beobachtet, dass die Zahl der API-Calls auf der Developer-Seite bei jedem Update des FHEM-Devices um 2 zunimmt.

Gruß,
Jochen

[stefanru]

Hi Jochen,

aus deinem Log kann ich sehen dass du wohl 2 Timer aktiv hast.
Das verwundert mich sehr.
Ich habe das Coding des alten Moduls bei dem es vorkommen konnte genau analysiert und umgebaut so dass dies nicht mehr passieren sollte.
Seit dem Umbau kamen auch keine Meldungen mehr dazu hoch bis auf deine jetzt

Ich habe im Coding mal 2 Dinge angepasst um es besser eingrenzen zu können.
Bei dem Fehler Anzahl der möglichen API Calls in überschritten! kommt nun immer der Name des Hashes und die Memoryadresse.

Ich habe auch im GetUpdate das Logging bei Verbose 4 verbessert.
Auch hier kommt nun Name des Hashes und die Memoryadresse.

Ich hänge die angepasste Version hier an.
Bitte lade sie mit "reload 98_vitoconnect.pm" in der commandline.

Setze das Device auf Verbose 4.

Danach solltest du im Log so etwas sehen:

Code Auswählen Erweitern

2025.10.15 11:57:59 4: VitoCal250AH GetUpdate called by caller name: VitoCal250AH, memoryadress: HASH(0x5591465e10)
2025.10.15 11:57:59 4: VitoCal250AH - enter getResourceOnce
2025.10.15 11:57:59 4: VitoCal250AH - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 11:57:59 4: VitoCal250AH - installation: 2772216
2025.10.15 11:57:59 4: VitoCal250AH - gw: 7736172146035226
2025.10.15 11:58:00 4: VitoCal250AH - getResourceCallback went ok
2025.10.15 12:00:20 4: VitoCal250AH GetUpdate called by caller name: VitoCal250AH, memoryadress: HASH(0x5591465e10)
2025.10.15 12:00:20 4: VitoCal250AH - enter getResourceOnce
2025.10.15 12:00:20 4: VitoCal250AH - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 12:00:20 4: VitoCal250AH - installation: 2772216
2025.10.15 12:00:20 4: VitoCal250AH - gw: 7736172146035226
2025.10.15 12:00:21 4: VitoCal250AH - getResourceCallback went ok
2025.10.15 12:02:41 4: VitoCal250AH GetUpdate called by caller name: VitoCal250AH, memoryadress: HASH(0x5591465e10)
2025.10.15 12:02:41 4: VitoCal250AH - enter getResourceOnce
2025.10.15 12:02:41 4: VitoCal250AH - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 12:02:41 4: VitoCal250AH - installation: 2772216
2025.10.15 12:02:41 4: VitoCal250AH - gw: 7736172146035226
2025.10.15 12:02:42 4: VitoCal250AH - getResourceCallback went ok
2025.10.15 12:05:03 4: VitoCal250AH GetUpdate called by caller name: VitoCal250AH, memoryadress: HASH(0x5591465e10)
2025.10.15 12:05:03 4: VitoCal250AH - enter getResourceOnce
2025.10.15 12:05:03 4: VitoCal250AH - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 12:05:03 4: VitoCal250AH - installation: 2772216
2025.10.15 12:05:03 4: VitoCal250AH - gw: 7736172146035226
2025.10.15 12:05:03 4: VitoCal250AH - getResourceCallback went ok

Also bei mir tut alles ein caller mit immer der selben Memoryadresse.
Die calls sind bei mir: 11:57:59, 12:00:20, 12:02:41, 12:05:03
Also alle 140 sek. genau mein intervall.

Kannst du das mal testen und den output posten.

Gruß,
Stefan

[JWRu]

Hi Stefan,

bei mir kommt zu jedem Update-Zeitpunkt kurz nacheinander zweimal die Meldung im Log:

Code Auswählen Erweitern

2025.10.15 14:09:20 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x354b728)
2025.10.15 14:09:20 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 14:09:20 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 14:09:20 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 14:09:20 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 14:09:28 4: Heizung_Vitoconnect - getResourceCallback went ok
2025.10.15 14:09:30 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x354b728)
2025.10.15 14:09:30 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 14:09:30 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 14:09:30 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 14:09:30 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 14:09:45 1: Heizung_Vitoconnect - An error occured: read from https://api.viessmann-climatesolutions.com:443 timed out
2025.10.15 14:11:28 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x354b728)
2025.10.15 14:11:28 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 14:11:28 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 14:11:28 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 14:11:28 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 14:11:28 4: Heizung_Vitoconnect - getResourceCallback went ok
2025.10.15 14:11:45 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x354b728)
2025.10.15 14:11:45 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 14:11:45 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 14:11:45 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 14:11:45 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 14:11:46 4: Heizung_Vitoconnect - getResourceCallback went ok
2025.10.15 14:13:28 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x354b728)
2025.10.15 14:13:28 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 14:13:28 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 14:13:28 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 14:13:28 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 14:13:29 4: Heizung_Vitoconnect - getResourceCallback went ok
2025.10.15 14:13:46 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x354b728)
2025.10.15 14:13:46 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 14:13:46 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 14:13:46 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 14:13:46 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 14:13:47 4: Heizung_Vitoconnect - getResourceCallback went ok

Noch ein Nachtrag, der evtl. bei der Ursachenforschung hilft:
Ich hatte einige Tage vor dem FHEM-Update, nach dem die Meldung erstmalig aufgereten ist, mein Passwort bei Viessmann geändert.
Ich hatte aber vergessen, in dem Vitoconnect Device das Passwort zu aktualisieren, da das Device problemlos weiter gelaufen ist.
Erst beim Neustart nach erfolgtem Update hat sich Vitoconnect beschwert, dass das Login nicht klappt:

Code Auswählen Erweitern

2025.10.11 07:32:48 1: Heizung_Vitoconnect - Login failure. Check password and apiKeyIch habe daraufhin mit "set Heizung_Vitoconnect password ..." das neue Passwort gesetzt - dann lief alles einwandfrei.
Am Abend gegen 23:00 Uhr sind dann die Meldungen erstmals im Log aufgetaucht:

Code Auswählen Erweitern

2025.10.11 23:02:23 1: Heizung_Vitoconnect - Anzahl der möglichen API Calls in überschritten!
Gruß,
Jochen

[stefanru]

Ok,

das mit dem Passwort schaue ich mir an.

Der Fehler bleibt bestehen bei einem Neustart von FHEM?

Gruß,
Stefan

[JWRu]

Der Fehler bleibt bestehen bei einem Neustart von FHEM?

Nein - ist verschwunden:

Code Auswählen Erweitern

2025.10.15 16:52:42 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x3819368)
2025.10.15 16:52:42 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 16:52:42 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 16:52:42 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 16:52:42 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 16:52:42 4: Heizung_Vitoconnect - getResourceCallback went ok
2025.10.15 16:54:42 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x3819368)
2025.10.15 16:54:42 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 16:54:42 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 16:54:42 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 16:54:42 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 16:54:42 4: Heizung_Vitoconnect - getResourceCallback went ok
2025.10.15 16:56:42 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x3819368)
2025.10.15 16:56:42 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 16:56:42 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 16:56:42 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 16:56:42 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 16:56:43 4: Heizung_Vitoconnect - getResourceCallback went ok
2025.10.15 16:58:43 4: Heizung_Vitoconnect GetUpdate called by caller name: Heizung_Vitoconnect, memoryadress: HASH(0x3819368)
2025.10.15 16:58:43 4: Heizung_Vitoconnect - enter getResourceOnce
2025.10.15 16:58:43 4: Heizung_Vitoconnect - access_token: eyJraWQiOiI0YzBhZGFh...
2025.10.15 16:58:43 4: Heizung_Vitoconnect - installation: 2555855
2025.10.15 16:58:43 4: Heizung_Vitoconnect - gw: 7637415070194233
2025.10.15 16:58:44 4: Heizung_Vitoconnect - getResourceCallback went ok
Ich setze dann das Interval mal wieder auf 90   

Gruß, Jochen

[stefanru]

Hi Jochen,

d.h. du hast das Passwort geändert und danach hattest du 2 Timer?

Wenn es so ist dann denke ich habe ich es gefunden und kann es fixen

Danke und Gruß,
Stefan

[stefanru]

Ich habe es gefixed.

Es ist im GIT und hängt hier an.
Ins SVN bringe ich es morgen.

Diese fixe sind neu gegenüber dem SVN:
  "0.9.5"  => "15.10.2025  Fix duplicate timer in case of password update (getCode)",
  "0.9.4"  => "15.10.2025  More logging for timers",
  "0.9.3"  => "15.10.2025  URL to dev portal updated",

Danke und Gruß,
Stefan

[stefanru]

Neue Version ist im SVN.
Wir sind jetzt bei 0.9.5.

Bekommt ihr morgen im Update...

Gruß,
Stefan

[Beta-User]

...bin endlich auch mal dazu gekommen, deine Änderungen in meine Version zu übernehmen, Ergebnis und diff anbei. Bisher nicht groß getestet, aber scheint zu laufen...
@stefanru: Das diff ist vielleicht interessant, ich habe das Löschen der InternalTimer je an eine andere Stelle verlagert . 

Frage zum neuen error-handling bei Timeouts etc.: Sehe ich das richtig, dass irgendwann gar keine Timer mehr gesetzt sein können und man dann das ganze manuell via "update" wieder anwerfen muss?
Vorschlag dazu (analog - jedenfalls soweit ich mich entsinne - DevIo.pm): Wenn was schiefgeht, verlängern wir den Timer deutlich (Faktor 10, aber z.B. nicht unter 30 Minuten?)

[stefanru]

Hi Beta User,

nein eigentlich sollte immer ein Update Timer laufen.
Hier gibt es eigentlich keine Stelle wie dieser beendet wird.
Ich sorge nur dafür dass nicht mehrere laufen.
Dafür musste ich an 2 Stellen anpassen (das hatte mit getCode) zu tun.

Beim Senden hole ich mir bei einem abgelaufenen Token nun ein neues und im Fehlerfall versuche ich es 20X im 10 Sekunden Takt dann gebe ich auf beim Senden mit Fehlermeldung. Hier endet das Senden dann und es gibt keinen weiteren Versuch. Der Set ging schief.

Sorry ich komme noch nicht ganz zu deinem Diff da mich ein anderes Thema noch zu erst beschäftigt.
Können wir danach das ganze nochmal zusammen führen und vielleicht auch mal kurz reden.
Dann nehme ich deine Verbesserungen gern mit auf.
Sorry dass es wieder nicht klappt.
Ich finde es super dass du dir die Mühe machst mir geht nur immer die Zeit aus.
Ich melde mich sobald ich mit dem Log Thema durch bin und wir schließen uns mal kurz um deine Änderung dann bald rein zu bekommen.
Ok?


@ALL (bitte um Rückmeldung):
Viessmann schaltet zum 1. Nov. ViGuide ab.
Damit verlieren wir das Ereignissprotokoll!
Einige haben sich schon beschwert im Forum.
Ihr könnt das gern auch tun und zwar hier:
https://community.viessmann.de/t5/Konnektivitaet/Abschaltung-ViGuide-fuer-Endkunden-am-1-November/m-p/566982

Nun Versuche ich uns die Funktionalität in FHEM zu geben.
Bei alten Geräten gibt es nur Error Codes, für diese kann ich über die API auch die Fehlertexte bekommen.
Für neue OneBase Geräte habe ich die Fehler/Status/Info usw Texte aus anderen Projekten zusammen gesammelt und muss dies noch einbauen. Viessmann stellt hier noch keine Nachschlag Funktion für die neuen Geräte zur Verfügung.

Nun ist für mich die Frage wie ihr gerne ein Protokoll hättet?
Bzw. wie wir die Meldungen ablegen und anzeigen wollen.
Ist in FHEM ja nicht so einfach ein Log als Reading dazustellen.

Ich habe mehrere Optionen:
1. Ich erstelle Readings für die neusten 10 Messeges einer Kategorie (Status, Fehler, Information, Wartung, Information, Alarm).
   Diese werden dann immer erhalten im Device.
2. Ich erstelle nur Readings für die aktuellen Meldungen.
3. Ich erstelle für Status, Fehler, Information, Wartung, Information, Alarm jeweils ein Reading in das ich die Fehler zusammenfasse, so wie jetzt die Raw readings.
4. Sollte es auch ein Fehlerlog als Textfile im Logverzeichniss geben?

Was würde euch am ehesten zusagen?

Viele Grüße,
Stefan