Neues Modul: vitoconnect

[mcp]

Moin gadget,

Ich hatte verbose 5 eingeschaltet und eine Viertelstunde gewartet (Mein Update Intervall sind 600 Sekunden).

du kannst da ruhig einen kleineren Intervall nehmen, ich fahre seit Ewigkeiten gut mit 65 Sekunden.

In der freien Version sind 1450 API Aufrufe pro Tag möglich (siehe auch https://developer.viessmann.com/start/pricing.html)

86400 / 1450 == 59,586..., mit 60 hatte ich es vor einiger Zeit mal probiert, kam dann aber gegen Abend öfter an das Limit, mit 65 läuft es gut (ich mache aber auch so gut wie nichts/nie mit der ViCare App) - das muss man natürlich berücksichtigen.

[mcp]

Moin gadget,

Code Auswählen Erweitern


2022.11.09 11:00:23 1: PERL WARNING: "my" variable $param masks earlier declaration in same scope at ./FHEM/98_vitoconnect.pm line 1858, <DATA> line 1.
2022.11.09 11:00:23 1: PERL WARNING: "my" variable $err masks earlier declaration in same scope at ./FHEM/98_vitoconnect.pm line 1865, <DATA> line 1.
2022.11.09 11:00:23 1: PERL WARNING: "my" variable $msg masks earlier declaration in same scope at ./FHEM/98_vitoconnect.pm line 1865, <DATA> line 1.
2022.11.09 11:00:23 1: PERL WARNING: "my" variable $decode_json masks earlier declaration in same scope at ./FHEM/98_vitoconnect.pm line 1866, <DATA> line 1.


bereits lokal gefixt.

etwas später dann:

Code Auswählen Erweitern


2022.11.09 11:01:43 1: vitoconnect - An error occured: read from https://iam.viessmann.com:443 timed out
2022.11.09 11:01:43 1: vitoconnect - Login failure. Check password and apiKey


Seitdem hat das Modul dann aber offenbar aufgegeben zyklisch  weitere Logins zu versuchen.
Irgendwas scheint meiner Meinung nach mit dem Retry nach Fehler nicht so ganz zu passen (was auch erklären würde, warum hier manche mit anderen Mechanismen versuchen einen Update zu erzwingen).

Ein manuelles set <vitoconnect-Device> update hat das Modul bei mir jedenfalls wieder in Gang gebracht.

@andreas13: kann es sein, daß genau in dem Fall kein InternalTimer mehr aufgerufen wird und daher bei dem Fehler nichts weiter passiert?

Edit: es ist genau so wie vermutet, gerade nachgestellt. Werde ich beheben.

Dabei gab es noch ein paar Warnings, die aber vermutlich ignorierbar sind:

Code Auswählen Erweitern


2022.11.09 17:09:53 4 : vitoconnect - getFeatures went ok
2022.11.09 17:09:53 1 : PERL WARNING: Use of uninitialized value in string ne at ./FHEM/98_vitoconnect.pm line 1849.
2022.11.09 17:09:54 1 : PERL WARNING: Use of uninitialized value in string ne at ./FHEM/98_vitoconnect.pm line 1867.



ebenso bereits lokal gefixt - ich uploade später/morgen ein Update des Moduls.

--
ciao, Marc

[neworder]

Moin Andreas und Marc,

@Andreas: läuft seit April/Mai stabill und hat mir viel übers die Heizung gezeigt! *verbeuge mich* TOP!  Besten Dank!

Wenn das im April so gelaufen wäre, hätte ich aufgegeben!

@Marc: Dir alles Beste für die Modulbetreuung. Wenn du mal einen Dummy/Test User brauchst -> Hier isser.

[PeterLustig]

Im Developer-Bereich bei www.viessmann-community.com wird eine Wartung für Mittwoch angekündigt:

Scheduled maintenance 11/16/2022
There is planned maintenance work on the Viessmann servers on 11/16/2022, 09:00 to 10:00 CET. During this time there may be a limitation of API functionality. This maintenance has no effect on your Viessmann heating system. It serves to improve our servers and thus also the API.

[buec65]

Es gibt wieder Wartungsarbeiten

[RappaSan]

Wie haltet ihr das nur aus...
Die Vitoconnect-Hardware ist ja weiß Gott nicht preiswert.
Dafür ist der Support für das Ding von Viessmann unterirdisch.
Ich bin froh, daß ich die Optolink-Schnittstelle benutzen kann, die läuft seit Jahren Problemfrei ohne Cloud-Anbindung.

[buec65]

Eigenbau Optolink hatte ich auch ein paar Jahre im Einsatz aber die neuen Geräte haben das nicht mehr.

Nach einigen Anpassungen ist das für mich schon nutzbar.
Mit der ViCare-App kann man ja Einstellungen anpassen.

[h0nIg]

@andreas13: kann es sein, daß genau in dem Fall kein InternalTimer mehr aufgerufen wird und daher bei dem Fehler nichts weiter passiert?

Edit: es ist genau so wie vermutet, gerade nachgestellt. Werde ich beheben.

--
ciao, Marc

Hi, gibts dazu demnächst ein Update bitte? Danke! Grüße

[buec65]

Steht doch weiter oben schon

Ich habe nur das eine Modul updaten lassen - dauert sehr lange

Seit dem keine Probleme mit Reonnect bei Wartungsarbeiten an den Servern

[mcp]

Guten Morgen h0nIg,

Hi, gibts dazu demnächst ein Update bitte? Danke! Grüße

Hmm, ich war felsenfest der Meinung, dass ich am nächsten Tag, nach meiner Nachricht, das Update hochgeladen habe?!

Anscheinend ist das nicht der Fall

Ich mache das im Verlauf des Tages erneut und prüfe! das dann auch.

Tut mir Leid und soll nicht wieder vorkommen.

[mcp]

Update ist hochgeladen:

98_vitoconnect.pm: Missing update interval after login failure

[neworder]

Mal etwas ganz anderes (positives Feedback): Läuft bei mir seitdem ohne Aussetzer! 

[gadget]

Hallo,

Ich hätte da mal wieder ein Problem:

- Modul läuft gemütlich vor sich hin, Readings werden aktualisiert, SVGs passen. Alles schick.

- Im Frontend habe ich einen Pushbotton, um die Heizung aus zu schalten. Der wird gedrückt. Das führt dazu, dass ein Dummy sofort auf "Aus" geschaltet wird und so wird das im Frontend auch angezeigt. Frontend-Benutzer geht davon aus, dass die Heizung jetzt aus ist.

- Die Änderung am Dummy führt dazu, dass  ein DOIF ein set vitoconnect HK1-Betriebsart standby lostritt wird und geht davon aus, dass das dann auch so verarbeitet wird und die Anzeige im Frontend korrekt ist.

- Im Log steht aber:

Code Auswählen Erweitern


022.11.30 13:26:16 1 : vitoconnect - set vitoconnect HK1-Betriebsart standby: Fehler während der Befehlsausführung:  :: {"viErrorId":"req-de3a1e0fbf344d9782e32a5281cc9d1b7","statusCode":401,"errorType":"UNAUTHORIZED","message":"Token provided in request is expired or invalid.","error":"EXPIRED TOKEN"}


Der set wird also nicht ausgeführt weil Token abgelaufen.

- Einige Minuten später im Log, wohl bei der zyklischen Abfrage (inzwischen verbose 4 eingeschaltet)

Code Auswählen Erweitern


2022.11.30 13:34:23 4 : vitoconnect - GetUpdate called ...
2022.11.30 13:34:23 4 : vitoconnect - enter getResource
2022.11.30 13:34:23 4 : vitoconnect - access_token: eyJlbmEDsWiJBMjU2R0N...
2022.11.30 13:34:23 4 : vitoconnect - installation: 323866
2022.11.30 13:34:23 4 : vitoconnect - gw: 7637412216793209
2022.11.30 13:34:23 4 : vitoconnect - getResourceCallback went ok
2022.11.30 13:34:23 4 : vitoconnect - statusCode: 401 errorType: UNAUTHORIZED message: Token provided in request is expired or invalid. error: EXPIRED TOKEN
2022-11-30 13:34:23 vitoconnect vitoconnect statusCode: 401 errorType: UNAUTHORIZED message: Token provided in request is expired or invalid. error: EXPIRED TOKEN
2022-11-30 13:34:23 vitoconnect vitoconnect Betriebsart: standby
2022.11.30 13:34:23 4 : vitoconnect - getRefreshCallback went ok
2022.11.30 13:34:23 4 : vitoconnect - Access Token: eyJlbmEDsWiJBMjU2R0N...
2022.11.30 13:34:24 4 : vitoconnect - getGwCallback went ok
2022.11.30 13:34:24 4 : vitoconnect - getInstallationCallback went ok
2022.11.30 13:34:25 4 : vitoconnect - getDeviceCallback went ok



also ist jetzt offenbar wieder ein gültiges Token vorhanden

- Das reading HK1-Betriebsart wird aktualisiert, da steht jetzt nach wie vor dhwAndHeating drin.
- Das aktualisiert den Dummy und führt dazu, dass jetzt auch im Frontend wieder Heizung+WW angezeigt wird.

Wenn ich jetzt nochmal im Frontend auf "Aus" drücke klappt der set  ... standby diesmal und die Anzeige im Frontend bleibt auch beim nächsten Zyklus  auf "Aus".

Das ist natürlich so nicht brauchbar. Wenn ich im Frontend Aus schalte soll die Heizung auch zuverlässig ausschalten und nicht nur dann wenn der Token noch gültig ist.
Für alle anderen Betriebsarten, Temperaturänderungen  usw. natürlich genau so.

Ich könnte die Logik jetzt so umbauen, dass ich solange zyklisch set-Befehle abschicke bis es keine Diskrepanz mehr zwischen Frontend-Dummy und reading in der Heizung gibt. Dann wären Änderungen aber auch nur noch vom Frontend aus möglich. Wenn direkt an der Heizung oder über die Viesmann-App umgeschaltet wird, würde das von fhem wieder rückgängig gemacht werden.

Ich bin eigentlich davon ausgegangen, dass die set-Kommandos in eine Queue gestellt werden wenn ein 401 zurück kommt und der Token zunächst refresht werden muss.

Wäre es denkbar, zumindest eine Option einzubauen, die vor jedem set erst mal das Token testet und refresht (oder einfach immer refresht bei einem set) ? So oft passiert das ja i.d.R. nicht (bei mir maximal 6 mal täglich ein set-Kommando ).

Beim zyklischen aktualisieren der readings ist es hingegen ja nicht weiter tragisch, wenn da mal ein Zyklus ausfällt, weil erst mal das Token aktualisiert werden muss ....


Grüße, gadget

PS: Hab die aktuellste Modul-Version von vor einer Woche.

[mcp]

Moin gadget,

ja, habe ich bereits lokal eingebaut (allerdings ohne Option sondern eleganter ) und vieles vieles mehr, ebenso diverse Bugfixes.

Ich denke/hoffe übernächste Woche bin ich soweit für das große Update.

Aber selbst wenn vor dem Set der Token erneuert wird hast Du keine Garantie, daß der Set-Befehl auch ausgeführt bzw. korrekt ausgeführt wurde (sei es Token expired, timeout, Internet-Leitung platt, Vitoconnect Modul platt, Viessmann Wartung and whatnot ...)

Daher gibt's in der neuen Version auch ein Reading, ob das Set Kommando erfolgreich war oder nicht, ebenso wird nach einem Set, wenn die Übertragung an die API erfolgreich war, eine Aktualisierung vorgenommen, die dann die Änderung auch widerspiegeln muss.

Heißt aber auch, daß Du dein Konstrukt dann umbauen solltest so daß das set nicht einfach das Dummy blind ausschaltet sondern erst auf off geht, wenn das DOIF entsprechend geschaltet hat _UND_ die Rückmeldung von der Heizung gekommen ist / wirklich umgeschaltet hat - Ansonsten kannst Du nie 100%ig sicher sein, daß dem auch wirklich so ist.

Wie hoch hast Du Deinen Intervall eingestellt? Ich nehme an, daß Du einen sehr hohen Intervall hast, ich vermute >= 1 Stunde, sonst würdest Du eigentlich nie einen expired Token bei einem Set sehen, weil der Token 3600 Sekunden (1 Stunde) valide ist.

Edit: Schmarrn. Der Token wird ja auch nur aktualisiert sobald irgendwas von der API meldet, dass der Token expired ist. Wenn dein Intervall 10 Minuten ist hast du nach Ablauf der Token Zeit und VOR refresh den Set gemacht und der Set hat einen refresh ausgelöst.

[gadget]

Hört sich super an !

Mein Refresh Intervall ist aktuell 10 min.