Vitoconnect - Verbesserte Version

Begonnen von stefanru, 14 Dezember 2024, 23:32:17

Vorheriges Thema - Nächstes Thema

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 ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

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 ;D .

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....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

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"
    "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:
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

stefanru

Hi Schlimbo,
ich bin immer noch etwas außer gefecht.
Das mit den "device.messages.errors.raw.entries" habe ich mir angeschaut.
Im Februar kam es noch.
Jetzt ist es nicht enthalten.
Ich finde aber auch nichts weder im Google noch im Viessmann Forum dass das gelöscht wurde.
Viessmann will ja immer Daten sparen und Bandbreite.
In der API Doku unter DataPoints taucht es nicht auf https://documentation.viessmann.com/static/iot/data-points.
Entweder haben sie es entsorgt oder der Datenpunkt kommt nur wenn man auch einen Fehler hat.
Da meine Anlage zur Zeit mal keine Fehler hat kann ich das nicht prüfen.

Das Mapping wird von Viessmann geändert, deshalb sind ja Raw Readings eigentlich die bessere Wahl.
Dann wird automatisch umgestellt.

Ich kann die neuen Mappings aber gerne auch irgendwann nachtragen.

Gruß,
Stefan

Beta-User

Scheint, wir haben ein Problem mit Path::Tiny, ich zitiere das auch mal hier:

Zitat von: Olaf am 29 Juni 2025, 10:17:24Can't locate object method "child" via package "6" (perhaps you forgot to load "6"?) at ./FHEM/98_vitoconnect.pm line 3924.[...]
Welche Infos werden noch benötigt, um hier weiterhelfen zu können?

Weitere Diskussion im Ausgangsthread.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors