FHEM Forum

Breaking-Change

Beta-User und ich sind dabei einen Breaking Change vorzubereiten.
Der Standard im Modul wird vitoconnect_raw_readings.
Die Umstellung wird in 3 Wochen erfolgen.

Ab jetzt hat jeder drei Wochen Zeit, sich Gedanken darüber zu machen, wie er weiter verfahren möchte:

Entweder auf SVN umstellen, wenn die neue Version gezogen wird.
Oder auf RAW Readings umsteigen und die Änderungen mitmachen.

Es sollte klar sein, dass RAW Readings die Hauptentwicklungslinie sein wird.
Ja, die Readings sind länger, aber man kann sie mit stateformat (ich werde auch meine Templates bereitstellen) oder im TabletUI an seine Wünsche anpassen.

Ein großer Vorteil ist, dass die Readings im Device denen in der API entsprechen.
Das bedeutet, wenn man ein Problem hat, kann man direkt mit diesen Namen im Viessmann-Forum nachfragen.
Viessmann und alle anderen wissen dann genau, worüber man sprichst.

Auch wird eine Änderung der Viessmann API sich direkt auswirken.
Somit erhält man direkt neue Viessmann Readings, ohne Anpassungen am Code beziehungsweise den alten Mappings.


Ab hier die weiter gültige Beschreibung des Moduls, das neue Verhalten der Attribute wird im Wiki dokumentiert.

Vitoconnect - Verbesserte Version

Zusammenfassung der Änderungen:

• 14.12.2024:
    - Einführung der Versionsnummer.
    - Code-Optimierungen und Sortierung der Schlüssel pro Reading, um sicherzustellen, dass Leistungs-Readings in der richtigen Reihenfolge sind (Tag vor Tageswert).
  
• 12.12.2024:
    - Set_New nur erlaubt, wenn bei mehreren Gateways die Seriennummer angegeben ist.
    - Objekt- und Hash-Werte in Array-Readings integriert (z.B. device.messages.errors.raw).
    - Bei abgelaufenem Token (jede Stunde) werden unnötige Gateway-Aufrufe vermieden, nur neuer Token wird geholt. Dies spart API-Aufrufe und reduziert die API-Überlastung.
  
• 06.12.2024: Interner Timer entfernt, wenn das Gerät definiert oder neu definiert wird.
  
• 05.12.2024: Fehler behoben, logResponseOnce-Flag nach einem Lauf entfernt.
  
• 04.12.2024: getResource angepasst, um Gateway beim ersten Versuch zu lesen, unnötige API-Aufrufe bei fehlender Gateway-Seriennummer vermieden. Timer bei mehreren Gateways korrigiert.
  
• 02.12.2024: Tagesleistungs-Readings werden nun unter .asSingleValue gespeichert. Daten kommen sporadisch von der API, Funktion trägt sie nach und ermöglicht das Erstellen von Graphen.
  
• 01.12.2024: Statisches Mapping von SVN übernommen, Fehlerbehandlung bei vitoconnect_action verbessert, Parameter vitoconnect_mapping_roger hinzugefügt, um Rogers Mapping zu nutzen. RequestLists nach SVN und Roger aufgespalten, neue Subroutine vitoconnect_Set_Roger.
  
• 30.11.2024: Mehrere neue Readings hinzugefügt (z.B. HK1_Betriebsart:active,standby,heating,dhw,dhwAndHeating,forcedReduced,forcedNormal). Wenn Setter mit ok aufgerufen wird, wird der Wert auch im Reading gesetzt.
  
• 16.11.2024: Änderungen für Hybridanlagen mit 2 Gateways und eigenem Mapping der Werte. Mehrere Gateways werden abgefragt, Readings oder gedumpte Dateien haben als Suffix die Gateway-Seriennummer. Neues Attribut vitoconnect_serial ermöglicht die Festlegung einer spezifischen Gateway-Seriennummer. Unterschiedliche Abfrageintervalle für verschiedene Geräte möglich. Eigenes Mapping und Translation für Werte implementiert. Fehlerbehandlung und Initialisierung von installationFeatures überarbeitet, alle Subroutinen sind nun non-blocking. Attribut model entfernt, da nicht verwendet. vitoconnect_gw_readings und vitoconnect_actions_active implementiert. Set für RAW-Readings dynamisch wie möglich gestaltet. Beschreibungen für Attribute im WebUI angepasst. Keine Umlaute in Heizkreisnamen verwenden.
  

Neue Attribute:

• vitoconnect_serial:
    - Ermöglicht die Festlegung einer spezifischen Gateway-Seriennummer, die fortan allein abgerufen werden soll. Dies ermöglicht es, für jeden Gateway ein separates vitoconnect-Gerät anzulegen oder alle Readings in einem Gerät zu verwalten.
  
• vitoconnect_mapping_roger:
    - Parameter, um Rogers Mapping zu nutzen. Dies ermöglicht die Verwendung eines spezifischen Mappings für die Daten.
  
• vitoconnect_gw_readings:
    - Wenn auf 1 gesetzt, werden die internen Readings in Readings gespeichert. Wenn auf 0 gesetzt, werden sie nicht gespeichert.  Dies ermöglicht eine dynamische Handhabung der Aktionen basierend auf den JSON-Daten.
  
• vitoconnect_actions_active:
    - Setter im JSON werden als reading.setURI gespeichert.
  

Motivation:
Ich habe eine Heizungsanlage von Viessmann eingebaut bekommen, eine Hybridanlage VitoCal250 AH mit Vitoladens 300C und einem Pufferspeicher Vitocell 120E inklusive Frischwasserstation Vitotrans 353. Ich wollte die Daten der Anlage auswerten und setzen können, aber sie hat zwei Gateways, einen für den VitoCal und einen für den VitoLadens. Das ging mit dem alten Modul nicht.

Ich wollte FHEM auch etwas zurückgeben, da ich von vielen großartigen Modulen schon profitiert habe.
Ein besonderer Dank geht an @DS_Starter, der mir des öfteren geholfen hat wenn ich nicht weiter gekommen bin.
Dessen Modul für SolarForecast finde ich hervorragend. Für jeden mit Solaranlage ein muss  ;)


Das verbesserte Modul ist abwärtskompatibel zu der SVN VErsion und zu Rogers Version.
Ich empfehle aber Raw Readings zu verwenden da ihr nur dann auch die Raw Setter bekommt die dynamisch aus dem JSON erstellt werden.

Das Modul bekommt ihr zur Zeit noch von meinem Git.
https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm (https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm)
Ich empfehle eine Neustart von FHEM da es bei einem Sprung von dem alten auf das neue Modul sonst Probleme mit dem Timer geben kann.

Ich bin dabei das Modul hier zu übernehmen und hoffentlich auch als Verantwortlicher dann hier ins SVN einchecken zu können, so dass ihr es dann mit dem normalen Update bekommt.

Also testet es bitte etwas und lasst mal Rückmeldung da ab es so eingecheckt werden kann.

Viele Grüße,
Stefan

Ich nutze Dein verbessertes Modul seit ein paar Tagen und möchte mich recht herzlich für all Deine Bemühungen bedanken!

Eingestellt habe ich "vitoconnect_mapping_roger 0" und seither funktioniert das Auslesen sowie Einstellen meiner Vitocal 252A so wie ich es mir wünsche. Aufgefallen ist mir nur das ältere Datum der Version (FVERSION 98_vitoconnect.pm:v0.2.0-s26738/2022-11-23).

Hi Karl,

danke für das Feedback.
Ja das mit dem Versions ist noch normal, v0.2.0 ist aktuell. Das Datum ist das Datum der letzten Version inm SVN.
Sobald ich ins SVN einchecke taucht dort dann auch das richtige Datum auf.

Eine kleine Rückfrage, musstest du vitoconnect_mapping_roger = 0 explizit setzen?
Ein Löschen des Attributes hat nicht ausgereicht?

Gruß,
Stefan

Ich hatte das Attribut händisch gesetzt - habe nicht abgewartet was sich ohne dessen Setzen tut.

Ok, alles klar danke!

Guten Morgen @stefanru,

vielen vielen Dank für Deine Arbeit! Ich nutze das Modul schon seit beginn an und habe heute morgen auch auf Deine verbesserte Version umgestellt.
Hat auch alles gleich Problemlos geklappt. Wollte nur mal danke sagen ;D.

Hi es gibt eine neue Version.
Nun sind die Beschreibungstexte auf dem UI in Deutsch und Englisch verfügbar.
Liegt wie am Anfang beschrieben auf meinem Git.

Gruß,
Stefan

Hi,

und wieder eine neue Version:
Fix setter new for cases where more than one gateway is actively pulled in 2 devices.

Die Devices haben ihre Setter gegenseitig überschrieben.
Dies ist nun behoben.

Gruß,
Stefan

@stefanru:
Ich habe mir die noch fehlenden Readings mal genauer angesehen. Eigentlich wollte ich diese nun übersetzen aber das ist nicht nötig. 99% davon gibt es bereits als Übersetzung.
Beispiel: heating.circuits.1.name.name = HK1-Name

Jetzt ist die Frage, warum ich diese quasi doppelt angezeigt bekomme oder ob das normal ist.
Anbei mal ein Readings und Attribut List (Die SN habe ich geändert):
   READINGS:
     2024-12-18 22:30:18   Aktion_Status   OK: HK2-Betriebsart standby
     2024-12-19 13:37:45   Aktive_Heizkreise 0,1
     2024-12-19 13:37:45   Aussen_Status   connected
     2024-12-19 13:37:45   Aussentemperatur 8.5
     2024-12-19 13:37:45   Brenner_1_Betriebsstunden 18747
     2024-12-19 13:37:45   Brenner_1_Modulation 0
     2024-12-19 13:37:45   Brenner_1_Starts 15742
     2024-12-19 13:37:45   Brenner_1_aktiv 0
     2024-12-19 13:37:45   Gasverbrauch_Heizung/Jahr 1252.5,3731.9
     2024-12-19 13:37:45   Gasverbrauch_Heizung/Jahr_gelesen_am 2024-12-19T10:59:52.000Z
     2024-12-19 13:37:45   Gasverbrauch_Heizung/Monat 159.3,210.7,77.3,0,0,0.1,8.2,7.4,90,159.1,194.3,346.1,264.5
     2024-12-19 13:37:45   Gasverbrauch_Heizung/Monat_gelesen_am 2024-12-19T10:59:52.000Z
     2024-12-19 13:37:45   Gasverbrauch_Heizung/Tag 1.6,7.8,5.9,6.4,8.4,10.9,11.6,10.1
     2024-12-19 13:37:45   Gasverbrauch_Heizung/Tag_gelesen_am 2024-12-19T10:59:52.000Z
     2024-12-19 13:37:45   Gasverbrauch_Heizung/Woche 21.7,66,61.7,51.1,75.8,38.1,43.2
     2024-12-19 13:37:45   Gasverbrauch_Heizung/Woche_gelesen_am 2024-12-19T10:59:52.000Z
     2024-12-19 13:37:45   Gasverbrauch_Total/Jahr 1489.8,4022.3
     2024-12-19 13:37:45   Gasverbrauch_Total/Jahr_gelesen_am 2024-12-19T09:55:49.000Z
     2024-12-19 13:37:45   Gasverbrauch_Total/Monat 178.2,242,95.5,15.2,13.3,14.9,25.7,26.1,110.3,183,214.5,370.7,288.3
     2024-12-19 13:37:45   Gasverbrauch_Total/Tag 2.2,8.9,7.7,7.4,9.4,11.9,12.3,11.3
     2024-12-19 13:37:45   Gasverbrauch_Total/Tag_gelesen_am 2024-12-19T09:55:49.000Z
     2024-12-19 13:37:45   Gasverbrauch_Total/Woche 26.2,72.9,67.8,59.3,83.4,45.5,50.8
     2024-12-19 13:37:45   Gasverbrauch_Total/Woche_gelesen_am 2024-12-19T09:55:49.000Z
     2024-12-19 13:37:45   Gasverbrauch_WW/Jahr 237.3,290.4
     2024-12-19 13:37:45   Gasverbrauch_WW/Jahr_gelesen_am 2024-12-19T09:55:49.000Z
     2024-12-19 13:37:45   Gasverbrauch_WW/Monat 18.9,31.3,18.2,15.2,13.3,14.8,17.5,18.7,20.3,23.9,20.2,24.6,23.8
     2024-12-19 13:37:45   Gasverbrauch_WW/Monat_gelesen_am 2024-12-19T09:55:49.000Z
     2024-12-19 13:37:45   Gasverbrauch_WW/Tag 0.6,1.1,1.8,1,1,1,0.7,1.2
     2024-12-19 13:37:45   Gasverbrauch_WW/Tag_gelesen_am 2024-12-19T09:55:49.000Z
     2024-12-19 13:37:45   Gasverbrauch_WW/Woche 4.5,6.9,6.1,8.2,7.6,7.4,7.6
     2024-12-19 13:37:45   Gasverbrauch_WW/Woche_gelesen_am 2024-12-19T09:55:49.000Z
     2024-12-19 13:37:45   HK1-Betriebsart heating
     2024-12-19 13:37:45   HK1-Frostschutz_Status off
     2024-12-19 13:37:45   HK1-Heizkurve-Niveau 1
     2024-12-19 13:37:45   HK1-Heizkurve-Steigung 1.2
     2024-12-19 13:37:45   HK1-Name        Heizkoerper
     2024-12-19 13:37:45   HK1-Programmstatus normal
     2024-12-19 13:37:45   HK1-Solltemperatur_Anforderung unknown
     2024-12-19 13:37:45   HK1-Solltemperatur_SummerEco_aktiv 0
     2024-12-19 13:37:45   HK1-Solltemperatur_aktiv 1
     2024-12-19 13:37:45   HK1-Solltemperatur_comfort 23
     2024-12-19 13:37:45   HK1-Solltemperatur_comfort_Anforderung unknown
     2024-12-19 13:37:45   HK1-Solltemperatur_comfort_aktiv 0
     2024-12-19 13:37:45   HK1-Solltemperatur_eco_aktiv 0
     2024-12-19 13:37:45   HK1-Solltemperatur_normal 21
     2024-12-19 13:37:45   HK1-Solltemperatur_reduziert 18
     2024-12-19 13:37:45   HK1-Solltemperatur_reduziert_Anforderung unknown
     2024-12-19 13:37:45   HK1-Solltemperatur_reduziert_aktiv 0
     2024-12-19 13:37:45   HK1-Standby_aktiv 0
     2024-12-19 13:37:45   HK1-Typ         heatingCircuit
     2024-12-19 13:37:45   HK1-Vorlauftemperatur 36.5
     2024-12-19 13:37:45   HK1-Vorlauftemperatur_aktiv connected
     2024-12-19 13:37:45   HK1-Zeitsteuerung_Heizung {"thu":[{"mode":"normal","end":"22:30","start":"07:00","position":0}],"wed":[{"mode":"normal","end":"22:30","start":"07:00","position":0}],"sat":[{"start":"07:00","position":0,"mode":"normal","end":"22:30"}],"tue":[{"start":"07:00","position":0,"mode":"normal","end":"22:30"}],"sun":[{"end":"22:30","mode":"normal","start":"07:00","position":0}],"fri":[{"start":"07:00","position":0,"end":"22:30","mode":"normal"}],"mon":[{"mode":"normal","end":"22:30","position":0,"start":"07:00"}]}
     2024-12-19 13:37:45   HK1-Zeitsteuerung_Heizung_aktiv 1
     2024-12-19 13:37:45   HK1-Zirkulationspumpe on
     2024-12-19 13:37:45   HK1-ZoneMode_aktive 0
     2024-12-19 13:37:45   HK1-aktiv       1
     2024-12-19 13:37:45   HK1-forcedLastFromSchedule_aktiv 0
     2024-12-19 13:37:45   HK1-heizen_aktiv 1
     2024-12-19 13:37:45   HK2-Betriebsart standby
     2024-12-19 13:37:45   HK2-Frostschutz_Status off
     2024-12-19 13:37:45   HK2-Heizkurve-Niveau 0
     2024-12-19 13:37:45   HK2-Heizkurve-Steigung 0.9
     2024-12-19 13:37:45   HK2-Name        Fussbodenheizung
     2024-12-19 13:37:45   HK2-Programmstatus standby
     2024-12-19 13:37:45   HK2-Solltemperatur_Anforderung unknown
     2024-12-19 13:37:45   HK2-Solltemperatur_SummerEco_aktiv 0
     2024-12-19 13:37:45   HK2-Solltemperatur_aktiv 0
     2024-12-19 13:37:45   HK2-Solltemperatur_comfort 23
     2024-12-19 13:37:45   HK2-Solltemperatur_comfort_Anforderung unknown
     2024-12-19 13:37:45   HK2-Solltemperatur_comfort_aktiv 0
     2024-12-19 13:37:45   HK2-Solltemperatur_eco_aktiv 0
     2024-12-19 13:37:45   HK2-Solltemperatur_normal 22
     2024-12-19 13:37:45   HK2-Solltemperatur_reduziert 18
     2024-12-19 13:37:45   HK2-Solltemperatur_reduziert_Anforderung unknown
     2024-12-19 13:37:45   HK2-Solltemperatur_reduziert_aktiv 0
     2024-12-19 13:37:45   HK2-Standby_aktiv 1
     2024-12-19 13:37:45   HK2-Typ         heatingCircuit
     2024-12-19 13:37:45   HK2-Vorlauftemperatur 24.5
     2024-12-19 13:37:45   HK2-Vorlauftemperatur_aktiv connected
     2024-12-19 13:37:45   HK2-Zeitsteuerung_Heizung {"tue":[{"mode":"normal","end":"22:30","position":0,"start":"07:00"}],"sun":[{"mode":"normal","end":"22:30","start":"07:00","position":0}],"fri":[{"mode":"normal","end":"22:30","start":"07:00","position":0}],"mon":[{"mode":"normal","end":"22:30","start":"07:00","position":0}],"thu":[{"mode":"normal","end":"22:30","position":0,"start":"07:00"}],"wed":[{"end":"22:30","mode":"normal","position":0,"start":"07:00"}],"sat":[{"mode":"normal","end":"22:30","start":"07:00","position":0}]}
     2024-12-19 13:37:45   HK2-Zeitsteuerung_Heizung_aktiv 0
     2024-12-19 13:37:45   HK2-Zirkulationspumpe off
     2024-12-19 13:37:45   HK2-ZoneMode_aktive 0
     2024-12-19 13:37:45   HK2-aktiv       1
     2024-12-19 13:37:45   HK2-forcedLastFromSchedule_aktiv 0
     2024-12-19 13:37:45   HK2-heizen_aktiv 0
     2024-12-19 13:37:45   Kessel_Common_Supply connected
     2024-12-19 13:37:45   Kessel_Common_Supply_Temperatur 37
     2024-12-19 13:37:45   Kessel_Seriennummer 123456
     2024-12-19 13:37:45   Kessel_Solltemperatur 20
     2024-12-19 13:37:45   Stromverbrauch_Heizung/Jahr 312.5,688.1
     2024-12-19 13:37:45   Stromverbrauch_Heizung/Monat 26.3,41,38.3,3.4,3.5,6.4,13.8,16.6,32.5,41.1,40.2,48.8,45.2
     2024-12-19 13:37:45   Stromverbrauch_Heizung/Tag 0.6,1.3,1.2,1.3,1.3,1.4,1.5,1.4
     2024-12-19 13:37:45   Stromverbrauch_Heizung/Woche 4.4,9.7,10.1,9.1,10.2,8.7,9.2
     2024-12-19 13:37:45   Stromverbrauch_Total/Jahr 327.5,705.7
     2024-12-19 13:37:45   Stromverbrauch_Total/Jahr_gelesen_am 2024-12-18T23:01:07.000Z
     2024-12-19 13:37:45   Stromverbrauch_Total/Monat 27.4,43.8,39.4,4.2,4.3,7.2,14.8,17.6,33.6,42.3,41.2,50.1,46.4
     2024-12-19 13:37:45   Stromverbrauch_Total/Monat_gelesen_am 2024-12-18T15:34:39.000Z
     2024-12-19 13:37:45   Stromverbrauch_Total/Tag 0,1.3,1.3,1.3,1.5,1.5,1.4,1.3
     2024-12-19 13:37:45   Stromverbrauch_Total/Tag_gelesen_am 2024-12-17T18:07:17.000Z
     2024-12-19 13:37:45   Stromverbrauch_Total/Woche 2.6,9.9,10.1,9.5,10.3,8.8,9.5
     2024-12-19 13:37:45   Stromverbrauch_Total/Woche_gelesen_am 2024-12-17T18:07:17.000Z
     2024-12-19 13:37:45   Stromverbrauch_WW/Jahr 15,17.6
     2024-12-19 13:37:45   Stromverbrauch_WW/Monat 1.7,2.8,1.1,0.8,0.8,0.8,1,1,1.1,1.2,1,1.3,1.2
     2024-12-19 13:37:45   Stromverbrauch_WW/Tag 0,0.1,0,0,0.1,0,0,0
     2024-12-19 13:37:45   Stromverbrauch_WW/Woche 0.1,0.2,0,0.4,0.1,0.1,0.3
     2024-12-19 13:37:45   Urlaub_Ende     
     2024-12-19 13:37:45   Urlaub_Start   
     2024-12-19 13:37:45   Urlaub_aktiv    0
     2024-12-19 13:37:45   WW-Haupttemperatur 52
     2024-12-19 13:37:45   WW-Isttemperatur 47.8
     2024-12-19 13:37:45   WW-Sensoren_Auslauf_Status connected
     2024-12-19 13:37:45   WW-Sensoren_Auslauf_Wert 33
     2024-12-19 13:37:45   WW-Status       on
     2024-12-19 13:37:45   WW-Temperatur_aktiv connected
     2024-12-19 13:37:45   WW-Zeitplan     {"fri":[{"mode":"on","end":"23:00","position":0,"start":"07:00"}],"mon":[{"start":"07:00","position":0,"end":"22:30","mode":"on"}],"sun":[{"end":"22:00","mode":"on","position":0,"start":"08:30"}],"tue":[{"end":"22:30","mode":"on","start":"07:00","position":0}],"sat":[{"end":"23:00","mode":"on","position":0,"start":"08:30"}],"thu":[{"position":0,"start":"07:00","end":"22:30","mode":"on"}],"wed":[{"position":0,"start":"07:00","end":"22:30","mode":"on"}]}
     2024-12-19 13:37:45   WW-Zirkulationspumpe_Status on
     2024-12-19 13:37:45   WW-Zirkulationspumpe_Zeitplan {"wed":[{"start":"07:00","position":0,"mode":"on","end":"22:00"}],"thu":[{"mode":"on","end":"22:00","start":"07:00","position":0}],"sat":[{"position":0,"start":"08:00","end":"23:00","mode":"on"}],"mon":[{"position":0,"start":"07:00","mode":"on","end":"22:00"}],"fri":[{"mode":"on","end":"23:00","position":0,"start":"07:00"}],"tue":[{"start":"07:00","position":0,"mode":"on","end":"22:00"}],"sun":[{"mode":"on","end":"22:00","position":0,"start":"08:00"}]}
     2024-12-19 13:37:45   WW-Zirkulationspumpe_Zeitsteuerung_aktiv 1
     2024-12-19 13:37:45   WW-aktiv        1
     2024-12-19 13:37:45   WW-einmaliges_Aufladen 0
     2024-12-19 13:37:45   WW-zeitgesteuert_aktiv 1
     2024-12-19 13:37:45   device.messages.errors.raw.entries
     2024-12-19 13:37:45   device.serial.value 123456
     2024-12-19 13:37:45   heating.burners.enabled 0
     2024-12-19 13:37:45   heating.circuits.0.name.name Heizkoerper
     2024-12-19 13:37:45   heating.circuits.0.operating.programs.reducedEnergySaving.active 0
     2024-12-19 13:37:45   heating.circuits.0.operating.programs.reducedEnergySaving.demand heating
     2024-12-19 13:37:45   heating.circuits.0.operating.programs.reducedEnergySaving.reason unknown
     2024-12-19 13:37:45   heating.circuits.1.name.name Fussbodenheizung
     2024-12-19 13:37:45   heating.circuits.1.operating.programs.reducedEnergySaving.active 0
     2024-12-19 13:37:45   heating.circuits.1.operating.programs.reducedEnergySaving.demand heating
     2024-12-19 13:37:45   heating.circuits.1.operating.programs.reducedEnergySaving.reason unknown
     2024-12-19 13:37:45   heating.dhw.hygiene.active 0
     2024-12-19 13:37:45   heating.dhw.hygiene.enabled 1
     2024-12-19 13:37:45   heating.dhw.hygiene.trigger.startHour 3
     2024-12-19 13:37:45   heating.dhw.hygiene.trigger.startMinute 0
     2024-12-19 13:37:45   heating.dhw.hygiene.trigger.weekdays Sun,Mon,Tue,Wed,Thu,Fri,Sat
     2024-12-19 13:37:45   heating.dhw.operating.modes.active.value balanced
     2024-12-19 13:37:45   heating.dhw.operating.modes.balanced.active 1
     2024-12-19 13:37:45   heating.dhw.operating.modes.off.active 0
     2024-12-19 13:37:45   heating.dhw.sensors.temperature.dhwCylinder.status connected
     2024-12-19 13:37:45   heating.dhw.sensors.temperature.dhwCylinder.value 47.8
     2024-12-19 13:37:45   heating.dhw.temperature.hygiene.value 65
     2024-12-19 13:37:45   heating.gas.consumption.summary.dhw.currentDay 0.6
     2024-12-19 13:37:45   heating.gas.consumption.summary.dhw.currentMonth 18.9
     2024-12-19 13:37:45   heating.gas.consumption.summary.dhw.currentYear 237.3
     2024-12-19 13:37:45   heating.gas.consumption.summary.dhw.lastMonth 31.3
     2024-12-19 13:37:45   heating.gas.consumption.summary.dhw.lastSevenDays 7.2
     2024-12-19 13:37:45   heating.gas.consumption.summary.dhw.lastYear 290.4
     2024-12-19 13:37:45   heating.gas.consumption.summary.heating.currentDay 1.6
     2024-12-19 13:37:45   heating.gas.consumption.summary.heating.currentMonth 159.3
     2024-12-19 13:37:45   heating.gas.consumption.summary.heating.currentYear 1252.5
     2024-12-19 13:37:45   heating.gas.consumption.summary.heating.lastMonth 210.7
     2024-12-19 13:37:45   heating.gas.consumption.summary.heating.lastSevenDays 52.6
     2024-12-19 13:37:45   heating.gas.consumption.summary.heating.lastYear 3731.9
     2024-12-19 13:37:45   heating.power.consumption.dhw.dayValueReadAt 2024-12-17T23:01:36.000Z
     2024-12-19 13:37:45   heating.power.consumption.dhw.monthValueReadAt 2024-12-18T23:01:07.000Z
     2024-12-19 13:37:45   heating.power.consumption.dhw.weekValueReadAt 2024-12-17T23:01:36.000Z
     2024-12-19 13:37:45   heating.power.consumption.dhw.yearValueReadAt 2024-12-18T23:01:07.000Z
     2024-12-19 13:37:45   heating.power.consumption.heating.dayValueReadAt 2024-12-19T12:21:57.000Z
     2024-12-19 13:37:45   heating.power.consumption.heating.monthValueReadAt 2024-12-19T12:21:57.000Z
     2024-12-19 13:37:45   heating.power.consumption.heating.weekValueReadAt 2024-12-19T12:21:57.000Z
     2024-12-19 13:37:45   heating.power.consumption.heating.yearValueReadAt 2024-12-19T12:21:57.000Z
     2024-12-19 13:37:45   heating.power.consumption.summary.dhw.currentDay 0
     2024-12-19 13:37:45   heating.power.consumption.summary.dhw.currentMonth 1.7
     2024-12-19 13:37:45   heating.power.consumption.summary.dhw.currentYear 15
     2024-12-19 13:37:45   heating.power.consumption.summary.dhw.lastMonth 2.8
     2024-12-19 13:37:45   heating.power.consumption.summary.dhw.lastSevenDays 0.6
     2024-12-19 13:37:45   heating.power.consumption.summary.dhw.lastYear 17.6
     2024-12-19 13:37:45   heating.power.consumption.summary.heating.currentDay 0.6
     2024-12-19 13:37:45   heating.power.consumption.summary.heating.currentMonth 26.3
     2024-12-19 13:37:45   heating.power.consumption.summary.heating.currentYear 312.5
     2024-12-19 13:37:45   heating.power.consumption.summary.heating.lastMonth 41
     2024-12-19 13:37:45   heating.power.consumption.summary.heating.lastSevenDays 8.8
     2024-12-19 13:37:45   heating.power.consumption.summary.heating.lastYear 688.1
     2024-12-19 13:37:45   heating.sensors.volumetricFlow.allengra.status connected
     2024-12-19 13:37:45   heating.sensors.volumetricFlow.allengra.value 1263
     2024-12-19 13:37:45   holidayAtHome_Ende
     2024-12-19 13:37:45   holidayAtHome_Start
     2024-12-19 13:37:45   holidayAtHome_aktiv 0
     2024-12-09 15:30:24   ownstateHk1     on
     2024-12-19 13:37:45   ownstateHk2     off
     2024-12-19 13:37:45   state           last update: 2024-12-19 13:37:45
Attributes:
   disable    0
   event-min-interval ownstateHk2:60
   event-on-change-reading (?!state)(?!HK2-Zeitsteuerung_Heizung)(?!HK1-Zeitsteuerung_Heizung)(?!WW-Zirkulationspumpe_Zeitplan)(?!WW-Zeitplan).*
   event-on-update-reading ownstateHk2,Brenner_1_Modulation,HK1-Vorlauftemperatur,HK2-Vorlauftemperatur,WW-Isttemperatur,HK2-Betriebsart,Aussentemperatur
   group      Server
   room       f_server
   userReadings ownstateHk2:HK2-Betriebsart:.* {ReadingsVal("$name","HK2-Betriebsart","standby") eq "standby" ? "off" : "on"},
ownstateHk1:HK1-Betriebsart:.* {ReadingsVal("$name","HK1-Betriebsart","standby") eq "standby" ? "off" : "on"}

Hi @87insane,

das mit dem Namen kenne ich.
Die Viessmann API liefert bei mir da auch sowohl ein Reading heating.circuits.1.name als auch eins mit heating.circuits.1.name.name.
Das 2te könnte man unterdrücken wenn gewünscht, sieht eh ein bisschen nach einem API Bug aus.

Wenn ich mir deine weiteren Readings anschaue fehlt eine Übersetzung für alle dhw (WarmWasser Readings).
Die kannst du mir gerne liefern.

Es hilft auch mal in das resources.json im FHEM log zu schauen.
Da siehst du genau was die API liefert. Z.b. siehst du da die doppelten namen Readings.

Wenn du genau schaust glaube ich das tatsächlich für die ganzen Readings ein Mapping fehlt. Entweder weil dhw oder weil es doch etwas anderes ist als das jetzt schon gemappte.
Wenn du mal anfängst ein Mapping zu erstellen können wir nachher über die unklaren nochmal drüber schauen.

Ich denke wir bekommen das dann alles gemapped.

Du möchtest das SVN mapping erweitern richtig?

Danke und Gruß,
Stefan

Für WW ist doch bis auf die Hygiene Geschichte auch alles vorhanden.
Die ganzen Statistik-Werte sind mir eigentlich egal. Die stimmen so oder so nicht. Das ist alles irgendwie errechnet und für nichts zu gebrauchen. Da hilft nur Zähler ablesen.

Ggf. macht es Sinn, gewisse Readings ausschalten zu können, da hast du Recht.

Ich will die Warmwasserbereitung dann einschalten, wenn mein Stromanbieter günstige Stundentarife anbietet (hourly-Tarif). Mit "set vitoconnect WW-einmaliges_Aufladen activate" kann ich das auch erfolgreich einschalten. Meine Vitocal252A heizt aber deswegen noch lange nicht das Warmwasser auf, weil der Wert der WW-Hysterese (bzw. heating.dhw.temperature.hysteresis.switchOnValue) noch zu hoch ist (Beispiel: 04:30 Uhr, Hysterese 7, WW-Ist-Temp 44°, WW-Soll-Temp 49° --> nichts; klar, erst wenn in diesem Fall die WW-Ist-Temp unter 42° fällt wird tatsächlich WW aufheizt).

Könnte ich den Wert für WW-Hysterese auf "4" setzten, so würde sie im obigen Fall das WW aufheizen --> meine Frage: kann die WW-Hysterese einstellbar gemacht werden?

@87insane: Ich schaue mir die Readings nochmal an, aber ich denke schon dass das alles nicht gemappt ist.
Wenn es dir nur darum geht die raw readings für diese nicht gemappten readings zu verstecken ist das einfach umzusetzen und ich kann ein Attribute liefern dass dies bewerkstelligt.

@kkoenig: Das ist schon setzbar. Wahrscheinlich aber in keinem der Mappings enthalten.
Wenn du es unbedingt gemapped haben willst kann ich das einbauen.
Aber wenn Viessmann was ändert geht es wieder nicht.
Deshalb hatte ich gesagt man soll wenn möglich mit raw readings arbeiten.
Dann hat man automatisch alle Setter dynamisch erzeugt.
Im Anhang ein Screenshot meiner Setter, inklusive DHW hysterese, ich habe eine Vitocal 250 AH.


Gruß,
Stefan

Das das nicht gemappt ist, sehe ich ja. Aber die Frage ist ob man das wirklich braucht. Die ganzen errechneten Werte sind nutzlos. Einstellen kann ich dank deiner Verbesserungen auch alles. Ich bin rundum glücklich. Das ist nun nur noch Schönheit.

Hi @87insane,

freut mich, dass du mit dem Modul zufrieden bist.
Klar, das braucht man nicht alles.
Ich baue gern ein dass man die Raw Readings auch ganz ausblenden kann, das ist nicht viel Arbeit.

Eine kleine Frage ich habe oft gelesen dass die Leistungswerte der Wärmepumpe nicht stimmen.
Weißt du wie weit sie abweichen?
Ich habe mir deswegen schon einen Shelly besorgt mit dem ich die echte Leistungsaufnahme messen will.
Ich frage mich aber woher bekomme ich die Wärmeleistungsabgabe um auch den COP zu berechnen?
Die Wärmeleistung kann ich doch nur von der Wärmepumpe bekommen?

Danke und Gruß,
Stefan

P.S.: Habe es dir eingebaut, neues Attribut heißt vitoconnect_disable_raw_readings.
Könntest du es für mich bei dir testen?
Einfach das Attribut auf 1 stellen und einmal alle Readings löchen mit clearReadings.
Beim nächsten Abruf sollten die raw readings nicht mehr auftauchen.

Im Anhang die Version, stelle sie auf GIT sobald sie getestet wurde.

Danke und Gruß,
Stefan

Zitat von: stefanru am 19 Dezember 2024, 17:41:26...

@kkoenig: Das ist schon setzbar...
Aber wenn Viessmann was ändert geht es wieder nicht.
Deshalb hatte ich gesagt man soll wenn möglich mit raw readings arbeiten.
Dann hat man automatisch alle Setter dynamisch erzeugt.
...

Danke Stefan! Das war mir nicht klar - jetzt funktionierts auch bei mir.

Danke fürs Feedback, Karl.

Ja ich kann nur alle ermutigen auf RAW Readings zu switchen.
Hier ist der Haupt Entwicklungsaufwand reingeflossen um eben die API dynamisch auszuwerten und auch die Setter dynamisch zu erstellen.
D.h. selbst wenn Viessmann nun etwas an der API Struktur ändert oder neue Readings oder Setter hinzunimmt, es wird direkt automatisch erzeugt.
Natürlich nur solange sie nicht die komplette Syntax der API umkrempeln.
Aber in dem Rahmen wartet sich das Modul selbst. Und das geht eben nur mit RAW Readings.

Auch finde ich sie gut wiederzufinden oder wenn man im Viessmann Forum etwas diskutieren möchte sind es eben diese Namen die bekannt sind und nicht irgendwas gemapptes.

Will man die Namen in einer Readingsgroup oder auf Tablet UI anzeigen kann man sie eh dann dort auf etwas Mappen das einem gefällt.

Auch weiterhin habe ich vor die meiste Entwicklung und Wartung in dem Bereich der Raw Readings zu tätigen, das ist für mich die Zukunftsfähige Programmierung für das Modul.


Danke und Gruß,
Stefan

Zu Danken haben wir Nutzer Deines Moduls für Deinen Einsatz:)

Deine Frage nach den Leisungswerten der WP ist sehr berechtigt. Was die WP hier liefert ist mM eigentlich nur Unsinn, selbst die Addition ist falsch. Vielleicht sind hier bei der WP thermische Werte gemeint? - Aber das kann es auch nicht sein, denn in ViCare stehen andere Werte.

Ich habe einen Shelly davor und der zeigt mir einen ganz anderen Wert an. Siehe screenshot: die WP zeigt mir gerade 33.5kWh (Gesamt heating.power.consumption.total.day.asSingleValue = Wasser heating.power.consumption.dhw.day.asSingleValue + Wärme heating.power.consumption.heating.day.asSingleValue), der Shelly EM3 15.81 (berechnet anhand gestrigem Gesamtwert um 23:59), und letzterem glaube ich jedenfalls mehr. (Das SVG der WP ist heute unvollständig - vor 12h habe ich auf die RAW Readings umgestellt)

Hi Karl,

danke für die Antwort.
Und super du verwendest genau das Setup das ich auch noch installieren will, also ein Shelly zur Überwachung.

Jetzt würde mich etwas interessieren.
Die Shelly Werte hast du sicher pro Tag?

Bei den Consumption Readings musst du aber aufpassen, sie werden von der API stark verzögert geliefert. D.h. 1-3 Tage verzögert.
Der Wert passt dann aber genau zu ViCare und ViGuide zum passenden Tag.
Deshalb habe ich diese Reading eingeführt: heating.power.consumption.total.day.asSingleValue.
Bei diesem Reading schreibe ich von der API gelieferte Werte mit dem korrekten Zeitstempel im Reading weg.
Also das ist kein aktueller Wert sondern immer von den Tagen die die API gerade liefert. Ich schreibe nur komplette Tage weg und dann immer mit dem Zeitstempel Tag 23:59:59.
Heißt du musst auf den Zeitstempel achten um die richtigen Tage zu vergleichen.
Man kann den Wert gut in Plots anzeigen und es sollte dann so aussehen (auch bei mir startet es erst vor ein paar Tagen).
Screenshot 2024-12-20 164632.png

Wäre jetzt wirklich für mich interessant wie sich diese Werte im Vergleich zum Shelly verhalten.

Danke und Gruß,
Stefan

Super. Dass die Werte nicht fortlaufend geschrieben werden können habe ich auch erkannt.

Hier ein kurzer kWh-Vergleich ViCare/Shelly (23:59 Uhr):

17.12.: 15.9 / 19.0600000000013
18.12.: 23.3 / 26.2099999999991
19.12.: 28.7 / 31.380000000001

Die kWh-Werte aus dem Modul hatte ich nicht gelogt. Es scheint mir die Relation zu stimmen, aber nicht der Wert. Meine ursprüngliche Schätzung von rund 10% zu wenig kann passen. In meinem einfachen SVG sieht das so aus:

Ah super, der Graph sieht gut aus und ähnliche Idee wie meine.
Vergleich Verbrauch und Außentemp ;-)

Ich habe mal bei mir geschaut, mein Zwischenzähler für die WP zeigt 2535 kWh und die WP selbst sagt 2750 kWh.
Sind bei mir auch ca. 10% aber in die andere Richtung?
Das ist seltsam.
Der Zähler ist geeicht da ich damit im Haus die Stromkosten für die WP bestimmen muss.

Vielleicht liegts auch an dem genauen Modell und der verbauten Zähler. Habe die VitoCal 250AH.
Oder an der Software Version, habe 2404.

Danke und Gruß,
Stefan

Ich denke der unterschiedliche Stromverbrauch liegt wohl an der Firmware. Bei mir die veralterte 2324. Und über die Updatepolitik von Viessmann möchte ich mich hier nicht auslassen :-(

Heute hat meine VitoCal 252-A-16 zwar die Warmwasserbereitung wunschgemäß bei niedrigen Strompreisen gemacht, aber verzögert (siehe screenshot von ViGuide). Dafür kann das Modul nichts, das ist einfach die WP. Ich muss dabei mit dem DOIF noch mehr testen.

Zitat von: stefanru am 19 Dezember 2024, 21:27:01Hi @87insane,

freut mich, dass du mit dem Modul zufrieden bist.
Klar, das braucht man nicht alles.
Ich baue gern ein dass man die Raw Readings auch ganz ausblenden kann, das ist nicht viel Arbeit.

Eine kleine Frage ich habe oft gelesen dass die Leistungswerte der Wärmepumpe nicht stimmen.
Weißt du wie weit sie abweichen?
Ich habe mir deswegen schon einen Shelly besorgt mit dem ich die echte Leistungsaufnahme messen will.
Ich frage mich aber woher bekomme ich die Wärmeleistungsabgabe um auch den COP zu berechnen?
Die Wärmeleistung kann ich doch nur von der Wärmepumpe bekommen?

Danke und Gruß,
Stefan

P.S.: Habe es dir eingebaut, neues Attribut heißt vitoconnect_disable_raw_readings.
Könntest du es für mich bei dir testen?
Einfach das Attribut auf 1 stellen und einmal alle Readings löchen mit clearReadings.
Beim nächsten Abruf sollten die raw readings nicht mehr auftauchen.

Im Anhang die Version, stelle sie auf GIT sobald sie getestet wurde.

Danke und Gruß,
Stefan

Hey,

inwieweit die Werte bei einer WP abweichen weiß ich nicht. Ich selber habe eine Gas Therme. Aber auch hier ist es immer anders. Daher sind diese Werte für mich nutzlos.

Ich habe die Test Version eingespielt, FHEM restart und mal ein Update gemacht. Leider bekomme ich mit aktiviertem vitoconnect_disable_raw_readings
gar keine Readings mehr. Stelle ich das auf 0 und mache ein Update, sehe ich wieder alles.

Hi @87insane,

dann habe ich deine Anfrage falsch verstanden.

Ich dachte du wolltest nur die im Mapping enthaltenen Werte und gar keine Raw Readings mehr?
Wie genau soll das Verhalten sein?

@kkoeniger:
Das Verhalten habe ich bei mir auch schon beobachtet.
Trotz Anfrage zur einmaligen Warmwasserbereitung ist nichts passiert.
Ich bin mir noch nicht sicher ob es nur bei der Anfrage durch die API nicht passiert oder auch bei Anfrage aus der App.
Aber ja das scheint ein Fehler zu sein und müsste man mal im Viessmann Forum melden.

Ich hatte dann mal die gewünschte Warmwasser Temperatur um 5 Grad erhöht so dass er aufheizen muss. Das schien funktioniert zu haben und er hat warmes Wasser gemacht.
Das ist aber natürlich nicht wirklich was man tun will.

Gruß,
Stefan

Hi @87insane,

sorry hatte nicht aufmerksam genug gelesen.
Es hatte gar keine Updates der Readings mehr gegeben, verstanden ;-)

Habe den Fehler gefunden und eine neue Version erstellt.
Kannst du bitte nochmal testen?

Danke und Gruß,
Stefan

Guten Morgen @stefanru,

ich habe gerade bemerkt, dass ich doch noch ein Problem mit dem Modul habe. Ich hatte seither (mit dem alten Modul) immer per Sprachbefehl eine Speicherladung starten lassen. Gestern ging das dann plötzlich nicht mehr und dabei habe ich gesehen, dass bei mir keine Setter erzeugt wurden.

Ich habe das Attribut vitoconnect_raw_readings auf 1 gesetzt, clearReadings und logResponseOnce duchgeführt. Es kommen auch sofort alle Readings - nur habe ich eben keine Setter. Verstehe ich es richtig, dass sie eigentlich dynamisch erzeugt werden sollten?


Ich habe eine Vitodens 300 mit vitoconnect Opto1. Was mit aufgefallen ist, dass sich device.serial.value = heating.boiler.serial.value sind aber ungleich heating.controller.serial.value.

Hast Du eine Idee, was ich falsch mache?

Vielen Dank im Vorraus.

--- Edit:
Hat sich erledigt - obwohl ich nur eine Vitodens 300 habe, musste ich vitoconnect_serial setzen. Die Seriennummer hatte ich dann aus der Datei device_xxx.json genommen ("gatewaySerial"), die nach dem logResponseOnce erzeugt wurde (falls jemand noch das gleiche Problem hat).

Hi @mthome,

das ist ja interessant.
Also hat er irgendwie die falsche Serial verwendet und erkennt 2 Gateways?

Bei einem Device versuche ich das eigentlich automatisch zu ermitteln.
Für mich interessant wären alle json Files deiner Anlage bevor du die Serial gesetzt hast.
Kannst du mir gern per PM zukommen lassen.
Dann könnte ich das vielleicht auch automatisch richtig machen.
Danke!

@87insane
Hattest du Zeit die letzte Version mal zu testen und zu schauen ob es für dich passt?

Gruß und Danke,
Stefan

Hi @mthome,

hier eine Debug Version wie in der PM besprochen.

Danke fürs helfen!

Hi,

Ich konnte einen Bug bei den Raw Settern finden.
Hat man nur eine Serial wurden die Setter nicht automatisch erzeugt, nur nach setzen dieser Serial.
Er hatte sich eingeschlichen als ich das Abspeichern für mehrere Serials implementiert habe.
Danke @mthome fürs bereitstellen der Infos nach Aufspielen der Debug Version.

Hier die neue Version mit dem Fix und einer Verbesserung beim benutzen von activate/deactivate settern.
Außerdem ein neues Attribut nach Wunsch von @87insane.

Changelog:
  "0.4.0"  => "28.12.2024  Fixed setNew to work again automatically in case of one serial in gateways,".
                           "for more than one serial you have to define the serial you want to use".
  "0.3.2"  => "27.12.2024  Set in case of activate and deactivate request the active value of the reading".
  "0.3.1"  => "19.12.2024  New attribute vitoconnect_disable_raw_readings".

Die Version liegt in meinem GIT.
https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm


Da wir mittlerweile eine ziemlich stabile Version haben die abwärtskompatibel geblieben ist werde ich mich mal darum kümmern ob wir sie ins FHEM SVN einchecken können.

Danke und Gruß,
Stefan

@stefanru,

getestet und funktioniert einwandfrei  ;D - vielen Dank!!!

Hi,

mir sind beim Starten von FHEM ein paar unschöne Meldungen aufgefallen die durch die letzten Änderungen hinein kamen.
Auch habe ich den neuen Setter gedubgged und mir ein paar mehr Logausgaben eingebaut.

Changelog:
Bug fixes, fixed Releasenotes, changed debugging texts and messages in Set_New

Neue Version wie immer in meinem GIT.
https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm

Gruß,
Stefan

Hallo,
vielen Dank für deine Arbeit !!
Habe noch ein kleines Problem:
 Ich habe  2 Gateways OPTO 1 und OPTO2.
Jtzt wird das 7571381712920100 Gateway nicht angezeigt, das 7637415024100242 wird komplett angezeigt:

{"cursor":{"next":""},"data":[{"serial":"7637415024100242","version":"2.50.3.0","firmwareUpdateFailureCounter":0,"autoUpdate":false,"createdAt":"2024-02-29T13:53:53.296Z","producedAt":"2024-02-29T13:53:53.290Z","lastStatusChangedAt":"2024-12-30T14:03:07.643Z","aggregatedStatus":"Error","targetRealm":"DC","gatewayType":"VitoconnectOPTO2","installationId":2788865,"registeredAt":"2024-11-27T12:07:39.909Z","description":null,"otaOngoing":false},{"serial":"7571381712920100","version":"2.8.0.0","firmwareUpdateFailureCounter":0,"autoUpdate":false,"createdAt":"2016-12-06T20:12:53.333Z","producedAt":"2016-12-06T12:40:49.000Z","lastStatusChangedAt":"2025-01-01T11:43:13.651Z","aggregatedStatus":"WorksProperly","targetRealm":"DC","gatewayType":"VitoconnectOptolink","installationId":175606,"registeredAt":"2019-05-21T15:44:31.378Z","description":null,"otaOngoing":false}]}

Mir ist auch aufgefallen, wenn ich 7571381712920100 bei vitoconnect_serial eingebe, bekomme ich die Meldung:
device {"viErrorId":"req-c7b2b02333b448b3be4201ce22a44774","statusCode":404,"errorType":"GATEWAY_NOT_FOUND","message":"GATEWAY_NOT_FOUND","extendedPayload":{}}

state Device not found: Optolink prüfen!

Hi Freibeuter,

das sieht irgendwie so aus als ob er nur eine Gateway sieht.
Hast du in der APP beide Gateways?
Setze bitte mal vitoconnect_gw_readings = 1 und schicke das Reading "gw" und "number_of_gateways".

Und kannst du mir bitte folgende Files aus dem FHEM Log Verzeichnis schicken zur Analyse?
Die Files bitte erstellen wenn keine Serial eingetragen ist und ein LogResponceOnce am Device ausführen.
gw.json => Hier sollten alle Gateways die er sieht und die erreichbar sind aufgelistet werden.
device_[serial].json => hier werden pro Serial die erreichbaren Devices gelistet.

Gruß,
Stefan

Hallo, vielen Dan k für dein Hilfe!
unter GW sieht er beide Gateways:
gw:
{"cursor":{"next":""},"data":[{"serial":"7637415024100242","version":"2.50.3.0","firmwareUpdateFailureCounter":0,"autoUpdate":false,"createdAt":"2024-02-29T13:53:53.296Z","producedAt":"2024-02-29T13:53:53.290Z","lastStatusChangedAt":"2024-12-30T14:03:07.643Z","aggregatedStatus":"Error","targetRealm":"DC","gatewayType":"VitoconnectOPTO2","installationId":2788865,"registeredAt":"2024-11-27T12:07:39.909Z","description":null,"otaOngoing":false},{"serial":"7571381712920100","version":"2.8.0.0","firmwareUpdateFailureCounter":0,"autoUpdate":false,"createdAt":"2016-12-06T20:12:53.333Z","producedAt":"2016-12-06T12:40:49.000Z","lastStatusChangedAt":"2025-01-01T11:51:00.083Z","aggregatedStatus":"WorksProperly","targetRealm":"DC","gatewayType":"VitoconnectOptolink","installationId":175606,"registeredAt":"2019-05-21T15:44:31.378Z","description":null,"otaOngoing":false}]}


In der App und im iobroker Adapter sind beide Anlagen erreichbar.
Logfiles kommen gleich
Gruß Peter

die Logfiles

Hi Peter,

ok deine gw.json sieht ganz normal aus und er versucht auch beide zu rufen.

Aber bei dem GW mit 7571381712920100 bekommt er nichts mehr zurück:
$VAR1 = {
          'viErrorId' => 'req-c3871e3d2e244574b0b8e9bcc0199683',
          'extendedPayload' => {},
          'statusCode' => 404,
          'message' => 'GATEWAY_NOT_FOUND',
          'errorType' => 'GATEWAY_NOT_FOUND'
        };

Hmmm, das kenne ich so jetzt auch nicht. Du hast die ganze Anlage in einem Account?

Für den Gateway Call benötigt er die Installation ID, vielleicht hast du hier mehrere? Schicke mir mal noch die installation.json.
Mehrere Installations waren so nicht vorgesehen, müsste ich mir in deinen Daten ansehen ob man da leicht was bauen kann.

Mache bitte auch mal ein logResponseOnce mit Verbose 4 und schicke mir die Logausgabe, vielleicht kann ich da noch etwas erkennen.

Danke und Gruß,
Stefan

Es handelt sich um 2 Anlagen an 2 Standorten.

Logfile:
2025.01.01 21:17:13 4: Vitoconnect - getCodeCallback went ok
2025.01.01 21:17:13 4: Vitoconnect - code: pmifDU76vdgDzNEm1IrS-ZpiUuDQtxJ1skhjuAH3jeU
2025.01.01 21:17:14 4: Vitoconnect - getAccessTokenCallback went ok
2025.01.01 21:17:14 4: Vitoconnect - Access Token: eyJraWQiOiI0ZWNhM2Vk...
2025.01.01 21:17:14 4: Vitoconnect - getGwCallback went ok
2025.01.01 21:17:14 3: Vitoconnect Datei: log/log/gw.json geschrieben
2025.01.01 21:17:14 4: Vitoconnect - getInstallationCallback went ok
2025.01.01 21:17:14 3: Vitoconnect Datei: log/log/installation.json geschrieben
2025.01.01 21:17:14 4: Vitoconnect - getDeviceCallback went ok
2025.01.01 21:17:14 3: Vitoconnect Datei: log/log/device_7571381712920100.json geschrieben
2025.01.01 21:17:14 4: Vitoconnect - getFeatures went ok
2025.01.01 21:17:14 4: Vitoconnect - getDeviceCallback went ok
2025.01.01 21:17:14 3: Vitoconnect Datei: log/log/device_7637415024100242.json geschrieben
2025.01.01 21:17:14 4: Vitoconnect - getFeatures went ok
2025.01.01 21:17:15 1: Vitoconnect,vitoconnect_getFeatures: Fehler während Gateway features:  :: {
  "viErrorId": "|1cb3a25a-478cc16ba42428b3.",
  "statusCode": 404,
  "errorType": "GATEWAY_NOT_FOUND",
  "message": "Gateway not found",
  "extendedPayload": {}
}
2025.01.01 21:17:15 4: Vitoconnect - statusCode: 404 errorType: GATEWAY_NOT_FOUND message: Gateway not found error:
2025.01.01 21:17:15 1: Vitoconnect - Device not found: Optolink prüfen!
2025.01.01 21:17:15 4: Vitoconnect - enter getResourceOnce
2025.01.01 21:17:15 4: Vitoconnect - access_token: eyJraWQiOiI0ZWNhM2Vk...
2025.01.01 21:17:15 4: Vitoconnect - installation: 2788865
2025.01.01 21:17:15 4: Vitoconnect - gw: 7637415024100242

Oh wow, ja das ist es.
2 Standorte, also 2 Installations.
Das war im Modul nie vorgesehen.


Man benötigt isntallation ID + Serial für die Calls.

Als installation ID wird zur Zeit im Modul nur die erste aus installation.json genommen.
Man sollte sie aber passend zur serial aus dem GW.json nehmen, den installations Call kann man sich quasi sparen, oder nur zu debug Zwecken.

Vielen Dank erstmal für die Infos!

Das ist aber leider schon etwas Arbeit.
Die Endgültige Lösung wird ein Umbau bei dem InstallationID zusammen mit der Serial aus dem GW.json geholt wird.
Das ganze ist komplizierter weil jetzt kann man ja pro Installation wieder mehrere Geräte haben.
Da muss ich einiges abändern.

Ich schaue mal ob ich kurzfristig dir etwas bauen kann, dass du isntallationID und serial im Device einfach mitgeben kannst und es die eingelesenen überschreibt.
Damit könnte ich kurzfristig dir ein Lösung bieten.
Wäre das erstmal ausreichend?

Bin bald in Urlaub und den großen Umbau werde ich davor nicht schaffen.

Danke und Gruß,
Stefan

Ich freue mich über jede Zwischenlösung und es drängt nicht ! :-)

PS, ich lösche hier die Dateien wieder, da sie etwas zu viel persönliche Daten enthalten :-)

Klar kein Problem,

eine Version habe ich gerade gemacht, teste noch kurz und lade sie gleich hier hoch, dann kannst du sie testen.

Eine Frage, da du auch ioBroker erwähnst, dir ist klar das die API beschränkte Calls hat (1450 pro Tag).
Wenn du mit mehreren Servicen dort anfragst verbrauchst du dementsprechend mehr API Calls.

Gruß,
Stefan

Hi Peter,

siehe den Post oben drüber wegen API Calls.

Hier ist nun eine Version, in der du das Attribut vitoconnect_installationID eingeben kannst.
Das bedeutet, du erstellst zwei Geräte in FHEM, eines für jedes Gerät/Installation.

In jedem Gerät spezifizierst du vitoconnect_serial und vitoconnect_installationID.
Diese müssen natürlich zueinander passen.
Bei mir sah das gut aus und hat funktioniert.

Mit zwei Geräten solltest du das Intervall nicht unter 120 Sekunden setzen.
Wenn du auch noch beide Geräte in IOBroker mit einem Intervall abrufst, passe das Intervall entsprechend an.
Ich denke, 240 Sekunden pro Gerät wären das Maximum, wenn du vier mal abrufst (2xIOBroker, 2xFHEM).
Jeder Geräte Call ist immer ein API Call.

Wenn du es erfolgreich testest, kommt es so ins GIT und später auch ins FHEM-Repo.
Ich kann es auch schon in FHEM einchecken, möchte es aber erst nach meinem Urlaub angehen.

Ausblick und Überlegungen:
Einen Fix, der alles automatisch erkennt, werde ich mir überlegen.
Aber da muss man mal nachdenken, da es sehr unübersichtlich wird, wenn jedes Reading dann _[installationsID]_[serial] hat.
Wenn man davon ausgeht, dass Serials immer eindeutig sind, kann man die installationsID auch wieder weglassen.
Man müsste nur die Daten Serial und installationsID zusammen ablegen und intern verarbeiten.
Naja, wie gesagt, ich denke mir etwas aus.

Gruß,
Stefan

Hallo Stefan,
ein herzliches Dankeschön, klappt alles 1A.
Danke auch für den Hinweis mit den Zeiten, werde jedoch nur mit FHEM arbeiten, iobroker war nur ein Test, woran das Problem lag.
Dir einen schönen Urlaub !
Peter

Hi Peter,

danke fürs testen.

Es gibt wieder eine neue Version im Git mit folgenden Änderungen:

Added attribute installationID, in case you use more than one installation, see https://forum.fhem.de/index.php?msg=1329165",
Small fix for Vitoladens 300C, heating.circuits.0.operating.programs.comfort",

Gruß,
Stefan

Frage, gibts ein Reading zum Stromverbrauch einer Wärmepumpe z.b. ?

Ja es gibt readings, aber sie kommen sehr verspätet und manchmal muss man das Kommunikations Modul durchstarten damit überhaupt wieder was kommt. Ist im Viessmann Forum so auch bekannt.
Die Readings beginnen alle mit:
heating.power.consumption
Ich erstelle eines zum loggen und Anzeigen das auch Nachträge sobald wieder Daten kommen. Geht bis zu einer Woche nachträglich.
Diese Readings heißen z.b.
heating.power.consumption.heating.day.asSingleValue

Sorry bin in Urlaub, deshalb nur kurz vom Handy.

Gruß,
Stefan

Be

Hmm, hab neueste Version, aber kann das reading nicht finden.

Hi satprofi,

bin wieder zurück ;-)

Welche Wärmepumpe hast du denn?
Ich sehe, dass bei dir die Werte fehlen.

Kannst du mir, nur um auf Nummer sicher zu gehen, die resource.json Datei aus deinem FHEM Log Verzeichnis schicken?

Ich habe eine VitoCal 250 und da kommen folgende Werte:
heating.power.consumption.dhw.day
heating.power.consumption.dhw.day.asSingleValue
heating.power.consumption.dhw.dayValueReadAt
heating.power.consumption.dhw.month
heating.power.consumption.dhw.monthValueReadAt
heating.power.consumption.dhw.week
heating.power.consumption.dhw.weekValueReadAt
heating.power.consumption.dhw.year
heating.power.consumption.dhw.yearValueReadAt
heating.power.consumption.heating.day
heating.power.consumption.heating.day.asSingleValue
heating.power.consumption.heating.dayValueReadAt
heating.power.consumption.heating.month
heating.power.consumption.heating.monthValueReadAt
heating.power.consumption.heating.week
heating.power.consumption.heating.weekValueReadAt
heating.power.consumption.heating.year
heating.power.consumption.heating.yearValueReadAt
heating.power.consumption.summary.dhw.currentDay
heating.power.consumption.summary.dhw.currentMonth
heating.power.consumption.summary.dhw.currentYear
heating.power.consumption.summary.dhw.lastMonth
heating.power.consumption.summary.dhw.lastSevenDays
heating.power.consumption.summary.dhw.lastYear
heating.power.consumption.summary.heating.currentDay
heating.power.consumption.summary.heating.currentMonth
heating.power.consumption.summary.heating.currentYear
heating.power.consumption.summary.heating.lastMonth
heating.power.consumption.summary.heating.lastSevenDays
heating.power.consumption.summary.heating.lastYear
heating.power.consumption.total.day
heating.power.consumption.total.day.asSingleValue
heating.power.consumption.total.dayValueReadAt
heating.power.consumption.total.month
heating.power.consumption.total.monthValueReadAt
heating.power.consumption.total.week
heating.power.consumption.total.weekValueReadAt
heating.power.consumption.total.year
heating.power.consumption.total.yearValueReadAt

Im Viessmann Forum gibt es hier einen Thread zu den Power Werten der Vitocal.
https://community.viessmann.de/t5/The-Viessmann-API/API-liefert-Verbrauchswerte-nicht-mehr/td-p/445412
Es gibt wohl auch einen Hack über einen nicht offiziell bereit gestellten Endpoint.
Die Frage ist wie lange so etwas geht. Kann ich mir aber mal anschauen.

Aber lass uns erstmal schauen warum du die offiziellen Daten nicht bekommst.


Gruß,
Stefan

Hallo.
Anbei die datei, Vitocal 200-s

Hi Satprofi,

ich habe mir dein JSON angeschaut, aber es kommen keine Werte zurück.
Daher habe ich im Viessmann Forum nach einer Antwort gesucht und Folgendes gefunden:

Es gibt Funktionen, deren Verfügbarkeit von der vorliegenden Regelung abhängen. Ein Beispiel ist "heating.power.consumption.total", welches nur auf ONE BASE Geräten verfügbar ist. Du erkennst, ob du ein ONE BASE Gerät hast, wenn deine Anlage ein integriertes Wifi-Modul besitzt, mit dem du die Anlage mit dem Internet verbindest. Sollte deine Anlage einen Optolink-Anschluss besitzen, mit dem ein Vitoconnect Gateway verbunden ist, besitzt du kein ONE BASE Gerät.

Siehe: https://community.viessmann.de/t5/The-Viessmann-API/Energy-consumption-for-Viessmann-heat-pump-300G/td-p/289425

Das ist natürlich wieder großer Murks von Viessmann und man kann nur hoffen, dass hier nachgearbeitet wird.

Du könntest noch versuchen, ob du über diesen Endpoint Daten bekommst, aber ich glaube, auch hier gibt es nur Daten bei ONE BASE Geräten:
https://api.viessmann.com/iot/v1/analytics-api/dataLake/chronos/v0/thermal_energy
Dieser ist undokumentiert, den ich im Notfall einbauen könnte, aber da er undokumentiert ist, würde ich das lieber nicht machen.

Eine weitere Möglichkeit ist, einfach einen Shelly Pro 3EM zur Messung zu verwenden.
Ich hätte sogar noch einen hier, den ich nicht verwendet habe, da ich meinen Stromzähler der Wärmepumpe auslesen kann.

Eine andere Möglichkeit ist, an den CANBUS des Gerätes mit open3E zu gehen:
https://community.viessmann.de/t5/Konnektivitaet/CAN-Bus-Home-Automation-E3-Generation-lokal-und-kostenlos/td-p/356066

Gruß,
Stefan

Wir haben den optolink. In der App aber selbst sehe ich zumindest den Gesamtstromverbrauch.
Danke, lg

Ok, das hatte ich vermutet.
Wenn du willst baue ich mal testweise eine Abfrage des anderen Endpoints ein, ob dann Werte kommen.
Ich bezweifle es aber wer weiß.

Zur Zeit komme ich nicht dazu, aber zum WE hin kann ich dir denke ich mal eine Testversion geben.

Gruß,
Stefan

Hi satprofi,

ich habe den in dem GIT beschriebenen Endpoint ausprobiert.
https://api.viessmann.com/iot/v1/analytics-api/dataLake/chronos/v0/thermal_energy
Das bekam ich aber keine Antwort von der API.

Das ist im Viessmann Forum nun auch so erwähnt. Siehe:
https://community.viessmann.de/t5/The-Viessmann-API/API-liefert-Verbrauchswerte-nicht-mehr/td-p/445412/page/6

Also es tut mir leid aber das Thema muss ich erstmal zurück stellen bis es hier von Viessmann eine offizielle Lösung für nicht ONEBASE Geräte gibt.
Du kannst gern in dem oben erwähnten Thread im Viessmann Forum auch lesen und sobald es etwas gibt kann ich versuchen es einzubauen.

Gruß,
Stefan

Hi Stefan,
erst mal vielen Dank für die Weiterentwicklung des Moduls. Ich hatte es schon einige Wochen in Verwendung und es hat alles super geklappt. 
Ich habe gerade mein FHEM neu aufgesetzt, beim erneuten einrichten des Moduls bekomme ich beim versuch den API Key zu setzen jedoch folgende Meldung:

Zitatunknown value apiKey, choose one of update:noArg clearReadings:noArg password apiKey logResponseOnce:noArg

Weißt du woran das liegen könnte?

Viele Grüße
Schlimbo

@stefanru

Keine Ursache, in der App sieht man es ja.
Danke trotzdem für die Arbeit

Hi Schlimbo,

ich habe es gerade bei mir nochmal ausprobiert und ein neues Device erstellt und einen API Key eingetragen.
Es ging leider ohne Probleme.

Welche Version hast du denn im FHEM?
Die letzte aus meinem GIT? (Meine Version ist noch nicht im FHEM Repo, da arbeite ich dran sobald ich den Umbau für mehrere Standorte abgeschlossen habe)
In den alten Versionen gab es ja noch keinen API Key.

Hast du schon irgendwelche Attribute gesetzt?

Gruß,
Stefan

Hallo Stefan,
den API-Key brauchte man doch auch in der "alten" Version.

Wozu braucht es eigentlich eine Version für mehrere Standorte, kann man da nicht einfach 2 Instanzen von vitoconnect laufen lassen eventuell sogar mit unterschiedlichen Zugangsdaten.

Hi buec65,

danke für deine Anmerkung.
Es wäre schön von euch zu erfahren was ihr davon haltet und wie die fertige Version dann am besten tickt.

Freibeuter hat 2 Standorte mit einem Account.
Ich habe 2 Gateways mit einem Account.
Denkbar sind auch X Standorte mit X Gateways.

Mein erster Umbau hat sich einzig und allein auf mehrere Gateways bezogen.
Und ich habe versucht dies in einem FHEM Gerät zu lösen.
Das benutze ich selbst nicht mal so und macht die Sache sehr kompliziert, ganz zu schweigen dass setter gar nicht möglich sind.

Mein Plan ist nun, dass ich pro Account (FHEM Device) schaue was ich dort finde.
Finde ich nur ein Gateway an einem Standort läuft alles wie bisher.
Finde ich mehrere Gateways oder Standorte merke ich mir alle und schreibe ins Status Reading "Mehrere Geräte entdeckt, bitte unter Attribute das gewünschte Gerät auswählen".
Unter den Attributen findet man eine Liste aller erkannten Geräte und muss eins auswählen.
Ab dann arbeitet dieses FHEM Device mit diesem Viessmann Gerät.

Will man weiter einbinden geht es wieder so.
Am Schluss hat man also pro Gerät ein FHEM Device.
Für den Standard User mit einem Gerät geht das voll automatisch.

Was hältst du davon?

Danke und Gruß,
Stefan

Hi Stefan,

bei mir gibt es nur 1 Standort 1 Gateway und bisher auch keine aktive Eingriffe mit Setter.

Bin aber glücklich das am Modul aktiv gearbeitet wird und es sehr gut funktioniert.

Wenn das mit mehreren Fhem Devices funktioniert und dadurch die Programmierung einfacher ist macht das doch Sinn.

Gruß
buec65

Ok,
danke für deine Rückmeldung.

Werde den Umbau baldmöglichst angehen.
Sollte das Modul und das Handling mit mehreren Geräten stark vereinfachen.

Wenn das geschafft und getestet ist würde ich das Modul im FHEM SVN updaten.

Beim Testen wäre es super wenn du auch dabei bist.
Da ich nun mal zwei Geräte habe kann ich den Standard Fall der natürlich nach wie vor sofort funktionieren soll ohne Auswahl der Geräte in den Attributen nicht selbst testen.

Ich gebe bescheid sobald es eine neuen Version gibt.

Gruß,
Stefan

Zitat von: stefanru am 17 Januar 2025, 13:16:29ich habe es gerade bei mir nochmal ausprobiert und ein neues Device erstellt und einen API Key eingetragen.
Es ging leider ohne Probleme.

Danke für die Rückmeldung.
Ich habe es jetzt auch noch einmal gelöscht und neu angelegt, und jetzt funktioniert es auch bei mir. :-)

Die Version, die ich nutze, ist bereits deine angepasste (98_vitoconnect.pm:v0.5.0-s26738/2022-11-23, wird im Internal "FVERSION" angezeigt). Allerdings scheint das Datum dort noch nicht zu stimmen.

Zuvor hatte ich es über "Raw definition" erstellt und meine alte Definition mit allen Attributen hineinkopiert.
Habe es gerade noch mal getestet und es hängt mit dem Attribut "vitoconnect_raw_readings" zusammen, ist das auf 1 gesetzt bevor apiKey gesetzt ist, kommt der Fehler.

Mir ist außerdem aufgefallen, dass bei einem Delete passwd und apiKey in der uniqueID-Datei erhalten bleiben. Vom 70_BOTVAL-Modul kenne ich es so, dass bei einem Delete auch das Passwort gelöscht wird.
sub Delete {
    my ( $hash, $arg ) = @_;
    my $name = $hash->{NAME};

    Log3( $name, 5, "BOTVAC $name: called function Delete()" );

    my $index = $hash->{TYPE} . "_" . $name . "_passwd";
    setKeyValue( $index, undef );

    return;
}Mir gefällt es, wenn die Module beim Löschen auch wieder aufräumen  :)

Gruß,
Schlimbo

Hi Schlimbo,

wow, vielen Dank für deine Arbeit.
Das hilft mir sehr.

Habe das Modul ja nur übernommen und erweitert.
Aber werde das delete auf jeden fall aufnehmen.
Auch werde ich mir die Initialisierung mit gesetztem RAW Readings anschauen.
Da ich sowieso die Initialisierung und das bestimmen der Anlagenkonfiguration überarbeiten will, wird das zusammen geschehen.

Der Zeitstempel in FVERSION ist der letzte bei dem das Modul offiziell ins FHEM SVN eingecheckt wurde.
Sobald ich eine neue stabile Version habe werde ich diese dort auch einchecken, es ist alles vorbereitet.
Die Versionsnummer passt aber und entspricht der letzen in meinem GIT.

Die geplanten Entwicklungen sind:
Bestimmen der kompletten Anlagenkonfiguration in getGW.
Auswahl bei mehreren Standorten, mehreren Gateways, mehreren Geräten über Attribute.
Pro FHEM Device gibt es nur noch ein Viessmann Gerät nach der Auswahl.
Mehrere Viessmann Geräte werden durch mehrere FHEM Devices abgebildet.
Checken das anlegen über "Raw Definition" funktioniert.

Alle Calls für Installation, Features, Device usw nur noch optional.

Beim Löschen des gespeicherten APIKeys und Passwort auch die Daten in der uniqueID-Datei löschen.

So wenn ich das habe und es getestet ist wird ins FHEM SVN eingechecked.

Gruß,
Stefan

Hallo Stefan,

vielen Dank für Deinen Einsatz!!

Mir ist noch aufgefallen, dass das Setzen von Werten, wie z.B. WW-Temperatur nicht funktioniert.
Das liegt dann wohl an einer Änderung bei Viessmann. (siehe: https://community.viessmann.de/t5/The-Viessmann-API/API-nimmt-seit-ca-2-Wochen-keine-Set-Befehle-mehr-entgegen/td-p/465679)

Ich habe in meiner lokalen pm die folgende Änderung vorgenommen. So funktioniert es wieder.
Vielleicht kannst Du die Änderung mit in das Release übernehmen.

# my $apiURLBase    = "https://api.viessmann-platform.io/iot/v1/equipment/";
my $apiURLBase    = "https://api.viessmann.com/iot/v1/equipment/";



Hi Uwe,

welche Version des Moduls verwendest du denn?
Meine Version verwendet schon seit Anfang an die neuen API Endpunkte sowie die V2 API für das setzen.

Ich denke du Verwendest noch die Version aus dem SVN.

Zieh dir mal meine Version aus dem GIT.


Am Umbau bin ich dran tu mir aber schwer mit den auswählbaren Devices.

Gruß,
Stefan

Hi zusammen,

ich habe eine erste Version fertiggestellt. Diese Version erzwingt bei mehreren Gateways und/oder Installationen (Standorten) die Auswahl der Geräte. Die Auswahl erfolgt über den Befehl
set selectDevice <serial>, wobei die Werte vorgegeben sind. Diese werden bei
set logResponceOnce oder beim ersten Durchlauf eingelesen.

Funktionalitäten:
- Automatische Auswahl: Hat man nur genau ein Device, sollte die Auswahl automatisch erfolgen.
- Attribute setzen: Bei nur einem Device werden auch automatisch die Attribute
vitoconnect_serial und
vitoconnect_installationId erzeugt und befüllt.
Bei mehreren Devices nach dem set.
- Secrets löschen: Das Löschen der Secrets ist ebenfalls eingebaut.

Hinweis:
Ich habe im Moment leider wenig Zeit zum Testen. Bei mir läuft die Version und es sah auf den ersten Blick gut aus.
War aber ein sehr rudimentärer Test. Kein Neustart usw.

Gibt es mutige Tester, die diese Version ausprobieren möchten und präzises Feedback über die Bugs? 

Wenn ja lade ich diese Version als early Beta hoch.
Wenn nicht teste ich am Wochenende etwas und lade dann hier eine nach gutem wissen getestete Version hoch ;-)

Viele Grüße,
Stefan

Gruß, 
Stefan

Hallo Stefan,
ich kann gerne auf meiner 2.Installation testen, ist ein Device - die Version ohne Auswahl.

Vielen Dank für die Zeit die Du in das Modul investierst.

Hi buec65,

das wäre super.
Bei mir läuft das neue Coding seit 24 Stunden ohne Probleme.
Die Initialisierung mit nur einem Gerät kann ich bei mir nicht testen.
Wäre toll wenn du das testen kannst.
Nach dem ersten logResponceOnce, oder auch nach dem ersten automatischen Daten besorgen sollten automatisch die attribute vitoconnect_serial und vitoconnect_installationId auftauchen und gefüllt sein. Ab da sollte das Modul Daten ziehen und laufen.

Für alle anderen gerne auch testen und bitte auf jeden fall Rückmeldung geben auch wenn es problemlos funktioniert.
Ich benötige von euch dann euer Setup, also ein Geräte, mehrere Geräte an einem Gateway oder mehrere Geräte an mehreren Standorten.


Hier die Beta Version des Moduls mit neuer Bestimmung der Geräte.

Gruß,
Stefan

Zitat von: stefanru am 23 Januar 2025, 22:49:26

Code Auswählen Erweitern

set logResponceOnce

Lässt sich das noch von Responce auf Response ändern?

Hallo Stefan,

hab es mal in Betrieb genommen - nur gewartet bis automatisch Daten kamen, sieht sehr gut aus.
Habe da auch ein Logfile erstellt falls mehr Daten gebraucht werden.

war falsch

@ph1959de: Sorry war ein Tippfehler es heißt logResponseOnce ;-)
@buec65: Super! Kannst du mir noch die Attribute vom Device zeigen? Da sollte es zwei neue geben die automatisch angelegt wurden.

Danke,
Stefan

Habe vitoconnect in fhem nicht neu geladen - Sorry

attr Vito_TEST2 room TEST-Vitodens
attr Vito_TEST2 vitoconnect_installationID 20xxxx4
attr Vito_TEST2 vitoconnect_raw_readings 1
attr Vito_TEST2 vitoconnect_serial 772482xxxxxxxx24

define Vito_TEST2 vitoconnect USER PASS 180
attr Vito_TEST2 room TEST-Vitodens
attr Vito_TEST2 vitoconnect_installationID 2091914
attr Vito_TEST2 vitoconnect_raw_readings 1
attr Vito_TEST2 vitoconnect_serial DEVICE
#   CFGFN     
#   DEF        USER PASS 180
#   FUUID      6793a069-f33f-e80e-bdab-452cdd202ebd154c
#   NAME       Vito_TEST2
#   NR         48
#   Redirect_URI http://localhost:4200/
#   STATE      last update: 2025-01-24 15:26:59
#   TYPE       vitoconnect
#   apiKey     Key
#   counter    0
#   eventCount 30
#   intervall  180
#   login      ok
#   refresh_token Token
#   timeout    15
#   user       USER
#   OLDREADINGS:
#   READINGS:
#     2025-01-24 15:26:58   device.messages.errors.raw.entries
#     2025-01-24 15:26:58   device.serial.value SERIAL
#     2025-01-24 15:26:58   heating.boiler.sensors.temperature.commonSupply.status connected
#     2025-01-24 15:26:58   heating.boiler.sensors.temperature.commonSupply.value 46.6
#     2025-01-24 15:26:58   heating.boiler.serial.value SERIAL
#     2025-01-24 15:26:58   heating.boiler.temperature.value 15
#     2025-01-24 15:26:58   heating.burners.0.active 1
#     2025-01-24 15:26:58   heating.burners.0.modulation.value 55.7
#     2025-01-24 15:26:58   heating.burners.0.statistics.hours 14050
#     2025-01-24 15:26:58   heating.burners.0.statistics.starts 4838
#     2025-01-24 15:26:58   heating.burners.enabled 0
#     2025-01-24 15:26:58   heating.circuits.0.active 1
#     2025-01-24 15:26:58   heating.circuits.0.circulation.pump.status on
#     2025-01-24 15:26:58   heating.circuits.0.frostprotection.status off
#     2025-01-24 15:26:58   heating.circuits.0.heating.curve.shift 2
#     2025-01-24 15:26:58   heating.circuits.0.heating.curve.slope 0.8
#     2025-01-24 15:26:58   heating.circuits.0.heating.schedule.active 1
#     2025-01-24 15:26:58   heating.circuits.0.heating.schedule.entries {"thu":[{"position":0,"end":"22:00","start":"05:00","mode":"normal"}],"sun":[{"mode":"normal","start":"06:00","position":0,"end":"22:00"}],"mon":[{"mode":"normal","start":"05:00","position":0,"end":"22:00"}],"wed":[{"start":"05:00","mode":"normal","end":"22:00","position":0}],"tue":[{"mode":"normal","start":"05:00","position":0,"end":"22:00"}],"fri":[{"mode":"normal","start":"05:00","end":"22:00","position":0}],"sat":[{"end":"22:00","position":0,"mode":"normal","start":"06:00"}]}
#     2025-01-24 15:26:58   heating.circuits.0.name Heizkoerper
#     2025-01-24 15:26:58   heating.circuits.0.name.name Heizkoerper
#     2025-01-24 15:26:58   heating.circuits.0.operating.modes.active.value heating
#     2025-01-24 15:26:58   heating.circuits.0.operating.modes.heating.active 1
#     2025-01-24 15:26:58   heating.circuits.0.operating.modes.standby.active 0
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.active.value normal
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.comfort.active 0
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.comfort.demand unknown
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.comfort.temperature 18
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.eco.active 0
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.forcedLastFromSchedule.active 0
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.normal.active 1
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.normal.demand unknown
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.normal.temperature 18
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.reduced.active 0
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.reduced.demand unknown
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.reduced.temperature 18
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.reducedEnergySaving.active 0
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.reducedEnergySaving.demand heating
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.reducedEnergySaving.reason unknown
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.standby.active 0
#     2025-01-24 15:26:58   heating.circuits.0.operating.programs.summerEco.active 0
#     2025-01-24 15:26:58   heating.circuits.0.sensors.temperature.supply.status connected
#     2025-01-24 15:26:58   heating.circuits.0.sensors.temperature.supply.value 35.6
#     2025-01-24 15:26:58   heating.circuits.0.temperature.levels.max 70
#     2025-01-24 15:26:58   heating.circuits.0.temperature.levels.min 20
#     2025-01-24 15:26:58   heating.circuits.0.type heatingCircuit
#     2025-01-24 15:26:58   heating.circuits.0.zone.mode.active 0
#     2025-01-24 15:26:58   heating.circuits.1.active 1
#     2025-01-24 15:26:58   heating.circuits.1.circulation.pump.status on
#     2025-01-24 15:26:58   heating.circuits.1.frostprotection.status off
#     2025-01-24 15:26:58   heating.circuits.1.heating.curve.shift 5
#     2025-01-24 15:26:58   heating.circuits.1.heating.curve.slope 0.7
#     2025-01-24 15:26:58   heating.circuits.1.heating.schedule.active 1
#     2025-01-24 15:26:58   heating.circuits.1.heating.schedule.entries {"tue":[{"end":"22:00","position":0,"mode":"normal","start":"05:00"}],"wed":[{"mode":"normal","start":"05:00","end":"22:00","position":0}],"fri":[{"mode":"normal","start":"05:00","end":"22:00","position":0}],"sat":[{"mode":"normal","start":"06:00","position":0,"end":"22:00"}],"thu":[{"end":"22:00","position":0,"mode":"normal","start":"05:00"}],"sun":[{"mode":"normal","start":"06:00","position":0,"end":"22:00"}],"mon":[{"mode":"normal","start":"05:00","end":"22:00","position":0}]}
#     2025-01-24 15:26:58   heating.circuits.1.name Fussboden Hzg.
#     2025-01-24 15:26:58   heating.circuits.1.name.name Fussboden Hzg.
#     2025-01-24 15:26:58   heating.circuits.1.operating.modes.active.value heating
#     2025-01-24 15:26:58   heating.circuits.1.operating.modes.heating.active 1
#     2025-01-24 15:26:58   heating.circuits.1.operating.modes.standby.active 0
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.active.value normal
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.comfort.active 0
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.comfort.demand unknown
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.comfort.temperature 18
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.eco.active 0
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.forcedLastFromSchedule.active 0
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.normal.active 1
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.normal.demand unknown
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.normal.temperature 17
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.reduced.active 0
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.reduced.demand unknown
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.reduced.temperature 17
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.reducedEnergySaving.active 0
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.reducedEnergySaving.demand heating
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.reducedEnergySaving.reason unknown
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.standby.active 0
#     2025-01-24 15:26:58   heating.circuits.1.operating.programs.summerEco.active 0
#     2025-01-24 15:26:58   heating.circuits.1.sensors.temperature.supply.status connected
#     2025-01-24 15:26:58   heating.circuits.1.sensors.temperature.supply.value 36.7
#     2025-01-24 15:26:58   heating.circuits.1.temperature.levels.max 50
#     2025-01-24 15:26:58   heating.circuits.1.temperature.levels.min 20
#     2025-01-24 15:26:58   heating.circuits.1.type heatingCircuit
#     2025-01-24 15:26:58   heating.circuits.1.zone.mode.active 0
#     2025-01-24 15:26:58   heating.circuits.enabled 0,1
#     2025-01-24 15:26:58   heating.dhw.active 1
#     2025-01-24 15:26:58   heating.dhw.hygiene.enabled 0
#     2025-01-24 15:26:58   heating.dhw.oneTimeCharge.active 0
#     2025-01-24 15:26:58   heating.dhw.operating.modes.active.value balanced
#     2025-01-24 15:26:58   heating.dhw.operating.modes.balanced.active 1
#     2025-01-24 15:26:58   heating.dhw.operating.modes.off.active 0
#     2025-01-24 15:26:58   heating.dhw.pumps.circulation.schedule.active 1
#     2025-01-24 15:26:58   heating.dhw.pumps.circulation.schedule.entries {"mon":[{"end":"24:00","position":0,"mode":"on","start":"00:30"}],"sun":[{"start":"00:30","mode":"on","end":"24:00","position":0}],"thu":[{"mode":"on","start":"00:30","position":0,"end":"24:00"}],"fri":[{"start":"00:30","mode":"on","position":0,"end":"24:00"}],"sat":[{"mode":"on","start":"00:30","end":"24:00","position":0}],"wed":[{"mode":"on","start":"00:30","end":"24:00","position":0}],"tue":[{"mode":"on","start":"00:30","position":0,"end":"24:00"}]}
#     2025-01-24 15:26:58   heating.dhw.pumps.circulation.status off
#     2025-01-24 15:26:58   heating.dhw.schedule.active 1
#     2025-01-24 15:26:58   heating.dhw.schedule.entries {"mon":[{"position":0,"end":"22:00","mode":"on","start":"05:00"}],"thu":[{"start":"05:00","mode":"on","position":0,"end":"22:00"}],"sun":[{"mode":"on","start":"05:30","position":0,"end":"22:00"}],"fri":[{"start":"05:00","mode":"on","position":0,"end":"22:00"}],"sat":[{"position":0,"end":"22:00","mode":"on","start":"05:30"}],"tue":[{"mode":"on","start":"05:00","end":"22:00","position":0}],"wed":[{"start":"05:00","mode":"on","position":0,"end":"22:00"}]}
#     2025-01-24 15:26:58   heating.dhw.sensors.temperature.dhwCylinder.status connected
#     2025-01-24 15:26:58   heating.dhw.sensors.temperature.dhwCylinder.value 106.7
#     2025-01-24 15:26:58   heating.dhw.sensors.temperature.hotWaterStorage.status connected
#     2025-01-24 15:26:58   heating.dhw.sensors.temperature.hotWaterStorage.value 106.7
#     2025-01-24 15:26:58   heating.dhw.sensors.temperature.outlet.status notConnected
#     2025-01-24 15:26:58   heating.dhw.status on
#     2025-01-24 15:26:58   heating.dhw.temperature.main.value 50
#     2025-01-24 15:26:58   heating.gas.consumption.dhw.day 1.5,2.1,2.4,2.3,2.6,2.3,2.3,2.1
#     2025-01-23 23:59:59   heating.gas.consumption.dhw.day.asSingleValue 2.1
#     2025-01-24 15:26:58   heating.gas.consumption.dhw.dayValueReadAt 2025-01-24T14:00:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.dhw.month 57.2,79.9,71.9,68.5,65.4,67.8,71.9,73,78.6,79.8,84.1,73.6,78.2
#     2025-01-24 15:26:58   heating.gas.consumption.dhw.monthValueReadAt 2025-01-24T14:00:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.dhw.week 10.9,16.7,17.8,17.1,18.6,17.5,16.9,16.4
#     2025-01-24 15:26:58   heating.gas.consumption.dhw.weekValueReadAt 2025-01-24T14:00:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.dhw.year 57.2,893.2
#     2025-01-24 15:26:58   heating.gas.consumption.dhw.yearValueReadAt 2025-01-24T14:00:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.heating.day 14.6,24.4,24.3,24.2,23.8,23.2,22.7,24.3
#     2025-01-23 23:59:59   heating.gas.consumption.heating.day.asSingleValue 24.4
#     2025-01-24 15:26:58   heating.gas.consumption.heating.dayValueReadAt 2025-01-24T13:50:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.heating.month 576,733.4,543.3,319.6,125.2,12.7,24,69.1,124.5,307.1,438.1,483,753.1
#     2025-01-24 15:26:58   heating.gas.consumption.heating.monthValueReadAt 2025-01-24T13:50:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.heating.week 111.3,174.3,160.3,185.3,165.6,138.6,167.1,161.7
#     2025-01-24 15:26:58   heating.gas.consumption.heating.weekValueReadAt 2025-01-24T13:50:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.heating.year 576,3933.4
#     2025-01-24 15:26:58   heating.gas.consumption.heating.yearValueReadAt 2025-01-24T13:50:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.summary.dhw.currentDay 1.5
#     2025-01-24 15:26:58   heating.gas.consumption.summary.dhw.currentMonth 57.2
#     2025-01-24 15:26:58   heating.gas.consumption.summary.dhw.currentYear 57.2
#     2025-01-24 15:26:58   heating.gas.consumption.summary.dhw.lastMonth 79.9
#     2025-01-24 15:26:58   heating.gas.consumption.summary.dhw.lastSevenDays 15.5
#     2025-01-24 15:26:58   heating.gas.consumption.summary.dhw.lastYear 893.2
#     2025-01-24 15:26:58   heating.gas.consumption.summary.heating.currentDay 14.6
#     2025-01-24 15:26:58   heating.gas.consumption.summary.heating.currentMonth 576
#     2025-01-24 15:26:58   heating.gas.consumption.summary.heating.currentYear 576
#     2025-01-24 15:26:58   heating.gas.consumption.summary.heating.lastMonth 733.4
#     2025-01-24 15:26:58   heating.gas.consumption.summary.heating.lastSevenDays 157.3
#     2025-01-24 15:26:58   heating.gas.consumption.summary.heating.lastYear 3933.4
#     2025-01-24 15:26:58   heating.gas.consumption.total.day 16.1,26.5,26.7,26.5,26.4,25.5,25,26.4
#     2025-01-23 23:59:59   heating.gas.consumption.total.day.asSingleValue 26.5
#     2025-01-24 15:26:58   heating.gas.consumption.total.dayValueReadAt 2025-01-24T13:50:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.total.month 633.2,813.3,615.2,388.1,190.6,80.5,95.9,142.1,203.1,386.9,522.2,556.6,831.3
#     2025-01-24 15:26:58   heating.gas.consumption.total.monthValueReadAt 2025-01-24T13:50:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.total.week 122.2,191,178.1,202.4,184.2,156.1,184,178.1
#     2025-01-24 15:26:58   heating.gas.consumption.total.weekValueReadAt 2025-01-24T13:50:31.000Z
#     2025-01-24 15:26:58   heating.gas.consumption.total.year 633.2,4826.6
#     2025-01-24 15:26:58   heating.gas.consumption.total.yearValueReadAt 2025-01-24T13:50:31.000Z
#     2025-01-24 15:26:58   heating.operating.programs.holiday.active 0
#     2025-01-24 15:26:58   heating.operating.programs.holiday.end
#     2025-01-24 15:26:58   heating.operating.programs.holiday.start
#     2025-01-24 15:26:58   heating.operating.programs.holidayAtHome.active 0
#     2025-01-24 15:26:58   heating.operating.programs.holidayAtHome.end
#     2025-01-24 15:26:58   heating.operating.programs.holidayAtHome.start
#     2025-01-24 15:26:58   heating.power.consumption.dhw.day 0,0.1,0.1,0.1,0.1,0.1,0.1,0.1
#     2025-01-22 23:59:59   heating.power.consumption.dhw.day.asSingleValue 0.1
#     2025-01-24 15:26:58   heating.power.consumption.dhw.dayValueReadAt 2025-01-23T23:00:27.000Z
#     2025-01-24 15:26:58   heating.power.consumption.dhw.month 2.8,3.8,3.4,3.2,3.1,3.1,3.3,3.4,3.6,3.7,3.9,3.5,3.8
#     2025-01-24 15:26:58   heating.power.consumption.dhw.monthValueReadAt 2025-01-24T14:16:31.000Z
#     2025-01-24 15:26:58   heating.power.consumption.dhw.week 0.4,0.7,0.7,0.7,0.7,0.7,0.7,0.7
#     2025-01-24 15:26:58   heating.power.consumption.dhw.weekValueReadAt 2025-01-23T23:00:27.000Z
#     2025-01-24 15:26:58   heating.power.consumption.dhw.year 2.8,42.2
#     2025-01-24 15:26:58   heating.power.consumption.dhw.yearValueReadAt 2025-01-24T14:16:31.000Z
#     2025-01-24 15:26:58   heating.power.consumption.heating.day 0.9,1.5,1.5,1.5,1.5,1.5,1.5,1.5
#     2025-01-23 23:59:59   heating.power.consumption.heating.day.asSingleValue 1.5
#     2025-01-24 15:26:58   heating.power.consumption.heating.dayValueReadAt 2025-01-24T13:18:30.000Z
#     2025-01-24 15:26:58   heating.power.consumption.heating.month 36.1,48.9,45.1,43.3,20.3,6.1,8,15.4,23.7,34.9,45.6,43.2,47.1
#     2025-01-24 15:26:58   heating.power.consumption.heating.monthValueReadAt 2025-01-24T13:18:30.000Z
#     2025-01-24 15:26:58   heating.power.consumption.heating.week 6.9,10.4,10.5,10.5,10.5,10.3,10.5,10.5
#     2025-01-24 15:26:58   heating.power.consumption.heating.weekValueReadAt 2025-01-24T13:18:30.000Z
#     2025-01-24 15:26:58   heating.power.consumption.heating.year 36.1,382.2
#     2025-01-24 15:26:58   heating.power.consumption.heating.yearValueReadAt 2025-01-24T13:18:30.000Z
#     2025-01-24 15:26:58   heating.power.consumption.summary.dhw.currentDay 0
#     2025-01-24 15:26:58   heating.power.consumption.summary.dhw.currentMonth 2.8
#     2025-01-24 15:26:58   heating.power.consumption.summary.dhw.currentYear 2.8
#     2025-01-24 15:26:58   heating.power.consumption.summary.dhw.lastMonth 3.8
#     2025-01-24 15:26:58   heating.power.consumption.summary.dhw.lastSevenDays 0.8
#     2025-01-24 15:26:58   heating.power.consumption.summary.dhw.lastYear 42.2
#     2025-01-24 15:26:58   heating.power.consumption.summary.heating.currentDay 0.9
#     2025-01-24 15:26:58   heating.power.consumption.summary.heating.currentMonth 36.1
#     2025-01-24 15:26:58   heating.power.consumption.summary.heating.currentYear 36.1
#     2025-01-24 15:26:58   heating.power.consumption.summary.heating.lastMonth 48.9
#     2025-01-24 15:26:58   heating.power.consumption.summary.heating.lastSevenDays 10.1
#     2025-01-24 15:26:58   heating.power.consumption.summary.heating.lastYear 382.2
#     2025-01-24 15:26:58   heating.power.consumption.total.day 0,1.6,1.6,1.6,1.6,1.6,1.6,1.6
#     2025-01-22 23:59:59   heating.power.consumption.total.day.asSingleValue 1.6
#     2025-01-24 15:26:58   heating.power.consumption.total.dayValueReadAt 2025-01-23T17:30:26.000Z
#     2025-01-24 15:26:58   heating.power.consumption.total.month 38.9,52.7,48.5,46.5,23.4,9.2,11.3,18.8,27.3,38.6,49.5,46.7,50.9
#     2025-01-24 15:26:58   heating.power.consumption.total.monthValueReadAt 2025-01-24T12:40:29.000Z
#     2025-01-24 15:26:58   heating.power.consumption.total.week 6.4,11.1,11.2,11.2,11.2,11,11.2,11.2
#     2025-01-24 15:26:58   heating.power.consumption.total.weekValueReadAt 2025-01-23T17:30:26.000Z
#     2025-01-24 15:26:58   heating.power.consumption.total.year 38.9,424.4
#     2025-01-24 15:26:58   heating.power.consumption.total.yearValueReadAt 2025-01-24T13:18:30.000Z
#     2025-01-24 15:26:58   heating.sensors.temperature.hydraulicSeparator.status connected
#     2025-01-24 15:26:58   heating.sensors.temperature.hydraulicSeparator.value 35.5
#     2025-01-24 15:26:58   heating.sensors.temperature.outside.status connected
#     2025-01-24 15:26:58   heating.sensors.temperature.outside.value 6.7
#     2025-01-24 15:26:58   heating.sensors.volumetricFlow.allengra.status connected
#     2025-01-24 15:26:58   heating.sensors.volumetricFlow.allengra.value 1035
#     2025-01-24 15:26:58   state           last update: 2025-01-24 15:26:59
#   devices:
#     DEVICE:
#       gatewayType SA1800019WiFi
#       installationId 2091914
#       version    506.2340.8.0
#
setstate Vito_TEST2 last update: 2025-01-24 15:26:59
setstate Vito_TEST2 2025-01-24 15:26:58 device.messages.errors.raw.entries
setstate Vito_TEST2 2025-01-24 15:26:58 device.serial.value SERIAL
setstate Vito_TEST2 2025-01-24 15:26:58 heating.boiler.sensors.temperature.commonSupply.status connected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.boiler.sensors.temperature.commonSupply.value 46.6
setstate Vito_TEST2 2025-01-24 15:26:58 heating.boiler.serial.value SERIAL
setstate Vito_TEST2 2025-01-24 15:26:58 heating.boiler.temperature.value 15
setstate Vito_TEST2 2025-01-24 15:26:58 heating.burners.0.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.burners.0.modulation.value 55.7
setstate Vito_TEST2 2025-01-24 15:26:58 heating.burners.0.statistics.hours 14050
setstate Vito_TEST2 2025-01-24 15:26:58 heating.burners.0.statistics.starts 4838
setstate Vito_TEST2 2025-01-24 15:26:58 heating.burners.enabled 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.circulation.pump.status on
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.frostprotection.status off
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.heating.curve.shift 2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.heating.curve.slope 0.8
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.heating.schedule.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.heating.schedule.entries {"thu":[{"position":0,"end":"22:00","start":"05:00","mode":"normal"}],"sun":[{"mode":"normal","start":"06:00","position":0,"end":"22:00"}],"mon":[{"mode":"normal","start":"05:00","position":0,"end":"22:00"}],"wed":[{"start":"05:00","mode":"normal","end":"22:00","position":0}],"tue":[{"mode":"normal","start":"05:00","position":0,"end":"22:00"}],"fri":[{"mode":"normal","start":"05:00","end":"22:00","position":0}],"sat":[{"end":"22:00","position":0,"mode":"normal","start":"06:00"}]}
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.name Heizkoerper
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.name.name Heizkoerper
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.modes.active.value heating
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.modes.heating.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.modes.standby.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.active.value normal
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.comfort.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.comfort.demand unknown
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.comfort.temperature 18
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.eco.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.forcedLastFromSchedule.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.normal.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.normal.demand unknown
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.normal.temperature 18
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.reduced.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.reduced.demand unknown
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.reduced.temperature 18
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.reducedEnergySaving.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.reducedEnergySaving.demand heating
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.reducedEnergySaving.reason unknown
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.standby.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.operating.programs.summerEco.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.sensors.temperature.supply.status connected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.sensors.temperature.supply.value 35.6
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.temperature.levels.max 70
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.temperature.levels.min 20
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.type heatingCircuit
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.0.zone.mode.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.circulation.pump.status on
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.frostprotection.status off
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.heating.curve.shift 5
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.heating.curve.slope 0.7
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.heating.schedule.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.heating.schedule.entries {"tue":[{"end":"22:00","position":0,"mode":"normal","start":"05:00"}],"wed":[{"mode":"normal","start":"05:00","end":"22:00","position":0}],"fri":[{"mode":"normal","start":"05:00","end":"22:00","position":0}],"sat":[{"mode":"normal","start":"06:00","position":0,"end":"22:00"}],"thu":[{"end":"22:00","position":0,"mode":"normal","start":"05:00"}],"sun":[{"mode":"normal","start":"06:00","position":0,"end":"22:00"}],"mon":[{"mode":"normal","start":"05:00","end":"22:00","position":0}]}
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.name Fussboden Hzg.
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.name.name Fussboden Hzg.
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.modes.active.value heating
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.modes.heating.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.modes.standby.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.active.value normal
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.comfort.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.comfort.demand unknown
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.comfort.temperature 18
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.eco.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.forcedLastFromSchedule.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.normal.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.normal.demand unknown
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.normal.temperature 17
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.reduced.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.reduced.demand unknown
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.reduced.temperature 17
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.reducedEnergySaving.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.reducedEnergySaving.demand heating
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.reducedEnergySaving.reason unknown
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.standby.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.operating.programs.summerEco.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.sensors.temperature.supply.status connected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.sensors.temperature.supply.value 36.7
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.temperature.levels.max 50
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.temperature.levels.min 20
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.type heatingCircuit
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.1.zone.mode.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.circuits.enabled 0,1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.hygiene.enabled 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.oneTimeCharge.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.operating.modes.active.value balanced
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.operating.modes.balanced.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.operating.modes.off.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.pumps.circulation.schedule.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.pumps.circulation.schedule.entries {"mon":[{"end":"24:00","position":0,"mode":"on","start":"00:30"}],"sun":[{"start":"00:30","mode":"on","end":"24:00","position":0}],"thu":[{"mode":"on","start":"00:30","position":0,"end":"24:00"}],"fri":[{"start":"00:30","mode":"on","position":0,"end":"24:00"}],"sat":[{"mode":"on","start":"00:30","end":"24:00","position":0}],"wed":[{"mode":"on","start":"00:30","end":"24:00","position":0}],"tue":[{"mode":"on","start":"00:30","position":0,"end":"24:00"}]}
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.pumps.circulation.status off
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.schedule.active 1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.schedule.entries {"mon":[{"position":0,"end":"22:00","mode":"on","start":"05:00"}],"thu":[{"start":"05:00","mode":"on","position":0,"end":"22:00"}],"sun":[{"mode":"on","start":"05:30","position":0,"end":"22:00"}],"fri":[{"start":"05:00","mode":"on","position":0,"end":"22:00"}],"sat":[{"position":0,"end":"22:00","mode":"on","start":"05:30"}],"tue":[{"mode":"on","start":"05:00","end":"22:00","position":0}],"wed":[{"start":"05:00","mode":"on","position":0,"end":"22:00"}]}
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.sensors.temperature.dhwCylinder.status connected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.sensors.temperature.dhwCylinder.value 106.7
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.sensors.temperature.hotWaterStorage.status connected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.sensors.temperature.hotWaterStorage.value 106.7
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.sensors.temperature.outlet.status notConnected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.status on
setstate Vito_TEST2 2025-01-24 15:26:58 heating.dhw.temperature.main.value 50
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.dhw.day 1.5,2.1,2.4,2.3,2.6,2.3,2.3,2.1
setstate Vito_TEST2 2025-01-23 23:59:59 heating.gas.consumption.dhw.day.asSingleValue 2.1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.dhw.dayValueReadAt 2025-01-24T14:00:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.dhw.month 57.2,79.9,71.9,68.5,65.4,67.8,71.9,73,78.6,79.8,84.1,73.6,78.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.dhw.monthValueReadAt 2025-01-24T14:00:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.dhw.week 10.9,16.7,17.8,17.1,18.6,17.5,16.9,16.4
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.dhw.weekValueReadAt 2025-01-24T14:00:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.dhw.year 57.2,893.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.dhw.yearValueReadAt 2025-01-24T14:00:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.heating.day 14.6,24.4,24.3,24.2,23.8,23.2,22.7,24.3
setstate Vito_TEST2 2025-01-23 23:59:59 heating.gas.consumption.heating.day.asSingleValue 24.4
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.heating.dayValueReadAt 2025-01-24T13:50:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.heating.month 576,733.4,543.3,319.6,125.2,12.7,24,69.1,124.5,307.1,438.1,483,753.1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.heating.monthValueReadAt 2025-01-24T13:50:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.heating.week 111.3,174.3,160.3,185.3,165.6,138.6,167.1,161.7
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.heating.weekValueReadAt 2025-01-24T13:50:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.heating.year 576,3933.4
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.heating.yearValueReadAt 2025-01-24T13:50:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.dhw.currentDay 1.5
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.dhw.currentMonth 57.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.dhw.currentYear 57.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.dhw.lastMonth 79.9
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.dhw.lastSevenDays 15.5
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.dhw.lastYear 893.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.heating.currentDay 14.6
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.heating.currentMonth 576
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.heating.currentYear 576
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.heating.lastMonth 733.4
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.heating.lastSevenDays 157.3
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.summary.heating.lastYear 3933.4
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.total.day 16.1,26.5,26.7,26.5,26.4,25.5,25,26.4
setstate Vito_TEST2 2025-01-23 23:59:59 heating.gas.consumption.total.day.asSingleValue 26.5
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.total.dayValueReadAt 2025-01-24T13:50:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.total.month 633.2,813.3,615.2,388.1,190.6,80.5,95.9,142.1,203.1,386.9,522.2,556.6,831.3
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.total.monthValueReadAt 2025-01-24T13:50:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.total.week 122.2,191,178.1,202.4,184.2,156.1,184,178.1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.total.weekValueReadAt 2025-01-24T13:50:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.total.year 633.2,4826.6
setstate Vito_TEST2 2025-01-24 15:26:58 heating.gas.consumption.total.yearValueReadAt 2025-01-24T13:50:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.operating.programs.holiday.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.operating.programs.holiday.end
setstate Vito_TEST2 2025-01-24 15:26:58 heating.operating.programs.holiday.start
setstate Vito_TEST2 2025-01-24 15:26:58 heating.operating.programs.holidayAtHome.active 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.operating.programs.holidayAtHome.end
setstate Vito_TEST2 2025-01-24 15:26:58 heating.operating.programs.holidayAtHome.start
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.dhw.day 0,0.1,0.1,0.1,0.1,0.1,0.1,0.1
setstate Vito_TEST2 2025-01-22 23:59:59 heating.power.consumption.dhw.day.asSingleValue 0.1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.dhw.dayValueReadAt 2025-01-23T23:00:27.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.dhw.month 2.8,3.8,3.4,3.2,3.1,3.1,3.3,3.4,3.6,3.7,3.9,3.5,3.8
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.dhw.monthValueReadAt 2025-01-24T14:16:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.dhw.week 0.4,0.7,0.7,0.7,0.7,0.7,0.7,0.7
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.dhw.weekValueReadAt 2025-01-23T23:00:27.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.dhw.year 2.8,42.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.dhw.yearValueReadAt 2025-01-24T14:16:31.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.heating.day 0.9,1.5,1.5,1.5,1.5,1.5,1.5,1.5
setstate Vito_TEST2 2025-01-23 23:59:59 heating.power.consumption.heating.day.asSingleValue 1.5
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.heating.dayValueReadAt 2025-01-24T13:18:30.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.heating.month 36.1,48.9,45.1,43.3,20.3,6.1,8,15.4,23.7,34.9,45.6,43.2,47.1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.heating.monthValueReadAt 2025-01-24T13:18:30.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.heating.week 6.9,10.4,10.5,10.5,10.5,10.3,10.5,10.5
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.heating.weekValueReadAt 2025-01-24T13:18:30.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.heating.year 36.1,382.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.heating.yearValueReadAt 2025-01-24T13:18:30.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.dhw.currentDay 0
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.dhw.currentMonth 2.8
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.dhw.currentYear 2.8
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.dhw.lastMonth 3.8
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.dhw.lastSevenDays 0.8
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.dhw.lastYear 42.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.heating.currentDay 0.9
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.heating.currentMonth 36.1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.heating.currentYear 36.1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.heating.lastMonth 48.9
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.heating.lastSevenDays 10.1
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.summary.heating.lastYear 382.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.total.day 0,1.6,1.6,1.6,1.6,1.6,1.6,1.6
setstate Vito_TEST2 2025-01-22 23:59:59 heating.power.consumption.total.day.asSingleValue 1.6
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.total.dayValueReadAt 2025-01-23T17:30:26.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.total.month 38.9,52.7,48.5,46.5,23.4,9.2,11.3,18.8,27.3,38.6,49.5,46.7,50.9
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.total.monthValueReadAt 2025-01-24T12:40:29.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.total.week 6.4,11.1,11.2,11.2,11.2,11,11.2,11.2
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.total.weekValueReadAt 2025-01-23T17:30:26.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.total.year 38.9,424.4
setstate Vito_TEST2 2025-01-24 15:26:58 heating.power.consumption.total.yearValueReadAt 2025-01-24T13:18:30.000Z
setstate Vito_TEST2 2025-01-24 15:26:58 heating.sensors.temperature.hydraulicSeparator.status connected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.sensors.temperature.hydraulicSeparator.value 35.5
setstate Vito_TEST2 2025-01-24 15:26:58 heating.sensors.temperature.outside.status connected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.sensors.temperature.outside.value 6.7
setstate Vito_TEST2 2025-01-24 15:26:58 heating.sensors.volumetricFlow.allengra.status connected
setstate Vito_TEST2 2025-01-24 15:26:58 heating.sensors.volumetricFlow.allengra.value 1035
setstate Vito_TEST2 2025-01-24 15:26:58 state last update: 2025-01-24 15:26:59



Ja perfekt!
Vollautomatisch die Attribute erzeugt.
So soll das laufen.
Vielen Dank fürs Testen.

@Freibeuter: Jetzt bräuchte ich noch jemand mit 2 Standorten, da kenne ich dich ;-)
Hier sollte das Device beim ersten Einlesen sagen, dass es mehrere Gateways/Devices gefunden hat und dass du eins auswählen musst.
Danach sollte alles gesetzt sein und laufen.

Ich selbst habe schon 2 Gateways an einem Standort getestet, da lief es wie erwartet.

P.S.: Die Version ist nun auch im GIT.
Sobald alle Testfälle durch sind würde ich diese Version dann ins FHEM SVN einchecken und alle User damit beglücken ;-)

Danke und viele Grüße,
Stefan

Habe das Wiki etwas angepasst.
Die neuen Einstellungen sind erwähnt.

Bitte alle das neue Modul aus dem GIT Testen und Rückmeldung geben.
Sobald ich jede Anlagen Konfiguration einmal bestätigt habe werde ich das Modul ins SVN einchecken.
Dann werden alle mit dem neuen Modul zwangsbeglückt ;-)

Also bitte diese Version mal testen:
https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm (https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm)
Ich empfehle eine Neustart von FHEM da es bei einem Sprung von dem alten auf das neue Modul sonst Probleme mit dem Timer geben kann.

Gruß,
Stefan

Moin,

gute Arbeit Stefan und alles läuft perfekt ohne Fehler  :)

Meine Anlage: Viessmann Vitodens 200-W (19 kW)


Grüße

Sandro

Update problemlos mit einer Anlage, Vitocal252A, alle Daten werden gelesen.

Ich habe ein riesiges Internal (.response_7736172034790220) durch das ich scrollen muss bis ich zu den Readings komme (war aber vielleicht schon vorher da?) - wie kriege ich das weg?

Hi kkoeniger.

ja das .response reading brauch ich um die Setter aufzubauen.
War schon länger im Modul.

.Readings sind internal Readings und werden von Modul Autoren oder können auch von dir verwendet werden um Readings zu verstecken.
Wie auch .Filenamen in Linux.

Du hast scheinbar an deinem Global Device eingestellt dass du die sehen willst.

Schau mal hier:
list global showInternalValues
und setze es auf 0 das ist auch der Default.

Oder hast du das aus einem bestimmten Grund auf 1?

So nun bräuchte ich nur noch eine Aussage von @Freibeuter, aber er hat auch ein sehr seltenes Setup 2 Anlagen an 2 Standorten.
Wenn keine kommt checke ich trotzdem ins SVN mal ein.
Warte aber noch bis nächste Woche.

Gruß und Danke,
Stefan

Zitat von: stefanru am 26 Januar 2025, 13:00:11Schau mal hier:
list global showInternalValues
und setze es auf 0 das ist auch der Default.

Danke - das war es. Keine Ahnung mehr wofür das bei mir gesetzt war.

Hi,

ich habe noch etwas an der Dokumentation geschraubt.
Habe noch etwas getestet auch mit Server Restarts usw.

Ich denke ich bin dann so weit das ins SVN einzuchecken.
Warte nochmal bis morgen und dann versuche ich mein Glück.

Die letzte Version ist wieder in meinem GIT, mit ein paar kleinen Bugfixen.

Viele Grüße,
Stefan

Hi,

ok ich habe mich getraut.
Das erstmal, dass ich etwas ins FHEM SVN eingechecked habe.
Ich hoffe es klappt alles.
Soweit ich es verstanden habe steht es morgen zur Verfügung?

P.S.: Die Version die ihr bekommen solltet sollte:
"0.6.2"  => "29.01.2025" sein.

Hat bei mir heute morgen ohne Probleme geklappt:
Screenshot 2025-01-30 091046.png


Viele Grüße,
Stefan

Vielen Dank Stefan,

endlich konnte ich das Modul von der exclude_from_update-Liste streichen  ;D und update hat auch gleich wunderbar funktioniert.

Hi,

scheint bisher gut zu laufen, keine Beschwerden.
Habe angefangen die Wiki zu überarbeiten.
https://wiki.fhem.de/wiki/Vitoconnect

Ich werde noch bei Hilfsmitteln einiges zu Wärempumpen, COP ausrechnen und Stromverbrauchsaufzeichnung ergänzen sobald ich dazu komme.

Bei weiteren Wünsche ans Modul einfach hier im Thread melden.

Gruß,
Stefan

Guten Morgen,

erhalte seit gestern kein Reading Updates mehr. Verwende Version: 98_vitoconnect.pm 29593 2025-01-29 23:12:02Z

Ich habe heute morgen alle Readings gelöscht. Passwort erneut eingegeben. LogResponseOnece ausgeführt. Device ausgewählt und update ausgeführt.
Leider kein Erfolg.

Folgende Meldungen waren im Log

2025.02.04 11:20:24.664 1:  PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 3697.
2025.02.04 11:20:24.664 1:  PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 3702.
2025.02.04 11:20:24.675 1:  viessmann - Device not found: Optolink prüfen!

Bei den Readings werden

     -device
     -gw
     -gw_features
     -installation

     -installation_features
           {
              "data": []
           }      2025-02-04 11:20:23

     -number_of_gateways   1     2025-02-04 11:20:23

angezeigt

Teilauszug von gw_features sieht so aus. War vorher nicht vorhanden.

              "id": "0",
              "fingerprint": "ecu;7994220401109129;0020.0511.2417.0257;0002.0612.0101.0004",
              "modelId": "E3_Vitocal",
              "modelVersion": "Ljyw6PG0prRxLUxWYR1YwL4K9FU",
              "name": "Vitocal XXX-A, Release x11+",
              "type": "heating",
              "roles": [
                "capability:backup;0020_HPMU_VC",
                "capability:consumptionReport;electric",
                "capability:monetization;AdvancedReport",
                "capability:monetization;DhwSavingsCalculator",
                "capability:productionReport;thermal",
                "type:E3",
                "type:cooling;integrated",
                "type:dhw;integrated",
                "type:heating;integrated",
                "type:heatpump",
                "type:product;Vitocal_252A"
              ],
              "status": "online"
            },
            {
              "id": "RoomControl-1",
              "fingerprint": "src:0010;33.325.2314.86;46.503.2341.17",
              "modelId": "E3_RoomControl_One_03",
              "modelVersion": "5YQQWkBdOSx-KBX_QNqNtS_-1x4",
              "name": "E3_RoomControl_One_03",
              "type": "roomControl",
              "roles": [
                "capability:monetization;FTDC",
                "capability:monetization;OWD",
                "capability:zigbeeCoordinator",
                "type:E3",
                "type:virtual;smartRoomControl"
              ],
              "status": "online"

Das System lief seit Juli 2024 ohne Probleme. Was mache ich falsch?

Danke im voraus für Hilfe.

Hi wieral,

kannst du mir das gw.json aus deinem Logverzeichniss schicken?
Bitte schaue auch ob das Datum des gw.json aktuell ist.
Kannst du mir außerdem sagen was unter attribute in serial und installationID eingetragen ist?
Hast du oben bei set selectDevice zur Auswahl? Und was wird dir da angezeigt?

Viele Grüße,
Stefan

Hallo Stefan,

vielen Dank für deine schnelle Reaktion.

    vitoconnect_serial     7736172168624224
 
unter selectDevice ist   7736172168624224

gw.json

Ok,
das sieht eigentlich gut aus.

Ist unter Attributen auch das Attribut vitoconnect_installationID gesetzt?
Wenn nicht führ bitte mal das set selctDevice aus.
Danach sollte vitoconnect_installationID und vitoconnect_serial gestezt sein und es sollte alles funktionieren.

Ich bin mir nicht sicher wie es dazu bei dir kam. Eventuell war eine vitoconnect_serial gesetzt aber keine Installation ID?
Ich hätte im Status dann aber die Meldung erwartet, dass du set selectDevice ausführen sollst.

Die 2 Warnings habe ich gefunden und gefixed:
2025.02.04 11:20:24.664 1:  PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 3697.
2025.02.04 11:20:24.664 1:  PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 3702.

Gruß,
Stefan

Hallo Stefan,

habe das Attribut vitoconnect_installationID geprüft und set selctDevice noch einmal ausgeführt.
Keine Änderung.

2025.02.04 12:42:50.331 1:  viessmann - Device not found: Optolink prüfen!
2025.02.04 12:43:25.816 1:  viessmann - Device not found: Optolink prüfen!
2025.02.04 12:43:53.164 1:  viessmann - Device not found: Optolink prüfen!

Ok,

danke für den Screenshot!
Wie kommt denn "vitoconnect_device 1" da hin?
Das ist von meinem Vorgänger mal vorgesehen worden und switched auf ein weiteres Device.
Solch ein Setup ist mir noch nicht unter gekommen. Da müsste an einem Gateway 2 Devices installiert sein.
Weiß nicht ob es sowas geben kann.
Auch mein Vorgänger hatte geschrieben dass er dies nicht testen kann.

Du hast doch sicher nur ein Device, oder?
Setze das Attribut mal auf 0.
Löschen sollte auch gehen, aber versuch erstmal mit 0.

P.S.: Bitte gib mir Rückmeldung ob es hilft, wenn es geht auch eine Erklärung wie es dazu kommt.
Vielleicht kann ich ja am Modul etwas verbessern um solche Situationen zu verhindern.
Normalerweise würde ich das gerne in den selectDevice setter mit integrieren.
Da ich aber nicht weiß wie solch ein Setup aussieht ist das schwierig für mich.

Gruß,
Stefan

Hallo Stefan,

Das war der Fehler. Alles Funktioniert wieder.
Woher das Attribut kam kann ich nicht erklären.

Gruß und vielen Dank.

Ok,
super dass es wieder geht.
Eigentlich wird das Attribut nicht vom Coding gesetzt.

Ich kenne leider die Historie dazu nicht, sonst würde ich es entfernen und erst wenn jemand so ein Setup hat es richtig einbauen, so dass es Automatisch gesetzt werden kann.
Ich bezweifle fast dass es für eine Serial mehr als ein Device geben kann.

Naja, Hauptsache es tut bei dir und ich konnte 2 Warnings entfernen.

Viele Grüße und weiterhin viel Spaß mit dem Modul,
Stefan

Ok, es liegt eine neue Version in meinem Git zum Testen mit ein paar kleinen Bugfixes um Warnings loszuwerden.

Wenn kein Wiederspruch kommt die nächsten Tage im SVN.

Gruß,
Stefan

Update ist morgen im SVN.

Hallo,

ich bekomme seit einem Neustart meiner Heizung jetzt auch die Fehlermeldung "Device not found: Optolink prüfen"
Bei Neustart von Fhem ist kurz zu sehen, dass der Login an der API funktioniert. Aber danach bleibt dieser Fehler.

Hi jemu75,

schick mir bitte mal alle deine am Device gesetzten Attribute und bitte auch die gw.json Datei.
Sollte sie nicht aktuell sein mach bitte ein set logResponseOnce.
Sag mir bitte auch mal was du unter set selectDevice zur Auswahl hast.

Da bin ich ja gespannt ob bei dir auch das Attribut vitoconnect_device umgefallen ist.

Danke und Gruß,
Stefan

Hi Stefan,

vielen Dank erstmal für die schnelle Rückmeldung. Habe eben gesehen, dass mein FHEM-Log seit gestern mit unzähligen Einträgen vollgelaufen ist, da das Modul scheinbar sehr viele API-Anfragen gestellt hat. Seit heute Mittag meldet die API auch, dass die Anzahl der Anfragen überschritten ist.
2025.02.06 13:06:29 1: vitoconnect - Device not found: Optolink prüfen!
2025.02.06 13:08:18 1: vitoconnect - Anzahl der möglichen API Calls in überschritten!

Anbei erstmal ein List von meinem Device
Internals:
   DEF        xxx@xxx.de pw 120
   FUUID      xxx
   FVERSION   98_vitoconnect.pm:v0.6.3-s29620/2025-02-04
   NAME       vitoconnect
   NR         374
   Redirect_URI http://localhost:4200/
   STATE      Anzahl der möglichen API Calls in überschritten!
   TYPE       vitoconnect
   apiKey     xxx
   counter    0
   eventCount 5848
   intervall  120
   login      ok
   refresh_token xxx
   timeout    15
   user       info@jateam.de
   HELPER:
     PACKAGE    main
     VERSION    0.6.3
     VERSION_API unused
     VERSION_CTZ unused
     VERSION_ErrCodes unused
     VERSION_SMUtils 1.28.3
   READINGS:
   
Attributes:
   alias      Vitodens 343-F
   event-on-change-reading Soll_Temperatur,Solar_Sensor_Temperatur_Kollektor,Solar_Sensor_Temperatur_WW,WW-Isttemperatur,HK1-Vorlauftemperatur,Brenner_1_Modulation,Brenner_1_Starts,Brenner_1_aktiv,state
   group      Heizung
   room       HAR
   userReadings Soll_Temperatur {if(ReadingsVal("$name","HK1-Solltemperatur_reduziert_aktiv", 0) eq 1) {return ReadingsVal("$name","HK1-Solltemperatur_reduziert", 0)} else {return ReadingsVal("$name","HK1-Solltemperatur_normal", 0)}}
   vitoconnect_gw_readings 1
   vitoconnect_serial xxx


Ach, vergessen.  ;D
Wo finde ich denn die gw.json?

Ok da fehlt die istallationID.

Eine serial hast du gesetzt, da steht nicht in echt xxx, oder?

Ich hätte erwartet das er die installationID von alleine füllt.
Da schaue ich nochmal im Coding was passiert wenn nur serial aber keine installationID gesetzt ist.
Ich schaue auch warum er da Runden dreht, sollte er nicht und die API Calls nicht aufbrauchen wenn er eh in Fehler geht.

Mach mal bitte ein set selectDevice und schicke dann nochmal die Attribute.
Die gw.json ist im fhem log Verzeichniss.

P.S.:
Sehr seltsam, er sollte die Attribut vitoconnect_installationID automatisch in deinem Fall erzeugen und laufen.
Ich werde deine Situation versuchen nachzustellen.

Auf jedenfall solltest du dein Problem lösen können sobald vitoconnect_installationID gesetzt ist.
Das sollte wenn es jetzt nicht automatisch geht mit einem set selectDevice passieren.
Falls das auch nicht geht kannst du die installationID im gw.json finden und manuell reinschreiben.

Deine API Calls werden heute Nacht um 12 bzw. 1 Uhr zurückgesetzt.
Danach sollte dann alles gehen sobald eine vitoconnect_installationID gesetzt ist.


Gruß,
Stefan

Hallo Stefan,

ich hatte alle persönlichen Daten mit "xxx" ersetzt. An den Stellen waren (hoffentlich) korrekte Werte.
Anbei die gw.json

In dem List hatte ich noch das unterschlagen:
devices:
     7555115604618101:
       gatewayType Lancard
       installationId 4127
       version    1.2.12.0

Ich hoffe das hilft erstmal weiter  ;)

Beste Grüße
Jens :)

Wow, ja das hilft sehr, danke!

Deine InstallationID ist tatsächlich 4-stellig! Die kenne ich viel länger.
Ich prüfe beim Setzen von vitoconnect_installationID auf mindestens 5 Stellen und werfe einen Fehler, wenn sie kürzer ist.
Beim automatischen Setzen aus dem Coding wurde der Fehler nicht abgefangen.
Der Fehler an sich plant einen neuen Zyklus ein.
Das Coding lief aber weiter und führte im weiteren Verlauf zu einem weiteren Fehler wegen der fehlenden InstallationID, was zum Einplanen eines zweiten Zyklus führte.
Somit die vielen Timer und API-Calls.

Ich habe die Prüfung nun auf 2-stellige InstallationIDs entschärft, das Fehlerhandling repariert und es sollte nun alles klappen.
Bitte starte nach dem Update FHEM neu, damit alle Timer verschwinden.
Da sind sicher viele bei dir am Laufen.

Eine Frage in eigener Sache:
Als Gateway-Typ steht bei dir "Lancard".
Ist das eine Vitocal mit so einer ganz neuen LAN-Karte oder etwas Älteres, da die InstallationID wirklich sehr klein ist im Vergleich zu denen, die ich kenne.
Was für eine Anlage hast du?

Die neue Version ist schon im Git und wird morgen per Update in FHEM verfügbar sein.

Sorry für die Unannehmlichkeiten und die aufgebrauchten API Calls.
Mit so einer kurzen installationID hatte ich einfach nicht gerechnet.
Wie gesagt nachdem du die neue Version hast und durchgestartet sollte er im normalen Rythmus anfragen.
Deine API Calls werden für den Tag aufgebraucht sein, aber ab 12 bzw. 1 Uhr nachts sollte es dann wieder gehen.

Viele Grüße,
Stefan

Hallo Stefan,

ich habe das Device einmal neu angelegt (dann "set passwort", dann "set apiKey") und danach update (+shutdown restart) gemacht.

jetzt sieht das list wie folgt aus: (email, apikey und refreshtoken habe ich hier im Post "ge-xxxt")
Internals:
   DEF        xxx@xxx.xx fakePassword 120
   FUUID      67a50988-f33f-b88d-0b0c-50293093ad8c460c
   FVERSION   98_vitoconnect.pm:v0.7.0-s29627/2025-02-06
   NAME       vitodens
   NR         447
   Redirect_URI http://localhost:4200/
   STATE      unbekannter Fehler, bitte den Entwickler informieren!
   TYPE       vitoconnect
   apiKey     xxx
   counter    0
   eventCount 7
   intervall  120
   login      ok
   refresh_token xxx
   selectedDevice 7555115604618101
   timeout    15
   user       xxx@xxx.de
   HELPER:
     PACKAGE    main
     VERSION    0.7.0
     VERSION_API unused
     VERSION_CTZ unused
     VERSION_ErrCodes unused
     VERSION_SMUtils 1.28.3
   READINGS:
     2025-02-07 10:05:45   state           unbekannter Fehler, bitte den Entwickler informieren!
   devices:
     7555115604618101:
       gatewayType Lancard
       installationId 4127
       version    1.2.12.0
Attributes:
   alias      Vitodens 343-F
   group      Heizung
   room       HAR
   vitoconnect_installationID 4127
   vitoconnect_serial 7555115604618101


Hi jemu75,

das sieht aus wie erwartet, vitoconnect_installationID und vitoconnect_serial sind gesetzt.
Damit wird die Anfrage eigentlich richtig gestellt.
Könntest du mal Verbose hochstellen und mir die Ausgabe schicken?

Ich schaue mal in welchem Fall er in "unbekannter Fehler, bitte den Entwickler informieren!" hinein läuft.
Melde mich gleich wieder.

Gruß,
Stefan

Ok, schau erstmal ins FHEM log.
Nach der Zeile "unbekannter Fehler, bitte den Entwickler informieren!"
Muss es eine weitere Zeile geben mit den Rückgabe Werten der API.
Da sollten wir erkennen was der API nicht passt.

Gruß,
Stefan

aktuell sieht das log wie folgt aus
2025.02.07 10:07:45 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:07:45 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:09:46 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:09:46 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:11:46 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:11:46 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:13:46 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:13:46 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:15:47 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:15:47 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:17:47 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:17:47 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:19:48 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:19:48 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:21:48 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:21:48 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:23:49 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:23:49 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:25:49 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:25:49 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:27:50 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:27:50 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:29:50 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:29:50 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:31:50 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:31:50 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:33:51 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:33:51 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:35:51 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:35:51 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:37:52 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:37:52 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:39:52 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:39:52 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:41:52 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.07 10:41:52 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
2025.02.07 10:43:53 1: PERL WARNING: Use of uninitialized value $a[1] in subtraction (-) at ./FHEM/99_Utils.pm line 21.
2025.02.07 10:43:53 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/99_Utils.pm line 21.


Ok,

jetzt wird es aber wild.
Die API scheint diesen Fehler auszuspucken.

Eine Idee wäre das irgendwie ein falsches Device verwendet wird. Vielleicht ist das bei so einem LAN Modul anders aufgebaut.
Kannst du bitte ein logRespnseOnce ausführen und mir alle .json Dateien aus dem FHEM Log Verzeichnis schicken?
Device ist per Standard 0.
Sollte es bei dir anders sein müssen kann man das per vitoconnect_device setzen.

Was sagt deine Anlage, ist sie verbunden mit Wifi oder LAN und hat sie Verbindung zu Viessmann?
Geht denn bei dir die ViCare App?
Wie ist da deine Anlage aufgebaut?

Du kannst auch gerne mal Verbose 5 einschalten und mir das log schicken.
Eventuell kann ich dann noch genau sehen welcher API Call das meldet.

Um einen Fehler im FHEM Modul auszuschließen kannst du eventuell nochmal mit einer alten Version des Moduls testen?
Ich würde dort den selben Fehler erwarten.


Gruß,
Stefan

Hi Stefan,

manchmal ist ne kurze Pause gut. Wollte eben nach dem Mittag das logReponseOnce machen und siehe da, meine Device ist wieder mit der API verbunden.  :D

Ich bin dir noch eine Antwort von gestern schuldig.
Ich habe eine Vitodens 343-F mit LAN-Modul (eingebaut 2016) hier stehen. Also nicht "ganz neu" ;)

Vielen Dank auf jeden Fall, dass Du dich hier so engagierst und super schnell reagiert hast. Ich finde es auch gut, dass Du das Modul weiterentwickelst.

Beste Grüße
Jens :)

Hi Jens,

puh, das ist gut.

Super, dass es jetzt geht und wir den Fehler mit der zu kurzen InstallationID und dem Fehlerhandling beheben konnten.
So wird das Modul immer robuster.
Den Fehler "DEVICE_COMMUNICATION_ERROR" nachdem alles gepasst hatte und der sich selbst geheilt hat verstehe ich aber nicht.
Vielleicht ein kurzzeitiges Problem mit der API.

Eventuell werde ich noch ein paar mehr Infos ins Device speichern, sodass ich beim List direkt sehen kann, was los ist, ohne nach gw.json fragen zu müssen.

Das gehe ich für eine nächste Version an.
Falls weitere Erweiterungswünsche bestehen, gerne melden.

P.S.: Was hast du da für ein cooles FHEM Design? FhemAPP, hatte ich noch gar nicht auf dem Schirm, schaue ich mir an.
Vielen Dank nochmal für deine Hilfe beim Finden der Bugs.

Viele Grüße,
Stefan

Hi Stefan,

ich nutze FHEMApp als Frontend.

siehe auch:
Github (https://github.com/jemu75/fhemApp#readme) bzw. auch hier im Forum unter dem Bereich Frontends.

Beste Grüße und einen schönen Start ins Wochenende!
Jens  :)

Danke, das schaue ich mir auf jeden fall mal an.

Schönes Wochenende,
Stefan

Hallo Stefan,

ich wollte nochmal ein kurzes Feedback geben. Bei mir sind heute zeitweise nochmal Fehler im log aufgetaucht.

2025.02.07 10:41:52 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren! 2025.02.07 10:41:52 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message: error: 2025.02.07 10:43:53 1: PERL WARNING: Use of uninitialized value $a[1] in subtraction (-) at ./FHEM/99_Utils.pm line 21. 2025.02.07 10:43:53 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/99_Utils.pm line 21.

Hast du einen Tipp, wie ich dem Problem noch besser auf den Grund gehen kann?

Grüße
Jens  :)

Hallo Stefan,

vielen Dank noch mal für die Überarbeitung des Moduls und das einchecken ins SVN.

Das Passwort und APIkey Löschen hat noch nicht funktioniert, da $kName nicht gesetzt wird.
Ich habe es bei mir jetzt mal abgeändert, so funktioniert es:
#####################################################################################################################
# verschlüsselte Werte löschen
#####################################################################################################################
sub DeleteKeyValue {
    my ($hash,$kName) = @_;    # Übergabe-Parameter
    my $name = $hash->{NAME};

    Log3( $name, 5,$name." - called function Delete()" );

    my $index = $hash->{TYPE}."_".$hash->{NAME}."_passwd";
    setKeyValue( $index, undef );
    my $index = $hash->{TYPE}."_".$hash->{NAME}."_apiKey";
    setKeyValue( $index, undef );

    return;
}
Was mir noch aufgefallen ist (war glaube ich auch schon bei dem alten Modul):
Das Reading heating.controller.serial.value hat bei mir nur eine reihe an Replacement Character.
heating.controller.serial.value  ����������������in der resource_**.json sieht es so aus:
    {
      "feature": "heating.controller.serial",
      "gatewayId": "********",
      "deviceId": "0",
      "timestamp": "2025-02-05T13:08:27.006Z",
      "isEnabled": true,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/******/gateways/*******1/devices/0/features/heating.controller.serial",
      "properties": {
        "value": {
          "type": "string",
          "value": "����������������"
        }
      },
      "commands": {}
    },Scheint als schon von der API so zu kommen, Ist das bei euch auch so?

Viele Grüße
Schlimbo

In der Viessmann API Doku habe ich gerade gesehen, dass es auch eine Datenbank der Fehlercodes gibt:
https://documentation.viessmann.com/service-documents/v3#service-documents_List_Errors_From_Database (https://documentation.viessmann.com/service-documents/v3#service-documents_List_Errors_From_Database)

eine komplette Liste kann mit
https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&countryCode=DE&languageCode=de (https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&countryCode=DE&languageCode=de)
abgerufen werden.

oder nur einen einzelnen error code mit:
https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&errorCode=c2&countryCode=DE&languageCode=de (https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&errorCode=c2&countryCode=DE&languageCode=de)

Die materialNumber sind die ersten 7 Stellen der Seriennummer (device.serial).

Über das Modul bekommt man im Reading "device.messages.errors.raw.entries" den Fehler Code z.b.:
"customer, a0, warning, 2025-02-03T17:25:19.000Z"

Es wäre super, wenn das Modul bei vorhandenem "Error-Code" die Fehlermeldungen in Klartext anzeigen könnte.

Hi,
bin gerade in Urlaub. Schaue mir das alles an wenn ich zurück bin. Fehlercodes könnte ich nachschlagen und abspeichern.
Könnte man auch in einem ErrorLast Reading speichern so dass der letzte Fehler erhalten bleibt.
Die Steuerzeichen habe ich in meinem json nicht gesehen.
Über den Communication Error muss ich mal Nachdenke und Nachlesen. Kann es sein dass du wirklich kurzzeitig die Verbindung verlierst?

Viele Grüße,
Stefan

Ich wollte hier mal ein großes Dankeschön an stefanru für die Weiterentwicklung des Moduls loswerden.
Ich habe ein Update gemacht (hat problemlos geklappt) und auf Raw Readings umgestellt. Das hat ein wenig Arbeit gemacht, die sich aber gelohnt hat.

Eine Geschichte ist aber geblieben (liegt sicher nicht am vitoconnect-Modul):
Ich habe eine Vitodens 200-W Gas-Brennwertheizung mit einem Vitoconnect OPTO2 Kommunikationsmodul.
Das Reading "heating.boiler.temperature.value" liefert immer mal wieder unsinnige Werte (> 6000 !). Das war auch in der alten vitoconnect-Version schon so.
Ich habe das Problem vor einiger Zeit mal im Viessmann-Forum gepostet, aber nie eine Antwort erhalten.
Mein Workaround ist ein userReading, das nur die plausiblen Werte verwendet.

Hi,

erstmal vielen Dank für den tollen Input. Ich werde versuchen, alles umzusetzen.

@jemu75:
Ich habe im Viessmann-Forum gesehen, dass es eventuell noch erweiterte Infos zum Fehler geben kann.
Da ich es bei mir nicht nachstellen kann und so nicht nachschauen kann, wo die Infos versteckt sind, schreibe ich nun im Fehlerfall ins FHEM-Log-Verzeichnis eine Datei vitoconnect_[serial].err. In diese Datei wird das ganze Antwort-JSON gedumpt. Es wäre super, wenn du mir bei deinem nächsten Fehler diese Datei zukommen lassen könntest.

@Schlimbo:
Vielen Dank für das korrigierte DeleteKeyValues.
Ich habe es übernommen und nach vitoconnect_DeleteKeyValues umbenannt, sodass es zum Modul passt.
Die Serial bei dir sieht echt komisch aus.
Bei mir kommt sie sauber zurück. Das scheint ein Problem bei deiner Anlage zu sein.

{ "feature": "heating.controller.serial", "gatewayId": "7637415075136238", "deviceId": "0", "timestamp": "2025-02-05T13:16:30.394Z", "isEnabled": true, "isReady": true, "apiVersion": 1, "uri": "https://api.viessmann.com/iot/v2/features/installations/2772216/gateways/7637415075136238/devices/0/features/heating.controller.serial", "properties": { "value": { "type": "string", "value": "7659552411XXXXXX" } }, "commands": {} }

Da müsstest du wahrscheinlich wirklich Viessmann fragen, warum deine Serial nicht korrekt in der API gemeldet wird.

Das mit der Error-Datenbank ist super interessant und ich habe schon mal damit gespielt.
Bei meinem Vitoladens funktioniert es wunderbar.
Meine neuere VoitCal 250 hat aber leider noch keine Dokumente im System:

{ "viErrorId": "req-86cd5590ec9f4aaebf19e82c60487aa6", "statusCode": 404, "errorType": "RESOURCE_NOT_FOUND", "message": "Required resource of type ServiceDocument was not found", "extendedPayload": { "resourceType": "ServiceDocument", "errorType": "DOCUMENT_MISSING" } }

Ich werde die Fehlerauflösung bei Gelegenheit einbauen.

@JWRu:
Solch einen Fehler habe ich bei mir nicht. Könnte es sein, dass dein Sensor ein Problem hat und manchmal wirklich falsche Werte liefert?
Ich könnte natürlich solche Ausreißer im Modul behandeln. Damit würde man falsche Messwerte oder fehlerhafte Sensoren aber auch verstecken.
Gibt es bei anderen Verwendern des Moduls auch Ausreißer bei Sensorwerten?


Eine neue Version des Moduls liegt im GIT und wenn kein Einspruch kommt für morgen auch im SVN.

Viele Grüße,
Stefan

Hallo, hier nur eine kurze Info zur Fehlermeldung meiner Anlage VC-222 - vermutlich wegen Wartungsarbeiten bei Viessmann.
Die ViCare App zeigte zur selben Zeit ebenfalls keine Infos an
Meldung dort: Ihre Anlage hat ein Problem ...
Ein Ping auf die Anlage zeigte an, dass diese im Netz ansprechbar war...
Am Display der Anlage war alles in Ordnung (Meldung Okay ...)

Hier kurz der Auszug aus dem LOG - weil unbekannter Fehler gemeldet werden sollte ...
Logfile FHEM alle 20 Minuten VIessmann Logs
...
2025.02.16 15:03:35 2: Viessmann Ereignis Stromverbrauch_Total/Jahr: 55.4,292.6.
2025.02.16 15:03:35 2: Viessmann Ereignis Gasverbrauch_aktuelle_Woche: 59.2.
2025.02.16 15:03:35 2: Viessmann Ereignis Gasverbrauch_aktueller_Monat: 147.6.
2025.02.16 15:03:35 2: Viessmann Ereignis Gasverbrauch_aktuelles_Jahr: 401.
2025.02.16 15:03:35 2: Viessmann Ereignis Gasverbrauch_total_akt_Monat: 147.6.
2025.02.16 15:03:35 2: Viessmann Ereignis Stromverbrauch_aktuelles_Jahr: 55.4.
...
Dann Fehlermeldung
2025.02.16 15:23:36 1: Viessmann - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.16 15:23:36 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/98_vitoconnect.pm line 3756.
2025.02.16 15:23:36 1: Viessmann - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
...
2025.02.16 15:43:37 1: Viessmann - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.16 15:43:37 1: Viessmann - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
Neustart FHEM
2025.02.16 15:47:38 1: Viessmann - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.16 15:47:38 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/98_vitoconnect.pm line 3756.
2025.02.16 15:47:38 1: Viessmann - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
...
2025.02.16 16:07:38 1: Viessmann - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.16 16:07:38 1: Viessmann - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
...
2025.02.16 16:27:39 1: Viessmann - unbekannter Fehler: Bitte den Entwickler informieren!
2025.02.16 16:27:39 1: Viessmann - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message:  error:
usw.
ab 17:07 ist die Anlage wieder erreichbar

LG Carsten

Hi cnkru,

ok, sieht ja aus wie erwartet.
Nur diese Zeile stört mich.
2025.02.16 15:47:38 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/98_vitoconnect.pm line 3756.

Kannst du mir bitte deine Version des Moduls schicken dann behebe ich diesen Fehler noch falls es nicht schon geschehen ist in den neueren Versionen.

Danke und Gruß,
Stefan

Ok ich habe lieber etwas weiter entwickelt.
Ich habe im GIT eine erste Version die die Error Codes mapped.
Diese benötigt aber use HTML::Entities; use HTML::Strip;
Am besten installieren mit:
Für HTML::Entities:
sudo apt-get install libhtml-parser-perl

Für HTML::Strip:
sudo apt-get install libhtml-strip-perl

Muss mich jetzt aber erstmal schlau machen wie ich sowas offiziell ausliefere, da das update bei vielen zum nicht funktionieren des Moduls führen wird da ich neue Abhängigkeiten eingeführt habe.

Wäre schön wenn einige von euch die neue Version aus dem GIT testen könnten.

Gruß,
Stefan

ZitatIch könnte natürlich solche Ausreißer im Modul behandeln. Damit würde man falsche Messwerte oder fehlerhafte Sensoren aber auch verstecken.

Ich denke, das ist nicht notwendig - wahrscheinlich eher ein Einzelfall.
Ich habe das mit einem einfachen userReading behoben:
heating.boiler.temperature.value.corrected:heating.boiler.temperature.value.*
{ if(ReadingsNum("$name","heating.boiler.temperature.value",1000)<100) { ReadingsNum("$name","heating.boiler.temperature.value",0) }
  else { ReadingsNum("$name","heating.boiler.temperature.value.corrected",0)} }

aktuelle Version aus dem GIT hab ich mal auf meinem Testsystem laufen
FVERSION 98_vitoconnect.pm:v0.7.5-s29593/2025-01-29

libhtml-parser-perl - war auf meinem System bereits installiert

2025.02.17 10:29:12 0: Server shutdown
2025.02.17 10:29:18 1: Including fhem.cfg
2025.02.17 10:29:21 3: WEB: port 8083 opened
2025.02.17 10:29:22 2: eventTypes: loaded 488 lines from ./log/eventTypes.txt
2025.02.17 10:29:40 3: Vito_300w - Passwort war bereits gespeichert

Danke für die Rückmeldungen.

Ich habe die neue Funktionalität nochmal überarbeitet und komme nun ohne die HTML-Libs aus.
Die Error-Texte liefere ich erstmal in Englisch, sonst müsste ich noch UTF-8-Handling einbauen.
Das kann aber noch nachgeliefert werden.

Fehler werden nun in neuen Readings abgelegt:
device.messages.errors.mapped.0.faultCode C2
device.messages.errors.mapped.0.faultCodes.0.cause Compressor power supply fault or phase monitor faulty
device.messages.errors.mapped.0.faultCodes.0.measure Check connections, power supply and phase connection. Check phase monitor.
device.messages.errors.mapped.0.systemCharacteristics Compressor stops.

Diese Readings werden nicht gelöscht, wenn der Fehler behoben ist.
Am Zeitstempel sieht man aber, dass sie alt sind.
device.messages.errors.raw.entries ist dann aber wieder leer.

Was meint ihr? Readings behalten oder lieber auch wieder löschen?

Führt die Abfrage des Error-Codes zu einem 404 bei Viessmann, weil dort keine Dokumente hinterlegt sind, wie z.B. zur Zeit bei meiner Vitocal, schreibe ich dies ins Log.

Ich habe nun eine neue Version des Moduls auf GitHub und werde diese morgen ins SVN übernehmen. Die Änderungen sind:

  "0.7.6"  => "17.02.2025  removed usage of html libraries",
  "0.7.5"  => "16.02.2025  Get mapped error codes and store them in readings",
  "0.7.4"  => "16.02.2025  Removed Unknow attr vitoconnect, small bugfix DeleteKeyValue",
  "0.7.3"  => "16.02.2025  Write *.err file in case of error. Fixed DeleteKeyValue thanks Schlimbo",
  "0.7.2"  => "07.02.2025  Attr logging improved",
  "0.7.1"  => "07.02.2025  Code cleanups",

P.S:
noch zwei weitere
  "0.7.8"  => "17.02.2025  fixed undef warning thanks cnkru",
  "0.7.7"  => "17.02.2025  introduced set clearMappedErrors",

Vorab auch wieder im GIT morgen alles im SVN.

Viele Grüße,
Stefan

Hi Stefan,

wow das sind super News, vielen Dank für die Erweiterung. :)

Hatte bis jetzt nur eine einzelne Meldung anstehen, wie ist es wenn mehrere Meldungen zur gleichen Zeit vorhanden sind? zum Beispiel:
device.messages.errors.raw.entries: customer, a0, warning, 2025-02-03T17:25:19.000Z, customer, c5, note, 2025-02-03T16:57:36.000ZWerden dann einfach mehrere Readings angelegt?

zu den Readings:
Ich persönlich fände es besser, wenn die Readings nach einem Fehler auch wieder geleert werden, für History Zwecke finde ich ein externes FileLog-Device sinnvoller.

Da ich mir Störmeldungen der Heizung gerne über Alexa ausgeben möchte, wäre ein Attribut um die Sprache einzustellen super.

In den Texten sind noch Markup-Zeichen enthalten "<q>  </q>". Könntest du diese bitte noch encoden?
device.messages.errors.mapped.0.faultCodes.0.measure
No action required.If the message is constantly present: Check connection at terminal X3.7 (feed) first, then at terminal X3.6 (230 V~) (see <q>Cross connect PCB</q>/<q>Luster terminals</q>).
Im Reading "device.messages.errors.raw.entries" ist auch noch eine Meldeklasse mit angegeben.
customer, a0, warning, 2025-02-03T17:25:19.000ZGesehen habe ich bei mir bisher: "note", "warning", "error" oder "criticalError".
Könntest du für diese auch noch ein extra Reading spendieren?

Wenn eine Meldung ansteht habe ich aktuell noch alle 2 Minuten einen Log Eintrag:
2025.02.17 17:02:38.531 3: vitoconnect, vitoconnect_getErrorCode url=https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&errorCode=c5&countryCode=EN&languageCode=en
2025.02.17 17:02:38.783 3: vitoconnect, vitoconnect_getErrorCode: finished ok
2025.02.17 17:04:39.205 3: vitoconnect, vitoconnect_getErrorCode url=https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&errorCode=c5&countryCode=EN&languageCode=en
2025.02.17 17:04:39.454 3: vitoconnect, vitoconnect_getErrorCode: finished ok
2025.02.17 17:06:39.940 3: vitoconnect, vitoconnect_getErrorCode url=https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&errorCode=c5&countryCode=EN&languageCode=en
2025.02.17 17:06:40.265 3: vitoconnect, vitoconnect_getErrorCode: finished ok
2025.02.17 17:08:40.665 3: vitoconnect, vitoconnect_getErrorCode url=https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&errorCode=c5&countryCode=EN&languageCode=en
2025.02.17 17:08:40.928 3: vitoconnect, vitoconnect_getErrorCode: finished ok
2025.02.17 17:10:41.229 3: vitoconnect, vitoconnect_getErrorCode url=https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&errorCode=c5&countryCode=EN&languageCode=en
2025.02.17 17:10:41.527 3: vitoconnect, vitoconnect_getErrorCode: finished ok
2025.02.17 17:12:42.161 3: vitoconnect, vitoconnect_getErrorCode url=https://api.viessmann.com/service-documents/v3/error-database?materialNumber=7733738&errorCode=c5&countryCode=EN&languageCode=en
2025.02.17 17:12:42.428 3: vitoconnect, vitoconnect_getErrorCode: finished ok
Bei einem reload des Moduls oder einem FHEM Neustart  bekomme ich folgenden Log Eintrag:
2025.02.17 21:40:53.214 1: PERL WARNING: Prototype mismatch: sub main::decode_json ($;$$) vs ($) at /usr/local/lib/perl5/5.36.3/Exporter.pm line 63.
Viele Grüße
Schlimbo

Zitat von: Schlimbo am 17 Februar 2025, 21:53:32Hatte bis jetzt nur eine einzelne Meldung anstehen, wie ist es wenn mehrere Meldungen zur gleichen Zeit vorhanden sind? zum Beispiel:

Code Auswählen Erweitern

device.messages.errors.raw.entries: customer, a0, warning, 2025-02-03T17:25:19.000Z, customer, c5, note, 2025-02-03T16:57:36.000ZWerden dann einfach mehrere Readings angelegt?

Ja genau dafür sind die Nummer (hier zwei mal 0), laut Antwort kann es zu einem faultCode auch mehrere causes und measures geben, ob das wirklich so ist werden wir sehen müssen.
Mit allem kann ich aber mit den beiden Zählern umgehen.
device.messages.errors.mapped.0.faultCodes.0.measure

Zitat von: Schlimbo am 17 Februar 2025, 21:53:32zu den Readings:
Ich persönlich fände es besser, wenn die Readings nach einem Fehler auch wieder geleert werden, für History Zwecke finde ich ein externes FileLog-Device sinnvoller.

Ja das macht Sinn und werde ich so einbauen.

Zitat von: Schlimbo am 17 Februar 2025, 21:53:32Da ich mir Störmeldungen der Heizung gerne über Alexa ausgeben möchte, wäre ein Attribut um die Sprache einzustellen super.

Mit der Spräche habe ich das Umlaut Problem und muss UTF8 einbauen. Ich schaue mal was das für Abhängigkeiten nach sich zieht.

Zitat von: Schlimbo am 17 Februar 2025, 21:53:32In den Texten sind noch Markup-Zeichen enthalten "<q>  </q>". Könntest du diese bitte noch encoden?

Hatte bei mir nur <p>, werde <q> auch entfernen. Ich hoffe es kommt nicht noch mehr vor.
Sonst brauche ich doch die HTML lib.

Zitat von: Schlimbo am 17 Februar 2025, 21:53:32Im Reading "device.messages.errors.raw.entries" ist auch noch eine Meldeklasse mit angegeben.

Code Auswählen Erweitern

customer, a0, warning, 2025-02-03T17:25:19.000ZGesehen habe ich bei mir bisher: "note", "warning", "error" oder "criticalError".
Könntest du für diese auch noch ein extra Reading spendieren?

Klar mache ich.

Zitat von: Schlimbo am 17 Februar 2025, 21:53:32Wenn eine Meldung ansteht habe ich aktuell noch alle 2 Minuten einen Log Eintrag:

Ok setze ich von Verbose 3 auf 4 oder 5.

Zitat von: Schlimbo am 17 Februar 2025, 21:53:32Bei einem reload des Moduls oder einem FHEM Neustart  bekomme ich folgenden Log Eintrag:

Code Auswählen Erweitern

2025.02.17 21:40:53.214 1: PERL WARNING: Prototype mismatch: sub main::decode_json ($;$$) vs ($) at /usr/local/lib/perl5/5.36.3/Exporter.pm line 63.

Hmm, das habe ich bei mir nicht.
War das bei dir schon immer?
Ich schaue mal in der History ob ich an den Imports was geändert habe.
Ich verwende:
use JSON;
use JSON::XS qw( decode_json );

Eventuell habe ich XS eingeführt wegen der Performance, obs wirklich einen unterschied macht sei mal dahin gestellt.


Nochmals vielen Dank für dein Feedback, ist sehr hilfreich.
Ich versuche alles umzusetzen, wird aber ein paar Tage dauern da ich gerade keine Zeit habe.

Viele Grüße
Stefan

json_decode() schafft uU. erst das Umlaut-Problem. JSON->new->decode() macht dieselben Datenstrukturen ohne zwangsläufige UTF8-Unterstellung....

(Unicode First aid-Thread für Details)

Danke Beta-User,

das werde ich ausprobieren.
Dann könnte ich die Fehlertexte in der FHEM Sprache auslesen.

Gruß,
Stefan

 :)
Hoffe, du bist erfolgreich damit - wir bekommen die nächsten paar Tage auch eine Vitodens 200W...

Du darfst also damit rechnen, dass ich mir den Code auch nochmal näher reinziehe und dich ggf. nerve ;D .

Bis dahin auch von meiner Seite erst mal ein herzliches Danke für's Weiterentwickeln dieses Moduls!!!

(Ärgerlich, dass die bei Viessmann auch auf den Cloud-only-Zug gestiegen sind, den CAN-Teil werde ich mir dann auch bei Gelegenheit mal in Ruhe ansehen.)

@Beta-User
Ja openE3 (CAN Bus) sieht sehr interessant aus und scheint auch einfach per MQTT anzubinden zu sein.
Wegen fehlender Zeit und auch eventueller Garantie wollte ich aber erstmal bei der offiziellen Schnittstelle bleiben.
Weiß nicht was Viessmann sagt wenn man Parameter ändert an die man offiziell über die API gar nicht kommt.

Insgesamt muss ich sagen ist Viessmann mit ihrer Politik schräg drauf.
Alles zunageln, selbst für einfache Datenpunkte ein Abo Modell zu verlangen und vor allem kein direkten Kundenkontakt nur über Heizungsbauer, ist schon nervig.
Hatte jetzt ein paar Probleme mit meiner Anlage bei denen mein Heizungsbauer nicht weiter wusste.
Das lief dann immer über stille Post mit dem Heizungsbauer als Mittelsmann.
Sehr nervig und Zeitaufreibend.

Zum Modul:
Ich habe es ja übernommen und angepasst.
Es sind sicher noch einige Leichen im Keller und auch hat es einen dicken Overhead da ich die Kompatibilität der alten Mappings (SVN, Roger) mit rumschleppe.
Beim Raw Mapping bin ich auf einige Unzulänglichkeiten der Viessmann API gestoßen und musste hässliche Workarounds bauen die aber gut funktionieren.

Input und Verbesserungsvorschläge sind ausdrücklich erwünscht und es wäre toll wenn noch jemand sich den Code anschaut und Ideen und Verbesserungen einbringt.

Dann hoffe ich mit deiner Heizung geht alles glatt und freu mich auf Feedback.

Viele Grüße,
Stefan

Hi,

habe doch etwas Zeit gefunden.

Habe versucht alles umzusetzen.

Sprache: Wird aus dem Attribut language vom global device genommen.
Steht dort DE wird es deutsch.
@Beta-User: Danke dein Tipp hat geholfen und die Umlaute waren nun ok.

Markup: Es wird nun auch <q> </q> entfernt.

Severity: Da "note", "warning", "error" oder "criticalError" nicht in der Rückgabe kommt nehme ich es aus der Raw message und übersetze es selbst wenn DE gesetzt ist. Sie landet in device.messages.errors.mapped.0.severity

Log Meldungen: Die 2 Meldungen werden nur noch mit Verbose 5 ausgegeben.

Prototype mismatch: Ich habe JSON::XS wieder entfernt.
@Schlimbo, schaue bitte mal ob das hilft.

Löschen der Mapped Errors und File schreiben:
Ich habe mich erstmal gegen das automatische Löschen entschieden.
Immerhin sind Fehler eine Sondersituation und man muss sie für gewöhnlich sogar an der Heizung bestätigen.
Außerdem würde ich so einen Fehler der Nachts auftrat und sich selbst "geheilt" hat gern morgens im FHEM sehen.
Man kann die Fehler aber mit set <devicename> clearMappedReadings löschen.

Gegen das File schreiben habe ich mich auch erstmal entschieden. Ich müsste dann immer prüfen ob der Fehler schon drinsteht um nicht immer und immer wieder den selben Fehler ins Logfile zu schreiben.
Aber beim überdenken habe ich gemerkt, dass keiner der bisherigen File handles geschlossen wurde. Das habe ich gefixt.

Ich hoffe damit ist alles umgesetzt oder habe ich etwas vergessen?
Falls das mit löschen der mapped Errors und File schreiben doch gern anders gewünscht wird können wir natürlich darüber reden. Bitte mit Vorschlägen wie es am besten gehandhabt werden kann.

Neue Version ist im GIT.
Fix Text ist: enhanced error mapping now also language dependent, closing of file_handles, removed JSON::XS

Morgen dann auch im SVN.

Gruß,
Stefan

Hi Stefan,

funktioniert alles, und "Prototype mismatch" ist mit der Version auch behoben.

zu "Löschen der Mapped Errors": kein Thema, passt für mich auch.  :)
zu "Gegen das File schreiben habe ich mich auch erstmal entschieden.": Sorry, da habe ich mich vielleicht nicht klar ausgedrückt. Ich meinte nicht, dass hierzu etwas in das Modul aufgenommen werden sollte. Mein Ansatz war, dass man sich einfach selbst eine Log-Datei anlegt, wenn man die Meldungen speichern möchte:
define Viessmann_errorLog FileLog ./log/Viessmann_errorLog-%Y-%m.log vitoconnect:device.messages.*
Mir ist jetzt aber noch etwas anderes aufgefallen, das scheinbar schon länger vorhanden ist und nichts mit den letzten Änderungen im Modul zu tun hat:
Sobald ich die Detailansicht meines vitoconnect-Devices öffne, werden Mehrbyte-Zeichen (Umlaute & ß) in der FHEM-Weboberfläche nicht mehr korrekt angezeigt.
"Büro" wird in der Raumauswahl als "Büro" dargestellt.
Klicke ich jedoch auf einen anderen Raum, werden die Umlaute wieder korrekt angezeigt.
Ich weiß nicht, ob das mit dem Modul zusammenhängt, aber es scheint, als würde vitoconnect die Codierung der gesamten Webansicht ändern.
Weißt du an was das liegen könnte?

Das habe ich dazu im Forum gefunden: https://forum.fhem.de/index.php?topic=55539.0 (https://forum.fhem.de/index.php?topic=55539.0)
Der Beitrag ist aber schon sehr alt und das Problem wurde damals scheinbar gefixt.

Hi Schlimbo,

danke für die Rückmeldung und super dass alles auf Anhieb funktioniert.

Das Umlautproblem habe ich bei mir nicht, siehe Screenshot.
Hast du irgendeinen besonderen Skin?
Das konnte ich jetzt nicht testen.
Ich habe nichts wegen UTF8 ins Modul gebaut und finde auch erstmal nichts was es auslösen könnte.

Hast du gerade Fehlermeldungen mit Umlauten im Device?
Oder wird deine komische Seriennummer angezeigt?
Ich vermute dass eines der Zeichen ein Problem verursacht, wahrscheinlich die seltsamen Zeichen deiner Seriennummer.
Du könntest das Device mal disablen und die kritischen Readings eins nach dem anderen löschen.
Sollte es die Seriennummer sein könnte ich das rausfiltern im Modul.

Gruß,
Stefan

Tatsächlich,es liegt an der komischen Seriennummer.
Lösche ich das Reading "heating.controller.serial.value" werden die Umlaute korrekt angezeigt.

Danke für den Tipp

Hi Schlimbo,

ich habe mal etwas versucht um nicht druckbare Zeichen zu entfernen aus dem JSON.
Kannst du die angehängte Version mal bei dir testen?

Gruß,
Stefan

Guten Morgen Stefan,
hat nicht geklappt, die Zeichen sind weiterhin vorhanden.
LG Schlimbo

Zitat von: stefanru am 20 Februar 2025, 00:35:34ich habe mal etwas versucht um nicht druckbare Zeichen zu entfernen aus dem JSON.

Nach meinen Erfahrungen mit RHASSPY bringt es "relativ wenig", mit den vielen (de-) Codier-Optionen groß rumzuexperimentieren - jedes System ist etwas anders, und sobald man es für den einen passend hat, bringt man woanders was durcheinander...

Vielleicht sollten wird das Codierungs-Thema gesondert behandeln, auch damit sich Rudi mal mit dem FHEMWEB-Darstellungsthema auseinandersetzen kann (ohne sich groß mit den Details zum Modul ansonsten rumplagen zu müssen)?

Eventuell zielführende Infos wären
- OS, auf dem FHEM läuft
- Perl-Version
- Einstellung für Codierung in FHEM (schon bytestream?) und natürlich die Version
- tritt das Problem mit verschiedenen Browsern und Zielsystemen auf?
- Was passiert, wenn man die ganze Seite neu läd? (Cache etc.).
- Möglichkeit, das mit aktivierter bytestream-Option man separat auf einem "frischen FHEM" zu testen?
- Gibt es Optionen auf der Gegenstelle (dem cloud-Dienst)?

Zur Gegenstelle allgemein: Die _sollte_ eigentlich "sauberes UTF8" liefern - soweit ich mich entsinne, ist das die Konvention für JSON. Vielleicht ist das auch einfach ein Bug auf dieser Seite, den man adressieren müßte?

Hi Beta-User,

meine bisherige Einschätzung ist dass hier ein Bug auf der Sender Seite vorliegt.
In dem Teil des JSON sollte eine Seriennummer bestehend aus Zahlen stehen.

Bei Schlimbo kommt aber "value": "����������������".
Sonst hat niemand den Fehler.

Sieht nach irgend einem Codierungsproblem des JSON nur für die Seriennummer und nur bei Schlimbos Setup aus.
Alles andere ist ok in Schlimbos JSON.

Ich werde nochmal auf der Viessmann Developerseite nachsehen ob irgendetwas zur Codierung des JSON steht.
Ansonsten versuche ich erstmal den einen Wert bei Schlimbo zu entfernen, bzw. das JSONB auf darstellbare Zeichen zu reduzieren.

Gruß,
Stefan

Ok, @Schlimbo, neue Version zum testen.
Unbekannt Zeichen sollten nun als [VUC] gefiltert werden.

Hi Stefan,

danke damit klappt es.
Im Reading "heating.controller.serial.value" steht jetzt "[VUC]" und die Umlaute sind wieder richtig.

Zitat von: Beta-User am 20 Februar 2025, 08:08:45Eventuell zielführende Infos wären
- OS, auf dem FHEM läuft
- Perl-Version
- Einstellung für Codierung in FHEM (schon bytestream?) und natürlich die Version
- tritt das Problem mit verschiedenen Browsern und Zielsystemen auf?
- Was passiert, wenn man die ganze Seite neu läd? (Cache etc.).
- Möglichkeit, das mit aktivierter bytestream-Option man separat auf einem "frischen FHEM" zu testen?
- Gibt es Optionen auf der Gegenstelle (dem cloud-Dienst)?

Zur Gegenstelle allgemein: Die _sollte_ eigentlich "sauberes UTF8" liefern - soweit ich mich entsinne, ist das die Konvention für JSON. Vielleicht ist das auch einfach ein Bug auf dieser Seite, den man adressieren müßte?

Hi Beta-User,

mein System ist ein Raspberry Pi 4 B mit Raspberry Pi OS Lite Debian Bookworm.
Fehm läuft im Docker image: ghcr.io/fhem/fhem-docker:4-bullseye
Perl v5.36.3
Fhem: FVERSION fhem.pl:v6.1-s29402/2024-12-05 (letztes SVN update am 19.02.2025).
attr global encoding ist nicht gesetzt, also sollte default bytestream verwendet werden.
Problem ist bei allen getestete Browsern vorhanden: Chrome (Windows 11); MS Edge (Windows 11); Chrome (Android 15).
Auch beim neu laden der Seite (mit gelöschten cache) tritt das problem auf.
Möglichkeit auf einem frischen FEHM System zu testen habe ich gerade nicht.
Auf der Viessmann API Seite kann man hierzu nichts einstellen. Ich werde bei Viessmann mal ein Ticket dazu erstellen...

Viele Grüße
Schlimbo

Hi Schlimbo,

da bin ich mal gespannt was Viessmann dazu sagt.

Es gibt eine neue Version im GIT und morgen im SVN.
"0.8.1" 
replace U+FFFD (unknown character with [VUC] see https://forum.fhem.de/index.php?msg=1334504
fill reason in error case from extended payload

Das letzte ist wegen diesem Post:

Zitat von: jemu75 am 08 Februar 2025, 23:02:37Hallo Stefan,

ich wollte nochmal ein kurzes Feedback geben. Bei mir sind heute zeitweise nochmal Fehler im log aufgetaucht.

Code Auswählen Erweitern

2025.02.07 10:41:52 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren! 2025.02.07 10:41:52 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message: error: 2025.02.07 10:43:53 1: PERL WARNING: Use of uninitialized value $a[1] in subtraction (-) at ./FHEM/99_Utils.pm line 21. 2025.02.07 10:43:53 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/99_Utils.pm line 21.

Hast du einen Tipp, wie ich dem Problem noch besser auf den Grund gehen kann?

Grüße
Jens  :)

Ich hatte es heute auch. Der Grund war das heute Nacht meine FritzBox ein Update gemacht hat und die Viessmann Geräte nun an einem weiter entfernten Repeater hingen und ab und zu die Verbindung verloren haben.
Die extended Payload zeigt dann:  'reason' => 'GATEWAY_OFFLINE'
Dies wird nun auch im State oder Log je nach Art des Fehlers angezeigt.

Viele Grüße,
Stefan

Moin Stefan,

hatte vorhin kurz Zeit, um mal einen ersten Blick in das Modul zu werfen - eigentlich v.a., weil mich das mit der Fehlerbehandlung für die kaputten Umlaute "drumrum" interessiert hat.

Ein paar Dinge sind mir aufgefallen:
- Bisher habe ich praktisch kein (fremdes) Modul gesehen, das beim "cruel"-Check auf "perlcritic.com" so wenig "critics" gezeigt hat wie deines! Hut ab!!!
- Du hast nur an einer (?) Stelle das "decode_json()" durch die "JSON-new->decode()"-Variante getauscht. Absicht/Vorsicht/nur ein erster Test?
- Die "eval {}"-Variante mit anschließender unabhängiger Prüfung, ob irgendwelche Fehler in $@ sind hat einen großen, aber schwer zu entdeckenden Haken: Das schlägt auch an, wenn bereits vorher - eventuell aus ganz anderen Gründen - ein Fehler hinterlegt ist. Bin da irgendwann in der Vergangenheit (MPD?) drüber gestolpert, seitdem ist das hier mein Standardcode:

Zitatmy $decoded;
    if ( !eval { $decoded  = JSON->new->decode($content) ; 1 } ) {
        Log3($hash->{NAME}, 1, "JSON decoding error in languagefile $cfg: $@");
        return "languagefile $cfg seems not to contain valid JSON!";
    }
    return if !defined $decoded;

Zitat von: Schlimbo am 20 Februar 2025, 21:04:56mein System ist

Danke für die Infos - also alles mehr oder weniger so aktuell, wie es nur geht :) .

Da der Fix von Stefan zu greifen scheint, können wir m.E. das Thema erst mal auf die Seite legen, ansonsten wäre es (wegen der Wechselwirkungen mit FHEMWEB) vermutlich sinnvoll, diesen Teilaspekt wirklich separat zu diskutieren.

Mir ist noch eine Sache aufgefallen und ich wollte mal fragen, ob das bei den anderen Anwendern auch so ist:
Die Readings, die Zeitpläne enthalten (bei mir "heating.circuits.0.heating.schedule.entries", "heating.dhw.pumps.circulation.schedule.entries" und "heating.dhw.schedule.entries") werden bei jeder API-Abfrage aktualisiert.
Der Inhalt ist immer der gleiche, allerdings tauchen die Wochentage jedesmal in einer anderen Reihenfolge auf. Dabei sind die Wochentage bunt durcheinander gewürfelt - hier ein Beispiel:
{"wed":[{"mode":"normal","start":"06:00","position":0,"end":"22:00"}],"sat":[{"position":0,"end":"22:00","mode":"normal","start":"06:00"}],"thu":[{"start":"06:00","mode":"normal","end":"22:00","position":0}],
"mon":[{"position":0,"end":"22:00","mode":"normal","start":"06:00"}],"sun":[{"mode":"normal","start":"06:00","end":"22:00","position":0}],"fri":[{"start":"06:00","mode":"normal","end":"22:00","position":0}],
"tue":[{"mode":"normal","start":"06:00","end":"22:00","position":0}]} Dadurch greift auch mein event-on-change-reading .* nicht und es wird jedesmal ein Event ausgelöst.

Hi JWRu,

ja das ist eine offene Baustelle. Darum wollte ich mich irgendwann kümmern.
Die Readings vom Type "Schedule" sind nicht so toll.
Da das ganze als ein JSON kommt und in ein Hash gelesen wird ist die Reihenfolge keineswegs garantiert.
Auch finde ich das Setzen so nicht optimal.

Ich kann mich daran machen das zu verbessern, war bisher niedrigste prio.
Irgendein Wunsch bzw. eine Idee wie das am besten gelöst werden sollte?

Gruß,
Stefan

Das hat wirklich keine hohe Priorität!

ZitatIrgendein Wunsch bzw. eine Idee wie das am besten gelöst werden sollte?

Vielleicht nach Wochentagen (mon..sun) sortieren? Dann ändert sich das Reading nicht dauernd.

Ok, das habe ich mal eingebaut und es liegt in meinem Git.
Gibt es morgen mit dem Update.

Trotzdem finde ich diese Readings schwierig und wüsste auch auf anhieb nicht wie ich sie in FHEM sinnvoll mit einem schönen UI Element befüllen soll.
Wenn jemand ne Idee hat gerne melden.

Erstmal eine neue Version mit diesen 2 Änderungen:
  "0.8.3"  => "23.02.2025  fix order of days for type schedule readings",
  "0.8.2"  => "22.02.2025  improved state reading in case of unknown error",

Gruß,
Stefan

weekprofile?

(analog dazu, wie es bei MQTT2_DEVICE gelöst ist)

Bei Gelegenheit schau ich mir das mal an.

Zitatweekprofile?

Das ist eine gute Idee - nutze ich für meine HomeMatic Thermostatventile.

Hi,

ja weekprofile klingt super und müsste passen.
Benutze ich ja auch für meine MAX Thermostate.

Müsste man aber etwas anpassen da mode und position mitgegeben werden muss.

Die Vitocal hat 2 Scheduler (heating und dhw):
  {
      "feature": "heating.circuits.0.heating.schedule",
      "gatewayId": "7736172146035226",
      "deviceId": "0",
      "timestamp": "2025-02-23T04:35:06.658Z",
      "isEnabled": true,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/2772216/gateways/7736172146035226/devices/0/features/heating.circuits.0.heating.schedule",
      "properties": {
        "entries": {
          "type": "Schedule",
          "value": {
            "mon": [
              {
                "mode": "normal",
                "start": "05:30",
                "end": "24:00",
                "position": 0
              }
            ],
            "tue": [
              {
                "mode": "normal",
                "start": "05:30",
                "end": "24:00",
                "position": 0
              }
            ],
            "wed": [
              {
                "mode": "normal",
                "start": "05:30",
                "end": "24:00",
                "position": 0
              }
            ],
            "thu": [
              {
                "mode": "normal",
                "start": "05:30",
                "end": "24:00",
                "position": 0
              }
            ],
            "fri": [
              {
                "mode": "normal",
                "start": "05:30",
                "end": "24:00",
                "position": 0
              }
            ],
            "sat": [
              {
                "mode": "normal",
                "start": "05:30",
                "end": "24:00",
                "position": 0
              }
            ],
            "sun": [
              {
                "mode": "normal",
                "start": "05:30",
                "end": "24:00",
                "position": 0
              }
            ]
          }
        },
        "active": {
          "type": "boolean",
          "value": true
        }
      },

      "feature": "heating.dhw.schedule",
      "gatewayId": "7736172146035226",
      "deviceId": "0",
      "timestamp": "2025-02-23T04:35:06.658Z",
      "isEnabled": true,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/2772216/gateways/7736172146035226/devices/0/features/heating.dhw.schedule",
      "properties": {
        "entries": {
          "type": "Schedule",
          "value": {
            "mon": [
              {
                "mode": "on",
                "start": "00:00",
                "end": "01:00",
                "position": 0
              },
              {
                "mode": "on",
                "start": "05:00",
                "end": "24:00",
                "position": 1
              }
            ],
            "tue": [
              {
                "mode": "on",
                "start": "00:00",
                "end": "01:00",
                "position": 0
              },
              {
                "mode": "on",
                "start": "05:00",
                "end": "24:00",
                "position": 1
              }
            ],
            "wed": [
              {
                "mode": "on",
                "start": "00:00",
                "end": "01:00",
                "position": 0
              },
              {
                "mode": "on",
                "start": "05:00",
                "end": "24:00",
                "position": 1
              }
            ],
            "thu": [
              {
                "mode": "on",
                "start": "00:00",
                "end": "01:00",
                "position": 0
              },
              {
                "mode": "on",
                "start": "05:00",
                "end": "24:00",
                "position": 1
              }
            ],
            "fri": [
              {
                "mode": "on",
                "start": "00:00",
                "end": "01:00",
                "position": 0
              },
              {
                "mode": "on",
                "start": "05:00",
                "end": "24:00",
                "position": 1
              }
            ],
            "sat": [
              {
                "mode": "on",
                "start": "00:00",
                "end": "01:00",
                "position": 0
              },
              {
                "mode": "on",
                "start": "05:00",
                "end": "24:00",
                "position": 1
              }
            ],
            "sun": [
              {
                "mode": "on",
                "start": "00:00",
                "end": "01:00",
                "position": 0
              },
              {
                "mode": "on",
                "start": "05:00",
                "end": "24:00",
                "position": 1
              }
            ]
          }
        },
        "active": {
          "type": "boolean",
          "value": true
        }
      },

Gruß,
Stefan

Zitat von: stefanru am 24 Februar 2025, 09:11:33Die Vitocal hat 2 Scheduler (heating und dhw):

Meine Idee:
- weekprofile gibt die Info, dass das topic aktualisiert wurde
- Vitoconnect holt sich die beiden Profile für heating und dhw
- gleicht es intern auf Änderungen ab
- und schickt es dann weiter, wenn geändert.

Hi Beta-User,

ja das klingt super.

Willst du DHW und Heating zusammen verarbeiten?
Oder 2 Weektimer, einen für Heating und einen für DHW?

Macht vieleicht auch Sinn weil z.B. meine Vitoladens wiederrum nur einen Scheduler hat:
heating.circuits.0.heating.schedule.entries
[{"mon":[{"position":0,"end":"24:00","mode":"normal","start":"06:00"}]},{"tue":[{"position":0,"mode":"normal","end":"24:00","start":"06:00"}]},{"wed":[{"position":0,"mode":"normal","end":"24:00","start":"06:00"}]},{"thu":[{"mode":"normal","end":"24:00","start":"06:00","position":0}]},{"fri":[{"start":"06:00","mode":"normal","end":"24:00","position":0}]},{"sat":[{"position":0,"start":"06:00","mode":"normal","end":"24:00"}]},{"sun":[{"position":0,"mode":"normal","end":"24:00","start":"06:00"}]}]

Und wir wissen ja auch nicht ob es bei 2 Heizkreisen dann auch noch mehr Scheduler gibt.

Ich denke pro Scheduler ein Weekprofile wäre gut, oder?

Gruß,
Stefan

ZitatErstmal eine neue Version mit diesen 2 Änderungen:
  "0.8.3"  => "23.02.2025  fix order of days for type schedule readings"

Die neue Version ist zwar jetzt nach Wochentagen sortiert, löst aber immer noch Events aus, weil sich die Reihenfolge innerhalb der Wochentage ändert.
Hier ein Beispiel:
Ausgangszustand:[{"mon":[{"position":0,"end":"22:00","mode":"normal","start":"06:00"}]},{"tue":[{"start":"06:00","mode":"normal","end":"22:00","position":0}]},{"wed":[{"mode":"normal","start":"06:00","end":"22:00","position":0}]},{"thu":[{"mode":"normal","start":"06:00","end":"22:00","position":0}]},{"fri":[{"position":0,"end":"22:00","start":"06:00","mode":"normal"}]},{"sat":[{"start":"06:00","mode":"normal","position":0,"end":"22:00"}]},{"sun":[{"mode":"normal","start":"06:00","end":"22:00","position":0}]}]nach API-Abfrage:[{"mon":[{"end":"22:00","position":0,"mode":"normal","start":"06:00"}]},{"tue":[{"position":0,"end":"22:00","mode":"normal","start":"06:00"}]},{"wed":[{"end":"22:00","position":0,"start":"06:00","mode":"normal"}]},{"thu":[{"mode":"normal","start":"06:00","end":"22:00","position":0}]},{"fri":[{"mode":"normal","start":"06:00","position":0,"end":"22:00"}]},{"sat":[{"position":0,"end":"22:00","mode":"normal","start":"06:00"}]},{"sun":[{"start":"06:00","mode":"normal","position":0,"end":"22:00"}]}]

Zitat von: stefanru am 24 Februar 2025, 09:54:31Ich denke pro Scheduler ein Weekprofile wäre gut, oder?

In meiner Installation gibt es im Moment nur eine einzige weekprofile-Instanz, und mein Plan wäre gewesen, darüber die komplette Heizung (incl. Therme usw.) abzudecken; Profilwechsel erfolgt dann nur über "usetopics". Intern nutze ich eine ganze Reihe von Referenzierungen von ein paar wenigen Basisprofilen.

Das ist aber m.E. kein "Muss".

Würde vorschlagen, erst mal "das Hauptgerät" anzugehen. Dazu muss einfach ein userAttr "wekprofile" an das Device ran, ein entsprechender setter da sein, und weekprofile (afair gerüngfügig) aufgebohrt werden.

Die weiteren "Unterdevices" (oder sheduler oä.) könnte man dann über weitere userAttr ergänzen, aber bevor wir den ersten Schritt nicht im Detail verstanden haben, macht es m.E. wenig Sinn, den weiteren Ausbau oder gar die Syntax zu diskutieren. Grundsätzlich sollte es möglich sein, auch Profile aus weiteren weekprofile-Instanzen abzurufen, wobei der gesamte Prozess eben durch "das Hauptgerät" angeschubst werden würde.

Hoffe, das eventuell über das WE oder nächste Woche mal auch praktisch angehen zu können...

@JWRu: Ok das schaue ich mir an und sortiere das auch noch.

@Betra-User: Ok, das fände ich super wenn du dir das mit dem weekprofile anschauen könntest. Danke!

Gruß,
Stefan

@JWru:

hier eine neue Version. Kannst du sie mal testen?
  "0.8.4"  => "24.02.2025  also order mode, start, end, position in schedule"

Wirklich gefallen tut es mir nicht da ich die Werte an denen sortiert wird fest vorgeben muss.
Eventuell fällt mir noch was besseres ein, aber erstmal schauen ob es so für dich tut.

Gruß,
Stefan

Zitathier eine neue Version. Kannst du sie mal testen?
  "0.8.4"  => "24.02.2025  also order mode, start, end, position in schedule"

Funktioniert - vielen Dank!
Für mich ist das prima so - ich mache Änderungen an den Zeitplänen zu Zeit eh mit der ViCare-App.
Schauen wir mal was aus dem "Weekprofile-Projekt" wird - ich bin gespannt. 

Wenn ich z.B. "set vitoconnect heating.dhw.temperature.hysteresis.switchOffValue 1" abschicke, so wird der Wert korrekt gesetzt, aber ich erhalte eine Fehlermeldung. Das ist zwar störend, aber solange die Funktion erfüllt ist auch ok.

2025-02-24 15_03_37.jpg

Zitat von: JWRu am 24 Februar 2025, 15:12:06

Zitathier eine neue Version. Kannst du sie mal testen?
  "0.8.4"  => "24.02.2025  also order mode, start, end, position in schedule"

Funktioniert - vielen Dank!
Für mich ist das prima so - ich mache Änderungen an den Zeitplänen zu Zeit eh mit der ViCare-App.
Schauen wir mal was aus dem "Weekprofile-Projekt" wird - ich bin gespannt. 

Ok neue Version ist im GIT und kommt morgen im SVN.
98_vitoconnect: order mode, start, end, position in schedule

Zitat von: kkoeniger am 24 Februar 2025, 15:16:52Wenn ich z.B. "set vitoconnect heating.dhw.temperature.hysteresis.switchOffValue 1" abschicke, so wird der Wert korrekt gesetzt, aber ich erhalte eine Fehlermeldung. Das ist zwar störend, aber solange die Funktion erfüllt ist auch ok.

2025-02-24 15_03_37.jpg

Ok,
das hatte ich noch nicht bemerkt da ich immer über mein TabletUI schalte und dort die Prüfung nicht hoch kommt.
Irgendwie sind die Optionen nicht immer richtig gefüllt, das ging schonmal ist aber wohl irgendwie kaputt gegangen.

Ich schaue es mir an.

Gruß,
Stefan

Ok der Set Fehler ist behoben.

Im GIT schon jetzt, morgen im SVN.
  "0.8.5"  => "24.02.2025  fix error when calling setter from FHEMWEB"


Gruß,
Stefan

Zwischenstand:
- Die Vitodens ist online, viel mehr ging bisher nicht
- Das Versenden eines (händisch) modifizierten Wochenprofils ging (vermeintlich?) nicht, da kam auch diese Fehlermeldung mit "choose one of..." zurück. Soweit erkennbar kam auch nichts an der Therme an, lag eventuell auch am Zeitraster, wollte erst mal nur 10 Minuten an einem Tag ändert.

Insgesamt ist diese App reichlich unübersichtlich.

Hi Beta-User,
meinst du mit die APP das weekprofile Modul?

Ich kann mal testen ob das schicken eines Wochenplans überhaupt richtig funktioniert. Habe ich noch nie über FHEM gemacht, vielleicht habe ich da auch noch etwas nicht richtig implementiert.
Wenn ich etwas Zeit habe versuche ich es mal.

Danke und Gruß,
Stefan

Ging um den Versuch, in FHEM über die vitoconnect-Instanz den vorhandenen set-Befehl zu verwenden.

Das wäre erst mal die notwendige Vorstufe.

Ok, schaue ich mir an.

Also bei mir kommt kein "choose one of..."
Hast du die letzte Version die das behebt? (  "0.8.5"  => "24.02.2025  fix error when calling setter from FHEMWEB"  )

Unübersichtlich ja durch die 3 Mappings die ich wegen Kompatibilität mit rumschleppe.
Du benutzt denke ich auch das neue RAWMapping.

Ich habe mal eine Eintrag meiner Vitodens verändert.
Was passiert wenn ich das Logging erhöhe sieht gut aus aber die API gibt eine Webseite zurück die sagt:
"Ups! Etwas lief schief. Bitte kehren Sie zur Anwendung zurück und versuchen Sie es erneut."

Der gesendete Befehl sieht für mich erstmal gut und nach JSON Definition aus:
2025.03.04 17:37:35 1: Vitoladens300C, vitoconnect_action url= https://api.viessmann.com/iot/v2/features/installations/2772216/gateways/7637415075136238/devices/0/features/heating.circuits.0.heating.schedule/commands/setSchedule

2025.03.04 17:37:35 1: Vitoladens300C, vitoconnect_action data=
{"newSchedule":"[{"mon":{"mode":"normal","start":"07:00","end":"24:00","position":0}},{"tue":{"mode":"normal","start":"06:00","end":"24:00","position":0}},{"wed":{"mode":"normal","start":"06:00","end":"24:00","position":0}},{"thu":{"mode":"normal","start":"06:00","end":"24:00","position":0}},{"fri":{"mode":"normal","start":"06:00","end":"24:00","position":0}},{"sat":{"mode":"normal","start":"06:00","end":"24:00","position":0}},{"sun":{"mode":"normal","start":"06:00","end":"24:00","position":0}}]"}

Im JSON wird das vorgegeben mit:
      "commands": {
        "setSchedule": {
          "uri": "https://api.viessmann.com/iot/v2/features/installations/2772216/gateways/7637415075136238/devices/0/features/heating.circuits.0.heating.schedule/commands/setSchedule",
          "name": "setSchedule",
          "isExecutable": true,
          "params": {
            "newSchedule": {
              "type": "Schedule",
              "required": true,
              "constraints": {
                "modes": [
                  "normal"
                ],
                "maxEntries": 4,
                "resolution": 10,
                "defaultMode": "reduced",
                "overlapAllowed": true
              }
            }
          }
        },


Mir geht gerade etwas die Zeit aus aber ich versuche spätestens am WE mal herauszufinden was an dem Call nicht stimmt oder umgestellt werden muss.

Gruß,
Stefan

Hmm, hatte ein Update gefahren, die Version passt.

Habe aber grade leider auch nicht die Zeit, mich tiefer reinzudenken.

Ok, wenn du die neuste Version hast und trotzdem "choose one of..." bekommst, sollten wir uns das anschauen.
Da du gerade auch keine Zeit hast, denke ich mal drüber nach und mach dann Vorschläge wie wir herausfinden warum das bei dir passiert.

Du könntest mir aber bei Gelegenheit mal die Attribute deines Vitoconnect Devices schicken.

P.S.: Das Format scheint beim setSchedule nicht ganz zu passen.
Laut offizieller Doku sieht das JSON etwas anders aus als das welches ich schicke.
Eigentlich schicke ich nur zurück was ich bekommen habe. Das sollte aber zu lösen sein muss ich mir etwas Debugging einbauen und etwas am JSON für Schedule rumoperieren.
https://www.postman.com/vimicho/viessmann-api-public/request/hpbagam/set-heating-schedule


Gruß,
Stefan

So ich massiere nun die Schedule Daten nochmal vor dem senden nach und nun klappt das setzen bei mir.

Im GIT gibt es eine neue Version.
Morgen im SVN.

Gruß,
Stefan

Erst mal ein big THANX an Stefanru!

Schön, das es weitergeht. Ich habe heute FHEM per update aktualisiert und dann testweise ein SET HK1-Solltempereatur_normal abgesetzt und erhalte die Meldung:

unknown value HK1-Solltemperatur_normal, choose one of update:noArg clearReadings:noArg password apiKey logResponseOnce:noArg clearMappedErrors:noArg  selectDevice:77myid

Der Wert wird aber gesetzt. (Zeigt die ViCare app an) Ist nicht wirklich wichtig, das mach ich sonst über die ViCare app.

Danke neworder,

das ist wirklich seltsam.
BetaUser hat das Problem auch beschrieben.
Ich hatte einen fix dazu geliefert aber er scheint nicht überall zu helfen.
Ich benutze vitoconnect_raw_readings und kann das Problem bei mir nicht nachstellen, weiß aber eigentlich woher es kommt.

Ich werde mir das nochmal ansehen und hoffe ich finde den Fehler.

Gruß,
Stefan

Ok,
ich denke ich habe es gefunden.

Für vitoconnect_raw_readings hat es schon funktioniert, bei SVN und Roger hatte ich einen kleinen Bug drin.

Der Fehler sollte behoben sein mit:
98_vitoconnect: Fix return value when using SVN or Roger

Liegt in meinem GIT und ist ab morgen im FHEM update.

@BetaUser: Setzen der Schedules sollte seit der letzten Version auch funktionieren.

Gruß,
Stefan

Kurzer Zwischenstatus, hatte bisher aber weiter kaum Zeit, in den Code zu schauen:
- Bisher hatte ich kein "mapping"-Attribut gesetzt, demnach ist es "svn-Mapping". Falls der "eigentlich gewollte" default ein anderer ist: Warum stellen wir das nicht um?
- Der Versuch, einen Zeitplan zu setzen, ergibt (in der Konstallation) weiter auch mit der aktuellen Version die "Unbekannter setter"-Rückmeldung und ein "Aktion_Status"-Reading mit einem "Fehler ..."; wenn der Plan wieder gelesen wird, ist er weiter unverändert (habe nur an einer Stelle 5 Minuten früher angegeben).

Ursache für die Rückmeldung ist imo das "return;" in Verbindung mit dem "defined-or" in Zeile 1401 (dto für #1397). Also entweder das raus (kein "// ''") oder die Abfrage in Zeile 1405 ändern?

(Generell ist die Code-Doppelung an der Stelle unschön; auf die Schnelle unterscheidet sich das nur durch Bindestrich statt Unterstrich? Vielleicht könnte man an einer zentralen Stelle die Übersetzungstabelle unterbringen?)

Hi Beta-User,

ok jetzt ist mir alles klar.
Du verwendest SVN-Mapping.
Ich hatte alle fixe nur für das vitoconnect_raw_readings gemacht.

Das erklärt warum du den Fehler noch bekommen hast mit unknown value.
Das ist ab morgen gefixed.

Das Setzen der Scheduler habe ich auch nur für vitoconnect_raw_readings.

Solche neuen Features wollte ich eigentlich nicht mehr in den alten Mapping Methoden einbauen.
Ich kann aber mal schauen ob ich das doch irgendwie einfach eingebaut bekomme.
Man muss das Argument etwas massieren, dass es die API nimmt. So wie es von ihr geliefert wird geht es nicht im Setter.
Da muss ich mir meine Heizung mal auf SVN umstellen und das einbauen.
Kann aber etwas dauern.

Gruß,
Stefan

Lass mal gut sein, das muss einfacher werden....

Ja da gebe ich dir recht.
Das einfachste ist die raw readings zu nehmen und die API zu lesen und zu schreiben was das SetNew macht.
Ganz ohne diese Mappings.

Die Mappings habe ich eigentlich nur wegen der Kompatibilität drin.
Klar wir könnten noch SVN und Roger verheiraten, aber eigentlich wollte ich da keinen Aufwand mehr spendieren.

Am liebsten wäre mir die Nutzer stellen auf SetNew, also vitoconnect_raw_readings um.
Dann könnte ich das ganze Mapping Zeug entfernen und das Modul wäre 2/3 kürzer.

Gruß,
Stefan

Zitat von: stefanru am 09 März 2025, 21:59:18Am liebsten wäre mir die Nutzer stellen auf SetNew, also vitoconnect_raw_readings um.
Dann könnte ich das ganze Mapping Zeug entfernen und das Modul wäre 2/3 kürzer.

Was hindert dich, diesen Schritt zu tun?

Imo kann ja jeder user die alte Version beibehalten, dem das nicht gefällt...

Der erste Schritt wäre, für neue User das Setzen der Mappings-Attribute zu verhindern und "new" als default zu verwenden, damit noobs wie ich gleich die Variante verwenden, die du eigentlich haben willst.

Ungetesteter Vorschlag - der erfordert imo nur, dass man als Attributwert für "vitoconnect_raw_readings" auch "svn" zuläßt:
    if  (AttrVal( $name, 'vitoconnect_mapping_roger', 0 )) {
        #use roger setters
        $return = vitoconnect_Set_Roger ($hash,$name,$opt,@args);
    }
    elsif  ( AttrVal( $name, 'vitoconnect_raw_readings', 'svn') eq 'svn' ) {
        #use svn setters
        $return = vitoconnect_Set_SVN ($hash,$name,$opt,@args);
    }
    else {
        #use new dynamic parsing of JSON to get raw setters
        $return = vitoconnect_Set_New ($hash,$name,$opt,@args);
    }
Müßte man halt entsprechend ankündigen, aber die Betroffenen, die erst mal noch beim alten (svn-) Mapping bleiben wollen, haben die Chance dazu.

Danach können wir immer noch sehen, wie/ob man den Kompabilitätslayer drin läßt. Zumdindest auf den ersten Blick sieht das sehr nach "suchen und ersetzen" aus, um es einzukürzen und zu vereinheitlichen.

Dazu dann noch ein paar Log-Einträge wegen gesetzter "alter" Attribute - dann würde ich erst mal abwarten, wie groß der "Aufschrei" ist ;) .

Mahlzeit.

Habe mich mal versucht... Ist noch nicht fertig, aber zumindest wird jetzt per default das "raw-mapping" verwendet, und die "Dynamisierung" der "Roger"-Sets sieht zumindest auf den ersten Blick auch ok aus.

Später ggf. mehr, muss jetzt mal Schluss machen.

Hatte übrigens auch das "disconnected"-Problem nach einem update einer der Fritzboxen, Neustart nach update der anderen (zentralen) hat geholfen.

Das mit dem shedule setzen ging jetzt auch.

Zitat von: Beta-User am 10 März 2025, 19:06:23Später ggf. mehr, muss jetzt mal Schluss machen.

Hier mal der diff und ein paar Erläuterungen dazu:
diff --git a/98_vitoconnect.pm b/98_vitoconnect.pm
index ce4b367..2c866d0 100644
--- a/98_vitoconnect.pm
+++ b/98_vitoconnect.pm
@@ -1,5 +1,5 @@
 #########################################################################
-# $Id: 98_vitoconnect.pm 29740 2025-03-09 16:03:37Z stefanru $
+# $Id: 98_vitoconnect.pm 29740 2025-03-10 Beta-User $
 # fhem Modul für Viessmann API. Based on investigation of "thetrueavatar"
 # (https://github.com/thetrueavatar/Viessmann-Api)
 #
@@ -1275,7 +1275,7 @@ sub vitoconnect_Initialize {
       . "vitoconnect_mappings:textField-long "
       . "vitoconnect_translations:textField-long "
       . "vitoconnect_mapping_roger:0,1 "
-      . "vitoconnect_raw_readings:0,1 "                 # Liefert nur die raw readings und verhindert das mappen wenn gesetzt
+      . "vitoconnect_raw_readings:0,1,svn "             # Liefert nur die raw readings und verhindert das mappen wenn auf 1 gesetzt; svn-Mapping, wenn auf svn gesetzt
       . "vitoconnect_disable_raw_readings:0,1 "         # Wird ein mapping verwendet können die weiteren RAW Readings ausgeblendet werden
       . "vitoconnect_gw_readings:0,1 "                  # Schreibt die GW readings als Reading ins Device
       . "vitoconnect_actions_active:0,1 "
@@ -1385,26 +1385,26 @@ sub vitoconnect_Set {
     Log3($name,5,$name." - Set val: $val, Set Opt: $opt");
    
     # Hier richtig?
-    return "set ".$name." needs at least one argument" unless (defined($opt) );
+    return "set $name needs at least one argument" if !defined $opt;
    
     # Setter für Device Werte rufen
-    my $return;
-    if  (AttrVal( $name, 'vitoconnect_raw_readings', 0 ) eq "1" ) {
-        #use new dynamic parsing of JSON to get raw setters
-        $return = vitoconnect_Set_New ($hash,$name,$opt,@args);
-    }
-    elsif  (AttrVal( $name, 'vitoconnect_mapping_roger', 0 ) eq "1" ) {
+    my $more_sets;
+    if  (AttrVal( $name, 'vitoconnect_mapping_roger', 0 )) {
         #use roger setters
-        $return = vitoconnect_Set_Roger ($hash,$name,$opt,@args);
-    }
-    else {
+        $more_sets = vitoconnect_Set_Roger ($hash,$name,$opt,@args);
+    }
+    elsif  ( AttrVal( $name, 'vitoconnect_raw_readings', 1) eq 'svn' ) {
         #use svn setters
-        $return = vitoconnect_Set_SVN ($hash,$name,$opt,@args);
+        $more_sets = vitoconnect_Set_SVN ($hash,$name,$opt,@args);
+    }
+    else {
+        #use new dynamic parsing of JSON to get raw setters
+        $more_sets = vitoconnect_Set_New ($hash,$name,$opt,@args);
     }
    
     # Check if val was returned or action executed with return;
-    if (defined $return) {
-      $val .= $return;
+    if (defined $more_sets) {
+      $val .= $more_sets;
     } else {
       return;
     }
@@ -2183,9 +2183,11 @@ sub vitoconnect_Set_SVN {
 sub vitoconnect_Set_Roger {
     my ($hash,$name,$opt,@args ) = @_;  # Übergabe-Parameter
 
-    if ($opt eq "HK1_Betriebsart" )                  {   # set <name> HKn_Betriebsart: sets HKn_Betriebsart to heating,standby
+    my $hknum;
+    if ($opt =~ m{HK([\d+]).Betriebsart} )                  {   # set <name> HKn_Betriebsart: sets HKn_Betriebsart to heating,standby
+    $hknum = $1 - 1;
         vitoconnect_action($hash,
-            "heating.circuits.0.operating.modes.active/commands/setMode",
+            "heating.circuits.$hknum.operating.modes.active/commands/setMode",
             "{\"mode\":\"$args[0]\"}",
             $name,$opt,@args
         );
@@ -2610,33 +2612,56 @@ sub vitoconnect_Set_Roger {
         return;
     }
 
-    my $val = "WW_einmaliges_Aufladen:activate,deactivate "
-        ."WW_Zirkulationspumpe_Zeitplan:textField-long "
-        ."WW_Zeitplan:textField-long "
-#       ."WW_Haupttemperatur:slider,10,1,60 "
-        ."WW_Solltemperatur:slider,10,1,60 "
-        ."WW_Temperatur_2:slider,10,1,60 "
-        ."WW_Betriebsart:balanced,off "
-        ."Urlaub_Start_Zeit "
-        ."Urlaub_Ende_Zeit "
-        ."Urlaub_stop:noArg ";
-
-    if (ReadingsVal($name,"HK1_aktiv","0") eq "1") {
-        $val .=
-             "HK1_Heizkurve_Niveau:slider,-13,1,40 "
-            ."HK1_Heizkurve_Steigung:slider,0.2,0.1,3.5,1 "
-            ."HK1_Zeitsteuerung_Heizung:textField-long "
-            ."HK1_Urlaub_Start_Zeit "
-            ."HK1_Urlaub_Ende_Zeit "
-            ."HK1_Urlaub_stop:noArg "
-            ."HK1_Betriebsart:active,standby "
-            ."HK1_Soll_Temp_comfort_aktiv:activate,deactivate "
-            ."HK1_Soll_Temp_comfort:slider,4,1,37 "
-            ."HK1_Soll_Temp_eco_aktiv:activate,deactivate "
-            ."HK1_Soll_Temp_normal:slider,3,1,37 "
-            ."HK1_Soll_Temp_reduziert:slider,3,1,37 "
-            ."HK1_Name ";
+    my $separator = '_';
+   
+    my $val = "WW${separator}einmaliges_Aufladen:activate,deactivate "
+        ."WW${separator}Zirkulationspumpe_Zeitplan:textField-long "
+        ."WW${separator}Zeitplan:textField-long "
+#       ."WW${separator}Haupttemperatur:slider,10,1,60 "
+        ."WW${separator}Solltemperatur:slider,10,1,60 "
+        ."WW${separator}Temperatur_2:slider,10,1,60 "
+        ."WW${separator}Betriebsart:balanced,off ";
+    if ($separator eq '_') { #Set_Roger
+        $val .= "Urlaub_Start_Zeit "
+        ."Urlaub_Ende_Zeit "
+        ."Urlaub_stop:noArg ";
+    } else { #svn setters
+        $val .= "Urlaub_Start "
+        . "Urlaub_Ende "
+        . "Urlaub_unschedule:noArg ";
+    }
+
+    for my $i (1..3) {
+    if ( ReadingsVal($name,"HK${i}${separator}aktiv",0) ) {
+        $val .=
+         "HK${i}${separator}Heizkurve_Niveau:slider,-13,1,40 "
+        ."HK${i}${separator}Heizkurve_Steigung:slider,0.2,0.1,3.5,1 "
+        ."HK${i}${separator}Zeitsteuerung_Heizung:textField-long "
+        ."HK${i}${separator}Betriebsart:active,standby,heating,dhw,dhwAndHeating,forcedReduced,forcedNormal ";
+        if ($separator eq '_') { #Set_Roger
+            $val .= "HK${i}_Urlaub_Start_Zeit "
+            ."HK${i}_Urlaub_Ende_Zeit "
+            ."HK${i}_Urlaub_stop:noArg "
+            ."HK${i}_Soll_Temp_comfort_aktiv:activate,deactivate "
+            ."HK${i}_Soll_Temp_comfort:slider,4,1,37 "
+            ."HK${i}_Soll_Temp_eco_aktiv:activate,deactivate "
+            ."HK${i}_Soll_Temp_normal:slider,3,1,37 "
+            ."HK${i}_Soll_Temp_reduziert:slider,3,1,37 ";
+        } else { #svn setters
+            $val .= "HK${i}-Urlaub_Start "
+            . "HK${i}-Urlaub_Ende "
+            . "HK${i}-Urlaub_unschedule:noArg "
+            . "HK${i}-Betriebsart:active,standby,heating,dhw,dhwAndHeating,forcedReduced,forcedNormal "
+            . "HK${i}-Solltemperatur_comfort_aktiv:activate,deactivate "
+            . "HK${i}-Solltemperatur_comfort:slider,4,1,37 "
+            . "HK${i}-Solltemperatur_eco_aktiv:activate,deactivate "
+            . "HK${i}-Solltemperatur_normal:slider,3,1,37 "
+            . "HK${i}-Solltemperatur_reduziert:slider,3,1,37 ";
+        }
+        $val .= "HK${i}${separator}Name ";
+    }
     }
+=pod
     if (ReadingsVal($name,"HK2_aktiv","0") eq "1") {
         $val .=
             "HK2_Heizkurve_Niveau:slider,-13,1,40 "
@@ -2669,6 +2694,7 @@ sub vitoconnect_Set_Roger {
           . "HK3_Solltemperatur_reduziert:slider,3,1,37 "
           . "HK3_Name ";
     }
+=cut
    
     return $val;
 }
@@ -2683,8 +2709,8 @@ sub vitoconnect_Attr {
     Log(5,$name.", ".$cmd ." vitoconnect_: ".($attr_name // 'undef')." value: ".($attr_value // 'undef'));
     if ($cmd eq "set")  {
         if ($attr_name eq "vitoconnect_raw_readings" )      {
-            if ($attr_value !~ /^0|1$/)                     {
-                my $err = "Invalid argument ".$attr_value." to ".$attr_name.". Must be 0 or 1.";
+            if ($attr_value !~ /^0|1|svn$/)                     {
+                my $err = "Invalid argument $attr_value to $attr_name. Must be 0, 1 or svn.";
                 Log(1,$name.", vitoconnect_Attr: ".$err);
                 return $err;
             }
@@ -3516,7 +3542,7 @@ sub vitoconnect_getResourceCallback {
             foreach my $key ( sort keys %$properties ) {
                
                
-                my $Reading = "";
+                my $Reading;
                
                 if ( scalar keys %translations > 0) {
                    
@@ -3540,20 +3566,20 @@ sub vitoconnect_getResourceCallback {
                  # Use build in Mapping Roger (old way)
                  $Reading = $RequestListRoger->{ $feature->{feature} . "." . $key };
                 }
-                else {
+                elsif ( AttrVal( $name, 'vitoconnect_raw_readings', 1 ) =~ m{0|svn}x ) {
                  # Use build in Mapping SVN (old way)
                  $Reading = $RequestListSvn->{ $feature->{feature} . "." . $key };
                 };
 
-                if ( !defined($Reading) || AttrVal( $name, 'vitoconnect_raw_readings', 0 ) eq "1" )
-                {  
-                    $Reading = $feature->{feature} . "." . $key;
-                }
-               
                 if ( !defined($Reading) && AttrVal( $name, 'vitoconnect_disable_raw_readings', 0 ) eq "1" )
                 {  
                     next;
                 }
+
+                if ( !defined $Reading && AttrVal( $name, 'vitoconnect_raw_readings', 1 ) !~ m{0|svn}x )
+                {  
+                    $Reading = $feature->{feature} . ".$key";
+                }
                
                 my $Type  = $properties->{$key}->{type};
                 my $Value = $properties->{$key}->{value};
@@ -4023,6 +4049,7 @@ sub vitoconnect_DeleteKeyValue {
 
 1;
 
+__END__
 
 =pod
 =item device
"vitoconnect_raw_readings" hätte damit einen weiteren zulässigen Wert "svn". Über den schaltet der Code zwischen dem neuen default "raw" und dem alten default "svn" um, wer also die svn-Variante haben will, kann die auf diesem Weg bekommen, muss aber eingreifen.

Anders gesagt: ganz ohne, dass man irgendwelche Attribute setzen müßte, bekommt man damit die raw-Mappings und setter :) .

Ein gesetztes "roger"-Mapping hat Vorrang, wer also bisher (warum auch immer) beide Attribute gesetzt hatte, bekommt "anders komische" Ergebnisse - sollte verschmerzbar sein.

Bei der sub vitoconnect_Set_Roger() habe ich (am Ende der Funktion zu finden) mal angefangen, die set-Befehle aus beiden mappings zusammenzuführen und nur da wirklich zu unterscheiden, wo es echte Unterschiede in der Benennung gibt, so dass sich das später ggf. leichter zusammenführen ließe, wenn man das will.
Der Teil beginnend mit
if ($opt =~ m{HK([\d+]).Betriebsart} )
ist für den Moment als Beispielcode gedacht, wie man das via pattern-match soweit reduzieren kann, dass man nicht 6 if-Aufrufe an unterschiedlichen Stellen braucht, um letztlich dasselbe zu bewirken. Ob das tatsächlich wie gedacht funktioniert, habe ich allerdings nicht getestet; wäre gut, wenn sich da jemand finden würde, der eine der alten mapping-Varianten nutzt und das auch weiter tun will (sonst gibt das halt eine Trockenübung, bis sich jemand beschwert?).

Meine Bitte wäre: Falls das auch aus deiner Sicht in die richtige Richtung geht, würde ich erst mal versuchen, den Code an diesen Stellen vollends zu verschlanken, die Doku entsprechend nachzuziehen, und mich dann erst an das Thema weekprofile zu machen?

Hi Beta-User,

wow, da hast du dir ja viel Arbeit gemacht.
Ich finde die Idee, dass Raw Readings der neue Standard wird, großartig. Als neuer Entwickler hatte ich mich jedoch nicht getraut, gleich eine inkompatible Änderung vorzunehmen.

Nun wäre ich aber bereit dazu. Ich denke, es gibt noch nicht so viele Benutzer, und wir sollten sicherstellen, dass die Dokumentation aktuell ist, bevor wir die Änderung freigeben. Am besten machen wir im ersten Beitrag auch darauf aufmerksam.

Mit deiner Änderung ist gewährleistet, dass neue Nutzer automatisch Raw Readings verwenden. Das finde ich eine tolle Idee, da ich SVN und Roger nicht mehr warten möchte und sie am liebsten aussterben lassen würde. Sollte sich die API in irgendeiner Weise ändern, möchte ich diese nicht nachziehen müssen. Bei Raw Readings geht das wahrscheinlich automatisch oder mit geringem Aufwand.

Zurzeit komme ich nicht wirklich dazu, und bald steht auch wieder Urlaub an.

Du kannst gerne weitermachen, ich bin voll dabei. Wann ich die Zeit finde, das dann zu übernehmen, weiß ich aber noch nicht genau. Es kann noch etwas dauern.

Bugfixes mache ich weiterhin, aber ich glaube, das Modul ist im jetzigen Zustand funktionell ganz rund.

Natürlich abgesehen von der Weiterentwicklung, die du vorschlägst.

Passt das so für dich und hat es etwas Zeit?

Danke und Gruß,
Stefan

Zitat von: stefanru am 10 März 2025, 22:38:38Als neuer Entwickler hatte ich mich jedoch nicht getraut, gleich eine inkompatible Änderung vorzunehmen

Völlig nachvollziehbar, hatte als "Neuling" auch lange Hemmungen, Dinge anzufassen, die vielleicht nicht allen gefallen...

Letztlich geht es aber darum, dass du was für die Allgemeinheit zur Verfügung stellst, und das sollte halt (vor allem ) auch deinen Vorstellungen entsprechen und halbwegs (aus deiner Sicht) wartbar sein ;) .

Zitat von: stefanru am 10 März 2025, 22:38:38SVN und Roger nicht mehr warten möchte und sie am liebsten aussterben lassen würde

Nachvollziehbar - beide sind imo "irgendwie zufällig" in der Benennung. Mein Vorschlag läuft daraus hinaus, das soweit zu vereinfachen und zu vereinheitlichen, dass es mit überschaubarem Aufwand wartbar bleibt.
Und direkt nach der Übernahme eines Moduls ist eigentlich ein guter Zeitpunkt, da ist in der Regel die Bereitschaft der anderen User noch größer, Fehler zu "tolerieren", zu melden und mit zu fixen ;) .

Generell finde ich die "raw"-Benennung nicht besonders toll - mein Vorschlag wäre an der Stelle allerdings, dass wir uns bei Gelegenheit mal darüber beugen und sowas wie einen "Muster-Reading/setter"-Rahmen für Wärmeerzeuger allgemein überlegen (so ähnlich, wie es das bei PV-Anlagen bereits gibt). Das Mapping würde ich dann aber "add-on" sehen ;) .

Was auch (aus noob-Sicht) verbesserungfähig ist, ist das mit dem Passwort: "fake" ist irgendwie ein Würgaround, und rename ist imo im Moment gar nicht abgedeckt...
Sowas "gleich" zu bereinigen, ist zwar Aufwand, aber der entsteht sonst später beim User-support.

Was die Zeitfrage angeht, kann es auch bei mir wieder etwas dauern, bis es effektiv weitergeht - ist schwer abschätzbar, aber für manche Eingriffe braucht man eben ein paar Stündchen mehr oder weniger am Stück, um das wieder auf einen vertretbaren Stand zu bringen.

Mal sehen, Danke auf alle Fälle für deine positive Rückmeldung :) .

Bitte so kurz vor dem Urlaub nicht erschrecken - anbei mein aktueller Zwischenstand als diff und .pm...

Habe die mappings (hoffentlich) so vereinheitlicht, dass man nur noch einen Code braucht und nicht mehr alles doppelt pflegen muss (da scheinen aber ein paar Wackler auch im alten Code drin gewesen zu sein?).

Dann das mit decode_json() so umgestellt, dass "alte" Probleme in $@ nicht an der falschen Stelle missinterpretiert werden. Dazu eine Frage: Wenn das decode schief geht, startet nicht in allen Fällen wieder ein timer. Absicht?

Dann habe ich die ersten Bruchstücke mal in den Code übernommen für das weekprofile-Thema.
Falls da jemand weiter dran basteln mag: Es ginge im ersten Schritt darum, die Funktion aufrufen zu können und als Ergebnis einen Reading-Inhalt zu schreiben, der auch an die Therme versendet werden könnte (sowohl für WW wie HKn - also leicht unterschiedlich!). 
Die untere Funktion stammt aus dem ebus-Package, da werden auch "on/off"-Paare gesucht, wir brauchen das hier halt (für HKn) noch etwas ausdifferenzierter mit "comfort" und "normal"...
Der Plan wäre, das entweder als "Schlüsselwörter" gleich von weekprofile liefern zu lassen, oder (finde ich eleganter), die Abgrenzung anhand der Wunsch- ("Raum-") Temperaturen zu machen.

Ich habs wahrscheinlich überlesen: Wie stelle ich auf raw_readings um? Sorry für die vielleicht schon mal beantwortete Frage  O:-)

Zitat von: neworder am 12 März 2025, 19:20:36Ich habs wahrscheinlich überlesen: Wie stelle ich auf raw_readings um? Sorry für die vielleicht schon mal beantwortete Frage  O:-)

Meine Fassung: alle "mapping"-Attribute weglassen/löschen.

Aktuelle svn-Fassung: Das "raw-reading-Attribut" (vitoconnect_raw_readings) wie empfohlen auf "1" stellen.

weia, da hab ich jetzt aber wieder auf dem Schlauch gestanden bis ich die Attributes gefunden habe. DANKE!

Und gleich mal probiert: heating.circuits.0.operating.normal.temperature klingt zwar anders, aber setzen des Wertes funktioniert bestens.

8)

wieder einer weniger in der "alten Welt"

Hallo Beta-User,

vor meinem Urlaub werde ich nicht einchecken. 😊

Vielen Dank für deine Arbeit! Nach meinem Urlaub, in etwa drei Wochen, werde ich deine Änderungen überprüfen, testen und dann einchecken.

In der Zwischenzeit sollten wir versuchen, möglichst viele User über den Breaking-Change zu informieren.
Ich werde im ersten Beitrag bereits einige Informationen aufnehmen und rot kennzeichnen.
Ab jetzt hat jeder drei Wochen Zeit, sich Gedanken darüber zu machen, wie er weiter verfahren möchte:

• Entweder auf SVN umstellen, wenn die neue Version gezogen wird.
• Oder auf RAW Readings umsteigen und die Änderungen mitmachen.

Es sollte klar sein, dass RAW Readings die Hauptentwicklungslinie sein wird.
Ja, die Readings sind länger, aber man kann sie mit stateformat (ich werde auch meine Templates bereitstellen) oder im TabletUI an seine Wünsche anpassen.

Ein großer Vorteil ist, dass die Readings im Device denen in der API entsprechen.
Das bedeutet, wenn man ein Problem hat, kann man direkt mit diesen Namen im Viessmann-Forum nachfragen.
Viessmann und alle anderen wissen dann genau, worüber man sprichst.

Danke und viele Grüße,
Stefan

Zitat von: Beta-User am 12 März 2025, 18:47:54Dann das mit decode_json() so umgestellt, dass "alte" Probleme in $@ nicht an der falschen Stelle missinterpretiert werden. Dazu eine Frage: Wenn das decode schief geht, startet nicht in allen Fällen wieder ein timer. Absicht?

Von mir war das keine Absicht.
Wie gesagt habe ich den Code nur übernommen meine Erweiterungen eingebaut und auch Bugs behoben.
Bei den Timern gab es auch Probleme im alten Coding die ich soweit ich konnte behoben habe, alle stellen habe ich aber sicher nicht gesehen.
Auch sind sicher bei den alten Mappern noch Leichen im Keller.
Da hatte ich angeboten es zu fixen wenn etwas auftritt, habe aktiv aber nichts unternommen.

Gruß,
Stefan

Hallo Stefanru,

dann bitte einmal auch für die uneingeweihten erklären wo der Unterschied zwischen svn (subversion?) oder auf RAW readings umstellen ist.

Sollte ich hier den Noob spielen? :-)

Ansonsten einen schönen Urlaub!

Hi Neworder,

SVN ist das Handling des Moduls das vor meinem Umbau der Standard war der in der FHEM Codeverwaltung war, den also alle benutzten.
Zu der Zeit gab es schon eine Eigenentwicklung von Roger, die ein etwas anderes Mapping benutzt hat. Dies habe ich auch übernommen und per Attribut auswählbar gemacht.
Beide Verfahren Mappen manuell die API Endpunkte auf eigene Namen.
D.h. der von Viessmann vorgesehen lange Name wird auf einen fest im Coding hinterlegten kurzen gemappt.
heating.circuits.0.operating.normal.temperature wird zu HK1_Temperatur_Normal.
Diese Mapping muss immer nachgezogen werden ändert Viessmann den Namen und ist auch nur dem Entwickler und hier im Forum bekannt.

Ich habe hinter einem Attribut vitoconnect_raw_readings = 1, ein neues Verfahren eingeführt.
Ich mache kein Mapping.
Ich versuche das API von Viessmann so dynamisch wie möglich zu mappen.
Die Readings entstehen Automatisch aus den Viessmann API Namen.

D.h. führt Viessmann ein neues Reading ein wie z.B.
heating.circuits.0.operating.boost.temperature wird dieses bei mir direkt auftauchen, ohne Änderung am Modul.
Bei SVN und Roger wird man es nicht sehen bis es jemand bemerkt und ein Mapping dafür ins Coding baut.

Des weiteren heißt es, schreibt man im Viessmann Forum das man ein Problem mit HK1_Temperatur_Normal z.B. das das Reading nur noch ab und zu befüllt wird, versteht das dort keiner.
Schreibt man aber von heating.circuits.0.operating.normal.temperature ist dieser API Endpoint Viessmann bekannt.

Viele Grüße,
Stefan

Und outch,

für die Auswertung/Datenbank/Anzeige wird die Umstellung kein Spaß.

Bin erstmal weg von den raw readings. Sorry!

Hab ich aber vieles schon bei mir gemacht und kann gerne meine Vorlagen liefern.
Habe auch logdb, benutze Plots und Tablet UI.
Am Device selbst habe ich auch noch ein großes StateFormat für die wichtigen Readings.

Für Neueinsteiger eh ziemlich egal wie das Reading heißt.
Umstellen ist immer etwas blöd aber es ist machbar.

Helfen kann ich mit Vorlagen wenn gewünscht, aber das schaffe ich auch erst nach meinem Urlaub.

Gruß,
Stefan

Die Umstellung meiner Plots auf Raw Readings hat eine halbe Stunde gedauert.

Ich schau mir das am WoEnde in Ruhe an. Das Umstellen der Plots: Fleißarbeit.

Das Umstellen von
Bildschirmfoto vom 2025-03-13 09-28-00.png
auch machbar (reduziert die Datenbankgröße enorm).

Dann nur noch die Werte der letzten Jahre in der logdb auf die neuen Attribute kopieren (sql bekomm ich auch hin). Oder in einem Jahr drann denken warum es keine Vorjahreswerte auf den alten mappings/Attributen gibt  ;D . Endlich wieder was zu tun 8).

Das riecht nach einem oder mehreren Backups.

ZitatDann nur noch die Werte der letzten Jahre in der logdb auf die neuen Attribute kopieren (sql bekomm ich auch hin).

Das geht auch gut mit DbRep (Befehl "readingRename"): https://fhem.de/commandref.html#DbRep (https://fhem.de/commandref.html#DbRep)

DbRep ein sehr guter Tip. Danke! Beim finden der neuen Bezeichnungen/mappings auf die alten in der 98_vitoconnect.pm wäre es für mich hilfreich wenn alte und neue "Attribute" gleichzeitig gefüllt werden (raw_readings=2). Ich habe eine weile gebraucht um zu erkennen das der Aussentemperaturwert (heating.sensors.temperature.outside.value) von gestern abend nicht zu (Aussentemperatur) von jetzt passte. Auch bei den heating.boiler* und heating.dhw* Werten bin ich noch nicht ganz sicher 8).

Fehlt ein verregnetes WoEnde und dann gehts los.

Man kann sich das Gerät auch 2 mal anlegen. Als Raw Readings und als normales. Dann bei beide disablen und ein GetResponceOnce bei beiden kurz hinter einander machen. Dann kann man die Werte in aller Ruhe vergleichen.
heating.sensors.temperature.outside.value sollte der Außentemperatur Fühler der Anlage sein. Ist es zumindest bei mir.

Zitatheating.sensors.temperature.outside.value sollte der Außentemperatur Fühler der Anlage sein. Ist es zumindest bei mir.

Bei mir auch.

Frage in die Runde: Ist es möglich, über das Modul auch die Betriebsart zu wechseln?

Wenn ich z. B. set vitoconnect HK-Betriebsart Standby wähle, passiert nichts bzw. nur eine Änderung des Readings Aktion_Status auf Fehler: [Wunschbetriebsart].

Wenn das funktionieren würde, wäre ich so happy, weil die Pumpe dann in der Nacht nicht mehr brummen würde (automatischer Standby in der Nacht – die Heizung ist unterm Dach).

sodele, 2/3 auf raw values angepasst. Bei  DbRep readingRename unbedingt auf Leerzeichen hinterm komma von oldvalue,newvalue achten. Sonst gibts viel Spass. Und fragt nicht wieso ich das schreibe. Nu sind die modulationswerte der letzten 2 Jahre Geschichte (egal  8)). Fürs Backup und restore der Modulationswerte waren sie einfach zu wenig nutzen.

@Basti-K:

Ja geht bei mir.
Ich benutze das attribut vitoconnect_raw_readings = 1.
heating.circuits.0.operating.modes.active.value standby schaltet die Pumpe aus.

Warum das bei dem SVN mapping nicht geht müsste ich nachschauen.
Schaffe ich vor meinem Urlaub aber wahrscheinlich nicht mehr.

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

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  8) . Es wird aber angezeigt und ist vom Wert ok.

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

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:
{vitoconnect_send_weekprofile('Therme_Vi','weekprofiles','default:Esszimmer','dht')}{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:

Zitat von: Prof. Dr. Peter Henning am 13 März 2025, 04:35:36[...]
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.

@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

Zitat von: stefanru am 14 März 2025, 21:54:22@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!!!

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

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

Zitat von: stefanru am 14 März 2025, 22:24:36Das waren meine ersten Versuche bis ich dann für mich auf die Raw Mappings umgestiegen bin weil mir nichts mit Übersetzung gut zugesagt hab.

;D  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?)

Zitat von: Basti-K am 14 März 2025, 19:08:09ha.. 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.

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

@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.

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

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

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

@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!

Hier die Ausgabe bei verbose 4

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  O:-)

Zitat von: neworder am 17 März 2025, 16:13:42Hier 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  O:-)

Gemeint war wohl der verbose-Level.
Du bist bei 4 - also "ziemlich gesprächig".

Mit severity bezog ich mich auf Beitrag 198 von Stefan.

Ja ich meine den Verbose Level 4.
Du scheinst FHEM mit 4 laufen zu haben.
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

Da kann man jetzt streiten ob das eine 4 ist oder nicht, 4 ist:
4 - von den einzelnen Geräten empfangene Daten.

Es geht nur noch eins höher mit 5 für Debugging.
Ich glaube standradmäßig steht FHEM auf 3.
Das würde ich dir auch empfehlen.

Gruß,
Stefan

2025.03.17 15:14:59 4: vitoconnect - access_token: eyJraWQiOiI0ZWNhM2Vk...
2025.03.17 15:14:59 4: vitoconnect - installation:
2025.03.17 15:14:59 4: vitoconnect - gw:
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
2025.03.17 15:15:00 4: vitoconnect - Access Token: eyJraWQiOiI0ZWNhM2Vk...
Das token scheint sich auch nicht zu ändern. Eintrag erscheint so ca. 1 mal die Stunde (gw und installation deleted by me)

Ich hatte wegen deiner Anfrage auf 4 gedreht. Nun wieder back :-)

Ja jede Stunde muss man neu Authentifizieren, ich denke das passt so und ist normal.

Hallo zusammen,

aus irgendeinem Grund funktioniert bei mir das SVN-Mapping
    "heating.burners.0.statistics.hours"  => "Brenner_1_Betriebsstunden",nicht.
Es wird weder das RAW-reading heating.burners.0.statistics.hours noch das gemappte Brenner_1_Betriebsstunden in der Liste angezeigt.

Aktiviere ich die RAW-Readings, ist das reading heating.burners.0.statistics.hours in der Liste.
Definiere ich über vitoconnect_mappings ein eigenes Mapping, wird auch mein eigenes reading angezeigt.

Nur wenn ich ausschliesslich die SVN-Mappings nutze, fehlt mir das reading.

Hat vielleicht jemand einen Tipp?

Hi Uwe,

hmmm, das ist aber sehr komisch.

Hast du zufällig vitoconnect_disable_raw_readings gestetzt?
Dann erzeugt er bei nicht gefundenen Mappings keine Raw Readings.
Also es sollte bei dir nicht oder auf 0 gesetzt sein.

Du kannst auch mal set logReponseOnce machen.
Dann sollte im FHEM Log Verzeichnis eine Datei Namens resource_<deine serien nummer>.json landen.
Dort drin kannst du mal nach heating.burners.0.statistics.hours suchen und das genau mit dem Namen im Mapping vergleichen.
Sollte das genau übereinstimmen bitte auch mal im FHEM log schauen ob es irgendwelche Fehler gab.

Welche Version von vitonnect.pm hast du denn genau?

Ansonsten bin ich relativ ratlos und könnte dir nur eine Debug Version anbieten.
Die müsste ich aber erst auf deinen Fall zuschneiden, da ich morgen in Urlaub gehe schaffe ich das nicht mehr davor aber in 15 Tagen könnte ich es dann versuchen wenn das Problem noch besteht.

Gruß,
Stefan

Hallo Stefan,

zuerst einmal vielen Dank für Deine schnelle Antwort.

Ich nutze die Version
98_vitoconnect.pm:v0.8.7-s29593/2025-01-29

vitoconnect_disable_raw ist nicht gesetzt.

Merkwürdig ist halt, dass wenn ich die raw-readings auslese, genau das heating.burners.0.statistics.hours dabei ist.
Und sollte es nicht so sein, dass alle nicht-gemappten readings mit ihrem raw-Namen angezeigt werden?

Ich werde mir mal deine Vorschläge anschauen.

Im JSON finde ich Folgendes:
    {
      "feature": "heating.burners.0.statistics",
      "gatewayId": "...",
      "deviceId": "0",
      "timestamp": "2025-03-19T08:04:25.918Z",
      "isEnabled": true,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/113885/gateways/.../devices/0/features/heating.burners.0.statistics",
      "properties": {
        "hours": {
          "type": "number",
          "value": 31504,
          "unit": "hour"
        },
        "starts": {
          "type": "number",
          "value": 550679,
          "unit": ""
        }
      },
      "commands": {}
    },

Und vor allem keinen Streß!! Urlaub geht vor!
Ich kann ja mal während Deines Urlaubs ein wenig testen und meine Erkenntnisse teilen.

Danke

Hi Uwe,
ok das JSON hilft schonmal weiter.

Ich habe das alte Mapping ja nicht gebaut und warte es nur.
Vielleicht gibt es ein Problem bei mehreren Properties zu einem Datenpunkt.
Den "starts" Datenpunkt bekommst du aber?

Ich schaue mir das gerne nach meinem Urlaub an, denke auch das da irgendwo ein Bug ist.

Wie oft erwähnt möchte ich dich auch motivieren darüber nachzudenken auf vitoconnect_raw_readings umzustellen.
Das wird in Zukunft der neue Standard und solche Probleme sollte es dabei nicht geben.

Gruß,
Stefan

ja, den starts-Datenpunkt bekomme ich.

Zudem habe ich getestet und das Mapping für heating.burners.0.statistics.hours aus der Liste entfernt.

Dann bekomme ich das reading auch als raw-reading angezeigt.

Zum Thema Umstellung auf die raw_readings:
- Die Werte sind so halt schöner lesbar. Natürlich könnte man sich da z.B. mit readingsProxys behelfen.
- Zur Umstellung wäre es hilfreich, wenn es ein Option gäbe, die gemappten und die raw-readings zu bekommen. Dann könnte man sukzessive umstellen.

ich wünsche einen schönen Urlaub

Beitrag #190

Zitat von: stefanru am 13 März 2025, 21:52:36Man kann sich das Gerät auch 2 mal anlegen. Als Raw Readings und als normales. Dann bei beide disablen und ein GetResponceOnce bei beiden kurz hinter einander machen. Dann kann man die Werte in aller Ruhe vergleichen.
heating.sensors.temperature.outside.value sollte der Außentemperatur Fühler der Anlage sein. Ist es zumindest bei mir.

Könnte man machen, um das zweite Gerät dann irgendwann wieder zu löschen....
Zudem müsste man nicht nur den Reading-Namen, sondern auch das device an den entsprechenden Stellen ändern.

Eleganter wäre da schon die Variante, beide readings zu haben. Wenn man dann irgendwann mit seiner Umstellung fertig ist, braucht man nur noch das attribut zurücksetzen und gut ist.

Zitat von: Beta-User am 14 März 2025, 21:28:12So, auch ein paar news zum Thema weekprofile...

Ergänzend zu diesem Beitrag (gar keine downloads bisher - keiner Interesse?!?) hier je eine weeksprofile- und vitoconnect-Version (samt diff zu letzterer), mit der man jetzt schon Profile aus weekprofile heraus an vitoconnect (und uU. andere, bisher unbekannte "Client"-Module) "versenden" kann. Dazu das neue Attribut bei weekprofile setzen (auf "vitoconnect").

Bisher wird noch nichts versendet, die nächsten steps wären:
- Vergleich mit dem Altwert, wenn geändert:
- Versenden (0.heating) (im Moment wird nur als Reading geschrieben, was versendet werden würde, Abgrenzungslogik siehe den oben verlinkten Beitrag).
- "Schleife" für weitere (per Attribut konfigurierbare) Unter-Geräte (WW-Bereitung und Pumpen mit "on"/"off"-Profilen)

Falls sich erfolgreiche Mittester gefunden haben, würde ich das mal an @Risiko adressieren, damit weekprofile allgemein so vorbereitet wird, dass man selbst weitere Client-Module angeben kann :) .

@Beta-User
Bei mir geht es nur darum Werte aus der Anlage zu lesen und entsprechend in Fhem darzustellen.
Mit der Weiterentwicklung von stefanru und Dir sind meine Anforderungen gut abgedeckt.
Die Umstellung auf nur RAW-Readings finde ich sehr gut.

Meine alte Viessmann hatte Optolink und die Unabhängigkeit von der Cloud-Lösung fand ich richtig gut.
Hab schon mehrfach bei open3e geschaut aber mich stört das es auf einem zusätzlichen Raspberry laufen würde und dann die Werte über MQTT ankommen.

Bei meiner Gastherme macht es nach meiner Kenntnis wenig Sinn ständig Werte zu ändern.
Das kann bei einer Wärmepumpe natürlich durchaus sinnvoll sein.

Noch eine Frage die hier ggf. falsch aufgehoben ist: Wie lösche ich nach erfolgreicher Umstellung auf RAW-readings alle nicht mehr aktuellen Readings aus dem Device (HK1*, WW*, Stromverbrauch* etc.)? Jedes einzeln mit { delete $defs{<NAME>}{READINGS}{T_avg_day} } wär jetzt nicht so meins :-). So ganz ist FHEM immer noch nicht mein Freund.

Zitat von: neworder am 21 März 2025, 20:06:35Noch eine Frage die hier ggf. falsch aufgehoben ist: Wie lösche ich nach erfolgreicher Umstellung auf RAW-readings alle nicht mehr aktuellen Readings aus dem Device (HK1*, WW*, Stromverbrauch* etc.)? Jedes einzeln mit { delete $defs{<NAME>}{READINGS}{T_avg_day} } wär jetzt nicht so meins :-). So ganz ist FHEM immer noch nicht mein Freund.

Gibt einen set-Befehl dafür. Damit ist zwar erst mal alles weg, aber das kommt dann auch wieder.
Oder ist statistics oder so dann beleidigt?

damn, "clearReadings" gerade selber gefunden O:-).

Zitat von: neworder am 21 März 2025, 20:14:20damn, "clearReadings" gerade selber gefunden O:-).

Na ja, auf mich wirkt dieser setter auch etwas nach einer eher überraschenden Übergangslösung...

Eigentlich ist "deletereading" mit passender regex die Lösung, die man mittelfristig kennen sollte - ich würde nämlich dafür votieren, "Standardfunktionalität" (die man eigentlich in so einem Device - anders als in einem BT-GW - nicht braucht) nicht extra als setter bereitszustellen.

Btw.: Es gibt auch Devices, bei denen man via "get" ReadingsVal()-Abfragen machen kann - historsch gewachsen, aber irgendwann halt überholt.

Zitat von: buec65 am 20 März 2025, 06:51:20Mit der Weiterentwicklung von stefanru und Dir sind meine Anforderungen gut abgedeckt.

Dieses Lob gilt ausdrücklich nur stefanru! Bis dato sind - abgesehen von dem dankenswerterweise aufgegriffenen Hinweis auf das "decode_json()"-codepage-Problem - keinerlei Vorschläge von mir im svn-Code enthalten ;)

(Und anscheinend hat auch außer mir keiner Bedarf an weekprofile - jedenfalls hat auch keiner bisher die überarbeitete Fassung (die effektiv nicht mehr kann wie die svn-Fassung) am Start).

Hi Stefan,

Im Log meiner Heizung ist mir aufgefallen, dass manche Fehlermeldungen HTML-formatierten Text zurückgeben (z. B. <ul><li>...</li></ul>). Wäre es möglich, diese im Modul zu parsen, sodass die Ausgabe als Klartext oder als formatierte Liste erscheint?

2025-02-25_14:32:26 vitoconnect device.messages.errors.raw.entries: expert, d4, note, 2025-02-25T14:28:49.000Z, debug, f0, note, 2025-02-25T14:28:49.000Z, maintainer, 07, note, 2025-02-25T14:28:48.000Z
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.0.faultCode: D4
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.0.faultCodes.0.cause: <ul><titel>Hochdruckstörung:</titel><li>Luft im Heizkreis</li><li>Sekundärpumpe oder Heizkreispumpe blockiert</li><li>Verflüssiger verschmutzt</li><li>Hochdrucksensor defekt</li></ul>
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.0.faultCodes.0.measure: <ul><li>Heizkreis entlüften.</li><li>Anlagendruck prüfen.</li><li>Sekundärpumpe und Heizkreispumpen prüfen.</li><li>Heizkreise spülen.</li><li>Speichertemperatur-Sollwert (Warmwassertemperatur-Sollwert 6000, Warmwassertemperatur-Sollwert 2 600C) um 2 bis 3 K verringern.</li><li><ul><titel>Hochdrucksensor an folgenden Anschlüssen der Außeneinheit prüfen:</titel><li>Vitocal 100-S/111-S:Anschluss H_PRESS auf der Hauptleiterplatte: Siehe Hauptleiterplatte [7] / [7-1].</li><li>Vitocal 200-A/200-S/222-A/222-S:Anschluss J10 auf EEV-Leiterplatte: Siehe EEV-Leiterplatte [4-3] / [4-4].</li><li>Vitocal 200-A, Typ AWCI-AC 201.A:Anschluss J3 auf EEV-Leiterplatte: Siehe EEV-Leiterplatte [2].</li><li>Vitocal 222-G/333-G:Anschluss J10 auf EEV-Leiterplatte: Siehe EEV-Leiterplatte [4-6] / [4-7].</li><li>Vitocal 300-A, Typ AWO-AC 301.B:Anschluss J10 auf EEV-Leiterplatte: Siehe EEV-Leiterplatte [4].</li><li>Vitocal 300-A, Typ AWO 302.B:Anschluss J5 auf Reglerleiterplatte: Siehe Reglerleiterplatte [6].</li></ul></li></ul>
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.faultCode: 07
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.severity: Hinweis
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.systemCharacteristics: Siehe Zusatzcode:Letzte Meldung aus Meldungshistorie Kältekreis
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.faultCodes.1.cause: Meldung vom Kältekreisregler Wärmepumpe 1. Stufe
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.faultCodes.1.measure: Diagnose, Kältekreis, Meldungshistorie beachten.
2025-02-25_14:34:26 vitoconnect device.messages.errors.raw.entries:

Viele Grüße
Schlimbo

Hi Schlimbo, schaue ich mir an wenn ich wieder Zuhause bin.
Lässt sich besser darstellen.

Gruß,
Stefan

So, hatte mal wieder etwas Zeit, weitergeschraubt und mir dabei die API-Calls verbraucht...

Code folgt, wenn (morgen früh?) alles soweit wieder funktioniert, hier aber erst mal ein paar Gedanken und Anmerkungen:
- Für das define würde ich vorschlagen, dass man nur den user angeben muss, aber sowohl apiKey wie Passwort (nebst Intervall) optional direkt mit angeben kann; die beiden "secrets" würden dann direkt weggeschrieben und aus der DEF entfernt?
- Bisher gab es gar keine RenameFn(). Ich hätte jetzt eine im Angebot. Der Haken: das ganze funktioniert (bei allen RenameFn() lt. https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Rename) allerdings nur dauerhaft, wenn man danach auch noch speichert. Da bei uns hier der user-Name Pflicht ist, könnte man auch einfach hergehen, und den (zusammen mit dem Modulnamen) als Kenner verwenden, dann könnte man sich das (weitgehend) sparen. "Lustig" wird das nur, wenn sich jemand beim user vertippt hat, das bekommt man dann nicht ohne weiteres aus der file wieder raus... Meinungen?
- Bei manchen Variablennamen habe ich Bauchweh: %translations, $client_secret, $callback_uri und ein paar andere sind imo eigentlich nicht verwechslungssicher, werden aber im main-namespace definiert. Das schafft definitiv spätestens dann Probleme, wenn jemand den Code als Blaupause für was eigenes verwenden will...
Also müssen wir entweder überall was unterscheidendes wie "vitoconnect_" davor schreiben, oder das Modul einpacken (ich würde letzteres vorschlagen).
- Was das "Verdoppeln" von Devices angeht, mals ins Unreine gesprochen:
Wir könnten Anfrageantworten doch schlicht so dispatchen, dass man andere Instanzen als Clients mit versorgt. Das ginge z.B., indem man im Define eines solchen Clients den Namen der Hauptinstanz als "IODev=xxx" mit angibt, zusammen mit einem weiteren Parameter für den Anlagenteil, den man in der Nebeninstanz haben will (z.B. "subset=0.heating"). Vorteil: Man könnte in den Nebendevices "schöne" Reading-Namen, set-Benennungen usw. haben, zu definieren über je eine eigene "Übersetzungsdatei", ohne dass der Anfrage-Aufwand steigt oder man irgendwelche Klimmzüge mit Ein- und Ausschalten machen muss.   

Meinungen?

Zitat von: Beta-User am 26 März 2025, 20:04:13Code folgt

Hmmm, das weekprofile wird zwar nicht versendet (vermutlich noch eine Frage der Payload, set_new scheint das anders zusammenzubasteln?), aber der Rest funktioniert anscheinend, ohne FHEM abzuschießen.

Daher hier meine aktuelle Fassung als Diskussionsgrundlage, ich komme vermutlich im Moment nicht wirklich dazu, das mit der Payload zu fixen.

OK, Fehler gefunden - das mit weekprofile funktioniert jetzt mit dem ersten Heizkreis :) .

Achtung: Da ist einiges geändert, wer testen will, muss zum einen FHEM neu starten und sollte zum anderen seine raw-Def irgendwohin wegsichern, weil die DEF selbst dann angefasst wird. So kann man gleich das echte Passwort und den apiKey übergeben, das wird dann intern weggesichert und nachträglich aus der DEF entfernt ;) . Vorschlag für die neue commandref:
define vitoconnect vitoconnect user@mail.xx password=somesecretthing apiKey=someothersecret 60

Hi Beta-User,

bin zurück vom Urlaub.

Danke für deine Arbeit.
Zur Zeit habe ich noch einiges abzuarbeiten was liegen blieb während meines Urlaubs aber ich würde mir deine Änderungen danach anschauen.
Ist die Version die, die dann ins Repo sollte oder bist du noch weiter am Arbeiten daran?

Danke und Gruß,
Stefan

Erst mal: Willkommen zurück!

Lass dir Zeit beim Ankommen.

Meine Fassung ist - soweit erkennbar - funktional, aber
- das nur mit der passenden weekprofile-Version,
- nicht intensiver getestet
- in manchen zentralen Punkten, "anders", v.a., was die Einrichtung angeht.

Man könnte das jetzt in Abschnitten angehen, aber vermutlich wäre es besser, wenn
- zumindest du (und ggf. weitere User) die Änderungen mal eine gewisse Zeit am Laufen hast (und das gut findest), und
- Risiko das in weekprofile übernommen hat, was da an Änderungen vorzunehmen wäre. Ich pinge ihn dazu jetzt mal an (erledigt, siehe https://forum.fhem.de/index.php?topic=46117.msg1338915#msg1338915).

Dann würden wir in der Zwischenzeit ggf. weitere Schritte überlegen:
- die Topic-Änderung auch an was anderes durchreichen wie im Moment nur den 0-er Heizkreis. Ich hätte da zwar ein paar unreife Gedanken dazu im Kopf, aber auch eher wenig Zeit, das anzugehen...
- Sub-Devices (z.B. für das Brauchwasser) ermöglichen? Das ginge jetzt vermutlich mit der geänderten DEF-Logik relativ einfach (ich müßte mal in den Code von snapcast schauen), und angrenzend:
- wie ist das mit eventuellen "Übersetzungsfiles"?

Hi @Schlimbo,
zu deiner Anfrage der HTML Fehler.
Ich versuche gerade herauszufinden wo das gelogged wird, bin aber etwas unschlüssig.
Da ich gerade keine Fehler bei meiner Anlage bekomme, ist es schwer für mich nachzuvollziehen.
Hast du vielleicht noch etwas davor und danach?
Außerdem fehlt mir irgendwie die Severity der Meldungen?

@ Uwe S.
Ich würde mir dein Problem mit dem Mapping auch gerne anschauen.
Könntest du mir zuerst mal das File resource_[seriennumemr].json aus dem FHEM Log Verzeichniss schicken?
Danach würde ich schauen dass wir debugging für dich einbauen und du das dann testest.


Gruß,
Stefan

Hi Stefan,
ich habe nun auch mal Deine Version ausprobiert. Das mit den Mappings ist kein Problem. Ich habe mir ein vitoconnect_mappings Attribut gebaut, womit ich "meine" Namen abbilde. Ein vitoconnect_mapping_roger ist also (zumindest für mich) nicht nötig.

Kann es aber sein, dass das Setzen der Warmwasser Betriebsart nicht funktioniert? Da muss man ja heating.dhw.operating.modes.active/commands/setMode verwenden. Das set <name> HK1-Betriebsart dhw oder dhwAndHeating funktioniert bei meiner Heizung nicht mehr.

Bin erst mal wieder auf "meine" Version zurück.

PS: Habe mal in Deine Code geschaut.  8) Ach so: Wenn man vitoconnect_mapping_roger setzt --> gibt es andere Befehle - dann auch ein set <name> WW_Betriebsart balanced oder off  ;)
Meiner Meinung nach sollte ein generelles Modul (was für alle Viessmann-Geräte geeignet ist), folgendes können:
- mit vitoconnect_mappings kann jeder ihm passende Readingsnamen setzen (wenn er will, sonst hat der die RAW-Namen)
- mit ????? kann jeder Befehle in seinem Syntax kreieren, welche dann den angegebenen String auf einen Wert setzt
So könnte man mit einem generellen Modul verschiedenen Viessmann-Geräte bedienen (und für sein Geräte die Anpassungen hier teilen).
Aber wie mach das Viessmann mit seiner App? Da gibt es ja auch nur eine Version der App für die verschiedenen Gerätetypen.

Gruß Roger

Hi Roger,

danke für deine Antwort.

Könnte ein Problem sein mit den vitoconnect_mappings.
Ich habe das gebaut, aber nur fürs mappen.
Dann bin ich selbst auf vitoconnect_raw_readings gewechselt, weil ich gemerkt habe dass das mappen nur alles schwieriger macht.
Habe die Mappings nie mit dem setzen von Befehlen getestet und das ist auch eigentlich nicht eingebaut.

Wie du schreibst wären die Mappings wahrscheinlich die Lösung, so dass man sich seine eigenen Mappings erstellen kann und diese auch hier teilen.
Diese wären auch einfach an neue XMLs von Viessmann anpassbar.

Wenn man nur vitoconnect_raw_readings verwendet werden auch die Setter aus dem von Viessmann gelieferten XML erzeugt und du solltest den Befehl setzen können.

Bei mir sieht das so aus:
Screenshot 2025-04-21 002804.png

Falls vitoconnect_mappings von vielen bevorzug würde könnte ich mir das anschauen ob man das mapping auch beim setzen irgendwie hinbekommt.
Das ist aber nicht trivial, müsste ich etwas ausprobieren, könnte aber klappen.

Viele Grüße,
Stefan

Vielleicht (!) klappt das mit dem mappen mit meiner Version, die ist etwas generischer, was die Namen angeht.

Habe auch was in Vorbereitung, das das mapping aus einer separaten Datei holen kann, das muss ich aber auch erst antesten - nicht vor kommender Woche ;) .

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

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.

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

Hi,
wie ich schrieb:

Zitat von: Roger am 21 April 2025, 11:57:30Meine 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

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

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

Gruß,
Stefan

...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 :) .

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

Gruß,
Stefan

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

Hi,

Ok, das klingt super!
Bin jetzt über den Feiertag weg, danach auch nochmal Urlaub  8)  :o  :o  ;D
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

Zitat von: stefanru am 30 April 2025, 16:31:26Ok, das klingt super!

Danke erst mal für die Rückmeldung!

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

Zitat von: stefanru am 30 April 2025, 16:31:26Wenn 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.

Zitat von: stefanru am 30 April 2025, 16:31:26Also 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?

Zitat von: stefanru am 30 April 2025, 16:31:26Ich 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 ;).

Zitat von: stefanru am 30 April 2025, 16:31:26Ja 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...

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.

Hi Beta-User,

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

Gruß,
Stefan

Moin, keine Eile...

Vielleicht noch ein paar Anmerkungen:

Mein "Server" ist (anonymisiert) so definiert:
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:

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 :) .

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?

Hi BetaUser,

oh wow das sind jetzt sehr spezifische Fragen.
Kannst du da ein Beispiel machen.

Ja ich achte auf das isExecutable Flag, wenn etwas nicht schaltbar ist wird es keinen Setter dafür geben.

Man muss auch sagen die API ist da total wild und ganz generisch geht es nicht.
Teilweise kommt es auf Reihenfolgen an die ja im JSON eigentlich nicht gegeben sind dann ist es uneinheitlich bei setActive und activate usw.
Das war ein Riesen Krampf, aber ich habe versucht es so generisch wie möglich hin zu bekommen, aber bei dem schlechten API Design gibt es ein paar Workarounds damit es überhaupt ging.

Ich versuche gern dir die Fragen im Detail zu erklären wenn du mir genau sagst was du wissen willst.
Was ist den depricated markiert?

Gruß,
Stefan

Zitat von: stefanru am 08 Mai 2025, 22:06:58oh wow das sind jetzt sehr spezifische Fragen.

Sorry for that :)

Habe gestern dann auch im Thread noch ein wenig rückwärts gelesen und gesehen, dass es dir v.a. darum geht, an die Infos zu kommen, weniger um's Steuern.

Zitat von: stefanru am 08 Mai 2025, 22:06:58Was ist den depricated markiert?

Einer von (bei mir) 6 Einträgen:
{
      "feature": "heating.circuits.0.operating.programs.noDemand",
      "gatewayId": "#gwid#",
      "deviceId": "0",
      "timestamp": "2025-05-09T04:28:24.746Z",
      "isEnabled": false,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/#installation#/gateways/#gwid#/devices/0/features/heating.circuits.0.operating.programs.noDemand",
      "properties": {},
      "commands": {},
      "deprecated": {
        "removalDate": "2024-09-15",
        "info": "replaced by heating.circuits.N.operating.programs.reducedEnergySaving"
      }
    },

Zitat von: stefanru am 08 Mai 2025, 22:06:58ich habe versucht es so generisch wie möglich hin zu bekommen, aber bei dem schlechten API Design gibt es ein paar Workarounds damit es überhaupt ging.

Ja, das sieht einigermaßen unübersichtlich aus, und wie man an "deprecated" erkennen kann, scheint auch einiges im Umbau zu sein, was ggf. einige "Uneinheitlichkeiten" erklären könnte.

Na ja, wir werden kaum Einfluss haben, wie es in der API künftig umgesetzt werden wird, sondern nur versuchen, "gute" und möglichst generische Lösungen zu finden, um das in FHEM (einigermaßen) sauber abzubilden.

ZitatKannst du da ein Beispiel machen.

Hier mal zwei Varianten:
{
      "feature": "heating.dhw.oneTimeCharge",
      "gatewayId": "#gwid#",
      "deviceId": "0",
      "timestamp": "2025-05-08T21:41:50.535Z",
      "isEnabled": true,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/#installation#/gateways/#gwid#/devices/0/features/heating.dhw.oneTimeCharge",
      "properties": {
        "active": {
          "type": "boolean",
          "value": false
        }
      },
      "commands": {
        "activate": {
          "uri": "https://api.viessmann.com/iot/v2/features/installations/#installation#/gateways/#gwid#/devices/0/features/heating.dhw.oneTimeCharge/commands/activate",
          "name": "activate",
          "isExecutable": true,
          "params": {}
        },
        "deactivate": {
          "uri": "https://api.viessmann.com/iot/v2/features/installations/#installation#/gateways/#gwid#/devices/0/features/heating.dhw.oneTimeCharge/commands/deactivate",
          "name": "deactivate",
          "isExecutable": true,
          "params": {}
        },
        "setActive": {
          "uri": "https://api.viessmann.com/iot/v2/features/installations/#installation#/gateways/#gwid#/devices/0/features/heating.dhw.oneTimeCharge/commands/setActive",
          "name": "setActive",
          "isExecutable": true,
          "params": {
            "active": {
              "type": "boolean",
              "required": true,
              "constraints": {}
            }
          }
        }
      }
    },
   
    {
      "feature": "device.time.daylightSaving",
      "gatewayId": "#gwid#",
      "deviceId": "0",
      "timestamp": "2025-05-08T21:41:50.535Z",
      "isEnabled": true,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/#installation#/gateways/#gwid#/devices/0/features/device.time.daylightSaving",
      "properties": {
        "active": {
          "type": "boolean",
          "value": true
        },
        "begin": {
          "type": "string",
          "value": "25-03"
        },
        "end": {
          "type": "string",
          "value": "25-10"
        }
      },
      "commands": {
        "activate": {
          "uri": "https://api.viessmann.com/iot/v2/features/installations/#installation#/gateways/#gwid#/devices/0/features/device.time.daylightSaving/commands/activate",
          "name": "activate",
          "isExecutable": true,
          "params": {
            "begin": {
              "type": "string",
              "required": true,
              "constraints": {
                "regEx": "^[\\d]{2}-[\\d]{2}$"
              }
            },
            "end": {
              "type": "string",
              "required": true,
              "constraints": {
                "regEx": "^[\\d]{2}-[\\d]{2}$"
              }
            }
          }
        },
        "deactivate": {
          "uri": "https://api.viessmann.com/iot/v2/features/installations/#installation#/gateways/#gwid#/devices/0/features/device.time.daylightSaving/commands/deactivate",
          "name": "deactivate",
          "isExecutable": true,
          "params": {}
        }
      }
    },
Das mit "oneTimeCharge" ergibt dann drei set-Kommandos, wobei in letzterem die "sinnvolle" Auswahl (on/off bzw. 0/1) "fehlt".
heating.dhw.oneTimeCharge.activate:noArg
heating.dhw.oneTimeCharge.deactivate:noArg
heating.dhw.oneTimeCharge.active
Als Reading taucht dann (m.E. korrekterweise) nur "heating.dhw.oneTimeCharge.active" auf.

Vermutlich sollten wir in den properties diesen Teil
"properties": {
        "active": {
          "type": "boolean",anders auswerten und dann (tendenziell) die "activate"/"deactivate"-Teile in der setFn anders ergänzen als bisher bzw. mal schauen, was Roger dazu gebastelt hatte. Das sollte auch irgendwie generisch(er) gehen...

Vermutlich schaue ich mir das bei Gelegenheit mal an, aber die nächsten paar Tage wird das eher nichts.

Hi Beta-User,
danke!

Jetzt verstehe ich.
Also die deprecated gab es bei mir noch nicht.
Die könnte man ja auch wegfiltern, wie auch mit dem isExecutable.
Oder man lässt sie einfach bis sie dann entfernt werden?

Na mir ging es erst ums Auslesen und mappen.
Als ich dann für mich auf RawReadings ging habe ich aber auch das setzen generisch umgesetzt.

Heißt an deinem Beispiel, dass mein Coding dynamisch "heating.dhw.oneTimeCharge.active" als reading erkennt.
Daraus werden generisch 2 Setter erzeugt:
heating.dhw.oneTimeCharge.activate:noArg
heating.dhw.oneTimeCharge.deactivate:noArg
Diese funktionieren auch.

Und halt auch wie in der API beschrieben noch einen dritten heating.dhw.oneTimeCharge/commands/setActive.
Der wird im DropDown als heating.dhw.oneTimeCharge.active 0/1 angezeigt.
Also mein Coding bildet hier die API ab, alle 3 Setter sind vorhanden.

Der 3te führt aber zu:
  "details": "The parameter active=\"1\" does not meet the constraints {\"type\":\"boolean\"}: Value '1' should be a boolean."
Da sollte ich wirklich im Coding auf das boolean achten und true und false reingeben.

Dann wäre es aber ok, oder?

Gruß,
Stefan

Zitat von: stefanru am 09 Mai 2025, 10:48:44Der wird im DropDown als heating.dhw.oneTimeCharge.active 0/1 angezeigt.

Nope. Da kommt (im Moment) die 0 (=Reading-Wert) als Vorgabe für ein Freitextfeld.

Zitat von: stefanru am 09 Mai 2025, 10:48:44Dann wäre es aber ok, oder?

Hmmm, also:
M.E. sind 3 setter nicht optimal, auch wenn 2 davon ootb funktionieren.

Den "eigentlich korrekten" setter (der mit dem Reading-Wert verknüpft ist) zu reparieren (auch hinsichtlich der 0/1-Vorgabe), ist imo "nur" das Minimal-Ziel.

(Die anderen beiden setter in den Kindern wegzufiltern, ist dagegen kein Problem, aber imo eben unnötig, wenn es die schon im "Server" nicht mehr gibt.)

Vom Vorgehen her würde ich dazu tendieren, aus dem einen setter die "activate" bzw. "deactivate"-Variante abzuleiten und das dann für die URL-Generierung zu verwenden.
Sonderlocke: Ja, aber eben beschränkt auf "boolean", und soweit in meinen JSON erkennbar auch einheitlich und generalisierbar umsetzbar.

Nachvollziehbar?

Ok, ja nachvollziehbar.

Zur Zeit zeigt dieser Setter den aktuellen zustand an in einem Freitextfeld
Also bei mir heating.dhw.oneTimeCharge.active 0.

Man müsste den Setter also auf Boolean umstellen und invertieren.
Also so dass man heating.dhw.oneTimeCharge.active true setzen würde.
Immer passend zum aktuellen Zustand.

Richtig?

Gruß,
Stefan

Zitat von: stefanru am 09 Mai 2025, 12:17:20Man müsste den Setter also auf Boolean umstellen und invertieren.

Dass der aktuell eingestellte Wert als Vorgabe eingestellt ist, ist m.E. ok, Invertieren braucht (und sollte!) man dagegen nicht. Nur sollte dann eben die Auswahl auf das "passende Paar" beschränkt werden (statt Freitext). Da die API für bool 0 und 1 verwendet/zurückmeldet, wäre es eben das.
FHEM-typischer wäre on/off, aber wenn schon denn schon könnte man für set-Befehle auch eine Logik implementieren, die mit allen drei Werten (on=true=1) klar käme und (?) das dann in (z.B.) "heating.dhw.oneTimeCharge.activate" bzw. "heating.dhw.oneTimeCharge.deactivate" umsetzt.

Ok,
jetzt reden wir aber etwas aneinander vorbei.
Bisher haben bei Raw readings die Setter im UI die Namen der Readings z.B. heating.circuits.0.heating.curve.shift.
Umgesetzt wird das dann wenn der Set Befehl gesendet wird.

Also wenn wir das für die Booleans so auch machen wollen müsste man doch:
heating.dhw.oneTimeCharge.activate:noArg
heating.dhw.oneTimeCharge.deactivate:noArg
entfernen und nur:
heating.dhw.oneTimeCharge.active [boolean]
nehmen.
Der beim senden dann
heating.dhw.oneTimeCharge/commands/setActiv [boolean] wird.

Also alles in allem scheine ich boolean nicht richtig zu beachten.
Im Coding habe ich:
                        } elsif ($param->{'type'} eq 'boolean') {
                            $val .= "$readingName ";

Ich kann mal schauen warum das nicht klappt und was ich machen muss.
Dann würden diese Setter auch gehen.
Die anderen beiden rausfiltern kann man dann noch machen.
Eventuell nur in einem Child?

Gruß,
Stefan


P.S.:
Ist ja lustig.
Bei mir sieht das API JSON mitlerweile anders aus und es gibt kein setActive mehr:
    {
      "feature": "heating.dhw.oneTimeCharge",
      "gatewayId": "7736172146035226",
      "deviceId": "0",
      "timestamp": "2025-03-07T12:06:31.802Z",
      "isEnabled": true,
      "isReady": true,
      "apiVersion": 1,
      "uri": "https://api.viessmann.com/iot/v2/features/installations/2772216/gateways/7736172146035226/devices/0/features/heating.dhw.oneTimeCharge",
      "properties": {
        "active": {
          "type": "boolean",
          "value": false
        }
      },
      "commands": {
        "activate": {
          "uri": "https://api.viessmann.com/iot/v2/features/installations/2772216/gateways/7736172146035226/devices/0/features/heating.dhw.oneTimeCharge/commands/activate",
          "name": "activate",
          "isExecutable": true,
          "params": {}
        },
        "deactivate": {
          "uri": "https://api.viessmann.com/iot/v2/features/installations/2772216/gateways/7736172146035226/devices/0/features/heating.dhw.oneTimeCharge/commands/deactivate",
          "name": "deactivate",
          "isExecutable": true,
          "params": {}
        }
      }
    },

Somit wäre meine Idee von oben hinfällig und man müsste eigentlich nur den unnötigen Setter ausblenden.
Das JSON neu einlesen hat den Setter setActive aber nicht verschwinden lassen.
Da muss ich mal drüber nachdenken warum er den noch anzeigt.

Gruß,
Stefan

Zitat von: stefanru am 09 Mai 2025, 12:37:04Also wenn wir das für die Booleans so auch machen wollen müsste man doch:
heating.dhw.oneTimeCharge.activate:noArg
heating.dhw.oneTimeCharge.deactivate:noArg
entfernen und nur:
heating.dhw.oneTimeCharge.active [boolean]
nehmen.

Korrekt. Das war der Vorschlag.

Zitat von: stefanru am 09 Mai 2025, 12:37:04Der beim senden dann
heating.dhw.oneTimeCharge/commands/setActiv [boolean] wird.

Da das "setActive" anscheinend nicht immer klappt, wenn wir es mit boolean zu tun haben, müßte man m.E. entweder erst schauen, ob es das gibt, und/oder gleich die anderen "topics" verwenden.

EDIT: qed mit deinem JSON-update...

Was das Rausfiltern angeht: bei den Kindern geht das schon jetzt. Imo ist es aber verwirrend, wenn man für ein und denselben Zweck 3 set-Optionen hat (von denen nur 2 einen Effekt haben können).
Von daher würde ich dafür votieren, das "FHEM-ish" zu gestalten und beim Prinzip "das Reading soll geändert werden" bleiben und auch im Hauptdevice ausschließlich die eine set-Option anbieten. Dann muss man übrigens hinterher bei den Kindern auch nichts mehr filtern ;) .

Ok, ja verstehe ich.
Da es bei mir im JSON gar kein setActive mehr gibt müsste ich erstmal nachschauen warum es den Setter noch gibt.
Das verstehe ich gerade nicht.
Sollte doch hierüber gar nicht reinkommen:
 if (exists $item->{commands}) {

Gruß,
Stefan

Zitat von: stefanru am 09 Mai 2025, 12:37:04Das JSON neu einlesen hat den Setter setActive aber nicht verschwinden lassen.
Da muss ich mal drüber nachdenken warum er den noch anzeigt.

Hmmm, unabhängig von allem:

In meinem Code ist das mit den set-Befehlen noch etwas statischer, das wird im Prinzip nur einmalig zum define-Zeitpunkt ermittelt (bzw. wenn das JSON da ist), und bei den Kindern dann nochmal, wenn das mapping geändert wird.
Wenn sich das ändern kann, ist das nicht so lustig, allerdings hatte ich bisher keine offensichtlichen Probleme (aber auch nicht viel gemacht). Ggf. müssen wir einen timer einbauen, der das zumindest hin und wieder erneuert...

Ja so wie ich das jetzt sehe schrauben sie an dem JSON gerade rum.
Es habe sich eindeutig dinge geändert.
Bei mir sollten die Setter bei jedem Einlesen angepasst werden.

Habe gerade in einem neuen Device logReponceOnce gemacht und der Setter wurde erzeugt.
Beim nachschauen im JSON ist er jetzt auch wieder vorhanden in der API???

Ich denke das müssen wir mal beobachten, vielleicht ist da gerade nur viel im Gange.
Habe da etwas im Viessmann Forum gelesen.

Lange Rede kurzer Sinn:
Ja das API scheint sich zu ändern, damit sollte man umgehen können.
Zur Zeit erstelle ich die Setter dynamisch anhand des JSON bei jeder Response.
Es wäre aber auch ok die Änderungen per Setter neu einzulesen.
Wäre eventuell auch konsistenter und man weiß wann sich etwas ändern kann und es fehlen nicht auf einmal Setter und man weiß nicht warum.

Gruß,
Stefan

Vielleicht noch zur Klarstellung zu meinem Code: Auch da werden die set-Optionen jedes Mal neu erstellt, aber es wird der "choose one of"-String (als  Antwort auf "getAllSets()") zwischengespeichert bzw. nur am Ende neu erstellt, wenn ein unbekanntes Kommando versucht wird.
Damit soll verhindert werden, dass jedes Mal (wenn man die ganzen Log3-Answeisungen dazu nimmt) imo aufwändig der String zusammengebastelt wird, nur weil z.B. FHEMWEB wissen will, was im Frontend anzuzeigen ist...

"Echte" und nach dem jeweils aktuellen JSON zulässige set-Anweisungen sollten aber eigentlich immer funktionieren, aber ehrlich gesagt bin ich da im Moment auch noch nicht so tief drin, wie das im Details funktioniert O:-) .

Bei den gemappten Kindern ist das allerdings anders, weil da getAllSets() verwendet wird um rauszufinden, was "Server" kann.

Ja bin bei dir, das macht schon Sinn die Setter nicht immer wieder neu zu erstellen.
Hatte das beim Debuggen meines Codes auch beobachtet.
Wusste aber als Neuling nicht wie man das behebt und hab mich erstmal auf die Funktionalität konzentriert.

Also bin völlig bei dir das zu Puffern, macht Sinn!

Gruß,
Stefan

Kurze Zwischeninfo - habe hier mal einen Post dazu aufgemacht, wie man das mit den "Kindern" ggf. sonst noch lösen könnte: https://forum.fhem.de/index.php?topic=141647.0

Im Moment tendiere ich dazu, den Teil abzutrennen und vitoconnect selbst als (optionales!) IODevice im Sinne des 2-stufigen Modulkonzepts zu modifizieren. (Weitere Info gleich im anderen Thread).
Meinungen dazu?

Ok, super, danke für das Update.
Ich folge der Diskussion mal.
Klingt interessant.
Ich habe leider hier noch ein weiteres Problem bei mir persönlich und kann gerade nicht viel mithelfen.
Ich lese auf jeden fall mit und hoffe auch in einiger zeit wieder mit testen und wenn nötig auch entwickeln zu können.

Viele Grüße,
Stefan

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 .

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
 

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

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 (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