Vitoconnect - Verbesserte Version

[Roger]

Hi Ihr Beiden,
ja, eine generische Version, welche für alle Viessmann-Geräte passt, wäre schön.
Falls Viessmann mal wieder was Grundlegendes ändert --> so braucht man nur die generische Version zu ändern.
Wenn neue Geräte mit speziellen Eigenschaften hinzukommen, so wird die Funktion unterstützt - nur Anpassungen zu Schönheit/Lesbarkeit muss man machen.

Meine Vorstellungen wären:
- Readingsnamen können individuell angepasst werden
- auch Namen der set und get Befehle können angepasst werden (bei set wäre eventMap noch möglich)
Ich verwende z.B. die Befehle der Heizungssteuerung an vielen Stellen meiner Hausautomation (Sommerbetrieb, Abwesenheit, Ventile alle zu, Ventil zu 100% offen, Wettervorhersage, Anz. Brennerstarts, ...). Da will ich bei Änderungen nicht an diversen Stellen anpassen müssen.

@Stefan: Du hast auch die Namen der set-Befehle dynamisch geändet: vitoconnect_Set_SVN, vitoconnect_Set_Roger

//Roger

[Beta-User]

Meine 2ct:

Es sollte ein zentrales Device geben mit ausschließlich generischen Readings, set/get usw..
Daneben kann es dann weitere "Kinder" geben, die (eigentlich: für Teilbereiche) kurze (und FHEM-typische "gute") Reading-Namen und set/get können - mappings per File.

Habe ein paar Dinge in diesem Sinn vorbereitet, das lädt auch, ist aber bei weitem noch nicht fertig. Bei Interesse kann ich einen Link auf die file@github bereitstellen.

[stefanru]

Hi Roger,

das Modul funktioniert generisch.
Dies ist zur zeit aber nur mit vitoconnect_raw_readings möglich.
Hierbei wird alles aus dem XML geholt und auch die Setter passend erstellt.

SVN und Roger Mappings, ist 1 zu 1 das alte Coding was Mapping und Setter angeht.
Das habe ich wegen Abwärtskompatibilität erstmal übernommen.

Auch die mehr generischen Mappings waren nur versuche von mir zu denen ich die Setter nicht angepasst habe.
Ich bin für mich von diesen abgekommen und komplett auf vitoconnect_raw_readings gegangen.
Ich erwarte dass diese ziemlich stabil sind, sonst schießt sich Viessmann ja ein Eigentor und diese werden auf jedenfall automatisch nachgezogen sollte Viessmann etwas ändern.
Klar müsste man bei einer inkompatiblen API Änderung seitens Viessmann dann leider an einigen Stellen z.B. Logging, Graphen, TabletUI nacharbeiten.

@Beta-User:
Wenn du hier etwas generisches schon vorbereitet hast schaue ich es mir gerne an sobald es meine Zeit zulässt.
Das wäre der nächste logische Schritt für die User die gerne noch ein Mapping zwischen Raw Readings und FHEM hätten.
Die Idee für diese User ein technisches Device mit den Raw Readings und eins das übersetzt zu haben finde ich nicht schlecht und macht die Fehlersuche einfacher.

Die einzige andere Möglichkeit wäre zu mappen was zu mappen geht laut Vorlage und alles was nicht gefunden wird dann als Raw Reading anzuzeigen.
Macht trotzdem die suche bei Setter Fehlern die schon gemappt werden schwieriger als dein Vorschlag.

Viele Grüße,
Stefan

[Roger]

Hi,
wie ich schrieb:

Meine Vorstellungen wären:
- Readingsnamen können individuell angepasst werden
- auch Namen der set und get Befehle können angepasst werden

Diese Anpassungsmöglichkeiten wären für mich wichtig. Die konkrete Umsetzung (in einem Device vs. Töchter) wäre mir egal.

@Stefan: Wenn man vitoconnect_raw_readings setzt, dann geht (wenn ich es richtig verstanden habe) kein vitoconnect_mappings mehr? Richtig? Dann könnte ich die Readingsnamen nicht mehr anpassen und ein (derzeitiges) set <name> heating.dhw.operating.modes.active/commands/setMode wäre mich auch zu lang/speziell/unlesbar/... 

//Roger

[Beta-User]

"Generisch" ist vermutlich übertrieben, aber hier mal der Link: https://github.com/rejoe2/FHEM/blob/vitoconnect-new-client/98_vitoconnect.pm

Da sind die Roger/svn-set-Kommandos schon zusammen geschoben, eigentlich sollte man m.E. ein umgekehrtes mapping verwenden und damit in den generischen set-Code gehen.

[stefanru]

Ok, danke!
Ich schaue es mir bei Gelegenheit mal an.
Bei mir ist einfach viel los zur Zeit

Gruß,
Stefan

[Beta-User]

...ist ja auch nicht dringend, und die Änderungen sind schon eher umfangreich...

Zur Orientierung:
Der Zweig "vitoconnect-new" (als diff: https://github.com/rejoe2/FHEM/compare/master...vitoconnect-new.diff) enthält die Änderungen, die man für das "weekprofile"-Feature benötigt nebst einiger Dinge, die mir im allgemeinen Coding aufgefallen waren.

Der neue Zweig "vitoconnect-new-client" (als diff: https://github.com/rejoe2/FHEM/compare/vitoconnect-new...vitoconnect-new-client.diff) bringt (ausgehend davon) dann die ersten Vorbereitungen, die man braucht, um das mit "Kindern" bzw. einer "confFile" (pro Kind, statt mapping-Attributen) zu lösen.

Bitte melden, falls Fragen dazu sind .

[stefanru]

Ok, ich schaue mir das als nächstes mal an und gebe Rückmeldung.
Danke!

Gruß,
Stefan

[Beta-User]

Moin, new news...

Bin etwas weiter gekommen mit den "Kindern", die angehängte Version kann:
- Mappings per Datei laden (JSON-Format, die bisherigen mappings Roger und svn anbei). Damit könnte das confFile-Attribut die bisherigen Mapping-Attribute ersetzen, und ich würde auch dafür votieren, "translations" zu eliminieren.
- Die setter der Kinder werden dynamisch aus den Reading/setter-Namen des "Servers" abgeleitet, im Moment geht alles, für das es ein Mapping gibt, zuzüglich der anderen, zum "subset" passenden, dynamisch erzeugten settern des "Servers".

Was (noch) NICHT geht:
- Aktualisieren der Readings aus dem "Server" heraus (das wäre der nächste Teilschritt)
- Reload der setter der Kinder bei Änderung der mapping-Datei ("eigentlich" sollte die via FHEMWEB als editierbar angezeigt werden...)

So wird ein "Kind" angelegt und auf "Roger"-Mapping eingestellt:

Code Auswählen Erweitern

defmod Therme_Roger vitoconnect IODev=Therme_Vi subset=circuits.0
attr Therme_Roger confFile ./conf/vitoconnect_roger.mapping

Wäre nett, wenn Rückmeldung dazu käme...

[stefanru]

Hi,

Ok, das klingt super!
Bin jetzt über den Feiertag weg, danach auch nochmal Urlaub       
Tut mir leid dass ich gerade nicht viel beitragen kann.
Aber sobald ich etwas Zeit habe schaue ich es mir gern an.

Ja vitoconnect_translations und vitoconnect_mappings kann man aus meiner Sicht entfernen. Die würden dann nicht mehr gebraucht.
Wenn ich das richtig verstehe würde ich dann also User mit nur Raw Readings einfach nur pro Anlage einen Server definieren?
Also in meinem Fall 2 da ich WP und Öl Brenner habe, also wie bisher?
Ich könnte dann für Mappings Kinder anlegen, muss es aber nicht, richtig?

Danke und Gruß,
Stefan

[Beta-User]

Ok, das klingt super!

Danke erst mal für die Rückmeldung!

Bin jetzt auch erst mal ein paar Tage weg bzw. schlecht verfügbar.

Wenn ich das richtig verstehe würde ich dann also User mit nur Raw Readings einfach nur pro Anlage einen Server definieren?

Wenn ich das richtig sehe, braucht man pro "vitoconnect_serial" ein "Server"-Device. Nach meiner jetzigen Denke würde ich dort dann keine mapping-Optionen mehr sehen, alle mappings wären dann ausschließlich an den "Kindern" zu finden.

Also in meinem Fall 2 da ich WP und Öl Brenner habe, also wie bisher?

Wenn das nicht "circuits.0" und "circuits.1" sind, mit gemeinsamer WW-Aufbereitung (?), dann schon, ansonsten könnte man einen Server haben und z.B. die drei Teil-Bereiche WP, Öl-Brenner und WW-Aufbereitung je als "Kind" anlegen - mit "ganz einfachen" Reading-Namen wie "desired-temp" und "meassured-temp", "temperature" usw.
Auch "weekprofile" würde ich dann auf die "Kinder" beschränken?

Ich könnte dann für Mappings Kinder anlegen, muss es aber nicht, richtig?

"Kinder" wären keine Pflicht, aber dann gibt es "nur" raw-Readings am "Server"-Device. Hintergrund: du hattest m.E. zurecht darauf hingewiesen, dass man den Usern klarmachen muss, dass es einen Unterschied zwischen "schönen" FHEM-Readings und support bei Viessmann gibt .

Ja vitoconnect_translations und vitoconnect_mappings kann man aus meiner Sicht entfernen. Die würden dann nicht mehr gebraucht.

Generell würde ich den Code dann mal versuchen zu vereinfachen. Ist halt "gefahrgeneigt". Vielleicht wäre es übergangsweise eine gute Idee, das Ding einzupacken, dann kann man recht zwanglos erst mal parallel mit beiden Versionen arbeiten? Man muss dann halt ggf. das jeweils andere deaktivieren.

Und ich bin auch weiter am Rätseln, ob es nicht sinnvoll wäre, das mit den "Kindern" und dem mapping als "generischen Client" im Sinne des zweistufigen Modulkonzepts anzulegen.
Mal sehen, Rom und so...

[Beta-User]

So, nächster Zwischenschritt - noch nicht wirklich voll getestet, manche "Sperren" fehlen auch noch, aber die Übernahme der Readings in meinem "Testkind" sieht erst mal gut aus...
Anbei das komplette Paket.

[stefanru]

Hi Beta-User,

vielen Dank.
Leider komme ich gerade nicht zum Testen.
Sobald ich etwas Luft habe schaue ich es mir an.

Gruß,
Stefan

[Beta-User]

Moin, keine Eile...

Vielleicht noch ein paar Anmerkungen:

Mein "Server" ist (anonymisiert) so definiert:

Code Auswählen Erweitern

defmod Therme_Vi vitoconnect user=address@server.de interval=60(Man kann die ganze Konfiguration via "define" eingeben, das ist dann das, was übrig bleibt).

Und dann hier ein Beispiel, wie eines der "Kinder" aussehen könnte:

Code Auswählen Erweitern

define Therme_Warmwasser vitoconnect IODev=Therme_Vi subset=dhw
attr Therme_Warmwasser confFile ./conf/vitoconnect_dhw.mapping
attr Therme_Warmwasser group Heizung
attr Therme_Warmwasser icon sani_therme_on1
attr Therme_Warmwasser room Heizung
#   .FhemMetaInternals 1
#   .sets      unknown value ?, choose one of clearReadings:noArg weekprofile heating.dhw.hygiene.activate:noArg heating.dhw.hygiene.disable:noArg heating.dhw.hygiene.trigger.startHour:slider,0,1,23 heating.dhw.hygiene.trigger.startMinute:slider,0,10,50 heating.dhw.oneTimeCharge.activate:noArg heating.dhw.oneTimeCharge.deactivate:noArg oneTimeCharge_active mode:balanced,off heating.dhw.schedule.resetSchedule:noArg schedule:textField-long heating.dhw.temperature.hygiene.value:slider,10,1,85 desired-temp:slider,10,1,60
#   CONFIGFILE ./conf/vitoconnect_dhw.mapping
#   DEF        IODev=Therme_Vi subset=dhw
#   FUUID      681af173-f33f-d171-b317-9bcd7525292e848b
#   FVERSION   0.8.7
#   NAME       Therme_Warmwasser
#   NOTIFYDEV  global
#   NR         695
#   NTFY_ORDER 50-Therme_Warmwasser
#   SERVER     Therme_Vi
#   STATE      on
#   TYPE       vitoconnect
#   eventCount 56
#   subset     dhw
#   .attraggr:
#   .attrminint:
#   HELPER:
#     PACKAGE    main
#     VERSION    0.8.7
#     VERSION_API unused
#     VERSION_CTZ unused
#     VERSION_ErrCodes unused
#     VERSION_SMUtils 1.28.3
#   OLDREADINGS:
#   READINGS:
#     2025-05-07 08:43:58   active          1
#     2025-05-07 08:43:58   desired-temp    45
#     2025-05-07 08:43:58   energy_gas_day  0.3
#     2025-05-07 08:43:58   energy_gas_lastMonth 12.3
#     2025-05-07 08:43:58   energy_gas_lastSevenDays 2.6
#     2025-05-07 08:43:58   energy_gas_lastyear 0
#     2025-05-07 08:43:58   energy_gas_month 2.6
#     2025-05-07 08:43:58   energy_gas_year 36
#     2025-05-07 08:43:58   energy_power_day 0
#     2025-05-07 08:43:58   energy_power_lastMonth 0.7
#     2025-05-07 08:43:58   energy_power_lastSevenDays 0.1
#     2025-05-07 08:43:58   energy_power_lastYear 0
#     2025-05-07 08:43:58   energy_power_month 0.1
#     2025-05-07 08:43:58   energy_power_year 1.9
#     2025-05-07 08:43:58   hygiene_enabled 0
#     2025-05-07 08:43:58   measured-temp   49.4
#     2025-05-07 08:43:58   mode            balanced
#     2025-05-07 08:43:58   oneTimeCharge_active 0
#     2025-05-07 08:43:58   schedule        [{"mon":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"mon":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"mon":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"mon":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"tue":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"tue":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"tue":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"tue":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"wed":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"wed":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"wed":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"wed":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"thu":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"thu":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"thu":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"thu":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"fri":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"fri":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"fri":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"fri":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"sat":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"sat":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"sat":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"sat":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"sun":{"mode":"on","start":"05:30","end":"22:00","position":0}}]
#     2025-05-07 08:43:58   schedule_active 1
#     2025-05-07 08:43:58   state           on
#   helper:
#     mappings:
#       heating.dhw.active active
#       heating.dhw.hygiene.enabled hygiene_enabled
#       heating.dhw.oneTimeCharge.active oneTimeCharge_active
#       heating.dhw.operating.modes.active.value mode
#       heating.dhw.operating.modes.balanced.active 0
#       heating.dhw.operating.modes.off.active 0
#       heating.dhw.schedule.active schedule_active
#       heating.dhw.schedule.entries schedule
#       heating.dhw.sensors.temperature.dhwCylinder.status 0
#       heating.dhw.sensors.temperature.dhwCylinder.value measured-temp
#       heating.dhw.sensors.temperature.hotWaterStorage.status 0
#       heating.dhw.sensors.temperature.hotWaterStorage.value 0
#       heating.dhw.sensors.temperature.outlet.status 0
#       heating.dhw.status state
#       heating.dhw.temperature.main.value desired-temp
#       heating.gas.consumption.dhw.day 0
#       heating.gas.consumption.dhw.dayValueReadAt 0
#       heating.gas.consumption.dhw.month 0
#       heating.gas.consumption.dhw.monthValueReadAt 0
#       heating.gas.consumption.dhw.week 0
#       heating.gas.consumption.dhw.weekValueReadAt 0
#       heating.gas.consumption.dhw.year 0
#       heating.gas.consumption.dhw.yearValueReadAt 0
#       heating.gas.consumption.summary.dhw.currentDay energy_gas_day
#       heating.gas.consumption.summary.dhw.currentMonth energy_gas_month
#       heating.gas.consumption.summary.dhw.currentYear energy_gas_year
#       heating.gas.consumption.summary.dhw.lastMonth energy_gas_lastMonth
#       heating.gas.consumption.summary.dhw.lastSevenDays energy_gas_lastSevenDays
#       heating.gas.consumption.summary.dhw.lastYear energy_gas_lastyear
#       heating.power.consumption.dhw.day 0
#       heating.power.consumption.dhw.dayValueReadAt 0
#       heating.power.consumption.dhw.month 0
#       heating.power.consumption.dhw.monthValueReadAt 0
#       heating.power.consumption.dhw.week 0
#       heating.power.consumption.dhw.weekValueReadAt 0
#       heating.power.consumption.dhw.year 0
#       heating.power.consumption.dhw.yearValueReadAt 0
#       heating.power.consumption.summary.dhw.currentDay energy_power_day
#       heating.power.consumption.summary.dhw.currentMonth energy_power_month
#       heating.power.consumption.summary.dhw.currentYear energy_power_year
#       heating.power.consumption.summary.dhw.lastMonth energy_power_lastMonth
#       heating.power.consumption.summary.dhw.lastSevenDays energy_power_lastSevenDays
#       heating.power.consumption.summary.dhw.lastYear energy_power_lastYear
#     sets:
#       desired-temp heating.dhw.temperature.main.value
#       mode       heating.dhw.operating.modes.active.value
#       oneTimeCharge_active heating.dhw.oneTimeCharge.active
#       schedule   heating.dhw.schedule.entries
#
setstate Therme_Warmwasser on
setstate Therme_Warmwasser 2025-05-07 08:43:58 active 1
setstate Therme_Warmwasser 2025-05-07 08:43:58 desired-temp 45
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_gas_day 0.3
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_gas_lastMonth 12.3
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_gas_lastSevenDays 2.6
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_gas_lastyear 0
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_gas_month 2.6
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_gas_year 36
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_power_day 0
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_power_lastMonth 0.7
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_power_lastSevenDays 0.1
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_power_lastYear 0
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_power_month 0.1
setstate Therme_Warmwasser 2025-05-07 08:43:58 energy_power_year 1.9
setstate Therme_Warmwasser 2025-05-07 08:43:58 hygiene_enabled 0
setstate Therme_Warmwasser 2025-05-07 08:43:58 measured-temp 49.4
setstate Therme_Warmwasser 2025-05-07 08:43:58 mode balanced
setstate Therme_Warmwasser 2025-05-07 08:43:58 oneTimeCharge_active 0
setstate Therme_Warmwasser 2025-05-07 08:43:58 schedule [{"mon":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"mon":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"mon":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"mon":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"tue":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"tue":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"tue":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"tue":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"wed":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"wed":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"wed":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"wed":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"thu":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"thu":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"thu":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"thu":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"fri":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"fri":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"fri":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"fri":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"sat":{"mode":"on","start":"05:50","end":"08:00","position":0}},{"sat":{"mode":"on","start":"12:00","end":"13:50","position":1}},{"sat":{"mode":"on","start":"17:00","end":"19:40","position":2}},{"sat":{"mode":"on","start":"21:50","end":"23:00","position":3}},{"sun":{"mode":"on","start":"05:30","end":"22:00","position":0}}]
setstate Therme_Warmwasser 2025-05-07 08:43:58 schedule_active 1
setstate Therme_Warmwasser 2025-05-07 08:43:58 state on

Die entsprechende mapping-file ist in vorigen Beitrag drin, damit alles beieinander ist, wie man (vielleicht) sieht, kann man damit auch Readings aktiv ausblenden, die eigentlich zum "subset" des "Kinds" gehören. Mir kommt das Device im Ergebnis einigermaßen übersichtlich vor .

Das weekproflie-feature habe ich damit noch nicht getestet, aber das sollte kein Problem sein .

[Beta-User]

Mal zur Abwechslung eine Frage zu den raw-Readings und den betreffenden settern als solchen:
Bisher habe ich mich im Prinzip nur damit befaßt, wie man das, was da ist "umverpacken" und (imo) besser gliedern kann (letzteres mit den "subset-Kindern"). Das "Master-JSON" im ".response_xxx"-Internal und dessen Auswertung sind daher ein neues Thema, bislang wurde einfach erst mal "durchgereicht", was da war.

Es gibt da drin ja Optionen, die per "activate" bzw. "deactivate" geschaltet werden können, manchmal (aber eher selten?) gekoppelt/gedoppelt (?) mit "setActive".
Wäre es nicht sinnvoll, das irgendwie so (generisch) zu vereinheitlichen, dass man nur eine Info und einen set-Befehl dafür generiert?

Und dann gibt es da als "deprecated" gemarkerte Infos drin. Wäre es nicht sinnvoll, die direkt (auch als Reading) zu ignorieren?
Ist bzgl. set in Teilen schon drin, zumindest gibt es einen Hinweis, dass wegen "noDemand" ein sort ausgeführt wird, aber "see below" erschließt sich mir dann nicht so richtig. Das "next" bei "setLevels" hat damit wohl auch nichts zu tun, ist eher das fehlende "isExecutable", das dann effektiv den setter ausknippst?