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 native auf einem Linux Rechner, das heißt einem Raspberry Pi installiert wird also ohne ein Hausautomatisierungsframework darum herum. Für Spezialrechner auf Linux Basis (z.B. CCU3) oder Windows PCs, Synology Disk Stations etc. gelten unter Umständen andere Voraussetzungen – zum Beispiel spezielle Client Firewall Regeln und Port-Einstellungen, die hier nicht behandelt werden. Dasselbe gilt für ein embedded Node-Red im Homeassistant oder IO Broker. Auch Docker macht immer wieder Probleme. Ich kann hier auch nur eingeschränkten Support leisten.
Ich habe mir mal die Mühe gemacht, und den IO Broker nebst integriertem Node-Red Adapter auf einem Raspi installiert. Abgesehen davon, dass ich den IO Broker für ein hoffnungslos überladenes Klickibunti halte, hat alles astrein 1:1 funktioniert. Bei der Instanziierung darauf achen, dass die NR Portnummer 1880 gesetzt wird. Läuft auch noch der Viessmann Adapter auf dem Broker, müssen (wahrscheinlich) zwei URIs bei der Edit Client Seite bei Viessmann eingetragen werden. Siehe unten.
A propos Firewall: Der Router braucht keine Portfreischaltung im Firewall. Hütet euch ferner davor, den Node-Red Port 1880 im Router freizuschalten. Damit hättet ihr ein riesiges Sicherheitsproblem.
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
Client 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 angelegt werden. Normalerweise braucht du nur eine URI. Zwei URIs sind ggf. vonnöten, wenn Node-Red zusammen mit dem Viessmann API Adapter auf einem IO Broker laufen soll.
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, wenn du am Ende “Save Client” anklickst.
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 beliebiger Pfad, der unbedingt erforderlich ist, sonst ruft Viessmann den Node-Red Editor anstatt des Flows auf. Merke dir diesen Pfad, du brauchst ihn in den nächsten Schritten.
Für den Anwendungsfall IOBroker mit Viessmann Adaper und gleichzeitig installiertem Node-Red Adapter muss dann noch gemäß Vorschrift im Broker eine 2. URI (http://localhost:4200) angelegt werden. Generell hakt es wohl öfter, wenn sowohl ein Viessmann Adapter/Modul auf der Hausautomatisierungs Software zusätzlich zu Node Red mit Viessmann Logik installiert ist. Für den Anfang vielleicht erst einmal den Adapter/das Modul stillegen.
Die Client ID ist statisch und bleibt so lange gültig, bis du sie im Dashboard löschst.
Merke: Die ClientID wird im Folgenden insgesamt dreimal in einen http Request Node eingetragen. Das wird gerne übersehen, wenn man die ClientID später einmal geändert hat.
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 uns 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.
ACHTUNG: Der Debug Node (debug 5) wird erst dann ein sinnvolles Ergebnis liefern, wenn ihr auch den weiter unten stehenden Schritt mit dem http in Node gegangen seid. Erst der http in Node erzeugt das virtuelle Verzeichnis, in das der Viessmann Server hineinschreibt.
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 Authentifizierungsprozesses: 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.
Die Redirect URI 1:1 aus dem ClientID Prozess auf den Viessmann Seiten übernehmen.
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 Viessmann „Edit Client“ Fenster) 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.
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. Der Response Node ist wichtig, um die Anfrage des Viessmann Servers korrekt abzuschließen!
Bitte beachte ferner, dass der Sende- und der Empfangsteil sind nicht miteinander verdrahtet sind. Hier zaubert das Internet.
Jetzt – erst jetzt – könnt ihr Testen: 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.
Hinweise zur Fehlersuche
Cannot get /authcode
Wie man manchen Kommentaren entnehmen kann, kommt es gelegentlich zu Fehlern der Art “Cannot GET /authcode“.
Der Fehler tritt immer dann auf, wenn der Viessmann Server unter der angegebenen Adresse nichts findet. Das kann an einer falsch konfigurierten URL liegen, einer falschen Portnummer oder daran, dass der in NR eingebaute Webserver nicht angesprochen werden kann. Hauptursache ist aber wahrscheinlich, dass der zum ersten http Request passende http in Node noch nicht eingebaut wurde. Siehe mit Achtung markierten Absatz weiter oben. Erst der http in Node, oben mit
[get] /authcode bezeichnet, erzeugt das vom Viessmann Server benötigte virtuelle Verzeichnis.
connect ECONNREFUSED
Unter bestimmten Umständen, z.B. wegen einer nicht ganz standardmäßgen Konfiguration auf eurer Seite, durchläuft Node Red eine Identitätskrise und weiß auf einmal nicht mehr, dass es selbst durch localhost aufgerufen wird. Demzufolge wird der Viessmann-Callback abgelehnt und es gibt eine Fehlermeldung der Art:
RequestError: connect ECONNREFUSED ::1:1880
Test: probiert mal Folgendes:
|
1 |
[{"id":"e008437fd10a7172","type":"tab","label":"Flow 1","disabled":false,"info":"","env":[]},{"id":"19375c41d180b1f7","type":"http in","z":"e008437fd10a7172","name":"\"http in\" Node","url":"test","method":"get","upload":false,"swaggerDoc":"","x":990,"y":160,"wires":[["62d56fd0194be715"]]},{"id":"cb7ae7e2d1498dd5","type":"http response","z":"e008437fd10a7172","name":"","statusCode":"200","headers":{"content-type":"text/plain"},"x":1460,"y":160,"wires":[]},{"id":"62d56fd0194be715","type":"template","z":"e008437fd10a7172","name":"","field":"payload","fieldType":"msg","format":"html","syntax":"mustache","template":"This is the payload!","output":"str","x":1240,"y":160,"wires":[["cb7ae7e2d1498dd5"]]},{"id":"59871b13fa1668f2","type":"http request","z":"e008437fd10a7172","name":"","method":"GET","ret":"txt","paytoqs":"ignore","url":"localhost:1880/test/?helloword","tls":"","persist":false,"proxy":"","insecureHTTPParser":false,"authType":"","senderr":false,"headers":[],"x":1190,"y":80,"wires":[["e961ab6d8dca2a1f"]]},{"id":"53be7c837e4a97d8","type":"inject","z":"e008437fd10a7172","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"trigger","payloadType":"str","x":1010,"y":80,"wires":[["59871b13fa1668f2"]]},{"id":"e961ab6d8dca2a1f","type":"debug","z":"e008437fd10a7172","name":"debug 145","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1410,"y":80,"wires":[]}] |
Mit dem Trigger wird ein http request angestupst, der an die Adresse localhost:1880/test eine belanglose Nachricht schickt. Der http in Node empfängt diese – vorausgesetzt localhost ist nicht blockiert – und gibt an den http request eine Nachricht zurück, die ihr im Debugfenster lesen könnt. Funktioniert das nicht, erscheint eine Fehlermeldung “Cannot GET /test“.
Um zu sehen, ob Node-Red überhaupt antwortet, könnt ihr den gerade erzeugten Microwebserver über einen Browser auf einem anderen Gerät im lokalen Netz aufrufen: http://IPdesNodeRedServers:1880/test . Wenn das nicht funktioniert, hat NR ein generelles Problem oder ihr habt euch irgendwo verschrieben.
Dem ECONNREFUSED Problem kann man oft abhelfen, indem man durchgehend 127.0.0.1 anstatt localhost verwendet. Logisch betrachtet ist beides dasselbe aber manchmal hilft es, anstatt des lokalen Namens, die IP Adresse zu verwenden .
Dafür die Viessmann Client ID löschen und dort die redirect URI neu mit
http://127.0.0.1:1880/authcode
anlegen. Dann noch die neu generierte Client ID und die neue URI in den obersten Request Node übertragen.
Dank an Günter fürs geduldige Ausprobieren und die Rückmeldung!
Docker:
Habt ihr NR in einem Docker Container laufen, dann wird das so ohne weiteres nicht funktionieren. Docker sperrt – so habe ich es verstanden – den Zugriff auf localhost. Das müsste erst einmal freigeschaltet werden. Wie? Keine Ahnung! Ich habe für mich keinen Vorteil von Docker erkannt und nutze es deshalb nicht. Zum Basteln habe ich einen isolierten Raspberry Pi und laufe so wenig Gefahr, etwas zu zuerstören.
Noch eine Möglichkeit (mangels Docker Installation blind geraten): Wenn Docker localhost sperrt, dann klappt es vielleicht mit 127.0.0.1 anstatt localhost. Siehe connect ECONNREFUSED weiter oben. Mir bitte unbedingt Bescheid geben, was daraus geworden ist.
Oder dieses Link hier: Docker Container unter Hostname nicht erreichbar
Zitat:
“Haben Docker Container nicht eine eigene “virtuelle” Netzwerkinfrastruktur, die man erst nach außen routen muss?
Also sprich sowas wie (Beispiel nginx Server):
docker run --name mynginx -d -p 8080:80 nginx Das macht nginx nach außen (localhost) auf Port 8080 erreichbar.”
Zitat Ende.
Aktuelle Node Red Version
Noch was: seht zu, dass ihr die aktuellste Version von Node Red auf eurer Kiste laufen habt. Stand November 2023 ist das Version 3.1.0
Eine Bitte:
Ich gebe mir alle Mühe, meinen Lesern bei der Fehlersuche weiterzuhelfen.
Daher eine Bitte: gebt genau an, welcher Node den Fehler ausgibt, ferner die komplett ausgeklappte Fehlermeldung im Debugfenster rechts. Idealerweise auch euren – anonymisierten – Flow per Mail schicken. (Adresse steht im Impressum). Gut zu wissen wäre ebenfalls, ob ihr Node-Red direkt auf eurem Rechner betreibt oder gekapselt in Docker, IO Broker, Home Assistant etc.
Und noch eine Bitte: Immer wieder zermartere ich mein Hirn und gebe ich Hinweise, wie ein Problem zu lösen sein könnte. Vom Adressaten bekomme ich meist… nichts! Kein Feedback, Funkstille. Damit stochere ich mit ‘ner Stange im Nebel, da ich nicht weiß, ob mein Tipp geholfen hat. Also, bitte gebt mir Feedback und ich gebe mein Bestes, euch weiterzuhelfen.
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.
Auch hier kommt wieder die Client ID an die entsprechende Stelle des Aufrufstrings – wird gerne vergessen, wenn man mal die ClientID neu erzeugt hat.
|
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.
Erläuterung der drei statischen Parameter:
InstallationID identifiziert eure gesamte Anlage mit alle Komponenten, Therme, Wärmepunpe, Photovoltaike etc. Normalerweise gibt es pro Haus/Wohnung nur eine InstallationID.
GatewaySerial: Hat man nur einen Viessmann Wärme-/Energieerzeuger, dann gibt es in der Regel auch nur eine einzige GatewaySerial. Hat man deren mehrere, dann hat jeder (modernere) Wärmeerzeuger eine WiFi Komponente (oder bei Legacy Geräten ein VitoConnect Kästchen).
Sind z.B. sowohl WP als auch PV installiert, musst du, um die gesamte Anlage über die API anzusprechen, beide GatewaySerials heranziehen und die Abfragen bzw. Befehle für die Geräte dem jeweiligen Gateway zuordnen. Auch bei einer späteren Nachrüstung (z.B. mit PV) muss die Programmierung entsprechend angepasst werden.
Jedes Gateway hat wiederum mehrere Device IDs. Relevant bzw. nutzbar für unsere Anwendungsfälle ist das Device Nummer “0” – der Wärme- oder Energieerzeuger.
Nr “1” ist das Gateway selbst, hier gibt es keine Festures, die abgerufen werden können.
Nr. “2” ist virtuell und bei meiner Therme etwas, das sich “HeatDemandControl” nennt und wohl die Sensorik (?) darstellt. Ebenfalls keine Features.
Device ID “3” ist auch virtuell und die Einzelraumsteuerung welche in der Vitotronic wohl auch dann angelegt ist, wenn physisch es gar keine Einzelraumsteuerung gibt.
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.
Hast du später einmal die ClientID geändert, nicht vergessen hier die neue ClientID einzutragen.
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,
ich habe die “Refresh” Routine weggelassen und führe stattdessen die “Initialroutine” alle 59 Minuten aus. Funktioniert seit 3 Wochen ohne Probleme.
Spricht was dagegen das weiter so zu tun oder wäre es tatsächlich besser mit der “Refresh” Routine zu arbeiten?
Super Anleitung übrigens…. war gar kein Problem das so nachzubauen!! Danke 😉
Totti
Freut mich, dass meine Tutorials dir gefallen. Bzgl. der dauernden Verwendung der Initialroutine anstatt des Refreshs bin ich überfragt.
Du kannst dich ja mal im Viessmann Forum schlau machen. Viessmann-Community.com
Viel Spaß
Chris
P.S. Das Einzige was mir als Grund für die Verwendung des Refresh Tokens einfällt, könnten Lastgründe sein. d.h. die Initialroutine braucht auf der Viessmann Seite mehr Systemressourcen, weshalb man den Weg über den Refresh vorzieht.
Hallo, bitte um Hilfe.
Ich versuche deinen Flow seit Stunden zum Laufen zu bringen.
ich bekomme immer folgenden Request:
Error
Hab auch nochmals einen Raps neu aufgesetzt mit nur NodeRed, immer das gleiche Ergebnis.
Hallo,
tut mir leid, dass das bei dir nicht klappt. Deine Informationen sind leider ein bisschen knapp. Bekommst du im obersten Flow (Timestamp-httpRequest-Debug) ein sinnvolles Ergebnis angezeigt?
Das sieht im ‘Debug Node etwa so aus: {“code”:”BXpX1B73QsqxyzaJZDt9EndUXJsQ0WMfs6SIH0-pNmM”}
Wenn nein, hast du bei der Client ID bzw. beim http Request etwas falsch gamcht.Es würde mir helfen, dir zu helfen, wenn du mir den Flow als JSON exportiert schicken könntest. Die privaten Daten kannst du gerne mit Text überschreiben.
VG Chris
ANMERKUNG: Im obersten/ersten Debug Node steht nur dann etwas Sinnvolles, wenn im weiteren Verlauf der zuerst eingebaute http in Node das vom Viessmann Server angesprochene virtuelle Verzeichnis
/authcodeaktiviert hat.Noch ein Tipp: Probiere doch mal, die URL Zeile aus dem allerersten http Request in den Browser einzugeben.
z.B.
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_accessDeine generierte ClientID musst du natürlich an der entsprechenden Zeile eintragen.
Dann kommt das Viessmann Login Fenster, du loggst dich ein. Es kommt eine Fehlermeldung aber in der URL Zeile vom Brwoser steht der Authcode. http://localhost:1880/authcode?code=2TsyNSphQ98hUHP6oMaoamhl4NSG1L1olDOetcpp
Wenn das funktioniert, dann kannst du weitermachen.
VG
Chris
Hallo, bei mir kommt auch der Fehler
Error
Aber die Abfrage im Browser funktioniert und der Code wir dort angezeigt.
Klingt jetzt blöd, aber bei mir funktioniert es problemlos.
Schicke mir doch bitte deinen Flow (eigene Codes etc. Mit xxx oder so überschreiben). Dann kann ich schauen, was evtl. nicht stimmt.
Adresse steht im Impressum.
Viele Grüße
Chris
Bitte sage mit, an welcher Stelle die Fehlermeldung kommt. Welcher Node/Debug Node gibt die aus? Was steht im Debug Balken aufder rechten Seite (Screenshot per Mail)? Ich kann den Fehler nicht reproduzieren, egal, wie sehr ich die ClientID Funktion bei Viessmann absichtlich verkehrt befülle. Steh am Schlauch….
Chris
Hi,
Ich hab auch diesen Fehler, konnte ihn aber etwas eingrenzen.
Da die URL den Code enthält (und die API andere Fehler auswirft falls nicht) sollte der Teil stimmen. Ich glaube eher das der Loopback das Problem ist.
Dem Nodered (und damit dem Webserver unten drunter) wird eine Anfrage auf ein Verzeichnis gestellt das er nicht kennt. Damit antwortet er mit der entsprechenden Meldung. Nehme ich das originale Nodered Verzeichnis bekomme ich eine andere Antwort – nämlich Standard Apache Index.html – Genauso falsch und kein Code, aber das GET wird akzeptiert.
Die Frage lautet also wie den Pi einstellen damit er das Verzeichnis akzeptiert… Dafür reicht mein Wissen aber nicht ;(
Danke für deine Mühe, aber: Der Webserver bzw. das Verzeichnis von NR muss nicht “eingestellt” werden. Das erledigt der “http in” Node. Probiere mal folgendes:
[{"id":"e51bfe99a850ee6c","type":"http in","z":"640d4a161fb8fa28","name":"\"http in\" Node","url":"test","method":"get","upload":false,"swaggerDoc":"","x":910,"y":100,"wires":[["8c6a6d49941230e9"]]},{"id":"7a56abfc800f82aa","type":"http response","z":"640d4a161fb8fa28","name":"","statusCode":"200","headers":{"content-type":"text/plain"},"x":1380,"y":100,"wires":[]},{"id":"8c6a6d49941230e9","type":"template","z":"640d4a161fb8fa28","name":"","field":"payload","fieldType":"msg","format":"html","syntax":"mustache","template":"This is the payload: test !","output":"str","x":1160,"y":100,"wires":[["7a56abfc800f82aa"]]}]Das ist ein Mini Webserver, der nur eine simple Nachricht zurückschickt, wenn er aufgerufen wird: http://IPdesNodeRedServers:1880/test also z.B. http://192.168.178.42:1880/test
Da muss also nichts eingestellt oder konfiguriert werden, sofern der “http in” Node das Zielverzeichnis aufführt.
Schicke mir bitte mal deinen Flow, zumindest die ersten 6 oder so Nodes bis inkl. dem http in Node und dem Response Node. Dann kann ich mir das ansehen. Ich versteh’ echt nicht, warum das bei manchen von euch nicht funktioniert.
Welche Version von Node-Red nehmt ihr her? 3.1.0 ist die aktuellste. Die im Raspberry Pi mitgelieferte Version ist eher veraltet.
Noch eine Möglichkeit für den Fall, dass du mit Docker arbeitest: Wenn Docker localhost sperrt, dann klappte es vielleicht mit
127.0.0.1anstatt localhost. Ist im Grunde dasselbe aber vielleicht nützt es ja was… Dafür aber auch bei der Anlage der ClientID anstatt localhost die IP Adresse127.0.0.1eintragen und ebenso beim ersten http request node. Mir bitte unbedingt Bescheid geben, was daraus geworden ist.VG
Chris
Ich habs gefunden… Dein Webserver-Hinweis hat mich auf die Lösung gebracht weil der genau das tut was ich vermisst habe: Das Verzeichnis aufrufbar machen.
Für dich ists wahrscheinlich selbstverständlich, aber ich habe das Tutorial Step-by-Step gelesen und umgesetzt und entsprechend schon den ersten einfachen Flow mit Timestamp->Request->Debug getestet was die Fehlermeldung verursacht hat. Im Abschnitt darunter wird dann das HHTP Objekt eingefügt.
Nachdem das drin war (Und der Request Ausgang mit dem Ergebnis verknüpft) klappt es jetzt und ich kriege den Code…
DANKE DIR!
Ich überarbeite dann meine Anleitung noch etwas. Natürlich funktioniiert der allererste Debug nur dann, wenn schon das Verzeichnis (durch den “http in” Node) bereitgestellt wurde. Freut mich, dass wir das endlich geschafft haben!
VG
Chris
Hallo, ich bekomme es leider nicht zum Laufen.
Hab alles so eingestellt wie beschrieben, auf einem Raps mit Nodered bekomme folgenden String zurück:
Viessmann Login
<link href="/idp/sso/v1/nevislogrend/applications/IDP_SSO_V1/webdata/css/icon.css" rel="s…
Auf einem Raspi mit Nodered in Docker, folgende Meldung:
Error
Bitte um Hilfe, danke.
Gruß Matthias
Sorry,
dein Post hing in meinem Spamfilter, wahrscheinlich wg. der komischen href Zeile von der ich keine Ahnung habe was die bedeuten soll. Kommt das von Viessmann oder ist das ein Copy&Paste Fehler?
Chris
Hi, ich benutze HomeAssistant mit NodeRed. Versuche dein Skript zum laufen zu bekommen aber es scheitert schon beim ersten Flow. Da kommt folgende Fehlermeldung im Node “Request Result”:
“RequestError: connect ECONNREFUSED ::1:1880 : https://iam.viessmann.com/idp/v3/authorize?client_id=MEINEIID&redirect_uri=http://localhost:1880/authcode&response_type=code&code_challenge=2e21faa1-db2c-4d0b-a10f-575fd372bc8c-575fd372bc8c&scope=IoT%20User%20offline_access”
Hast du da irgendeine Idee?
Hallo Daniel,
Tut mir leid, ich habe von Homeassistant keine Ahnung. Bei mir läuft das alles „native” auf Node-Red ohne irgendwelche Smart Home Frameworks.
Wenn du einen Linux (evtl. Geht auch Windows) Rechner hast, probier es doch mal ohne Homeassistant.
Ansonsten mal Tante Google fragen.
Jetzt im Sommer werde jetzt h wohl nicht dazu kommen, das Problem mal selbst nachzustellen.
Viel Glück noch
Chris
Hallo Daniel,
ich habe gerade noch etwas gegrübelt… Die Response vom Viessmann Server “RequestError: connect ECONNREFUSED ::1:1880” besagt, dass dein NR Server bzw. die HA Shell darum herum den Request abgelehnt hat. ::1:1880 ist dasselbe wie localhost:1880
Ich vermute, dass HA die Anfrage nicht durchlässt. Eventuell wird der Port 1880 geblockt oder umgeleitet. Probiere mal mit einem http-in Node einen Versuchsaufbau zu erstellen. Der Node sollte auf die GET Methode eingestellt werden, als URL trägst du test ein. Der Vollständigkeit halber noch einen http-Response Node, der den Statuscode 200 zurückschickt.
Hier der Setup als JSON:
[{"id":"d51ef4933a634ccc","type":"http in","z":"090ac94c9cd39a60","name":"","url":"/test","method":"get","upload":false,"swaggerDoc":"","x":300,"y":820,"wires":[["747daccfb6ae69f1","ec68e3b00f09949e"]]},{"id":"747daccfb6ae69f1","type":"debug","z":"090ac94c9cd39a60","name":"debug 59","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":500,"y":820,"wires":[]},{"id":"ec68e3b00f09949e","type":"http response","z":"090ac94c9cd39a60","name":"","statusCode":"200","headers":{},"x":500,"y":760,"wires":[]}]Kannst du diesen Node über einen Browser aus deinem Heimnetz “anfunken”? http://IPdeinesNRServers:1880/test/?message=deineTestMessage. Im Debug Node sollte message=deineTestMessage erscheinen
Wenn das nicht funktioniert, dann ist die Ursache wie oben beschrieben, und du musst schauen, wie du den HA Server bzw. NR darin freischaltest.
Keinesfalls den Port 1880 im Router freischalten sonst kann jeder auf deine Installation zugreifen!!
Wenn doch, dann musst du leider weiter forschen. Ich kann das leider nur sehr bedingt, da ich keine dieser Klickibunti Hausautomatisierungsgeschichten bei mir habe. HA oder IObroker sind mir für meine bescheidenen Anforderungen zu mächtig, zu kompliziert und zu intransparent.
Viele Grüße aus München
Chris
Hallo, bei mir läuft Node Red direkt auf der CCU3. Bedienung über Win 10 PC.
Bekomme auch immer die Fehlermeldung „ ErrorCannot GET /authcode“.
Habe zur Probe meine Firewall abgeschaltet—> gleicher Fehler
Den/die o. a. Code/Programmierung habe ich so übertragen.
Port 1880 ist in der CCU freigegeben.
Abfrage des Codes über Browser funktioniert.
Im Dev Portal von Viessmann stimmen die Einstellungen auch.
Was muss ich einstellen, damit ich den Authcode via Node Red abrufen kann?
Hallo,
Bin grad unterwegs. Mit CCU3/Homematic kenne ich mich überhaupt nicht aus. Wenn das Teil auf Linux läuft, dann probiere mal diese Hilfestellung:
Checke nochmal die ClientID Geschichte beim Developer.viessmann.com Dashboard:
Google Captcha muss ausgeschaltet sein
Redirect URI muss http://localhost:1880/authcode lauten. Keine IP Adresse verwenden.
im Node Red http request folgende URL eintragen (nur mit deiner Client ID anpassen, den Rest genau so lassen.)
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
Nicht vergessen, die Daten für das Basic Authentifizierungs Login einzutragen. Das ist dasselbe Login, dass du auch für deinen Viessmann Account oder die ViCare App verwendest.
Das MUSS funktionieren, d.h. im Debug Node (Request Result) steht dann der Auth Code. Wenn nicht, dann mal die URL Zeile in den Browser eingeben, dich mit deinem Viessmann Login einloggen. Es erscheint eine Verbindung Fehlgeschlagen Seite aber in der URL Zeile vom Browser steht jetzt etwas der Art: http://localhost:1880/authcode?code=1ewaadBgBpQchLjJN4hh-z4RMVR8FJ5dvG5heuZp23k
Wenn das geht, dann hast du etwas bei Node Red oder deinem Hardware Setup verkehrt. Wenn nein, würde ich vorschlagen, mit Michael Hanna von Viessmann Kontakt aufzunehmen.
Hi!
Danke für die schnelle Antwort.
Wie beschrieben passt die Config von Viessmann etc. . Wenn ich den Request im Browser ausführe, bekomme ich den Code.
Bzgl. der Einstellungen im Node Red bin ich absoluter Rookie.
Evtl. benötigt man in diesem Setup hier einen anderen Port, den man (zusätzlich) freigeben muss.
Werde mal den Kollegen von Viessmann kontaktieren. Danke für den Hinweis 🙂
Hi,
Probiere mal die ersten drei Nodes aus dem Kapitel „Authcode abrufen“. Im Debug Node steht das Resultat. Wie du den http Request Node konfigurierst steht im Text.
Normalerweise läuft Node-Red auf Port 1880. Evtl mal in der Konfigurationsdatei nachsehen, ob da ein anderer Port eingestellt ist.
Viele Ostermontags-Grüße
Chris
ANMERKUNG/Nachtrag: Im obersten/ersten Debug Node steht nur dann etwas Sinnvolles, wenn im weiteren Verlauf der zuerst eingebaute http in Node das vom Viessmann Server angesprochene virtuelle Verzeichnis /authcode aktiviert hat.
Hi!
Welche Konfigurationsdatei meinst Du genau?
Hallo,
Bei Linux steht die Datei settings.js im versteckten Node-Red Verzeichnis unterhalb deines Home Directories. Also z.B. /home/philipp/.node-red/settings.js
Aber wenn du Node-Red über die url http://deinServerName:1880 aufrufen kannst, dann ist das auch die Portnuummer für das Viessmann Gedöns.
VG
Chris
******Dieser Post ist fälschlicherweise vom Spamfilter aussortiert worden – sorry! *******
Hallo,
eine Abfrage mit GET (wie im Text beschrieben) im ersten http-Request liefert kein Ergebnis.
Grundsätzlich funktioniert diese URL für eine Abfrage via Browser bei Viessmann.
Bei einer Abfrage mit POST via Node Red mit gleicher URL kommt folgendes Ergebnis heraus:
302 FoundFoundThe document has moved here.
Zumindest wird da der Authcode angezeigt.
Ist es möglich dieses Ergebnis im Node Red so aufzubereiten, dass nur der Code-Teil im msg.payload abgespeichert wird?
Hallo,
ich muss da leider passen. Die Abfrage sollte mit einem GET Request funktionieren. Da ich das ganze für einen Raspberry Pi entwickelt habe, kann es durchaus sein, dass ein anderes Gerät mit Linux Kern nicht ganz so funktioniert wie gewünscht, da dort irgendwelche Standardkomponenten fehlen, deaktiviert oder anders konfiguriert sind. Im Prinzip ist eine z.B. Fritz!Box auch bloß ein Linux Rechner, aber die Viessmann API wirst du damit nur mit erheblichem Aufwand zum Laufen bringen. Bei der CCU3 ist das vielleicht auch so.
Notbehelf: Access und Refresh Token auf anderem Weg erzeugen (Postman, Funktion bei developer.viessmann.com) in Node-Red einbauen und laufen lassen. Nach 180 Tagen widerholen.
Viel Erfolg noch
Chris
ANMERKUNG: Im obersten/ersten Debug Node steht nur dann etwas Sinnvolles, wenn der weiter unten stehende http in Node existiert und das vom Viessmann Server angesprochene virtuelle Verzeichnis
/authcodegeneriert hat.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