Zugriff auf die API
Der Zugang zur Viessmann API ist nicht ganz trivial. Die Beschreibung auf den Viessmann Seiten lässt auch zu wünschen übrig. Trotzdem schadet es nicht, sich das alles dort einmal durchzulesen. Ich beschreibe hier den Ablauf analog dazu aber eben auf Node-Red angepasst. Ist der Flow erst einmal fertiggestellt, ist alles Weitere ein Klacks.
Schritt für Schritt
Vorbemerkung: diese Anleitung geht davon aus, dass Node-Red auf einem Linux Rechner, das heißt einem Raspberry Pi installiert wird. Für Windows PCs etc. gelten unter Umständen andere Voraussetzungen – zum Beispiel spezielle Client Firewall Regeln und Einstellungen, die hier nicht behandelt werden.
Der Router braucht keine Portfreischaltung im Firewall.
Voraussetzungen – Vorarbeiten
Grundvoraussetzung ist, die ViCare App zum Laufen zu bringen. Mit der App wird ein Viessmann Account angelegt und die Anlage registriert. Damit kennen die Viessmann-Server deine Installation. Es ist dann auch klar, dass die internetseitige Verbindung funktioniert. Darauf achten, dass das Vitoconnect Kästchen – sofern verwendet – eine ausreichende Empfangsstärke hat. 1 Balken ist definitiv zu wenig. Siehe Anleitung (Abschnitt Anleitung).
Anschließend, bzw. nach Erhalt und Quittierung des Bestätigungsmails sollte man sich bei developer.viessmann.com einloggen. Dabei sind dieselben Zugangsdaten zu verwenden, die bei der Registrierung der ViCare App verwendet wurden. Das Ganze ist weitestgehend selbsterklärend.
Nach dem Login hat man Zugriff auf die Dokumentation und das Viessmann Developer Dahboard. Dort muss zuerst einmal die
Customer ID
angelegt werden. Mit Klick auf My Dashboard wird dieses angezeigt. Auf der Kachel “Your Clients” klicken wir das Stiftsymbol an. Es kann nur ein Client und nur eine funktionierende URI angelegt werden auch wenn die Website das Anlegen mehrerer URLs erlaubt.
Bei Name trägst du denselben Namen ein, den du deiner Anlage in der App verpasst hast – ich bin mir aber nicht sicher, ob das wirklich so sein muss. Die Client ID wird automatisch erzeugt. Zuvor muss aber noch das Google reCAPTCHA ausgeschaltet und eine Redirect URI eingegeben werden. Die Redirect URI ist die Aufrufadresse (Callback Adresse) deiner Applikation, an die bei Aufruf ein AuthCode übermittelt wird. In der generischen Viessmann Anleitung steht http://localhost:4200 . Wir hingegen verwenden http://localhost:1880/authcode – das ist die Adresse bzw. der Port, auf dem Node-Red auf Input lauscht. Das /authcode ist ein optionaler, beliebiger Pfad. Merke dir diesen Pfad, du brauchst ihn in den nächsten Schritten.
Die Client ID ist statisch und bleibt so lange gültig, bis du sie im Dashboard löscht.
Authcode abrufen
Das Erzeugen der Client ID war der letzte manuelle Schritt und muss auch nur einmalig durchgeführt werden. Der Rest ist künftig automatisiert:
Wir ziehen und nun in Node-Red drei Nodes auf das Editiertableau und “verkabeln” diese.
Timestamp zum Triggern, http request zum Abfragen und Debug für das Ergebnis.
In die URL Zeile des http request kommt folgender Inhalt:
|
1 |
https://iam.viessmann.com/idp/v3/authorize?client_id=DeineClientIDkommtHierhin&redirect_uri=http://localhost:1880/authcode&response_type=code&code_challenge=2e21faa1-db2c-4d0b-a10f-575fd372bc8c-575fd372bc8c&scope=IoT%20User%20offline_access |
Bisherige Nutzer der API aufgepasst: seit Februar 2023 gibt es eine neue Version des API Autentifizierungsprozesses: Anstatt https://iam.viessmann.com/idp/v2/authorize… heißt es jetzt https://iam.viessmann.com/idp/v3/authorize… sonst ändert sich nichts. Der Vorteil liegt in konkreteren Fehlermeldungen beim Login. Siehe Viessmanm API Changelog Abschnitt Februar 2023. Übernimmt man die Änderung, sollte weiter unten d.h. bei https://iam.viessmann.com/idp/v3/token… ebenfalls v3 anstatt v2 verwendet werden.
Deine Client ID an der entsprechenden Stelle eintragen, den gesamten anderen Kram könnt ihr so stehen lassen. In der Viessmann Anleitung ist etwas von Oauth die Rede für Code Challenge und -Response. Ich habe nie verstanden, wie das funktioniert. Es reicht, hier dieselbe Challenge/Response wie in der Viessmann Dokumentation zu nehmen.
scope= IoT User (bzw. scope=IoT%20User ) ist vorgegeben, offline_access veranlasst die API noch ein Refresh Token mitzugeben, was die spätere Nutzung deutlich vereinfacht.
Den Rest des http requests wie folgt ausfüllen:
Methode ist GET, Nutzdaten ignorieren, Basis Authentifizierung verwenden – hier die Viessmann Account Daten (Username/eMail und Passwort aus der App; nicht den Namen aus dem „Edit Client“ Fenster oben) eintragen – und schließlich bei Rückgabe eine UTF-8 Zeichenfolge auswählen.
So lange du die Client ID nicht änderst, brauchst du diese Blöcke nicht mehr anfassen.
Nach dem Deployen und Starten des Flows liefert Viessmann einen Code, den wir uns im Debugfenster ansehen können und im nächsten Schritt weiter verwenden. Achtung: der Code ist nur 20 Sekunden lang gültig. Der Authorization Code steckt in msg.payload. Für den Fall, dass da nichts Gescheites drinsteht (Fehlermeldung, html Code), erst noch mal die Client ID checken und ggf. löschen und neu anlegen. Erst wenn hier der Authorization Code angezeigt wird kannst du weitermachen.
Mit dem http Request Node haben wir die Anfrage losgeschickt, mit einem http In Node empfangen wir die Antwort. Im Prinzip bauen wir hier einen winzigen Webserver auf.
Der http In Node wird wie folgt konfiguriert:
Das URL Feld muss dem Pfad entsprechen, der beim Anlegen der Client ID verwendet wurde. Allerdings ohne Localhost und Portnummer.
Der Response Node wird lediglich auf Status 200 gesetzt. Bitte beachte, dass der Sende- und der Empfangsteil sind nicht miteinander verdrahtet sind. Hier zaubert das Internet.
Wenn alles funktioniert, sollte der Debug Node am Empfangsende den Authorization code anzeigen wenn der Trigger auf der Sendeseite ausgelöst wurde. Der Code steckt jetzt in msg.payload.code .
Den kompletten JSON Flow findest du am Ende des Artikels.
Access Token initial erzeugen
Die drei Nodes oben links kennen bzw. haben wir schon.
Kommen wir zum Funktionsnode set payload & headers, der den darauf folgenden http Request Node mit Daten auflädt. Der im vorherigen Schritt gewonnene Code wird per Stringvariable hinten angehängt.
|
1 2 3 4 5 |
msg.payload = 'grant_type=authorization_code&client_id=DeineclientIDKommtHierhin&redirect_uri=http://localhost:1880/authcode&code_verifier=2e21faa1-db2c-4d0b-a10f-575fd372bc8c-575fd372bc8c&code=' + msg.payload.code; msg.headers = {}; msg.headers['Content-Type'] = 'application/x-www-form-urlencoded'; return msg; |
Anders als der oben verwendete http Request ist der hier verwendete http Request Node ein POST Request, d.h. es werden Daten im http header anstatt in der URL transportiert. Er wird wie folgt konfiguriert. Darauf achten, dass die Rückgabe als “Ein parsed JSON Objekt” erfolgen soll.
Auch hier sollte wieder v3 anstatt v2 verwendet werden.
Wenn alles funktioniert, dann enthält das zurück geschickte JSON Objekt sowohl das Access Token als auch das Refresh Token. Die Token stecken in msg.payload.access_token bzw. msg.payload.refresh_token.
Mit dem Access Token könnten wir nun 3600 Sekunden oder eine Stunde lang arbeiten bevor es verfällt.
Sinnvollerweise packen wir die beiden Token in Flow Variable um sie weiter zu verwenden. Hast du die Viessmann Logik auf mehreren Node-Red Blätter verteilt, sollten sie in Global anstatt in Flow Variablen untergebracht werden.
Das geschieht am einfachsten mit einem Change Node:
Variable können auch innerhalb eines Function Nodes mit
flow.set("FlowVariablenname", meineVariable) gesetzt werden. Das macht vor allem innnerhalb komplexerer Funktionsblöcke Sinn.
Abgerufen werden die Flow Variablen mit einem Kommando der Art:
var meineVariable = flow.get("FlowVariablenname");
Sind wir wie oben beschrieben vorgegangen, können wir jetzt überall innerhalb des Flows (Tabellenblatt) auf die Tokens zugreifen.
Statische Parameter
Um mit der API zu arbeiten, benötigen wir noch drei statische Werte, welche am Gerät hängen und sich normalerweise nie ändern.
Wie man sie bekommt, ist in der Viessmann Doku beschrieben oder man nutzt diesen JSON Flow für Node Red:
|
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 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 |
[ { "id": "3d828c3c867062b0", "type": "http request", "z": "31c57f8640528976", "name": "Installation ID", "method": "GET", "ret": "obj", "paytoqs": "ignore", "url": "https://api.viessmann.com/iot/v1/equipment/installations", "tls": "", "persist": false, "proxy": "", "insecureHTTPParser": false, "authType": "", "senderr": false, "headers": [], "x": 680, "y": 480, "wires": [ [ "f32181561f6a81ab" ] ] }, { "id": "0a5b06420e87d77f", "type": "function", "z": "31c57f8640528976", "name": "Auth Header", "func": "var atoken = flow.get('accessToken')\nmsg.headers = {\n Authorization: \"Bearer \"+ atoken\n}\nreturn msg;\n\n", "outputs": 1, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 450, "y": 480, "wires": [ [ "3d828c3c867062b0" ] ] }, { "id": "d189c65f2d221d39", "type": "http request", "z": "31c57f8640528976", "name": "Gateway Serial", "method": "GET", "ret": "obj", "paytoqs": "ignore", "url": "https://api.viessmann.com/iot/v1/equipment/gateways", "tls": "", "persist": false, "proxy": "", "insecureHTTPParser": false, "authType": "", "senderr": false, "headers": [], "x": 680, "y": 520, "wires": [ [ "a92443f4485556c4" ] ] }, { "id": "f32181561f6a81ab", "type": "change", "z": "31c57f8640528976", "name": "set flow.installationID", "rules": [ { "t": "set", "p": "installationID", "pt": "flow", "to": "payload.data[0].id", "tot": "msg" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 880, "y": 480, "wires": [ [ "dadfb8ae29d2643b" ] ] }, { "id": "a92443f4485556c4", "type": "change", "z": "31c57f8640528976", "name": "set flow.gatewaySerial", "rules": [ { "t": "set", "p": "gatewaySerial", "pt": "flow", "to": "payload.data[0].serial", "tot": "msg" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 880, "y": 520, "wires": [ [ "5cfecbbe8f899905" ] ] }, { "id": "dadfb8ae29d2643b", "type": "function", "z": "31c57f8640528976", "name": "Auth Header", "func": "var atoken = flow.get('accessToken')\nmsg.headers = {\n Authorization: \"Bearer \"+ atoken\n}\nreturn msg;\n\n", "outputs": 1, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 450, "y": 520, "wires": [ [ "d189c65f2d221d39" ] ] }, { "id": "f52e123cdd02a6bc", "type": "http request", "z": "31c57f8640528976", "name": "DeviceID", "method": "GET", "ret": "obj", "paytoqs": "ignore", "url": "https://api.viessmann.com/iot/v1/equipment/installations/{{iid}}/gateways/{{gws}}/devices/ ", "tls": "", "persist": false, "proxy": "", "insecureHTTPParser": false, "authType": "", "senderr": false, "headers": [], "x": 660, "y": 560, "wires": [ [ "e553113d728f21a8" ] ] }, { "id": "e553113d728f21a8", "type": "change", "z": "31c57f8640528976", "name": "", "rules": [ { "t": "set", "p": "deviceID", "pt": "flow", "to": "payload.data[0].id", "tot": "msg" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 870, "y": 560, "wires": [ [] ] }, { "id": "5cfecbbe8f899905", "type": "function", "z": "31c57f8640528976", "name": "extended auth header", "func": "var atoken = flow.get('accessToken')\nmsg.headers = {\n Authorization: \"Bearer \"+ atoken\n}\nmsg.iid = flow.get('installationID');\nmsg.gws = flow.get('gatewaySerial');\nreturn msg;\n\n", "outputs": 1, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 480, "y": 560, "wires": [ [ "f52e123cdd02a6bc" ] ] } ] |
Es bleibt dir überlassen, wo du diesen Teil einbaust. Im Prinzip kann man die drei Parameter Installation ID, Gateway Serial und Device ID ein einziges Mal abfragen und dann als fixe Werte weiterverarbeiten. Oder – so habe ich es gemacht – jedes Mal neu abfragen, wenn die Logik nach einem Neustart des Servers bzw. alle 180 Tage (siehe unten) initialisiert und die Token wieder neu generiert werden.
Refresh alle 3600 Sekunden
Jetzt endlich können wir mit der API arbeiten. Aber nach einer Stunde ist der Spaß vorbei, das Access Token ist abgelaufen. Um nun nicht wieder die gesamte obige Routine durchlaufen zu müssen, gibt es eine Abkürzung mit dem Refresh Token.
Hier wird der Trigger – auf “wiederhole automatisch alle 59 Minuten” eingestellt,
Der Funktionsnode hat folgenden Inhalt:
|
1 2 3 4 5 |
let refreshToken=flow.get('refreshToken'); msg.payload = 'grant_type=refresh_token&client_id=HierKommtDeine ClientIDHin&refresh_token=' + refreshToken; msg.headers = {}; msg.headers['Content-Type'] = 'application/x-www-form-urlencoded'; return msg; |
Wie du siehst, wird hier die Flow Variable “refreshToken” im Javascript ausgelesen. Deine Client ID muss ebenfalls wieder eingetragen werden und das Refresh Token wird als String hinten agehängt.
Einen http Request Node mit folgender Konfiguration:
Ferner noch ein Change Node, welcher die zurückgegebene Payload in die Access_Token Variable schreibt.
Und hier der zugehörige JSON Flow zum importieren:
|
1 |
[{"id":"794bf2047ed74376","type":"function","z":"8da86d39b73b390b","name":"set payload and headers","func":"let refreshToken=flow.get('refreshToken');\nmsg.payload = 'grant_type=refresh_token&client_id=DeineClientIDkommtHierhin&refresh_token=' + refreshToken;\nmsg.headers = {};\nmsg.headers['Content-Type'] = 'application/x-www-form-urlencoded';\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":490,"y":160,"wires":[["ed038a951c955501"]]},{"id":"38dd6ecae9f953db","type":"inject","z":"8da86d39b73b390b","name":"Refresh Access Token","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"3540","crontab":"","once":true,"onceDelay":"2","topic":"","payload":"","payloadType":"date","x":230,"y":160,"wires":[["794bf2047ed74376"]]},{"id":"ed038a951c955501","type":"http request","z":"8da86d39b73b390b","name":"refreshtoken","method":"POST","ret":"obj","paytoqs":"ignore","url":"https://iam.viessmann.com/idp/v3/token","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"credentials":{"user":"","password":""},"x":710,"y":160,"wires":[["e33267b623c5f5d6"]]},{"id":"c2d4d5a3cc1023ad","type":"debug","z":"8da86d39b73b390b","name":"Tokens","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1140,"y":160,"wires":[]},{"id":"e33267b623c5f5d6","type":"change","z":"8da86d39b73b390b","name":"","rules":[{"t":"set","p":"accessToken","pt":"flow","to":"payload.access_token","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":930,"y":160,"wires":[["c2d4d5a3cc1023ad"]]}] |
Bisherige Nutzer achten wieder auf “v3” in der URL des Request Nodes.
Wird der Flow regelmäßig ausgeführt, hat man immer ein gültiges Access Token.
Refresh nach 180 Tagen erneuern
…zumindest für 180 Tage. Dann verfällt auch das Refresh Token und wir müssen tatsächlich wieder beim Kapitel Authcode abrufen einsteigen. Die Client ID muss aber nicht neu erzeugt werden. Das Triggern der Schritte kann natürlich auch automatisch erfolgen, sodaß es keinerlei menschlichen Eingriffs mehr bedarf. Das ist z.B. möglich, indem man in der “Access Token Refresh” Routine eine Abfrage nach dem Wert des erneuerten Access Tokens einbaut. Hat das Access Token den Wert “null” (das ist etwas anderes als der Wert 0), wird auf die Initialroutine verzweigt. Die Abfrage mittels Switch-Node sieht so aus:
Siehe auch unten abgebildeten Flow mit Kommentar.
Was auch möglich wäre, aber nicht so betriebssicher, ist den Initialflow einfach alle 4319 Stunden (= 180 Tage minus 1 Stunde) per Trigger aufzurufen. Das wird aber nur funktionieren, wenn die ganze Viessmann Logik wirklich ununterbrochen durchläuft, damit der Trigger komplett abläuft. In 180 Tagen kann eine Menge passieren…
Im Prinzip spricht auch wenig dagegen, den “Refresh Token aktualisieren” Zyklus alle 24 Stunden oder so aufzurufen.
Gesamter Flow
JSON für dieses Kapitel
|
1 |
[{"id":"a4d8263673aa5304","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"3b410a91f520bb49","type":"debug","z":"a4d8263673aa5304","name":"complete msg object","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1020,"y":260,"wires":[]},{"id":"4c81428c90a1138b","type":"http request","z":"a4d8263673aa5304","name":"1st time Token Request","method":"POST","ret":"obj","paytoqs":"ignore","url":"https://iam.viessmann.com/idp/v3/token","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":750,"y":380,"wires":[["3b410a91f520bb49","15e001ef09f23d88","4509037e74642476","a716764e2a3358db"]]},{"id":"b8030e6bf7e2c2fe","type":"function","z":"a4d8263673aa5304","name":"set payload & headers","func":"msg.payload = 'grant_type=authorization_code&client_id=DeineClientIDKommtHierhin&redirect_uri=http://localhost:1880/authcode&code_verifier=2e21faa1-db2c-4d0b-a10f-575fd372bc8c-575fd372bc8c&code=' + msg.payload.code;\nmsg.headers = {};\nmsg.headers['Content-Type'] = 'application/x-www-form-urlencoded';\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":500,"y":380,"wires":[["4c81428c90a1138b"]]},{"id":"13d656fecf44fecd","type":"inject","z":"a4d8263673aa5304","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":300,"y":160,"wires":[["0a5452c6874bb78b"]]},{"id":"ac51d15e60a54224","type":"debug","z":"a4d8263673aa5304","name":"Request Result","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":640,"y":160,"wires":[]},{"id":"0c6ac2b550f4ec18","type":"http in","z":"a4d8263673aa5304","name":"","url":"/authcode","method":"get","upload":false,"swaggerDoc":"","x":260,"y":280,"wires":[["6e325af046eb26ab","b8030e6bf7e2c2fe","f97d73f6e2b4da5c"]]},{"id":"6e325af046eb26ab","type":"debug","z":"a4d8263673aa5304","name":"msg.payload.code","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload.code","targetType":"msg","statusVal":"","statusType":"auto","x":490,"y":240,"wires":[]},{"id":"f97d73f6e2b4da5c","type":"http response","z":"a4d8263673aa5304","name":"Reponse","statusCode":"200","headers":{},"x":540,"y":280,"wires":[]},{"id":"41a3347ff9726e5d","type":"comment","z":"a4d8263673aa5304","name":"Generate authorization code","info":"","x":340,"y":120,"wires":[]},{"id":"0a5452c6874bb78b","type":"http request","z":"a4d8263673aa5304","name":"","method":"GET","ret":"txt","paytoqs":"ignore","url":"https://iam.viessmann.com/idp/v3/authorize?client_id=DeineClientIDKommtHierhin&redirect_uri=http://localhost:1880/authcode&response_type=code&code_challenge=2e21faa1-db2c-4d0b-a10f-575fd372bc8c-575fd372bc8c&scope=IoT%20User%20offline_access","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"basic","senderr":false,"headers":[],"x":470,"y":160,"wires":[["ac51d15e60a54224"]]},{"id":"7018a2b8e0210860","type":"comment","z":"a4d8263673aa5304","name":"Click here -->","info":"","x":130,"y":160,"wires":[]},{"id":"b574abb731bafcab","type":"comment","z":"a4d8263673aa5304","name":"after expiry","info":"","x":120,"y":120,"wires":[]},{"id":"15e001ef09f23d88","type":"debug","z":"a4d8263673aa5304","name":"access_token","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload.access_token","targetType":"msg","statusVal":"","statusType":"auto","x":1000,"y":340,"wires":[]},{"id":"a716764e2a3358db","type":"debug","z":"a4d8263673aa5304","name":"refresh_token","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload.refresh_token","targetType":"msg","statusVal":"","statusType":"auto","x":1000,"y":300,"wires":[]},{"id":"4509037e74642476","type":"change","z":"a4d8263673aa5304","name":"set token flow variables","rules":[{"t":"set","p":"accessToken","pt":"flow","to":"payload.access_token","tot":"msg"},{"t":"set","p":"refreshToken","pt":"flow","to":"payload.refresh_token","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1030,"y":380,"wires":[["a417c2aa83ca2c18"]]},{"id":"38157a5108f0601a","type":"http request","z":"a4d8263673aa5304","name":"Installation ID","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://api.viessmann.com/iot/v1/equipment/installations","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":700,"y":520,"wires":[["9f149818c4e5a89f"]]},{"id":"a417c2aa83ca2c18","type":"function","z":"a4d8263673aa5304","name":"Auth Header","func":"var atoken = flow.get('accessToken')\nmsg.headers = {\n Authorization: \"Bearer \"+ atoken\n}\nreturn msg;\n\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":470,"y":520,"wires":[["38157a5108f0601a"]]},{"id":"f07f4847a63c8193","type":"http request","z":"a4d8263673aa5304","name":"Gateway Serial","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://api.viessmann.com/iot/v1/equipment/gateways","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":700,"y":560,"wires":[["bd917fdb3d39a9d5"]]},{"id":"9f149818c4e5a89f","type":"change","z":"a4d8263673aa5304","name":"set flow.installationID","rules":[{"t":"set","p":"installationID","pt":"flow","to":"payload.data[0].id","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":520,"wires":[["f9befdb0db02397c"]]},{"id":"bd917fdb3d39a9d5","type":"change","z":"a4d8263673aa5304","name":"set flow.gatewaySerial","rules":[{"t":"set","p":"gatewaySerial","pt":"flow","to":"payload.data[0].serial","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":900,"y":560,"wires":[["42022a621baeaa2c"]]},{"id":"f9befdb0db02397c","type":"function","z":"a4d8263673aa5304","name":"Auth Header","func":"var atoken = flow.get('accessToken')\nmsg.headers = {\n Authorization: \"Bearer \"+ atoken\n}\nreturn msg;\n\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":470,"y":560,"wires":[["f07f4847a63c8193"]]},{"id":"faac1f89ad0c3fe5","type":"http request","z":"a4d8263673aa5304","name":"DeviceID","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://api.viessmann.com/iot/v1/equipment/installations/{{iid}}/gateways/{{gws}}/devices/ ","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":680,"y":600,"wires":[["8710674c0e72c247"]]},{"id":"8710674c0e72c247","type":"change","z":"a4d8263673aa5304","name":"","rules":[{"t":"set","p":"deviceID","pt":"flow","to":"payload.data[0].id","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":890,"y":600,"wires":[[]]},{"id":"42022a621baeaa2c","type":"function","z":"a4d8263673aa5304","name":"extended auth header","func":"var atoken = flow.get('accessToken')\nmsg.headers = {\n Authorization: \"Bearer \"+ atoken\n}\nmsg.iid = flow.get('installationID');\nmsg.gws = flow.get('gatewaySerial');\nreturn msg;\n\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":500,"y":600,"wires":[["faac1f89ad0c3fe5"]]},{"id":"8864d1c56c11fea1","type":"comment","z":"a4d8263673aa5304","name":"get tokens 1st time","info":"","x":310,"y":340,"wires":[]},{"id":"ca76b1d03b0be675","type":"comment","z":"a4d8263673aa5304","name":"get/set invariable parameters","info":"","x":340,"y":460,"wires":[]}] |
Weiter gehts mit dem nächsten Kapitel Daten abfragen und visualisieren.
Moin, bin etwas am verzweifeln. Ich erhalte folgende Fehlermeldung “ErrorCannot GET /authcode”. Client-ID habe ich mehrfach neu angelegt.
Ich habe NodeRed auf einer Diskstation laufen. Hast Du irgendwelche Ideen?
Danke!
Thilo
Hi,
Es könnte sich um ein Firewall Problem der Diskstation handeln. Port 1880 muss in der Diskstation explizit freigegeben werden. Im Router hingegen NICHT sonst bekommst du ein massives Sicherheisproblem.
Gruß
Chris
Probier das mal
ist mittlerweile erledigt … die Diskstation hatte eine Macke … Neustart hat es gebracht … bitte den Eintrag löschen … und sorry!
Hallo Chris,
vielen Dank für die super Anleitung und das gesamte Tutorial!
Sogar ich als blutiger Anfänger auf dem Pi und mit Nodered finde mich gut zurecht.
Ich habe jetzt den Flow soweit implementiert (mit der Schleife für den refresh Token) und mir ein Dashboard gebastelt. Das funktioniert auch soweit so gut.
Leider kommt nach ca 1,5 Stunden ein Fehler und die function nodes für das Auslesen der Werte aus den Features laufen alle in die selbe Meldung: “TypeError: Cannot read properties of undefined (reading ‘findIndex’)”
Also irgendetwas kann mit dem Index ausgelesen werden.
Hast du eine Idee woran das liegen kann?
Vielen Dank und Grüße
Moritz
Hi,
Freut mich, wenn es dir hilft und gefallen hat. Das von dir beschriebene Problem tritt immer dann auf, wenn die Viessmann Server gerade nicht antworten.
Nach ein paar Minuten oder auch vielen paar Minuten funktioniert es dann wieder.
Viel Spaß noch
Chris
Hallo,
erstmal vielen Dank für das super Tutorial.
Kann mir bitte jemand die Integration für den 180 Tage refresh erklären.
Leider bin ich in NoteRed noch purer Anfänger. Danke.
Hallo Matthias,
aler Anfang ist schwer…
Danke für deine Frage, das hilft mir, Verständnisprobleme bei meinem Text zu erkennen. Ich passe mein Tutorial entsprechend an.
Im Prinzip musst du beim “Refresh Access Token” Teil, der spätestens alle 3600 Sekunden aufgerufen werden muss, mit einem Switch Node abfragen, ob der Refresh geklappt hat. Falls nicht (d.h. msg.payload.access_token = null), wird ganz nach oben zur Initialroutine verzweigt.
Alternativ kannst du den Trigger ganz am Anfang so einstellen, dass er vor dem Verfall des Refresh Tokens anspringt – z.B. alle 179 Tage.
Viele Grüße und viel Spaß
Chris
Danke! habs mit minimalen Anpassungen integriert – klasse! Schon lustig, entweder ich habs in der viessmann-doku überlesen, oder es wird nicht wirklich präsent erwähnt, dass auch dieser token nach 180t abläuft .. naja, macht ja sinn trotzdem. VG
Hi,
freut mich, wenn ich dir damit helfen konnte. Du schreibst “minimale Anpassungen”… hast du einen Fehler entdeckt oder was konkret hast du abgeändert. Vielleicht macht das ja mehr Sinn.
Danke Chris
Ja, es war bei den Debug-Steinen “access_token” und “refresh_token” ein Fehler. Sie haben beide beides angezeigt. Hier musste der Payload gefiltert werden.
Danke für den Hinweis, ich hab’s korrigiert.
VG
Chris