Neues Modul: vitoconnect

[stefanru]

Hi,

@wieral:
Leider habe ich keine Viessmann Smart Home Thermostaten.
In den Developer Data Points finde ich eigentlich nichts dazu.
https://documentation.viessmann.com/static/iot/data-points
Das einzige was ich sehen kann, aber nicht weiß ob es mit den Thermostaten etwas zu tun hat oder doch etwas anderes ist, ist in der Advanced API für deren Zugriff man bezahlen muss.

Code Auswählen Erweitern

Thermostatic radiator valve (TRV)
Advanced
trv.temperature
Shows the target temperature of the TRV and provides a command to set the target temperature

Ich helfe dir gern dabei Readings bzw Setter einzubinden wenn es diese gibt und wir Infos dazu finden.
Wo genau hast du dieses Reading her her?
"device" ["type:E3","type:actuator","type:radiator","type:smartRoomDevice"]

Findest du irgend etwas passendes in den RAW Readings?
Da wird eigentlich alles geparst was im JSON(der API von Viessmann) gefunden wird.

Du kannst auch mal ein logResponseOnce machen und im FHEM log Verzeichniss in das resource.json schauen.
Das ist was Viessmann liefert. Wenn es darin vorhanden ist kann ich alles einbauen, wenn nicht kommt es einfach nicht über die API.

@87insane:
Ok danke, dein Problem klingt wirklich seltsam.
Du hast ja ausgeschlossen, dass es mit dem Viessmann Modul zu tun hat.
Also das alte Modul mal wieder eingespielt?

Es scheint ja etwas im Z2M Modul zu sein.
Hast du versucht Verbose auch auf 4 oder 5 zu stellen bei dem Modul und dann FHEM zu starten, und zu schauen was im Log passiert?
Oder auch ganz FHEM auf 4 oder 5?
Wenn du einfach nichts sehen kannst vielleicht mal stacktrace am global Device auf 1 setzen.
Ob diese zusätzlichen Loginfos den Fehler sichtbar machen weiß ich aber nicht.

Gruß,
Stefan

[87insane]

Guten Morgen,

das Thema ist nun gelöst. Was ein Hick-Hack mal wieder. Das Modul hat zum Glück nichts damit zu tun, war aber der Auslöser. Zumindest indirekt. Das ist kein Schuld Vorwurf! Bin ja froh das sich jemand darum kümmert.

Nun zurück zum Modul
Was ich schonmal gut finde:
- Die Readings sind wieder wie ich es gewohnt bin (alte Umsetzung)
- Wenn ich etwas schalte, bekomme ich Feedback ohne auf Update klicken zu müssen

Ich schalte z.B. die FBH im Esszimmer über ein MSwitch. Die Heizung muss aufgrund der Raumverteilung nur 2, 3 mal am Tag laufen und ich habe kein Thermostat an diesem Kreislauf. Daher gibt es nur diesen Weg. Der Vorbesitzer hat die wohl immer angelassen.

Die Übersetzungen mache ich im UL. Denke also ab nächster Woche.

[stefanru]

@87insane:
Super dass du es lösen konntest.

Und sehr schön, dass dir die Änderung am Update Verhalten schon hilft.
Es hatte mich im TabletUI sehr gestört, dass ich einen Knopf für die Heizung drücke, aber erstmal nichts passiert und erst beim nächsten Update Zyklus.
Also schreibe ich bei erfolgreichem Senden des Befehls den Wert gleich ins Reading.

Mit der Übersetzung lass dir gerne Zeit.
Ich baue es ein sobald du soweit bist und mir etwas schickst.
Wenn möglich schicke es mir in solch einem Format:
"heating.circuits.enabled"                   => "Aktive_Heizkreise",

Sollte etwas auch ein Setter bekommen bzw. haben bräuchte ich noch etwas mehr Info von dir.
Bei dem alten Mapping ist jeder Setter einzeln programmiert.
Aber ich kann das gerne mit weiteren statischen Methoden erweitern.
Die Setter bekommst du angezeigt wenn du das Attribut vitoconnect_actions_active setzt.
Wenn du mir diese Info bei einem passenden Setter zu deinem Reading zukommen lässt baue ich diesen auch gerne ein.
Eventuell brauche ich zum Setter dann auch noch die passende Info aus dem resources.json im FHEM Log.

Viele Grüße,
Stefan

[alias2006]

Guten Morgen,
Bin vor 2 Tagen wieder auf diesen Thread gestossen und habe
"Zitat:Bitte versuche nochmal die letzte Version des Moduls aus meinem Git.
https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm"
das Modul installiert. Funktioniert seitdem einwandfrei, danke. Ich habe leider auch keine Thermostate von
Viessmann. Meinen Heizung, Modell: E3_Vitodens_300_0821.
Wenn ich was testen soll, gib Bescheid.
Gruß Klaus

[stefanru]

Hi alias2006,

danke für das Feedback.
Habe auch eine Vitoladens in Kombination mit Vitocal.
Sollte es mal was zu Testen geben melde ich mich gerne.

Auch können wir gern über neue Features reden.
Ich habe eine Speicherung der Verbrauchswerte gebaut (Wärmepumpe) die von Viessmann immer verzögert geliefert werden.
Das läuft bei mir gut.
Auch habe ich eine Berechnung der thermischen Energie gebaut, das aber als User Reading und nicht im Modul.
Zur Zeit schaue ich ob ich auch die Soll Vorlauftemperatur berechnen kann. Denke das würde wieder fast alle interessieren.
Mache das auch erstmal als UserReading. Wenn bedarf besteht kann das aber auch ins Modul ziehen.

Viele Grüße,
Stefan

[satprofi]

Hallo.
Wie viele Abrufe sind eigentlich möglich? Alle 3min. Wirklich zuviel?

    

Code Auswählen Erweitern

Anzahl der möglichen API Calls in überschritten!

[alias2006]

Hallo satprofi,
Ich benutze das Modul seit August 2022 und habe folgendes definiert:
defmod GasHeizung vitoconnect meine_email passwort 120
also eine Abfrage alle 120 Sekunden. Hatte bisher noch keine solche
Probleme.
Gruß

[stefanru]

Hi Satprofi,

du hast 1450 API Calls pro Tag.
Dazu kommt etwas Overhead wenn etwa neue API Keys gezogen werden.
Theoretisch solltest du alle 60 Sekunden updaten können.

Nun zu deinem Probleme, welche Version des Moduls benutzt du?
Eine neue von mir?
Da gab es kurzzeitig ein Problem mit den API Calls, sind aber in der neusten Version gefixed.
Hast du dir die neuste Version wie von mir beschrieben durch Eingabe der folgenden Befehle in die Kommandozeile von FHEM (oben) eingespielt?
"wget -qO ./FHEM/98_vitoconnect.pm https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm"
dann auch in die Kommandozeile (oben):
reload 98_vitoconnect.pm

Hast du einen oder mehrere Gateways?
Was sagt dein Reading number_of_gateways?
Jeder Gateway braucht einen API call.

Zusätzlich kannst du morgen das Modul gern mal auf Verbose 4 stellen.
Die API Calls protokolliere ich mit "enter getResource" und nach der Abfrage mit "getResourceCallback went ok".

Gruß,
Stefan

P.S.:
Ich habe gestern auch mal bei mir das logging mitlaufen lassen.
Sieht bei mir gut aus mit den API Calls.
Was ich sehen konnte, dass er jede Stunde ein neues Token braucht weil es abgelaufen ist.
Das kostet dann auch nochmal API Calls.
Da kann man im Modul eventuell noch etwas verbessern, da es beim holen des neuen Tokens unnötig viel macht.
Ich werde mir das anschauen so dass man eventuell auch wirklich an die theoretische Grenze von einem Call alle 60 sekunden kommt.
Im Moment würde ich empfehlen >= 90 sekunden zu nehmen.

[satprofi]

Hi Satprofi,

"wget -qO ./FHEM/98_vitoconnect.pm https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm"
dann auch in die Kommandozeile (oben):
reload 98_vitoconnect.pm

Hast du einen oder mehrere Gateways?
Was sagt dein Reading number_of_gateways?
Jeder Gateway braucht einen API call.

Hallo.
Habe jetzt aktualisiert, trotzdem fehler weiterhin. bin aber "login ok"
300sec. eingestellt.
Reading number_of_gateways finde ich nicht .
jetzt finde ich mit verbose 4 das im logfile

Code Auswählen Erweitern

2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_Initialize redefined at ./FHEM/98_vitoconnect.pm line 1444.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_Define redefined at ./FHEM/98_vitoconnect.pm line 1481.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_Undef redefined at ./FHEM/98_vitoconnect.pm line 1518.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_Get redefined at ./FHEM/98_vitoconnect.pm line 1527.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_Set_New redefined at ./FHEM/98_vitoconnect.pm line 1536.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_Set redefined at ./FHEM/98_vitoconnect.pm line 1753.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_Attr redefined at ./FHEM/98_vitoconnect.pm line 2821.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_GetUpdate redefined at ./FHEM/98_vitoconnect.pm line 2906.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getCode redefined at ./FHEM/98_vitoconnect.pm line 2924.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getCodeCallback redefined at ./FHEM/98_vitoconnect.pm line 2964.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getAccessToken redefined at ./FHEM/98_vitoconnect.pm line 3003.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getAccessTokenCallback redefined at ./FHEM/98_vitoconnect.pm line 3033.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getRefresh redefined at ./FHEM/98_vitoconnect.pm line 3073.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getRefreshCallback redefined at ./FHEM/98_vitoconnect.pm line 3100.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getGw redefined at ./FHEM/98_vitoconnect.pm line 3140.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getGwCallback redefined at ./FHEM/98_vitoconnect.pm line 3162.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getInstallation redefined at ./FHEM/98_vitoconnect.pm line 3242.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getInstallationCallback redefined at ./FHEM/98_vitoconnect.pm line 3264.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getInstallationFeatures redefined at ./FHEM/98_vitoconnect.pm line 3310.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getInstallationFeaturesCallback redefined at ./FHEM/98_vitoconnect.pm line 3337.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getDevice redefined at ./FHEM/98_vitoconnect.pm line 3361.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getDeviceCallback redefined at ./FHEM/98_vitoconnect.pm line 3404.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getFeatures redefined at ./FHEM/98_vitoconnect.pm line 3453.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getFeaturesCallback redefined at ./FHEM/98_vitoconnect.pm line 3491.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_errorHandling redefined at ./FHEM/98_vitoconnect.pm line 3530.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getResource_per_gw redefined at ./FHEM/98_vitoconnect.pm line 3604.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getResource redefined at ./FHEM/98_vitoconnect.pm line 3644.
2024.12.12 11:26:49 1: PERL WARNING: Subroutine vitoconnect_getResourceCallback redefined at ./FHEM/98_vitoconnect.pm line 3711.
2024.12.12 11:26:50 1: PERL WARNING: Subroutine vitoconnect_action redefined at ./FHEM/98_vitoconnect.pm line 3985.
2024.12.12 11:26:50 1: PERL WARNING: Subroutine vitoconnect_StoreKeyValue redefined at ./FHEM/98_vitoconnect.pm line 4036.
2024.12.12 11:26:50 1: PERL WARNING: Subroutine vitoconnect_ReadKeyValue redefined at ./FHEM/98_vitoconnect.pm line 4062.

[satprofi]

Habe jetzt FHEM Update durchgeführt, jetzt habe ich nur 1 Reading

Code Auswählen Erweitern

gw

{"viErrorId":"req-eeb31b84031e4bc485cb6cd6ed47138c","statusCode":429,"errorType":"RATE_LIMIT_EXCEEDED","message":"API calls rate limit has been exceeded. Please wait until your limit will renew.","extendedPayload":{"name":"development portal \"3bc612cc-bcb6-4c0c-bba9-3a65227ceef0\" daily limit","requestCountLimit":1450,"clientId":"8e23aa68f9039535280c8d092d4c67xx","userId":"3bc612cc-bcb6-4c0c-bba9-3a65227ceef0Xx","limitReset":1734048004473Aber Api Meldung nicht mehr da

[stefanru]

Hi Satprofi,

der Fehler sollte nach einem Tag verschwinden.
Immer um 1 Uhr Nachts werden deine API Calls zurück gesetzt.
Wenn sie heute schon wieder verbraucht sind wird es erst morgen wieder gehen.
Bis dahin kannst du leider nichts machen da alle Calls aufgebraucht sind.
Mit welcher Version ist das denn passiert?
Das wäre wichtig zu wissen.

Das Log was du angehängt hast ist vom Reload des Moduls.
Da sollten bei verbose 4 auch noch weitere Meldungen kommen, speziell zu den Anfragen an der API.

Ich verstehe leider immer noch nicht ganz welche Version du benutzt hast als der Fehler auftrat.

Entweder du verwendest eine bevor meinen Änderungen oder bitte die letzte von mir.
Zwischendrin gab es mal ein Problem mit API calls.

Ich würde außerdem empfehlen das Device zu disablen. Dann zu warten bis du wieder API Calls frei hast. Sollte 1Uhr heute Nacht so weit sein.
Danach das Modul mit verbose 4 laufen lassen.
Dann siehst du solche Einträge im Log:
enter getResource
Immer wenn dieser kommt wurde ein API call gemacht.

Wenn es immer noch Probleme gibt mir das Log schicken, ich kann dann sehen was da los ist.

Gruß,
Stefan

[satprofi]

wo lese ich fie version aus? habe aber deinen Link installiert.

[stefanru]

Hi satprofi,

das Modul scheint kein Version Reading zu besitzen. Das werde ich noch einbauen, danke für den Hinweis.
Um auf nummer sicher zu gehen dass du auch das richtige Modul verwendest wäre es super wenn du die Datei 98_vitoconnect.pm in /opt/fhem/FHEM mal aufmachen könntest in einem Texteditor und ziemlich am Anfang ab Zeile 70 findest du
##############################################################################
#   Changelog:


Schicke mir hier mal das erste was darunter kommt.

Gruß,
Stefan

[satprofi]

also irgendwas passt dann mit deinem link nicht.

zeile 1

Code Auswählen Erweitern

98_vitoconnect.pm 26738 2022-11-23 00:22:25Z mcp $
letzter eintrag vom changelog

Code Auswählen Erweitern

2021-07-19      neue Readings für heating.burners.0.*
datei hat aber heutiges Datum

[stefanru]

Ok, das ist die Version vom SVN.
Hast du ein Update über FHEM gemacht?
Das überschreibt natürlich meine Version.

Sie ist noch nicht übernommen und im offiziellen FHEM SVN.

Du kannst meine Befehle ausführen, aber danach kein Update mehr.
Willst du verhindern das meine Version von der offiziellen beim Update überschrieben wird musst du das Modul vorerst vom Update ausnehmen.
Das geht in dem du am global Device das Attribut exclude_from_update auf 98_vitoconnect.pm setzt.

Gruß,
Stefan