Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unterstützung von Viessmann Wärmepumpen #19639

Closed
MasterGoofy opened this issue Mar 10, 2025 · 24 comments · May be fixed by #20111
Closed

Unterstützung von Viessmann Wärmepumpen #19639

MasterGoofy opened this issue Mar 10, 2025 · 24 comments · May be fixed by #20111
Labels
heating Heating stale Outdated and ready to close

Comments

@MasterGoofy
Copy link

Hallo,

mit Freude habe ich gesehen, dass ihr angefangen habt Wärmepumpen zu unterstützen und man euch bitten darf neue hinzuzufügen wenn diese fehlen sollten. Auf dem deutschen Markt ist glaube ich Viessmann stark vertreten. Ich selbst habe eine Vitocal 250-A.

Im Developer Portal gibt es super Dokumentationen wie man die APIs bedienen und abfragen kann :
https://documentation.viessmann.com/static/getting-started

Hierzu wird allerdings ein Account benötigt.
Gerne liefere ich notwendige Informationen oder stelle mich als Tester zur Verfügung.

Viele Grüße

Daniel

@docolli
Copy link
Contributor

docolli commented Mar 10, 2025

Hallo Daniel ,

ich habe selbst auch die Vitocal-250A und nutze Open3E auf einem kleines Raspi und CAN-Board, um an die Daten ranzukommen: https://github.com/open3e/open3e

Darüber kann man die Daten auch leicht per MQTT zur Verfügung stellen (bei mir FHEM als Hausautomationssystem). Vermutlich könnte man auch evcc über MQTT mit den Wärmepumpendaten füttern, hab ich aber noch nicht ausprobiert.

Was erwartest du dir von evcc für deine Wärmepumpe (WP)?
Ich denke nicht, das man generell die Leistung steuern kann, das sollte die WP, meiner Meinung nach, selbst machen. Die Parameter dazu müssen aber in der WP für dein System passend eingestellt sein. Da ist Open3E genial, da man damit auch Parameter setzen kann, die sonst nur der Heizungsbauer über die spezielle Viessmann App ändern kann. Aber man muss auch wissen was man tut und sehr vorsichtig vorgehen, nicht zu viele Parameter auf einmal ändern und Parameter auch wieder zurückstellen, wenn sie nicht den erhofften Effekt haben.

Über den Hausverbrauch sieht evcc sowieso auch den Verbrauch der WP und kann so den PV-Überschuss für die Wallbox passend steuern. Wieviel die WP selbst verbraucht, ist dafür nicht notwendig. Einzig, wenn PV-Überschuss da ist und man will, dass die WP diesen verbraucht, dann kann man die WP über den SG-Ready Eingang dazu bringen in den bevorzugten Betrieb zu gehen. Einerseits hängt dieser Eingang an meinem E3DC Hauskraftwerkt und dieses meldet der WP PV Überschuss. Wie die WP damit umgeht, lässt sich konfigurieren (Erhöhung Warmwasserpuffer bzw. Heizungspufferüberhöhung) und da können wir uns gerne austauschen.

SG-Ready ist bei Viessmann etwas tricky, da die 230V Eingänge super empfindlich auf Einkoppelung durch Induktion durch eine benachbarte Leitung sind. Da genügen schon 1-2m Leitungslänge und 1 spannungsführende Ader im Kabel, schon ist das Potential der anderen SG Ready Leitungen auf einem Wert, den die WP als "aktiv" erkennt... Ein Eltako RC-Glied RC12-230V in den SG Ready Steuerleitungen ist hier notwendig, als Tipp an deinen Elektriker...

@andig
Copy link
Member

andig commented Mar 10, 2025

Hierzu wird allerdings ein Account benötigt.

Und wo bekommt man den her?

@andig andig added the heating Heating label Mar 10, 2025
@MasterGoofy
Copy link
Author

Ich würde gerne den nicht genutzten PV Überschuss in heißem Wasser speichern. Meine normale Warmwassertemperatur ist auf 43 Grad eingestellt und läuft nur morgens und abends an. Wenn jetzt viel PV Überschuss da ist, dann hätte ich gerne das Wasser auf 80 Grad erhitzt. Das hält sich dann auch so lange, dass ich beim nächsten regulären Turnus dann nicht WW erzeugen müsste.
Ich würde ungerne über SG ready gehen, da man eigentlich alles ziemlich cool über API machen kann. Über IOBroker habe ich mir z.B. Buttons eingepflegt, die man neben der Dusche drücken kann um einmalig Warmwasser zu produzieren. Und ich hätte gerne alles unter der Haube von EVCC.

@docolli
Copy link
Contributor

docolli commented Mar 10, 2025

Hierzu wird allerdings ein Account benötigt.

Und wo bekommt man den her?

Sollte hier gehen: https://account.viessmann.com/register-end-customer?application=ViCommunity

@docolli
Copy link
Contributor

docolli commented Mar 10, 2025

@MasterGoofy
Mein Heizungsbauer hat mir zu diesem Zweck einen MyPV 9kW Heizstab samt ACThor Steuerung im Pufferspeicher verbaut. Er meinte, dass damit die WP im Sommer geschont wird, auch wenn die Effizienz einer WP höher als beim Heizstab ist. Und wenn du 80°C hoch willst, ist das schon recht heftig für die WP, da geht die COP auch ganz schön in den Keller. Mal sehen, ob sich dass dann im Sommer auch bewahrheitet und die WP einfach aus ist.

ACThor und Heizstab werden übrigens aktuell bereits sehr gut von evcc unterstützt!

Zurück zur Viessmann API: Laut Doku muss man zuerst einen Authorization Request über einen Browser machen, dort seine Zugangsdaten eingeben, dann bekommt man einen "authorization code", mit dem man ein "access token" abrufen kann. Läuft über oAuth PKCE (https://www.oauth.com/oauth2-servers/pkce/).
Viessmann hat eine Kollektion in Postman angelegt: https://www.postman.com/vimicho/viessmann-api-public/collection/ut8c19s/viessmann-api-template?action=share&creator=12055031

Aber dort sind nur ein paar Beispiele für Datenpunkte enthalten. DIe kompletten Datenpunkte findet man in der Viessmann Doku.

Image

Der Aufruf fürs Warmwasser ist z.B.
https://api.viessmann.com/iot/v2/features/installations/{{installationID}}/gateways/{{gatewaySerial}}/devices/{{deviceId}}/features/heating.dhw.temperature.main/commands/setTargetTemperature

Woher bekommt man die {installationID}, das {gatewaySerial} und die {deviceId}, damit der Befehl auch korrekt im System landet?

@MasterGoofy

This comment has been minimized.

@Afrouper
Copy link

Hallo zusammen,

ich habe auch eine Viessmann Wärmepumpe (vitocal 300-G). Da sie schon älter als 10 Jahre hat kommt (aktuell) für mich SG Ready nicht in Frage...

Ich verwende zur Ansteuerung OpenHAB welches die entsprechenden Events via MQTT von evcc verarbeitet.

In OpenHAB ist es über ein Bindung integriert. Es scheint auch eine go Implementierung zu geben; allerdings habe ich mir die noch nicht genauer angeschaut; scheint auch schon recht "alt" zu sein.

Um die API testen zu können ist tatsächlich ein eher aufwändigerer OAuth2 Flow gewählt worden. Könnte man aber abbilden wenn man als Redirect URL in der viessmann API die lokale evcc URL angibt.
Ich müsste mal genauer schauen ob und wie, aber ich kann ggf. etwas verproben.

@docolli
Copy link
Contributor

docolli commented Mar 11, 2025

Ich verstehe evcc so, dass es konzeptionell so ausgelegt ist, die Leistung eines Verbrauchers (Wallbox) abhängig vom PV Überschuß zu steuern und dabei zusätzlich noch ein Limit (SOC) zu haben.

Bei einem IntegratedDevice (wie man eine Wärmepumpe einbinden müsste) entspricht das Limit nicht dem SOC des Autos, sondern einer Temperatur (z.B. des Puffers). Gesteuert im PV Modus wird von evcc aber weiterhin die Leistungsaufnahme des Verbrauchers. Das kann auch einfach ein Ein/Ausschalten des Verbrauchers sein, wenn man die Leistung der WP nicht modulieren kann. Und ich wüsste jetzt konkret nicht, ob man die Leistung der Vitocal-250A von extern vorgeben kann.

Das was @MasterGoofy hier aber beschreibt ist der Wunsch das Limit (die Temperatur) je nach PV Überschuß zu ändern, nicht die Leistung. Also ohne PV Überschuß sind es 43°C, gibt es PV Überschuß (z.B. mehr als 1000W), dann setze das Limit auf 80°C hoch. Das weiß ich nicht ob evcc das konzeptionell leisten kann, oder ob so ein Wunsch nicht leichter in einer Hausautomationslogik realisiert wird.

Pseudocode:
If pv-einspeisung>1000
then
curl "https://api.viessmann.com/iot/v2/features/installations/{{installationID}}/gateways/{{gatewaySerial}}/devices/{{deviceId}}/features/heating.dhw.temperature.main/commands/setTargetTemperature 80"

@Afrouper
Copy link

Hi @docolli,

sehe ich 1:1 auch so 😊
Wie schon in #19652 erwähnt habe ich die Ansteuerung der WP (bei meinem UseCase) optimiert. Im Ziel soll natürlich sein dass ab einem gewissen Überschuss die WP aktiviert wird.

Das kann man entsprechend über die API regeln.
Ich setze bei PV Überschuss eine höhere Warmwasser- und Heizungstemperatur. Die Wäremepumpe macht dann daraus das passende; erst Warmwasser und dann das Wasser für die Fußbodenheizung. Im Winter kann man da schon mal etwas im "Estrich speichern". Im Sommer wird dann nur das Warmwasser erwärmt, da die Heizung ansonsten ja aus ist.

@andig
Copy link
Member

andig commented Mar 11, 2025

Das wäre dann die sgready Lösung. Wenn die WP nix andere kann. Implementierung könnt ihr selbst machen, siehe Beispiele. Wenn die funktioniert können wir das OAuth Handling dazu bauen.

@andig
Copy link
Member

andig commented Mar 11, 2025

Creating living spaces for generations to come is our core principle at Viessmann and our IoT selection is the heart of this philosophy.

Blablabla. Hat denn jemand raus gefunden, mit welchen APIs sich hier konkret etwas steuern lässt? Ausser "set heating circuit operation mode" im Postman (ohne dass da die Optionen drin stehen würden) sehe ich nichts sinnvolles. In der Doku findet sich dieser Service nicht wieder.

Es fehlt also auch wieterhin eine nachvollziehbare Vorgehensweise wir das gehen soll.

@MasterGoofy
Copy link
Author

MasterGoofy commented Mar 11, 2025

Was ermöglichen denn die bisher vorhandenen Wärmepumpen und Heizstäbe Integrationen in EVCC?
https://docs.evcc.io/docs/devices/heating

@Afrouper
Copy link

Ich bin die Woche leider unterwegs.
Würde mal spätestens am Wochenende draufschauen.

Aber ich denke mal

  • Setzen der neuen Warmwassertemperatur
  • Setzen der neuen Heiztemperatur.

Datenpunkte (wie Viessmann sie nennt) kann ich mal raussuchen.

Und ja - die Viessmann API ist eher spärlich dokumentiert 🫤

@Pony5dotzero
Copy link

Hallo, ich klinke mich hier auch mal ein da ich ebenfalls seit Herbst 24 eine Vitocal 250A habe.

Z.Zt. nutze ich den viessmann adapter in iobroker und ein entsprechendes script welches bei Überschuss die WW Zieltemperatur hochsetzt und dann die "Einmalige Warmwasserbereitung" triggert.
Bei erreichen der temporären Zieltemperatur setze ich sie dann wieder zurück. Das klappt auch soweit.

Der Einsatz eines modulierenden MyPV Heizstabs wäre hier sicher die bessere Lösung zumal man diesen direkt ins SMA Portal oder auch in evcc einbinden kann. Da wir aber auch noch Solarthermie für die WW Aufbereitung haben muss ich diesen Sommer mal schauen ob sich ein Heizstab überhaupt lohnt.

Jedenfalls kann ich gerne bei Tests unterstützen.

VG Frank

@mpollmeier
Copy link

mpollmeier commented Mar 19, 2025

Ich habe die Viessmann API mal mit curl und jq mit meiner Viessmann Wärmepumpe mit Vitoconnect getestet. In der ViCare App konnte ich dann jeweils live sehen, dass die Einstellungen in der Anlage übernommen wurden - das ganze ist also erfolgversprechend, denke ich. Das Auth Token handling ist noch ein offener Punkt, siehe unten.

Am sinnigsten ist vermutlich, das Feature oneTimeCharge zu aktivieren, wenn gerade PV Überschuss am Start ist. Die Temperatur kann ebenfalls per API ausgelesen und (bis max 60°C) eingestellt werden.

Vorraussetzungen (manuell)

Generelle Informationen auslesen

VIESSMANN_TOKEN=... # von der viessmann website, siehe oben

curl "https://api.viessmann.com/iot/v1/equipment/installations?includeGateways=true" \
  -H "Authorization: Bearer $VIESSMANN_TOKEN" \
  > viessmann-installation.json
VIESSMANN_INSTALLATION_ID=$(jq '.data[].id' viessmann-installation.json)
VIESSMANN_GATEWAY_SERIAL=$(jq '.data[].gateways[].serial' --raw-output viessmann-installation.json)

# devices und deren features auflisten, um das gewünschte gerät zu finden
jq '[.data[].gateways[].devices[] | {id, modelId, roles}]' viessmann-installation.json
# in meinem Fall ist es die `0`, diese hat nämlich u.a. die Rollen "type:dhw;integrated", "type:heating;integrated", "type:heatpump"
DEVICE_ID=0

# informationen über die wärmepumpe anzeigen (optional)
curl "https://api.viessmann.com/iot/v2/features/installations/$VIESSMANN_INSTALLATION_ID/gateways/$VIESSMANN_GATEWAY_SERIAL/devices/$DEVICE_ID/features" \
  -H "Authorization: Bearer $VIESSMANN_TOKEN"

oneTimeCharge auslesen / konfigurieren / steuern

oneTimeCharge target temperature (temp2) auslesen:

curl "https://api.viessmann.com/iot/v2/features/installations/$VIESSMANN_INSTALLATION_ID/gateways/$VIESSMANN_GATEWAY_SERIAL/devices/$DEVICE_ID/features/heating.dhw.temperature.temp2" \
  -H "Authorization: Bearer $VIESSMANN_TOKEN" \
  | jq '.data.properties.value.value'
# beispiel output: `45`

oneTimeCharge status auslesen:

curl "https://api.viessmann.com/iot/v2/features/installations/$VIESSMANN_INSTALLATION_ID/gateways/$VIESSMANN_GATEWAY_SERIAL/devices/$DEVICE_ID/features/heating.dhw.oneTimeCharge" \
  -H "Authorization: Bearer $VIESSMANN_TOKEN" \
  | jq '.data.properties.active.value'
# beispiel output: `false`

oneTimeCharge activieren:

curl -X POST "https://api.viessmann.com/iot/v2/features/installations/$VIESSMANN_INSTALLATION_ID/gateways/$VIESSMANN_GATEWAY_SERIAL/devices/$DEVICE_ID/features/heating.dhw.oneTimeCharge/commands/activate" \
  -H "Authorization: Bearer $VIESSMANN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'
# http 200 bei erfolg (sowie `{"data"{"success":true}}`)

oneTimeCharge deaktivieren

curl -X POST "https://api.viessmann.com/iot/v2/features/installations/$VIESSMANN_INSTALLATION_ID/gateways/$VIESSMANN_GATEWAY_SERIAL/devices/$DEVICE_ID/features/heating.dhw.oneTimeCharge/commands/deactivate" \
  -H "Authorization: Bearer $VIESSMANN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'
# http 200 bei erfolg (sowie `{"data"{"success":true}}`)

setzen der oneTimeCharge target temperature - max value = 60

curl -X POST "https://api.viessmann.com/iot/v2/features/installations/$VIESSMANN_INSTALLATION_ID/gateways/$VIESSMANN_GATEWAY_SERIAL/devices/$DEVICE_ID/features/heating.dhw.temperature.temp2/commands/setTargetTemperature" \
  -H "Authorization: Bearer $VIESSMANN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"temperature": 46}'
# http 200 bei erfolg (sowie `{"data"{"success":true}}`)

Hinweis bzgl. Authentication

Ich habe noch keinen Weg gefunden, den Access Token ohne manuelle Browser-Interaktion zu bekommen. Dieser ist auch nur eine Stunde gültig, kann aber erneuert werden. Angeblich ist ein erneuerter Token dann 180 Tage gültig, zumindest steht das in https://documentation.viessmann.com/static/authentication. Wenn das stimmt, könnte man vielleicht bei der Konfiguration den User bitten, einen Token zu hinterlegen, und diesen könnte evcc dann automatisch regelmäßig erneuern... aber selbst das Erneuern habe ich nur mit Browser-Interaktion hinbekommen.

Andere clients wie https://github.com/openviess/PyViCare scheinen auch ohne Browser-Interaktion einen neuen Token erzeugen zu können, siehe z.b. https://github.com/openviess/PyViCare/blob/2d3143b640bc8f61d6169a1f29369303d450becf/PyViCare/PyViCareOAuthManager.py#L40. Dieser benutzt aber weitere libraries (insbesondere einen PKCE Code Generator für OAuth2) - diese gibt es aber auch für go und werden teils auch bereits in evcc benutzt (z.b. go-pkcs7).

@andig
Copy link
Member

andig commented Mar 21, 2025

Prima. Dann ist der nächste Schritt, das in einen sgready Charger einzubauen, Beispiele gibts genug. Zuletzt kommt dann das Template.

https://documentation.viessmann.com/static/authentication

Dazu brauchst Du einen API client mit Redirect url. Das ist für einen normalen Anwender eine echte Hürde. Ich fürchte an der Stelle kommen wir nicht weiter.

Ich habe noch keinen Weg gefunden, den Access Token ohne manuelle Browser-Interaktion zu bekommen.

Das könnte man in evcc automatisieren, bräuchte aber immer noch (je User) einen API client. An der Stelle kommen wir wohl nicht oder nur mit erheblichem Aufwand weiter.

@MasterGoofy
Copy link
Author

Kann man sich da ggf. was von Home Assistent oder IOBroker anschauen? Ich kann in beiden z.B. meine Temperatur oder WW regeln. Dazu muss ich nie manuell einen Token erzeugen...

@MasterGoofy
Copy link
Author

Hallo, hilft dieser Artikel ggf. weiter?
https://www.rustimation.eu/index.php/a-viessmann-api-und-node-red/

@andig
Copy link
Member

andig commented Mar 24, 2025

Das Tokenzeugs ist sekundär. Erstmal Konfiguration bauen und testen.

@mpollmeier
Copy link

mpollmeier commented Mar 24, 2025

Dann ist der nächste Schritt, das in einen sgready Charger einzubauen, Beispiele gibts genug

Du meinst vermutlich https://github.com/evcc-io/evcc/blob/master/charger/vaillant.go? Andere Beispiele habe ich jetzt gar nicht gefunden. Ich kenne mich weder mit der evcc api noch mit go generell aus, insofern bin ich da gerade ziemlich hilflos :(

Gibt es jemanden, der Zeit und Lust hat auf Basis der obigen curl statements ein viessman.go zu bauen? Oder zumindest das Grundkonstrukt erstellen und ich fülle die Lücken und teste es direkt an meiner Anlage? Den Auth Token können wir ja erstmal außen vor lassen und via Konfiguration definieren.

Und ist sg-ready wirklich die richtige Basis hier? Wir benutzen doch gar nicht die SG-Ready Schnittstelle in diesem Fall, sondern gehen über die Viessman Cloud API...

@andig
Copy link
Member

andig commented Mar 24, 2025

mpollmeier added a commit to mpollmeier/evcc that referenced this issue Mar 25, 2025
... mostly just looking for some feedback.
Based on the api investigation at evcc-io#19639 (comment)

* why does `getmode` trigger two identical http requests?
* authentication via oauth2 using only the viessmann client id
* user guidance to figure out the installation id, gateway serial and
device id
* should/can we configure a longer interval between updates? If so, how? Viessmann has an
api limit of ~1 request per minute

```
chargers:
  - name: viessmann
    type: template
    template: viessmann
    installation_id: 23XXXXX          # all digits
    gateway_serial: 76XXXXXXXXXXXXXX  # all digits
    device_id: 0
    target_temperature: 47
    token: eyJ.....
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann
...
Charge status: B
Enabled:       false
Features:      [Heating IntegratedDevice]

./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --disable
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --enable
[viessmann] TRACE 2025/03/25 13:28:51 {"temperature": 47}
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
[viessmann] TRACE 2025/03/25 13:28:52 { }
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

```
mpollmeier added a commit to mpollmeier/evcc that referenced this issue Mar 25, 2025
... mostly just looking for some feedback.
Based on the api investigation at evcc-io#19639 (comment)

* why does `getmode` trigger two identical http requests?
* authentication via oauth2 using only the viessmann client id
* user guidance to figure out the installation id, gateway serial and device id
* should/can we configure a longer interval between updates? If so, how? Viessmann has an api limit of ~1 request per minute

```
chargers:
  - name: viessmann
    type: template
    template: viessmann
    installation_id: 23XXXXX          # all digits
    gateway_serial: 76XXXXXXXXXXXXXX  # all digits
    device_id: 0
    target_temperature: 47
    token: eyJ.....
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann
...
Charge status: B
Enabled:       false
Features:      [Heating IntegratedDevice]

./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --disable
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --enable
[viessmann] TRACE 2025/03/25 13:28:51 {"temperature": 47}
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
[viessmann] TRACE 2025/03/25 13:28:52 { }
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

```
@mpollmeier
Copy link

Danke für die Pointer, ich habe mal eine erste Version des Templates gebastelt und getestet. Ergebnisse und offene Fragen sind alle hier: #20111

Würdest du da bitte mal drauf schauen und Feedback geben? Daaanke :)

mpollmeier added a commit to mpollmeier/evcc that referenced this issue Mar 25, 2025
... mostly just looking for some feedback.
Based on the api investigation at evcc-io#19639 (comment)

* why does `getmode` trigger two identical http requests?
* authentication via oauth2 using only the viessmann client id
* user guidance to figure out the installation id, gateway serial and device id
* should/can we configure a longer interval between updates? If so, how? Viessmann has an api limit of ~1 request per minute

```
chargers:
  - name: viessmann
    type: template
    template: viessmann
    installation_id: 23XXXXX          # all digits
    gateway_serial: 76XXXXXXXXXXXXXX  # all digits
    device_id: 0
    target_temperature: 47
    token: eyJ.....
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann
...
[viessmann] TRACE 2025/03/25 19:35:15 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
[viessmann] TRACE 2025/03/25 19:35:16 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
...
Charge status: B
Enabled:       false
Features:      [Heating IntegratedDevice]

./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --disable
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --enable
[viessmann] TRACE 2025/03/25 13:28:51 {"temperature": 47}
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
[viessmann] TRACE 2025/03/25 13:28:52 { }
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

```
mpollmeier added a commit to mpollmeier/evcc that referenced this issue Mar 25, 2025
... mostly just looking for some feedback.
Based on the api investigation at evcc-io#19639 (comment)

* why does `getmode` trigger two identical http requests?
* authentication via oauth2 using only the viessmann client id
* user guidance to figure out the installation id, gateway serial and device id
* should/can we configure a longer interval between updates? If so, how? Viessmann has an api limit of ~1 request per minute

```
chargers:
  - name: viessmann
    type: template
    template: viessmann
    installation_id: 23XXXXX          # all digits
    gateway_serial: 76XXXXXXXXXXXXXX  # all digits
    device_id: 0
    target_temperature: 47
    token: eyJ.....
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann
...
[viessmann] TRACE 2025/03/25 19:35:15 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
[viessmann] TRACE 2025/03/25 19:35:16 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
...
Charge status: B
Enabled:       false
Features:      [Heating IntegratedDevice]

./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --disable
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --enable
[viessmann] TRACE 2025/03/25 13:28:51 {"temperature": 47}
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
[viessmann] TRACE 2025/03/25 13:28:52 { }
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

```
mpollmeier added a commit to mpollmeier/evcc that referenced this issue Mar 25, 2025
... mostly just looking for some feedback.
Based on the api investigation at evcc-io#19639 (comment)

* why does `getmode` trigger two identical http requests?
* authentication via oauth2 using only the viessmann client id
* user guidance to figure out the installation id, gateway serial and device id
* should/can we configure a longer interval between updates? If so, how? Viessmann has an api limit of ~1 request per minute

```
chargers:
  - name: viessmann
    type: template
    template: viessmann
    installation_id: 23XXXXX          # all digits
    gateway_serial: 76XXXXXXXXXXXXXX  # all digits
    device_id: 0
    target_temperature: 47
    token: eyJ.....
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann
...
[viessmann] TRACE 2025/03/25 19:35:15 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
[viessmann] TRACE 2025/03/25 19:35:16 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
...
Charge status: B
Enabled:       false
Features:      [Heating IntegratedDevice]
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --enable
[viessmann] TRACE 2025/03/25 13:28:51 {"temperature": 47}
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
[viessmann] TRACE 2025/03/25 13:28:52 { }
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --disable
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
```
@github-actions github-actions bot added the stale Outdated and ready to close label Apr 1, 2025
mpollmeier added a commit to mpollmeier/evcc that referenced this issue Apr 6, 2025
... mostly just looking for some feedback.
Based on the api investigation at evcc-io#19639 (comment)

* why does `getmode` trigger two identical http requests?
* authentication via oauth2 using only the viessmann client id
* user guidance to figure out the installation id, gateway serial and device id
* should/can we configure a longer interval between updates? If so, how? Viessmann has an api limit of ~1 request per minute

```
chargers:
  - name: viessmann
    type: template
    template: viessmann
    installation_id: 23XXXXX          # all digits
    gateway_serial: 76XXXXXXXXXXXXXX  # all digits
    device_id: 0
    target_temperature: 47
    token: eyJ.....
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann
...
[viessmann] TRACE 2025/03/25 19:35:15 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
[viessmann] TRACE 2025/03/25 19:35:16 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
...
Charge status: B
Enabled:       false
Features:      [Heating IntegratedDevice]
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --enable
[viessmann] TRACE 2025/03/25 13:28:51 {"temperature": 47}
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
[viessmann] TRACE 2025/03/25 13:28:52 { }
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --disable
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
```
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 6, 2025
@MasterGoofy
Copy link
Author

Warum wurde das Thema geschlossen, wenn es doch hier Aktivitäten gibt?

@andig
Copy link
Member

andig commented Apr 7, 2025

Das hat der Bot gemacht genau weil es hier im Issue keine Aktivität gab. Der aktuelle Stand ist im PR.

mpollmeier added a commit to mpollmeier/evcc that referenced this issue Apr 7, 2025
... mostly just looking for some feedback.
Based on the api investigation at evcc-io#19639 (comment)

* why does `getmode` trigger two identical http requests?
* authentication via oauth2 using only the viessmann client id
* user guidance to figure out the installation id, gateway serial and device id
* should/can we configure a longer interval between updates? If so, how? Viessmann has an api limit of ~1 request per minute

```
chargers:
  - name: viessmann
    type: template
    template: viessmann
    installation_id: 23XXXXX          # all digits
    gateway_serial: 76XXXXXXXXXXXXXX  # all digits
    device_id: 0
    target_temperature: 47
    token: eyJ.....
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann
...
[viessmann] TRACE 2025/03/25 19:35:15 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
[viessmann] TRACE 2025/03/25 19:35:16 GET https://api.viessmann.com/iot/v2/features/installations/23XXXXX/gateways/76XXXXXXXXXXXXXX/devices/0/features/heating.dhw.oneTimeCharge
[viessmann] TRACE 2025/03/25 19:35:16 {
  "data": {
    ...
  }
}
...
Charge status: B
Enabled:       false
Features:      [Heating IntegratedDevice]
```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --enable
[viessmann] TRACE 2025/03/25 13:28:51 {"temperature": 47}
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
[viessmann] TRACE 2025/03/25 13:28:52 { }
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}

```

```
./evcc --log trace -c ~/.evcc/evcc.yaml --database ~/.evcc/evcc.db charger viessmann --disable
--
{
  "data": {
    "success": true,
    "message": null,
    "reason": "COMMAND_EXECUTION_SUCCESS"
  }
}
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
heating Heating stale Outdated and ready to close
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants