Vitoconnect - Verbesserte Version

[Basti-K]

ha.. vielen danke.
es Funktioniert.
Ich freue mich auf eine ruhige Nacht.

[neworder]

So, alles umgestellt und läuft.

Im log finde ich ab und an die Meldung:

vitoconnect vitoconnect statusCode: 401 errorType: UNAUTHORIZED message: Token provided in request is expired or invalid. error: EXPIRED TOKEN reason: undef
gefolgt von
vitoconnect vitoconnect Usr_Aktiv_Status: statusCode:

zum letzteren passt ein user reading Usr_Aktiv_Status:.* {(sprintf("%.12s", ReadingsVal("vitoconnect","state","")))} von dem ich keine Ahnung habe, wie es dahin kommt  . Es wird aber angezeigt und ist vom Wert ok.

Hat aber keine Auswirkung auf den Datentransfer das sieht alles sehr gut aus.

[Beta-User]

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

Wer testen mag - das wären die Befehle für den Test (FHEM-Kommandozeile), ob der Code aus den Profilen die erwünschte Payload erzeugt:

Code Auswählen Erweitern

{vitoconnect_send_weekprofile('Therme_Vi','weekprofiles','default:Esszimmer','dht')}

Code Auswählen Erweitern

{vitoconnect_send_weekprofile('Therme_Vi','weekprofiles','default:Esszimmer','0.heating')}- "Therme_Vi" ist der Device-Name, in den dann die JSON als Reading geschrieben werden (und die Info, welches Profil es war),
- "weekprofiles" ist der Name des weekprofile-Devices, von dem das Profil abgefragt werden soll
- "topic:entity" ist das konkrete Profil, das vom weekprofile-Device geliefert werden soll (ich arbeite mit topics, aber "default" sollte auch gehen, wenn man das nicht so eingestellt hat).

Die Variante "dht" (oder "bla" oder sonst was, was nicht auf "..heating" matcht) liefert ein reines "on"-Zeiten-Ergebnis,
"0.heating" eines mit "normal"- und/oder "comfort"-Zeiträumen.

Die Abgrenzung erfolgt im Moment anhand fester Werte, alles ab 22° ist "on" bzw. "comfort", darunter ist entweder "off" oder "normal", (letzteres, wenn mind. 20° gefordert sind).

Das wäre jetzt der erste Schritt. Als nächstes (nächste Woche erst) wäre dann ein setter zu generieren, über den man die Angaben zu weekprofile-Device, Profil-Identifier (und evtl. noch "Ziel"*) übergeben kann.

*"Ziel" kann weekprofiles nicht, von daher würde man m.E. immer unterstellen, dass ohne Angabe "0.heating" zu adressieren sein soll, und dann im Anschluss alle anderen (per Attribut konfigurierbar) abgerufen und geprüft werden sollen.

Was ich nicht geprüft habe: Theoretisch kann weekprofile auch direkt Klartext liefern (Achtung: "eco" ist im Moment nicht implementiert, das ist alles "off"). Ich finde das aber nicht so universell wie die Zahlenvergleiche, zumal man dann ggf. auch Reading-Werte aus der Therme selbst mit berücksichtigen könnte.

(Noch keine Ahnung, ob das sinnvoll ist).

Zur Reading-Benennung noch was aktuelles aus einem Nachbarthread:

[...]
Ich schlage noch vor, die Readingnamen etwas an die sonstigen FHEM-Gepflogenheiten anzupassen.

onOffMode -> status
operationMode -> mode
kWh_cooling_day -> energy_cooling_day (etc. für die anderen Energiemesswerte)
roomTemperature -> temperature(_measured)
setpoint -> temperature_desired
outdoorTemperature -> temperature_outdoor
roomHumidity -> humidity(_measured)

LG

pah

Ich finde den Vorschlag zwar (mind. zum Teil) auch etwas aus der Hüfte geschossen, aber wer "Spielmaterial" sucht, findet z.B. hier https://forum.fhem.de/index.php?topic=117933.0 eine (allgemeine) Diskussion zum Thema, und wie bereits angemerkt: Für Strom (PV etc.) gibt es da anscheinend bereits Konventionen, die dann auch die Visualisierung für alle erleichtern.

Für unseren Fall hier würde ich vorschlagen, die Option zu schaffen, _zusätzlich_ "gute" Reading-Namen per Attribut (ähnlich jsonMap in MQTT2_DEVICE) zu erzeugen (set-Befehle ist evtl. schwieriger).
Zusätzlich, weil das kaum mehr Last erzeugt, und dann klarer ist, dass es "eigentlich draufgesetzt" ist.

[stefanru]

@neworder: Kannst du mal die severity der Meldung mit angeben? Bzw. bitte mal das Log komplett kopieren an der Stelle.
EXPIRED TOKEN kommt jede Stunde und das Modul holt sich ein neues Token, sollte normal nicht im Log erscheinen, wird mit Verbose 4 ausgegeben.

@Beta-User: Sorry ich komme vor meinem Urlaub wohl nicht mehr zum testen. Danach gerne.
Das mit dem zusätzlich mappen mit einer Map finde ich gut.
So etwas ist sogar schon eingebaut nur nicht zusätzlich.
Könnte man aber umstellen.
Das geht mit dem Attribut: vitoconnect_mappings oder wenn auf Wortbasis vitoconnect_translations.
Das wird aber in den Settern noch nicht zurück gemappt. Aber wenn man es zusätzlich macht wäre das auch nicht nötig wenn ich es richtig verstehe.

Gruß,
Stefan

[Beta-User]

@Beta-User: Sorry ich komme vor meinem Urlaub wohl nicht mehr zum testen. Danach gerne.

Das mit dem Testen war ausdrücklich erst mal an andere gerichtet, dir einen schönen und erholsamen Urlaub!!!

So etwas ist sogar schon eingebaut nur nicht zusätzlich.

Hatte ich beim Überarbeiten gesehen, dass da was ist und fand die Idee an sich gut. Keine Ahnung, ob das (oder gar "Translations?!?) heute jemand nutzt...?

Prinzipiell fände ich es "vollständiger", wenn man auch die setter mappen könnte. (Diese technischen Bandwurm-setter sind eigentlich eine Zumutung, aber hey, wir reden von Automatisierung...)

Im Moment habe ich dazu folgende (unausgegorene) Gedanken:
Die ganzen Mappings sind umfangreich, also warum diesen Teil nicht in eine separate file auslagern - es funktioniert ja (im "add-on-Modell") auch ohne, und via Attribut ist tendenziell zusätzlich fehleranfällig.
Roger und svn könnte man in contrib bereitstellen (wer die haben will, muss sie eben manuell ruterladen), die alten Attribute dazu könnten entfallen, es wird anhand des Namens entschieden, ob "exklusiv" gemappt werden soll (=rückwärtskompatibel).

Aber erst mal "weekprofile", und dann bist du vermutich auch wieder aus dem Urlaub zurück und die Heizsaison vorbei...

[stefanru]

  Ja das mit dem Auslagern hatte ich mir auch schon gedacht.
Ich denke vitoconnect_mappings oder vitoconnect_translations benutzt niemand.
Das waren meine ersten Versuche bis ich dann für mich auf die Raw Mappings umgestiegen bin weil mir nichts mit Übersetzung gut zugesagt hab.
Deshalb hatte ich das zurück Mappen auch nicht weiter verfolgt, wäre aber sicher möglich.

Man könnte, wenn man das mit vitoconnect_mappings macht und das Rückmappen auch baut auch einfach SVN und Roger als Text bereitstellen.

Gruß,
Stefan

[Beta-User]

Das waren meine ersten Versuche bis ich dann für mich auf die Raw Mappings umgestiegen bin weil mir nichts mit Übersetzung gut zugesagt hab.

  Hatte mir fast sowas gedacht.

Das mit dem Auslagern ist zwar etwas Aufwand, aber eigentlich müßte sich der RHASSPY-Code mehr oder weniger wiederverwenden lassen. Da werden auch modulintern vorgegebene Strukturen per JSON-Analyse neu/anders gefüllt. Der Unterschied liegt nur darin, dass die da schon beim Laden des Moduls da sind und hier (teils erst später) dynamisch gebaut werden. Mal schauen, aber anscheinend haben wir dazu dieselben Gedanken, von daher neige ich dazu, den Weg zu gehen...
(Zumal der Teil dann ggf. für andere Lösungen wie ONECTA (?) übernommen werden könnte?)

[Basti-K]

ha.. vielen danke.
es Funktioniert.
Ich freue mich auf eine ruhige Nacht.

Zu früh gefreut.
Das zeitgesteuerte Deaktivieren des Heizkreises funktioniert, hat aber keinen Einfluss auf das eigentliche Problem. Die Pumpe läuft aufgrund der Frostschutzfunktion.
Diese kann man als ,,Normalsterblicher" weder deaktivieren noch beeinflussen.
In der Service-Anleitung ist die Rede von einem Software-Tool.

Geht das vielleicht auch über die API, oder muss ich bei der nächsten geplanten Wartung daran denken, dass der Techniker ein Notebook mitbringt!?

Frostschutz schön und gut, aber den Mechanismus dahinter verstehe ich nicht. Warum wird dafür die Außentemperatur verwendet? Der Default-Wert ist +3 Grad.
Mir fällt kein realistisches Szenario ein, in dem diese Funktion Sinn macht.
Frostschäden können nur auftreten, wenn die Heizung defekt ist, kein Gas oder kein Strom vorhanden ist. In allen drei Fällen würde die Funktion ohnehin nicht helfen.

[stefanru]

Hi Basti-K,

ja das mit den +3 Grad habe ich auch schon gelesen.
Ehrlich gesagt habe ich mich damit noch nicht beschäftigt.

Heißt das wenn die AT unter +3 Grad fällt geht die Pumpe wieder an?
Ich habe ein Wärmepumpe und da habe ich den Frostschutz immer auf das Außengerät bezogen.
Da macht das für mich schon etwas Sinn dass der zu und Ablauf zur Außeneinheit ab und zu auf Temperatur gehalten wird damit nichts einfriert.

Über die API kann man nur steuern was an Endpunkten von Viessmann bereit gestellt wird.
Mit vitoconnect_raw_readings = 1 kannst du alle sehen die zur Verfügung stehen.

Die Pumpe ist definitiv nicht dabei.

Man kann noch Bezahlen und ein paar API Punkte mehr bekommen, das sind aber mehr statistische Daten.
Zur Steuerung hast du dann auch nicht mehr.

Das Softwaretool mit dem du alles Steuern kannst bei E3 Geräten, ist open E3.
Da gehst du direkt an den CAN Bus des Geräts und hast alles was Viessmann auch kann.
Siehe: https://community.viessmann.de/t5/Konnektivitaet/CAN-Bus-Home-Automation-E3-Generation-lokal-und-kostenlos/td-p/356066
Aber du kannst die Anlage natürlich auch total verstellen.

Lange Rede kurzer Sinn:
Über die API gehen nur die von Viessmann bereitgestellten Endpunkte: https://documentation.viessmann.com/static/iot/data-points
D.h. in deinem Fall keine Pumpe, nur die Heizmodi.

Gruß,
Stefan

[Basti-K]

@stefanru
Ja, genau so ist es:
Das ist total nervig, weil ich quasi unter der Heizung schlafe und das Brummen der Heizung unterschwellig zu hören ist, wenn man im Bett liegt.
Je langsamer die Pumpe dreht, desto tiefer ist die Frequenz. Und tiefe Frequenzen werden lauter ... (subjektives Empfinden).

Ich probiere jetzt noch einmal, die Mindestdrehzahl der Pumpe auf 0 zu setzen. Vielleicht hilft das schon.
Danke für das vollständige Bild, was über die API geht.

Falls das nicht hilft, werde ich versuchen, dass dies bei der nächsten Wartung entsprechend eingestellt wird.

Plan B – der mir aber nicht gefällt, weil er eine zusätzliche Fehlerquelle darstellt – wäre, eine Hardwarelösung zu basteln, die dafür sorgt, dass der NTC (Außenfühler) in der Ruhezeit nicht unter 3 Grad melden kann.
Aber das wäre wirklich eine "dirty" Lösung.

[stefanru]

Ja an den Fühler hatte ich auch schon gedacht.
Bei mir sitzt er Richtung Norden aber ziemlich geschützt. Somit war heute Nacht nie 3 Grad unterschritten. Ich war so bei +4 Grad.
Meine Wetterstation draußen ungeschützt hatte +1 Grad.

Die Abweichung des Fühlers kann man an der Wärmepumpe im Service Menü einstellen nach + / - verschieben.
Den Parameter müsste ich heraussuchen.

Nur mehr wie 3 Grad sollte er ja dann auch nicht abweichen damit die Außeneinheit nicht einfriert.

Gruß,
Stefan

[Basti-K]

Bei mir gibt's keine Nordseite.
der Fühler hängt auf der Ostseite. Der Wert paßt immer sehr gut zur Realität, aber ob das Sinn machen würde bei mir alles um 9 Grad nach oben zu verschieben? Also das fühlt sich falsch an...

[stefanru]

Ja, das denke ich auch, das das keine gute Idee ist

Bei mir ist der Wert halt sehr gepuffert da der Sensor relativ geschätzt sitzt.
Er hinkt immer hinterher, außer es bleibt länger konstant.
War schon am überlegen den Sensor umzusetzen, aber ich komm gut damit zurecht da das auch eher den Gegebenheiten des Mauerwerks entspricht.

Gruß,
Stefan

[neworder]

@stefanru: sobald "vitoconnect vitoconnect statusCode: 401 errorType: UNAUTHORIZED message: Token provided in request is expired or invalid. error: EXPIRED TOKEN reason: undef" wieder auftaucht melde ich mich.

Ein kleines Problem mit den Raw Mappings und deren Bezeichnungen habe ich, aber das hängt eher an meinem nicht Verstehen von FHEM und regexp:

Wenn ich versuche beim Attribut event-on-change-reading ein Reading wie "heating.circuits.0.sensors.temperature.supply.value:2" auf Veränderungen ab 2° einzuschränken passiert nix. Mit "heating.circuits.0.sensors.temperature.supply.value.*:2" funktioniert es. Ist aber kein Problem vom vitoconnect Modul sondern meins .

@stefanru: Schönen Urlaub!

[neworder]

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