Vitoconnect - Verbesserte Version

[Beta-User]

Danke für die Rückmeldung und die Info, ich hoffe, dass sich dein weiteres Thema einigermaßen zeitnah und gut lösen läßt - unabhängig davon, wie schnell wir ggf. dann mit dem Modul weiterkommen.

Bei mir läuft das auch ziemlich nebenher, von daher wäre das Ziel, das vor der nächsten Heizperiode funktional zu haben .

[stefanru]

Hi Beta-User,
kurzes Lebenszeichen von mir.
Bis zur nächsten Heizperiode klingt realistisch
Bin aber noch die nächsten Wochen eingespannt.

Ich melde mich sobald ich etwas Luft habe.
Dann können wir mal schauen wie wir am besten weiter kommen und ich kann mir das mal anschauen und testen.

Gruß,
Stefan
 

[Beta-User]

Hi Stefan,

Danke für die Zwischeninfo , hat alles keine Eile!

Falls jemand testen will: Es gibt in https://forum.fhem.de/index.php?msg=1342809 eine Variante, bei der man ganz ohne Verzicht auf das aktuelle (svn-) Modul aus den raw-Reading-Namen in einem oder mehreren separaten Device/s "schöne" Reading-Namen erzeugen können sollte. Hab's noch nicht mit den "roger"- oder "svn"-mapping-files aus meinen letzten Beiträgen hier getestet, aber wenn es Events am "master" gibt, sollte es auch Aktualisierungen an den Proxy-Devices geben .

weekprofile geht dann (mit der svn-Version) natürlich noch nicht, aber sonst _könnte_ sogar das mit den "normalen" (aber gemappten!) set-Befehlen schon funktional sein.
Wenn sich jemand (nicht stefanru selbst!) mal an einen Test für subDeviceProxy wagen würde, wäre das super (das geht auch ganz unabhängig von vitoconnect!).

Mein nächster Schritt wäre, meine Variante von vitoconnect weiter zu verschlanken und dann die "Dispatch"-Anweisungen reinzucoden; auch deswegen wäre ich froh, wenn jemand anderes sich die notifyFn-Variante "ertesten" würde .
Wird auch etwas dauern, aber (sehr) vielleicht reicht es mir mit Dispatch bis Ende der kommenden Woche, mal schauen. So groß sollte der Aufwand nicht sein, aber der Teufel steckt halt oft im Detail....

[Schlimbo]

Hi,
bei mir wird seit dem 23.04.2025 das Reading "device.messages.errors.raw.entries" nicht mehr aktualisiert, die API scheint diesen Wert nicht mehr auszugebe.
Auch in der resource_*.json konnte ich ihn nicht mehr finden.
Ist das bei euch auch so?

Beim Analysieren der resource_*.json ist mir außerdem noch etwas anderes aufgefallen, das vielleicht für manche interessant sein könnte:
Bei manchen Datenpunkte gibt es ein Feld "deprecated"

Code Auswählen Erweitern

    "feature": "heating.dhw.sensors.temperature.hotWaterStorage",
      .
      .
      .
      }
      },
      "commands": {},
      "deprecated": {
        "removalDate": "2024-09-15",
        "info": "replaced by heating.dhw.sensors.temperature.dhwCylinder"
      }
Bei mir betrifft es folgende Readings:

Code Auswählen Erweitern

heating.buffer.sensors.temperature.main                -->  replaced by heating.bufferCylinder.sensors.temperature.main
heating.buffer.sensors.temperature.top                 -->  replaced by heating.bufferCylinder.sensors.temperature.top
heating.dhw.sensors.temperature.hotWaterStorage        -->  replaced by heating.dhw.sensors.temperature.dhwCylinder
heating.dhw.sensors.temperature.hotWaterStorage.bottom -->  replaced by heating.dhw.sensors.temperature.dhwCylinder.bottom
heating.dhw.sensors.temperature.hotWaterStorage.top    -->  replaced by heating.dhw.sensors.temperature.dhwCylinder.top
Laut ChangeLog von Viessmann (Feb 2025) betrifft es aber noch mehr: https://documentation.viessmann.com/static/changelog

Obwohl der 15.09.2024 schon vorbei ist und die deprecated Readings weiterhin aktualisiert werden, habe ich meine Logiken vorsorglich mal auf die neuen Readings umgestellt. (evtl. haben sie auch ein Schreibfehler und meinen 2025)

Gruß Schlimbo