Vitoconnect - Verbesserte Version

[stefanru]

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?

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

[neworder]

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!

[stefanru]

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

[neworder]

Und outch,

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

[neworder]

Bin erstmal weg von den raw readings. Sorry!

[stefanru]

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

[JWRu]

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

[neworder]

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

Das Umstellen von
Du darfst diesen Dateianhang nicht ansehen.
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  . Endlich wieder was zu tun .

Das riecht nach einem oder mehreren Backups.

[JWRu]

Dann 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

[neworder]

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 .

Fehlt ein verregnetes WoEnde und dann gehts los.

[stefanru]

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.

[JWRu]

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

Bei mir auch.

[Basti-K]

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

[neworder]

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  ). Fürs Backup und restore der Modulationswerte waren sie einfach zu wenig nutzen.

[stefanru]

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