Nachdem wir in den vorherigen Kapiteln gelernt haben, wie der Zugriff auf die API erfolgt und wie man Daten daraus auslesen kann, sehen wir jetzt, wie man die Einstellung der Heizung – z.B. die Temperatur oder den Betriebsmodus über die API verändern kann.
Dieses Tutorial ist auf die geänderte API von Februar 2023 angepasst. Anstatt dem Endpoint equipment wird jetzt der Endpoint features verwendet.
Schauen wir uns zuerst einmal das JSON Objekt aus der Feature Abfrage an. Der hier dargestellte Auszug zeigt bzw. setzt die Normaltemperatur des Heizkreises 2 (Feature: heating.circuits.2.operating.programs.normal): Ein Feature fängt immer mit "properties" an und läuft bis zur nächsten "properties" Zeile.
Inhalt
Beispiel: Normaltemperatur Heizkreis 2 einstellen
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
{ "properties": { "active": { "value": false, "type": "boolean" }, "demand": { "value": "unknown", "type": "string" }, "temperature": { "value": 17, "unit": "celsius", "type": "number" } }, "commands": { "setTemperature": { "uri": "https://api.viessmann.com/iot/v1/equipment/installations/999999/gateways/1234567890123456/devices/0/features/heating.circuits.2.operating.programs.normal/commands/setTemperature", "name": "setTemperature", "isExecutable": true, "params": { "targetTemperature": { "type": "number", "required": true, "constraints": { "min": 3, "max": 37, "stepping": 1 } } } } }, "apiVersion": 1, "uri": "https://api.viessmann.com/iot/v1/equipment/installations/999999/gateways/1234567890123456/devices/0/features/heating.circuits.2.operating.programs.normal", "gatewayId": "1234567890123456", "feature": "heating.circuits.2.operating.programs.normal", "timestamp": "2022-11-24T08:22:15.667Z", "isEnabled": true, "isReady": true, "deviceId": "0" }, |
Die eingestellte Solltemperatur beträgt 17 Grad Celsius – wie man sie ausliest, ist im vorigen Kapitel beschrieben.
Jedes Feature, das bei "commands" einen nicht leeren Inhalt hat, kann – theoretisch – manipuliert werden. In unserem Beispiel ist das der Fall. Dort steht "commands": { "setTemperature": {... gefolgt von einer URL und einigen Constraints (Einschränkungen).
Der Parameter "isExecutable" gibt an, ob sich ein Befehl in einem Feature unter den aktuellen Gegebenheiten ausführen lässt oder nicht. Bei "isExecutable" = true lässt sich der Befehl ausführen, ansonsten nicht. Beispiel: Du kannst das Betriebsprogramm "Eco" nicht einstellen, weil sich die Anlage im Standby Modus befindet.
Wie stellen wir nun die Normaltemperatur von Heizkreis 2 ein?
Straight forward
Zuerst kommt ein Dashboard Slider Node, den wir so einstellen, dass er "Output only on release" liefert. Der Zielwert steckt jetzt in msg.payload. Der Function Node, der den http-Reuest Header entsprechend aufbereitet, wird wie folgt programmiert:
bzw. als Javascript Snippet zum copy&paste:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
var atoken = flow.get('accessToken'); var setTo = msg.payload; msg.payload = { "targetTemperature": setTo } msg.headers = {}; msg.headers['content-type'] = 'application/json'; msg.headers['Authorization'] = "Bearer " + atoken; msg.installationID = flow.get('installationID'); msg.gatewaySerial = flow.get('gatewaySerial'); msg.deviceId = flow.get('deviceID'); return msg; |
Noch ein HInweis: Die in msg.header steckende Information ist ziemlich "klebrig", was bedeutet, dass da oft Informationen aus vorherigen http-Requests drin stehen bleiben. Um eine saubere Basis zu haben, sollte man vor jedem Setzen des Headers diesen mit einem msg.headers = {}; löschen.
Der http Rquest Node "set feature" enthält die für die Normaltemperatur Heizkreis 2 erforderliche URI:
|
1 |
https://api.viessmann.com/iot/v1/features/installations/{{installationID}}/gateways/{{gatewaySerial}}/devices/{{deviceId}}/features/heating.circuits.2.operating.programs.normal/commands/setTemperature |
Fertig! Oder nicht?
Flow Betriebssicher machen
Bedient man das Dashboard mit einem Mobilgerät, kann es schnell passieren, dass man den Slider Temperaturwähler versehentlich verstellt. Das ist natürlich nicht im Sinne des Erfinders. Ich habe deshalb den Slider und den Befehl enkoppelt. Zum Abschicken der neuen Temperatur muss noch ein Bestätigungsbutton geklickt werden.
Das sieht insgesamt wie folgt aus:
Die oberen drei grau unterlegten Nodes aus dem Feature Request hast du sicher schon; sie dienen lediglich der Rückkopplung des aktell in der Heizung eingestellten Werts. Da unsere Applikation ja nicht die einzige Eingabemöglichkeit ist – es gibt ja noch die ViCare App oder die Tasten am Gerät selbst – ist die Rückkopplung sehr wichtig um immer die aktuell geltende Einstellung zu sehen.
Der Function Node mit Namen "HK Soll Temp normal" wird einfach mit dem bereits existierenden "Feature auslesen" http Request verdrahtet. Dieser Node macht nichts Anderes als sich den in der Heizanlage geltenden Wert aus dem JSON File herauszusuchen. Die Logik ist aus dem vorigen Kapitel bekannt.
|
1 2 3 4 5 |
var featureArray = msg.payload.data; var idx = featureArray.findIndex((element) => element.feature === 'heating.circuits.2.operating.programs.normal'); msg.payload = msg.payload.data[idx].properties.temperature.value; flow.set("hkNormal", msg.payload); return msg; |
Danach kommt der Dashboard Slider Node – Einstellung wie oben. Letzter Node in diesem Strang ist noch ein Change Node, der die Flow Variable gemäß des Slider Werts zur Verwendung im nächsten Schritt abspeichert. Wenn nun der Slider bewegt wird, passiert wie gewollt erst einmal nichts. Das geschieht erst im nächsten Schritt, denn erst die unteren drei Nodes nehmen nach dem Auslösen des Dashboard Buttons die Einstellung vor.
Der Dashboard Button Node wird wie unten gezeigt eingestellt – wobei ich die Darstellung des Button Icons geändert habe:
Die Payload enhält die Flow Variable mit der eingestellten Temperatur.
Der Function Node Headers & Parameter sieht fast so aus, wie der beim "straight forward" Beispiel. Lediglich Zeile 2 ist unterschiedlich
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
var atoken = flow.get('accessToken'); var setTo = flow.get('sliHN'); msg.payload = { "targetTemperature": setTo } msg.headers = {}; msg.headers['content-type'] = 'application/json'; msg.headers['Authorization'] = "Bearer " + atoken; msg.installationID = flow.get('installationID'); msg.gatewaySerial = flow.get('gatewaySerial'); msg.deviceId = flow.get('deviceID'); ; return msg; |
Der http Requst Node "Set Feature" ist identisch zum straight forward Beispiel
|
1 |
https://api.viessmann.com/iot/v1/features/installations/{{installationID}}/gateways/{{gatewaySerial}}/devices/{{deviceId}}/features/heating.circuits.2.operating.programs.normal/commands/setTemperature |
Und hier noch die Darstellung des Dashboards mit Auswahl Betriebsart, Slider für normale und reduzierte Temperatur. Die gelben "OK Haken" lösen aus.
Beispiel: Betriebsart einstellen
Je nach Anlage gibt es mehrere Betriebsarten: Bei mir sind dies Aus, Nur Warmwasser, Zeitprogramm Heizung und Warmwasser, dauernd reduziert und dauernd normal.
Diese stellt man je nach Heizkreis wie folgt ein; in unserem Beispiel für Heizkreis 2:
|
1 |
heating.circuits.2.operating.modes.active/commands/setMode |
Im Prinzip funktioniert alles so wie bei der Temperatureinstellung. Der Function Node HK Betriebsart ist wieder die Rückkopplung aus der Feature Abfrage Betriebsart. Die Einstellung erfolgt über einen Dashboard Dropdown Node, der Headers & Parameter Node setzt die Payload auf einen der vorgeschriebenen Werte "mode: standby",
"mode: dhw", "mode: dhwAndHeating", "mode: forcedReduced", "mode: forcedNormal" .
Der http Request hat die URL
|
1 |
https://api.viessmann.com/iot/v1/features/installations/{{installationID}}/gateways/{{gatewaySerial}}/devices/{{deviceId}}/features/heating.circuits.2.operating.modes.active/commands/setMode |
Das zugehörige JSON File für Node-Red findest du hier:
|
1 |
[{"id":"354cb6e083ea9537","type":"function","z":"31c57f8640528976","name":"HK Betriebsart","func":"var featureArray = msg.payload.data;\nvar idx = featureArray.findIndex((element) => element.feature === 'heating.circuits.2.operating.modes.active');\nmsg.payload = msg.payload.data[idx].properties.value.value;\nreturn msg;\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":420,"y":2560,"wires":[["9ec49bb67331871e"]]},{"id":"9ec49bb67331871e","type":"ui_dropdown","z":"31c57f8640528976","name":"HK Betriebsart","label":"","tooltip":"","place":"Betriebsart","group":"ba68cdf22ac62395","order":1,"width":6,"height":1,"passthru":false,"multiple":false,"options":[{"label":"aus","value":"standby","type":"str"},{"label":"nur WW","value":"dhw","type":"str"},{"label":"Zeitprogr. Heizung & WW","value":"dhwAndHeating","type":"str"},{"label":"dauernd reduziert","value":"forcedReduced","type":"str"},{"label":"dauernd Tag","value":"forcedNormal","type":"str"}],"payload":"","topic":"topic","topicType":"msg","className":"","x":160,"y":2620,"wires":[["8c38cdcc5d584653"]]},{"id":"8c38cdcc5d584653","type":"function","z":"31c57f8640528976","name":"Headers & Parameter","func":"var atoken = flow.get('accessToken')\nvar setTo = msg.payload\n\nmsg.payload = {\n \"mode\": setTo\n}\nmsg.headers = {};\nmsg.headers['content-type'] = 'application/json',\nmsg.headers['Authorization'] = \"Bearer \" + atoken;\n\nmsg.installationID = flow.get('installationID');\nmsg.gatewaySerial = flow.get('gatewaySerial');\nmsg.deviceId = flow.get('deviceID');\n;\nreturn msg;\n\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":440,"y":2620,"wires":[["3f5d70a0adfe2d5a"]]},{"id":"3f5d70a0adfe2d5a","type":"http request","z":"31c57f8640528976","name":"Set Feature","method":"POST","ret":"obj","paytoqs":"ignore","url":"https://api.viessmann.com/iot/v1/equipment/installations/{{installationID}}/gateways/{{gatewaySerial}}/devices/{{deviceId}}/features/heating.circuits.2.operating.modes.active/commands/setMode","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"credentials":{},"x":650,"y":2620,"wires":[["ac3e542798c51fa6","47147733bf11ab71"]]},{"id":"ac3e542798c51fa6","type":"debug","z":"31c57f8640528976","name":"debug 17","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":840,"y":2620,"wires":[]},{"id":"ba68cdf22ac62395","type":"ui_group","name":"Einstellung HK Rustico","tab":"7e5ee24d.2d5ae4","order":5,"disp":true,"width":"6","collapse":false,"className":""},{"id":"7e5ee24d.2d5ae4","type":"ui_tab","name":"Solar/Heizung","icon":"dashboard","order":3,"disabled":false,"hidden":false}] |
Beispiel: "Ich möchte Warmwasser"
Hinter dieser Schnellwahlfunktion der App verbirgt sich die Ausführung des Befehls "Warmwasser einmal bereitstellen" bzw. heating.dhw.oneTimeCharge . Damit wird dann der Warmwasserboiler einmalig bis zu gewählten Temperatur aufgeheizt, egal in welchem Betriebsmodus sich die Heizung befindet – auch wenn sie auf AUS steht.
Der Befehl ist einerseits etwas anders als die oben beschriebenen, andererseits auch nicht schwieriger – man muss nur drauf kommen!
Ich schildere hier nur das Prinzip. Einbauen in deine Anwendung und mit Schalterchen versehen darfst du das selbst – inzwischen kannst du das ja, oder?
Die beiden Trigger schicken einen String und zwar entweder "activate" oder "deactivate". Im folgenden Function Node wird daraus die aufzurufende URL aufgebaut und an den http Request Node weitergeben.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
var atoken = flow.get('accessToken'); var setTo = msg.payload; var installationID = flow.get('installationID'); var gatewaySerial = flow.get('gatewaySerial'); var deviceId = flow.get('deviceID'); msg.payload = {}; msg.headers = {}; msg.headers['content-type'] = 'application/json', msg.headers['Authorization'] = "Bearer " + atoken; msg.url = "https://api.viessmann.com/iot/v1/features/installations/" + installationID + "/gateways/" + gatewaySerial + "/devices/" + deviceId + "/features/heating.dhw.oneTimeCharge/commands/" + setTo; return msg; |
Was passiert da: Der Function Node setzt die Payload auf eine leere Menge msg.payload={} , das ist wichtig, da der http Request keine Payload übermittelt bekommen soll. In der vorletzten Zeile wird die URL zusammengebastelt, d.h. erweitert um den gewünschten Aktivierungsstatus.
Die Funktion bzw. der Status ergibt sich hier also aus der URL und nicht wie sonst aus einem Parameter im http-Request Header, der übergeben wird.
Der http Request Node wird als POST konfiguriert und hat in der URL Zeile nichts drin stehen.
Schickt man zweimal denselben Status ab – z.B. zweimal activate, dann gibt es eine Fehlermeldung der Art:
Hier noch das JSON Snippet zum importieren
|
1 |
[{"id":"549e96f8b1dcf2b1","type":"http request","z":"31c57f8640528976","name":"Set Feature","method":"POST","ret":"obj","paytoqs":"ignore","url":"","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":650,"y":2880,"wires":[["ed98324b1f418d0b"]]},{"id":"b1ab78c225f82b3b","type":"function","z":"31c57f8640528976","name":"Headers & Parameter","func":"var atoken = flow.get('accessToken');\nvar setTo = msg.payload;\nvar installationID = flow.get('installationID');\nvar gatewaySerial = flow.get('gatewaySerial');\nvar deviceId = flow.get('deviceID');\n\nmsg.payload = {};\nmsg.headers = {};\nmsg.headers['content-type'] = 'application/json',\nmsg.headers['Authorization'] = \"Bearer \" + atoken;\nmsg.url = \"https://api.viessmann.com/iot/v1/features/installations/\" + installationID + \"/gateways/\" + gatewaySerial + \"/devices/\" + deviceId + \"/features/heating.dhw.oneTimeCharge/commands/\" + setTo;\n\nreturn msg;\n\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":440,"y":2880,"wires":[["549e96f8b1dcf2b1"]]},{"id":"ed98324b1f418d0b","type":"debug","z":"31c57f8640528976","name":"debug 44","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":820,"y":2880,"wires":[]},{"id":"0b018d39b29952e0","type":"inject","z":"31c57f8640528976","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"activate","payloadType":"str","x":210,"y":2900,"wires":[["b1ab78c225f82b3b"]]},{"id":"78d7db200a51816d","type":"inject","z":"31c57f8640528976","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"deactivate","payloadType":"str","x":200,"y":2840,"wires":[["b1ab78c225f82b3b"]]},{"id":"22529d0c5cc35dea","type":"comment","z":"31c57f8640528976","name":"dhw One Time charge","info":"","x":220,"y":2800,"wires":[]}] |
That's it.
Kommentare, Fehlermeldungen und ein kleines Dankeschön würden mich glücklich machen.
Hallo Chris,
ich habe soweit durch deine super Beschreibung alles zum fliegen gebracht.
Was mir noch fehlt ist die Darstellung von folgenden Datenpunkten, die ich leider in meinem Daten arrey nicht finden kann.
In der Vitoconnect lauten diese:
– Speichenladepumpe
– Heizwasserdurchlauferhitzer
Gibt es auch einen Datenpunkt mit dem man die Funktion "aktives kühlen" schalten kann die bei mir in dem Betriebsmodus "dwhAnd HeatingCooling" steckt?
Gruß
Joachim
Hallo Joachim,
Feut mich, wenn dir mein Blog geholfen hat. Ich habe im Laufe der Zeit festgestellt, dass sich die einzelnen Viessmanngeräte in bezug auf die Datenpunkte sehr vonenander unterscheiden. Insofern kann ich zu den von dir vermissten Datenpunkten nicht viel sagen. Ich hab' ja nur ne simple Gastherme…
Die Speicherladepumpe könnte sich hinter
heating.boiler.pumps.circuitverstecken. Ist aber nur im kostenpflichtigen Advanced Paket drin. Zum Durchlauferhiter und zur Kühlung kann ich leider nichts beitragen.Unter Umständen hilft etwas Reverse Engineering: Das gesamte Feature Set herunterladen, dann die gewünschte Funktion über die App oder sonstwie auslösen und dann nochmal das Featureset laden. Beide Feature Sets vergleichen (z.B. mit MS Word) und so herausfinden, welche Datenpunkte jetzt anders sind.
Viele Grüße
Chris
Vielleicht hilft auch dieser etwas ältere Hinweis von mir:
probiere mal das Feature heating.dhw.charging
bzw. entschlüsselt:
var featureArray = msg.payload.data;
var idx = featureArray.findIndex((element) => element.feature === 'heating.dhw.charging');
msg.payload = msg.payload.data[idx].properties.active.value;
return msg;
Ist im Basispaket enthalten
Hi Chris,
danke dir für deinen Tipps. Ich wusste gar nicht, dass es ein kostenpflichtiges Advanced Paket gibt. Ich habe zwar in der Viessmann DP Übersicht gesehen, dass es "Base" und "advanced" gibt, aber nicht, dass das kostenpflichtig ist. Wie kann man denn die "advanced" Variante ordern?
Noch ne Frage:
Ich bekomme es nicht hin weitere Abfragen auf unterschiedliche properties auf ein zuvor ermitteltes Feature in der node "Function" vorzunehmen. Das Ergebnis ist immer ein function error mit dem Hinweis "TypeError: Cannot read properties of undefined (reading '105')". 105 ist der zuvor ermittelte Array Eintrag.
Die Abfrage sieht folgendermaßne aus:
var featureArray=msg.payload.data;
var idx = featureArray.findIndex( (element) => element.feature === 'heating.dhw.pumps.circulation.schedule');
msg.payload=msg.payload.data[idx].properties.entries.value.mon;
if (msg.payload == ""){
msg.payload = false}
else {
//node.warn("ZP – Der Wert von idx ist: " + idx);
var start = msg.payload.data[idx].properties.entries.value.mon[0].start;
node.warn("start: " + start);
var end = msg.payload.data[idx].properties.entries.value.mon[0].end;
node.warn("ende: " + end);
msg.payload = true;
};
return msg;
Hast u eine Idee dazu?
Grüße
Joachim
Hi,
Das Advanced Paket kannst du über die Viessmann ViCare App bestellen. Es gibt da auch einen kostenlosen Testzeitraum.
Bzgl. der „Circulation Schedule” habe ich einen eigenen Beitrag verfasst.
Vielleicht hilft das.
VG
Chris
Hi Chris,
die Logik mit der Zirkulationspumpe habe ich bei mir eingebaut. Diese läuft ursprünglich gut. Nur wenn ich in dem function node für die Ermittlung des features diese um weitere Abfragen auf msg.payload.data mache kommt die beschriebene Fehlermeldung.
Grüße
Jochim
PS
Ich glaube ich werde das ganze auf die Optilink Schnittstelle von Phil umbauen. Erscheint mir doch etwas einfacher zu sein. Diese mir rätselhaften Situationen unter node red erscheinen für mich nicht lösbar.
Hi,
Ich habe mir das jetzt einmal genauer angesehen. Im Urlaub komme ich nicht so ohne weiteres an meinen Server.
—> Das Problem bei deiner Funktion liegt daran, dass du
msg.payload.data[idx].properties.entries.value.monmit der Schedule Info zuerst richtig ausliest und dann wieder mit
msg.payload=msg.payload.data[idx].properties.entries.value.mon;in die msg.payload reinschreibst. Ein paar Zeilen weiter unten willst du msg.payload dann nochmal über den Index analysieren und den Startzeitpunkt extrahieren. Das geht natürlich nicht, da die msg.payload ja inzwischen mit dem zuerst extrahierten Inhalt überschrieben worden ist.
Du solltest also das Feature erst einer Variablen zuweisen und diese kannst du dann beliebig oft durchkämmen um deine Werte zu extrahieren.
Ich bin mir nicht sicher, ob das bei der Optolink Geschichte wesentlich einfacher zu lösen wäre. Im Grunde ist es ja auch nur ein direkterer Weg, auf die Anlagenparameter zuzugreifen, die Analysearbeit ist ja dieselbe.
VG
Chris
Hi Chris,
du hast vollkommen Recht und es funktioniert so wie du es beschrieben hast. Danke dir für dein Engagement und das noch im Urlaub. 🙂
Gruß Joachim
Schon gefunden. Der Wert ist unter
viessmannapi.0.133000.0.features.heating.circuits.1.operating.modes.active.commands.setMode.setValue
Was für einen Wert kann man da übergeben, damit die Anlage aus ist? Wäre das "standby" ?
Hallo,
schön, dass du die Einstellung gefunden hast. mit standby schaltest du die Heizung in dem betreffenden Heizkreis (in deinem Fall oben ist das die Nr. 1) ab. Die Wärmepumpe ist aber trotzdem noch aktiv bzw. in Lauerstelllung um ggf. Wasser zu erwärmen oder die Frostsicherung anzuschalten.
Viel Spaß noch und frohe Ostertage.
Chris
Hallo, danke für die Infos.
Ich versuche anhand deiner Erkenntnisse die Anlage (Wärmepumpe) in die Betriebsart "Aus" zu versetzen. Ich verwende iobroker mit dem Standardadapter "viessmannapi". Allerdings habe ich den von dir o.g. Datenpunkt
installations/{{installationID}}/gateways/{{gatewaySerial}}/devices/{{deviceId}}/features/heating.circuits.2.operating.modes.active/commands/setMode
nicht. Bei mir wäre das (vermutlich?)
viessmannapi.0.133000.gateways01.devices01…
darunter gibt es dann aber nur "roles" und kein "features". Suche ich an der falschen Stelle, oder geht es mit dem Adapter einfach nicht, sondern muss ich auf anderem Weg suchen?
Hi,
mit dem IOBroker Adapter kenne ich mich nicht aus. Was du brauchst, ist das Feature JSON, das du dir auch "zu Fuß" organisieren kannst. Darin stehen alle Features deiner Anlage drin. Zum Einen müsste die Funktion als Feature aufgeführt sein, zum Anderen muss dann im selben Block etwas weiter unten etwas von "Commands" stehen.
Viel Erfolg.
Chris
Hallo Chris,
ich bin auch auf deine Seite hier gestoßen und bin begeistert wie gut alles funktioniert. Danke für deine Arbeit! Das hat mir viel Zeit und Nerven gespart. 😉
Einzig das Auslesen der Schnellwahlfunktion "Warmwasser aufbereiten" (ob aktiviert, oder nicht) funktioniert noch nicht ganz. Vielleicht hast du dafür noch einen Tipp.
Hallo,
danke für deinen Kommentar. Freut mich, wenn ich dir helfen konnte.
Bzgl genereller Status der Warmwasserbereitung:
probiere mal das Feature
heating.dhw.chargingbzw. entschlüsselt:
var featureArray = msg.payload.data;var idx = featureArray.findIndex((element) => element.feature === 'heating.dhw.charging');
msg.payload = msg.payload.data[idx].properties.active.value;
return msg;
Wenn du nur wissen willst, ob du die "Einmalladung" über die Schnellwahl aktiviert hast geht das so:
var featureArray = msg.payload.data;var idx = featureArray.findIndex((element) => element.feature === 'heating.dhw.oneTimeCharge');
msg.payload = msg.payload.data[idx].properties.active.value;
return msg;
Da ich mein Warmwasser fast ausschließlich über Solarthermie bzw. meinen Heizkamin erzeuge anstatt mit Gas und Therme, habe ich diese Funktion bei mir nicht implementiert. Wenn du das mal ausprobierst und mir sagst, was dabei herausgekommen ist, wäre ich dir dankbar.
VG
Chris
Hallo Chris,
Läuft alles so, wie gewünscht.
Danke für die tolle, verständliche und detaillierte Anleitung.
Viele Grüße Jürgen
Moin, wie kann ich "Schnellwahlen" wie zum Beispiel "Ich möchte Warmwasser" aktivieren? Das wäre eine tolle Ergänzung Deiner/Eurer großartigen Serie, über die ich nun meine Heizung in meine NodeRed-Installation erfolgreich eingebunden habe. Vielen Dank für Deine/Eure Arbeit!
Viele Grüße
Thilo
Hi,
freut mich, wenn ich dir helfen konnte. Ich knoble, experimentiere allein und schreibe das alles selbst auf. Ein "Team" habe ich nicht. Gelegentlich hilft mir Michael Hanna von Viessmann, wenn ich mal Fragen habe.
Schnellwahlen kannst du dir selbst zusammenbauen, indem du z.B. für "ich möchte einmalig Warmwasser" einen bzw. mehrere Nodes hernimmst: Der erste setzt die Zieltemperatur auf 60°C oder so, den zweiten lässt du alle 90 Sekunden (empfohlenes Intervall) die Wassertemperatur messen. Wenn Zieltemperatur erreicht, stellt der darauffolgende Node (aktiviert durch einen Switch Node) die Zieltemperatur auf den "Standby Wert" zurück. Alternativ kannst du das auch in zwei Function Nodes packen.Im Prinzip macht die App bzw. die Viessmann Logik dahinter auch nichts Anderes. Aber, Danke für den Tipp. Ich werde bei nächster Gelegenheit was darüber schreiben.
Was ich da oberhalb geschrieben habe ist zwar nicht ganz falsch, aber es gibt tatsächlich einen Parameter in der API mit dem ich einmalig Heißwasser erzeugen kann:
heating.dhw.oneTimeChargeIn der Viessmann Dokumentation steht: Shows whether one time charge of dhw is active. Also provides the commands to activate/deactivate it
Ist im Umfang des Basispakets enthalten. Die Anleitung dazu findet sich jetzt am Ende dieses upgedateten Artikels.
Viel Spaß noch.
Chris
Moin Chris, ich wollte mich noch mal für die Lösung "im möchte Warmwasser" bedanken. Das hat mir sehr geholfen! Funzt echt prima. Ich hoffe, Du machst weiter …
Viele Grüße
Thilo