Neues Modul: vitoconnect

Begonnen von andreas13, 24 November 2018, 17:42:33

Vorheriges Thema - Nächstes Thema

sepultura30

Hallo Stefan,

das Modul macht keine Änderung an der Heizung, ich habe alle Readings gelöscht und auch das Mapping.
Dann einfach mal die Temp. Warmwasser ändern oder vom HK1, also bei mir geht das nicht.

Das Modul gelöscht aund das aus dem SVN genommen, alles geht.

Vielleicht hättest du das Modul aus dem SVN nehmen sollen.


Grüße

Sandro

satprofi

Funktioniert bei euch der apikey noch? Letztes Reading vom 29.11. , Passwort oder. Apikey wrong. Passwort hat sich nicht geändert.
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

davidgross

Hallo Stefan,

super Danke für deine Arbeit.
Hast du ein Beispiel dafür? Bei meiner Vitocal200S kann ich nix setzen.

Zitat von: stefanru am 28 November 2024, 09:50:10Die Setter kann ich zu RAW Readings dynamisch erstellen.
Leide ist die API von Viessmann nicht gerade durchdacht und das Mapping funktioniert nicht komplett dynamisch, einige Anteile muss man hardcode. Viessmann scheint hier im JSON eine Reihenfolge zu haben, die es aber eigentlich nicht gibt bei HASH Strukturen.
Die Namen sind nicht gleich zwischen Rückgabe Werten und Settern bzw. sind diese in getrennten JSON Strukturen.
Trotzdem habe ich eine ziemlich dynamische Lösung hinbekommen.

Ich habe mir noch nicht die Mühe gemacht bei dem dynamischen Settern auch die neuen Mappings zu implementieren.
Sollte das wirklich jemand brauchen wäre es aber wahrscheinlich einfach umzusetzen.


schönen Abend und einen entspannte Adventszeit!

stefanru

#1098
Hi Sandro,

kannst du bitte nach einem nicht erfolgreichen Schalten mal ins FHEM log schauen und mir die Meldung dazu schicken?
Ich habe mal getestet und WarmWasser konnte ich umstellen.
Bei HK1 bekomme ich aber
2024.12.01 21:18:05 1: viessmann,vitoconnect_action: set viessmann HK1_Soll_Temp_normal 1, Fehler bei Befehlsausfuehrung:  :: {
  "viErrorId": "|f51b0a96-44411633b727e1ed.",
  "statusCode": 404,
  "errorType": "FEATURE_NOT_FOUND",
  "message": "",
  "extendedPayload": {}
}

Ok ich hatte schon gemerkt dass das alte Mapping ganz schön kaputt war.

Wie schon gesagt benutze ich Raw Readings.
Wenn diese eingeschaltet sind werden dynamisch die Setter dazu erzeugt.
Das funktioniert bei mir wunderbar.

Aber klar ich denke ich übernehme dann die Namen und Setter aus dem Modul vom SVN.
Das sollte kein großes Problem sein.
Und wenn dann noch gewünscht die von Roger hinter einem Attribut.

@davidgross:
Um die RAW Readings und Setter zu benutzen genügt es das attribut vitoconnect_raw_readings auf 1 zu setzen.
Danach am besten einmal am Device ein clearReadings und danach ein logResponseOnce.
Dabei werden die Setter eingelesen und erzeugt.
Danach einmal den Browser refreshen und es sollte alles da sein.
Das ganze halt im RAW Format aber wie gesagt ich arbeite da dann mit StateFormat und benutze TabletUI.
Die Raw Readings finde ich da am besten.

Sieht als Beispiel dann so aus.
Du darfst diesen Dateianhang nicht ansehen.

Gruß,
Stefan





stefanru

#1099
Ok, ich habe mal schnell die Mappings und Setter aus dem SVN Modul eingebaut anstatt die von Roger.
Da geht einiges mehr bei mir aber auch lang nicht alles.
Da scheint die API pro Gerät etwas anderes zu liefern.

Wie gesagt ich verwende vitoconnect_raw_readings, dabei versuche ich dynamisch die Setter zu erzeugen.
Bei mir mit einer VitoCal250AH und einem Vitoladens 300C getestet.
Alles geht.

Im Anhang das Modul mit SVN Mapping.
@sepultura30: Kannst du mir bescheid geben ob es so für dich ok ist?

Wenn ja baue ich Roger und SVN ein. SVN als Standard, Roger per Attribut anschaltbar.

Um diese statischen Mappings will ich mich eigentlich nur am Rande und auf genauen Zuruf kümmern.
Mein Hauptaugenmerk liegt auf dem dynamischen mappen,

Gruß,
Stefan

stefanru

Habe noch etwas geschraubt.

Hier das Modul mit beiden Mappings.
SVN ist der Standard.
Rogger kann über das attribut vitoconnect_mapping_roger eingeschaltet werden.

Da jeder von euch ein anderes verwendet habe ich mich hierzu entschieden.

ACHTUNG: Beide Mappings sind erstellt worden für eine spezifische Anlage und werden nicht alle Werte übersetzen.
         Es werden auch nicht alle Werte setzbar sein.
         Ich pflege sie gerne wenn ihr mir genau sagt in welchem Mapping welche übersetzung und welche setter.

Ich empfehle euch jedoch das reading vitoconnect_raw_readings zu setzen.
Ist das gesetzt werden die Setter dynamisch erzeugt und nach dem ersten logReponseOnce oder Datenabruf nach einem Refresh des Browsers angezeigt.
Mit dieser Methode funktioniert bei mir alles.
Hier bin ich bereit aktiv zu arbeiten und das Reading ins dynamische Mapping zu übernehmen mit allen Features und Settern wenn vorhanden.
So haben alle etwas davon.
Sollte beim dynamischen Mapping bei euch etwas nicht gehen, bitte Readingnamen und JSON aus dem FHEM Logverzeichnis (wird erstellt bei logResponceOnce).
Man muss halt mit den Raw Namen leben, aber ich persönlich finde das sogar besser als irgendwelche gemappten Namen.

Hier die neue Version.

Gruß,
Stefan


sepultura30

Hallo,

das einzige was nicht geht, ich kann meine Heizungswerte nicht ändern.
z.B setze ich Warmwasser auf 50 Grad, bei dem nächsten Update stehen wieder 60 Grad -> siehe Bild

Du darfst diesen Dateianhang nicht ansehen.

Und das bei allen set Readings im Device.

Grüße

Sandro


stefanru

Hi Sandro,

du benutzt nun die Raw Mappings?
Das Attribut vitoconnect_raw_readings ist gesetzt, auch bem setten?
Ein Ändern würde das alte Mapping verwenden auch beim setten.

Ich sehe Aktion Status liefert ok mit 50.
Das ist sehr seltsam. Wenn OK setze ich den Wert direkt auf den neuen. Hast du die letzte Version?
Hat sich der Wert denn in der App geändert? Oder wenn du nochmal logReponceOnce ausführst?

Schau bitte nach dem Setzen mal ins FHEM log ob etwas ausgegeben wird. Ich denke aber nicht bei Aktion_Status ok.
Fals gar nichts hilft schicke ich dir eine debug Version, oder baue das vorsorgehalber mal mit ein. So dass wir solche Probleme leichter analysieren können.

Gruß,
Stefan


sepultura30

Hallo Stefan,

schande über mein Haupt, ich habe eine falsche Version gehabt.
Die letzte Version von dir habe ich jetzt im Einsatz, und die läuft.


Grüße

Sandro

stefanru

Super! Danke für die Info.
Freut mich das es jetzt geht.

Ich werde trotzdem mal schauen dass alle set befehle mit verbose 3 geloggt werden können.
So dass eine Analyse für mich leichter wird.

Gruß,
Stefan

stefanru

So die letzte Änderung als Changelog und für alle die eine Wärmepumpe haben die möglichkeit die Day Power Readings zu verwenden, danke an @DS_Starter für die Hilfe.

#   2024-12-02   Day power readings werden nun unter .asSingleValue gespeichert.
#         Die Daten kommen von der API nur sporatisch, erst nach mehreren Tagen.
#         Diese Funktion trägt sie nach und man kann so Graphen malen.
#   2024-12-01   Statisches Mapping von SVN übernommen.
#         Bug bei Fehlerbehandlung von vitoconnect_action behoben
#         Parmeter vitoconnect_mapping_roger um Rogers mapping zu benutzen
#         RequestLists aufgespalten nach SVN und Roger
#         neue sub vitoconnect_Set_Roger

Im Anhang und in meinem Git die neue Version.

Gruß,
Stefan

87insane

TOP :)
Danke für die Arbeit

Nun habe ich auch wieder die alten Readings, was ich gut finde.
Ich habe auch noch ein paar nicht übersetzte. Ich hänge die Liste mal an. Stört mich nun aktuell nicht, da ich diese nicht nutze (bisher) aber so wurde es mal erwähnt.

device.messages.errors.raw.entries
device.serial.value
heating.burners.enabled
heating.circuits.0.name.name
heating.circuits.0.operating.programs.reducedEnergySaving.active
heating.circuits.0.operating.programs.reducedEnergySaving.demand
heating.circuits.0.operating.programs.reducedEnergySaving.reason
heating.circuits.1.name.name
heating.circuits.1.operating.programs.reducedEnergySaving.active
heating.circuits.1.operating.programs.reducedEnergySaving.demand
heating.circuits.1.operating.programs.reducedEnergySaving.reason
heating.dhw.hygiene.active
heating.dhw.hygiene.enabled
heating.dhw.hygiene.trigger.startHour
heating.dhw.hygiene.trigger.startMinute
heating.dhw.hygiene.trigger.weekdays
heating.dhw.operating.modes.active.value
heating.dhw.operating.modes.balanced.active
heating.dhw.operating.modes.off.active
heating.dhw.sensors.temperature.dhwCylinder.status
heating.dhw.sensors.temperature.dhwCylinder.value
heating.dhw.temperature.hygiene.value
heating.gas.consumption.summary.dhw.currentDay
heating.gas.consumption.summary.dhw.currentMonth
heating.gas.consumption.summary.dhw.currentYear
heating.gas.consumption.summary.dhw.lastMonth
heating.gas.consumption.summary.dhw.lastSevenDays
heating.gas.consumption.summary.dhw.lastYear
heating.gas.consumption.summary.heating.currentDay
heating.gas.consumption.summary.heating.currentMonth
heating.gas.consumption.summary.heating.currentYear
heating.gas.consumption.summary.heating.lastMonth
heating.gas.consumption.summary.heating.lastSevenDays
heating.gas.consumption.summary.heating.lastYear
heating.power.consumption.dhw.dayValueReadAt
heating.power.consumption.dhw.monthValueReadAt
heating.power.consumption.dhw.weekValueReadAt
heating.power.consumption.dhw.yearValueReadAt
heating.power.consumption.heating.dayValueReadAt
heating.power.consumption.heating.monthValueReadAt
heating.power.consumption.heating.weekValueReadAt
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.sensors.volumetricFlow.allengra.status
heating.sensors.volumetricFlow.allengra.value

Ggf. noch ein Hinweis. Mich selber nervt es wenn der Zeitplan zb immer wieder ein Event erzeugt. Ich habe bei mir (schon immer in diesem Modul) die Events ein wenig angepasst. Hänge das hier mal mit an. Ggf. braucht es ja einer.

event-on-change-reading
(?!state)(?!HK2-Zeitsteuerung_Heizung)(?!HK1-Zeitsteuerung_Heizung)(?!WW-Zirkulationspumpe_Zeitplan)(?!WW-Zeitplan).*

event-on-update-reading
Brenner_1_Modulation,HK1-Vorlauftemperatur,HK2-Vorlauftemperatur,WW-Isttemperatur,HK2-Betriebsart,Aussentemperatur

Eine Frage noch. Warum darf man keine Umlaute in den Namen der Kreise nutzen? Es werden einfach falsche Zeichen in FHEM angezeigt aber ich habe sonst keine Querschläge entdecken können. An sich finde ich Fußbodenheizung auch schöner als Fussbodenheizung. Gleiches bei Heizkörper. Aber ggf. bin ich einfach nur alt.

stefanru

Hi 87insane,

du benutzt das SVN oder Rogers mapping?
Da ich die Übersetzungen nicht nutze ist es etwas schwierig für mich für das jeweilige Mapping die passenden Namen zu finden.

Ich baue dir die Readings sehr gerne ein sobald ich weiß ob SVN oder Roger.
Wenn du mir noch einen Vorschlag liefern könntest am besten im Format wie unten mache ich das direkt ;-)

device.messages.errors.raw.entries => Geräte_Nachrichten
...

Das mit den Umlauten hat mich bei meinem neuen RAW Mapping erwischt. Beim setzen mit Umlaut 'Ä,Ö,Ü' hat die API keinen Fehler gemeldet aber auch kein update ausgeführt.
Danke für deinen Hinweis ich schaue nochmal beim alten SVN Mapping ob da etwas spezielles gemacht wird um Umlaute zu senden.

Viele Grüße,
Stefan


87insane

#1108
Ich habe tatsächlich nun seit meinem ersten Post die Console auf und suche nach einem Problem.

Ich bekomme alle Daten eingelesen (egal ob altes oder neues Mapping). ABER ich kann über FHEM nicht schalten.
Gewundert hatte ich mich, da wir eine FBH in einem Raum haben und diese laut FHEM die ganze Zeit an und aus geht.

Bei genauem betrachten, weiß ich nun:
FHEM: set HK2-Betriebsart heating. Ich bekomme auch die Bestätigung in Form OK: HK2-Betriebsart heating
Schaue ich in die APP oder direkt am Display der Therme, passiert dort rein gar nichts.
2024-12-03 16:07:54 vitoconnect viessmann_server Aktion_Status: OK: HK2-Betriebsart heating
2024-12-03 16:07:54 vitoconnect viessmann_server HK2-Betriebsart: heating

Ändere ich innerhalb der Handy App zb HK2 auf heizen, mache in FHEM ein update oder warte den eingestellten Abfragewert ab, steht dort alles korrekt.

Wie teste ich nun am besten weiter? Mit der alten Version von Roger zb konnte ich noch schalten.
Und woher kommt der Aktion_Status? Der Wert ist ja dem Anschein nach nur die Info -> Ich habe was an den Viessmann Server gesendet. Nicht aber, dass er auch was getan hat bzw. das die gewünschte Aktion auch durchgelaufen ist.

PS: Ich habe sogar die Heizkreise umbenannt, da ich dachte dies könnte das Thema sein. Leider nein

sepultura30

Hallo 87insane,

das hatte ich auch, lade das Modul noch mal auf den Server, dann die Readings löschen und den Cache vom Browser.
In FHEM dann ein "reload 98_vitoconnect" oder FHEM restart.


Grüße

Sandro