Vitoconnect - Verbesserte Version

[Beta-User]

Hier die Ausgabe bei verbose 4

Code Auswählen Erweitern

2025.03.17 15:15:00 4: vitoconnect - getResourceCallback went ok
2025.03.17 15:15:00 4: vitoconnect - statusCode: 401 errorType: UNAUTHORIZED message: Token provided in request is expired or invalid. error: EXPIRED TOKEN reason: undef
2025.03.17 15:15:00 4: vitoconnect - Set devices: HASH(0x56e7a38)
2025.03.17 15:15:00 4: vitoconnect. - getRefreshCallback went ok
Ich seh keine Severity 

Gemeint war wohl der verbose-Level.
Du bist bei 4 - also "ziemlich gesprächig".

[neworder]

Mit severity bezog ich mich auf Beitrag 198 von Stefan.

[stefanru]

Ja ich meine den Verbose Level 4.
Du scheinst FHEM mit 4 laufen zu haben.
2025.03.17 15:15:00 4: vitoconnect - statusCode: 401 errorType: UNAUTHORIZED message: Token provided in request is expired or invalid. error: EXPIRED TOKEN reason: undef

Da kann man jetzt streiten ob das eine 4 ist oder nicht, 4 ist:
4 - von den einzelnen Geräten empfangene Daten.

Es geht nur noch eins höher mit 5 für Debugging.
Ich glaube standradmäßig steht FHEM auf 3.
Das würde ich dir auch empfehlen.

Gruß,
Stefan

[neworder]

Code Auswählen Erweitern

2025.03.17 15:14:59 4: vitoconnect - access_token: eyJraWQiOiI0ZWNhM2Vk...
2025.03.17 15:14:59 4: vitoconnect - installation:
2025.03.17 15:14:59 4: vitoconnect - gw:
2025.03.17 15:15:00 4: vitoconnect - getResourceCallback went ok
2025.03.17 15:15:00 4: vitoconnect - statusCode: 401 errorType: UNAUTHORIZED message: Token provided in request is expired or invalid. error: EXPIRED TOKEN reason: undef
2025.03.17 15:15:00 4: vitoconnect - Set devices: HASH(0x56e7a38)
2025.03.17 15:15:00 4: vitoconnect. - getRefreshCallback went ok
2025.03.17 15:15:00 4: vitoconnect - Access Token: eyJraWQiOiI0ZWNhM2Vk...
Das token scheint sich auch nicht zu ändern. Eintrag erscheint so ca. 1 mal die Stunde (gw und installation deleted by me)

[neworder]

Ich hatte wegen deiner Anfrage auf 4 gedreht. Nun wieder back

[stefanru]

Ja jede Stunde muss man neu Authentifizieren, ich denke das passt so und ist normal.

[Uwe S.]

Hallo zusammen,

aus irgendeinem Grund funktioniert bei mir das SVN-Mapping

Code Auswählen Erweitern

    "heating.burners.0.statistics.hours"  => "Brenner_1_Betriebsstunden",nicht.
Es wird weder das RAW-reading heating.burners.0.statistics.hours noch das gemappte Brenner_1_Betriebsstunden in der Liste angezeigt.

Aktiviere ich die RAW-Readings, ist das reading heating.burners.0.statistics.hours in der Liste.
Definiere ich über vitoconnect_mappings ein eigenes Mapping, wird auch mein eigenes reading angezeigt.

Nur wenn ich ausschliesslich die SVN-Mappings nutze, fehlt mir das reading.

Hat vielleicht jemand einen Tipp?

[stefanru]

Hi Uwe,

hmmm, das ist aber sehr komisch.

Hast du zufällig vitoconnect_disable_raw_readings gestetzt?
Dann erzeugt er bei nicht gefundenen Mappings keine Raw Readings.
Also es sollte bei dir nicht oder auf 0 gesetzt sein.

Du kannst auch mal set logReponseOnce machen.
Dann sollte im FHEM Log Verzeichnis eine Datei Namens resource_<deine serien nummer>.json landen.
Dort drin kannst du mal nach heating.burners.0.statistics.hours suchen und das genau mit dem Namen im Mapping vergleichen.
Sollte das genau übereinstimmen bitte auch mal im FHEM log schauen ob es irgendwelche Fehler gab.

Welche Version von vitonnect.pm hast du denn genau?

Ansonsten bin ich relativ ratlos und könnte dir nur eine Debug Version anbieten.
Die müsste ich aber erst auf deinen Fall zuschneiden, da ich morgen in Urlaub gehe schaffe ich das nicht mehr davor aber in 15 Tagen könnte ich es dann versuchen wenn das Problem noch besteht.

Gruß,
Stefan

[Uwe S.]

Hallo Stefan,

zuerst einmal vielen Dank für Deine schnelle Antwort.

Ich nutze die Version
98_vitoconnect.pm:v0.8.7-s29593/2025-01-29

vitoconnect_disable_raw ist nicht gesetzt.

Merkwürdig ist halt, dass wenn ich die raw-readings auslese, genau das heating.burners.0.statistics.hours dabei ist.
Und sollte es nicht so sein, dass alle nicht-gemappten readings mit ihrem raw-Namen angezeigt werden?

Ich werde mir mal deine Vorschläge anschauen.

Im JSON finde ich Folgendes:

Code Auswählen Erweitern

    {
      "feature": "heating.burners.0.statistics",
      "gatewayId": "...",
      "deviceId": "0",
      "timestamp": "2025-03-19T08:04:25.918Z",
      "isEnabled": true,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/113885/gateways/.../devices/0/features/heating.burners.0.statistics",
      "properties": {
        "hours": {
          "type": "number",
          "value": 31504,
          "unit": "hour"
        },
        "starts": {
          "type": "number",
          "value": 550679,
          "unit": ""
        }
      },
      "commands": {}
    },

Und vor allem keinen Streß!! Urlaub geht vor!
Ich kann ja mal während Deines Urlaubs ein wenig testen und meine Erkenntnisse teilen.

Danke

[stefanru]

Hi Uwe,
ok das JSON hilft schonmal weiter.

Ich habe das alte Mapping ja nicht gebaut und warte es nur.
Vielleicht gibt es ein Problem bei mehreren Properties zu einem Datenpunkt.
Den "starts" Datenpunkt bekommst du aber?

Ich schaue mir das gerne nach meinem Urlaub an, denke auch das da irgendwo ein Bug ist.

Wie oft erwähnt möchte ich dich auch motivieren darüber nachzudenken auf vitoconnect_raw_readings umzustellen.
Das wird in Zukunft der neue Standard und solche Probleme sollte es dabei nicht geben.

Gruß,
Stefan

[Uwe S.]

ja, den starts-Datenpunkt bekomme ich.

Zudem habe ich getestet und das Mapping für heating.burners.0.statistics.hours aus der Liste entfernt.

Dann bekomme ich das reading auch als raw-reading angezeigt.

Zum Thema Umstellung auf die raw_readings:
- Die Werte sind so halt schöner lesbar. Natürlich könnte man sich da z.B. mit readingsProxys behelfen.
- Zur Umstellung wäre es hilfreich, wenn es ein Option gäbe, die gemappten und die raw-readings zu bekommen. Dann könnte man sukzessive umstellen.

ich wünsche einen schönen Urlaub

[buec65]

Beitrag #190

Man kann sich das Gerät auch 2 mal anlegen. Als Raw Readings und als normales. Dann bei beide disablen und ein GetResponceOnce bei beiden kurz hinter einander machen. Dann kann man die Werte in aller Ruhe vergleichen.
heating.sensors.temperature.outside.value sollte der Außentemperatur Fühler der Anlage sein. Ist es zumindest bei mir.

[Uwe S.]

Könnte man machen, um das zweite Gerät dann irgendwann wieder zu löschen....
Zudem müsste man nicht nur den Reading-Namen, sondern auch das device an den entsprechenden Stellen ändern.

Eleganter wäre da schon die Variante, beide readings zu haben. Wenn man dann irgendwann mit seiner Umstellung fertig ist, braucht man nur noch das attribut zurücksetzen und gut ist.

[Beta-User]

So, auch ein paar news zum Thema weekprofile...

Ergänzend zu diesem Beitrag (gar keine downloads bisher - keiner Interesse?!?) hier je eine weeksprofile- und vitoconnect-Version (samt diff zu letzterer), mit der man jetzt schon Profile aus weekprofile heraus an vitoconnect (und uU. andere, bisher unbekannte "Client"-Module) "versenden" kann. Dazu das neue Attribut bei weekprofile setzen (auf "vitoconnect").

Bisher wird noch nichts versendet, die nächsten steps wären:
- Vergleich mit dem Altwert, wenn geändert:
- Versenden (0.heating) (im Moment wird nur als Reading geschrieben, was versendet werden würde, Abgrenzungslogik siehe den oben verlinkten Beitrag).
- "Schleife" für weitere (per Attribut konfigurierbare) Unter-Geräte (WW-Bereitung und Pumpen mit "on"/"off"-Profilen)

Falls sich erfolgreiche Mittester gefunden haben, würde ich das mal an @Risiko adressieren, damit weekprofile allgemein so vorbereitet wird, dass man selbst weitere Client-Module angeben kann .

[buec65]

@Beta-User
Bei mir geht es nur darum Werte aus der Anlage zu lesen und entsprechend in Fhem darzustellen.
Mit der Weiterentwicklung von stefanru und Dir sind meine Anforderungen gut abgedeckt.
Die Umstellung auf nur RAW-Readings finde ich sehr gut.

Meine alte Viessmann hatte Optolink und die Unabhängigkeit von der Cloud-Lösung fand ich richtig gut.
Hab schon mehrfach bei open3e geschaut aber mich stört das es auf einem zusätzlichen Raspberry laufen würde und dann die Werte über MQTT ankommen.

Bei meiner Gastherme macht es nach meiner Kenntnis wenig Sinn ständig Werte zu ändern.
Das kann bei einer Wärmepumpe natürlich durchaus sinnvoll sein.