Hi mdkeil. Auch ein schöner Ansatz, vor allem in Sachen Usability.
Bei mir läuft es, seit ein paar Tagen via Python Script an den besagten Raspi-MQTT-Server.
Frage: Hast du Langzeiterfahrungen mit Tibber in Kombination mit dem Node?
Ich frage deshalb, weil ich gesehen habe, dass die Verbindung zu Tibber bei mir zuweilen abbricht (connection closed) und dann beim Reconnecten das hier kommt/kommen kann:
Too many open connections on this server: 2;
In dem Fall muss(?) man sich einen neuen API Key holen; Warten hat nicht geholfen. Das API Key holen kann ich zwar auch automatisieren, bedeutet aber zusätzlichen und hoffentlich vermeidbaren Aufwand.
Hi, da kann ich mal eben reingrätschen. Vielen Dank noch für Deinen Ansatz. Den habe ich gestern auch noch einmal ausprobiert und es läuft immerhin. Aber wie Du sagst, eben nicht wirklich stabil. Es kommt hin und wieder immer noch zu dem "Too many connections" Fehler.
Der Node-Red Node läuft bei mir absolut stabil. Ich hatte ihn gestern gestartet, und er hat heute morgen immernoch fein seine Daten ans Debug-Fenster gesendet. Siehe Bild im Post über diesem. Leider komme ich an die Daten jetzt nicht heran. Für einen erfahrenen Node.Red Spezialisten wohl kein Problem. Als Node-Red-Anfänger kann ich bis jetzt leider nur mit den Schultern zucken.
Und den MQTT Broker wollte ich erst mal nicht installieren. Da sollte es einen einfacheren Weg geben. Aber wenn nicht, dann werde ich darum wohl uch nicht herumkommen. Dann ist mein System aber wirklich nicht mehr "keep it simple".
@monokristallin Tatsächlich läuft meiner Konstrukt seit 36h auch stabil. Aber ich möchte natürlich nicht von einer Tagesform (egal ob Tibber-Api, Python oder 3rd Party libs) abhängig sein. Von daher sind deine langfristigen Beobachtungen für mich sehr interessant. 👍
@monokristallin Tatsächlich läuft meiner Konstrukt seit 36h auch stabil. Aber ich möchte natürlich nicht von einer Tagesform (egal ob Tibber-Api, Python oder 3rd Party libs) abhängig sein. Von daher sind deine langfristigen Beobachtungen für mich sehr interessant. 👍
Ja, Dein Skipt läuft soweit. Allerdings läuft da ja etwas im Hintergrund. Den Main-Part würde ich ja jedes Mal mit starten, wenn mein Hauptskript läuft. So wie ich das sehe, laufen dann zwei Instanzen, die dann zu viel für Tibber sind. Zumindest erkläre ich mir das so. Bei Node-Red kann ich so oft neustarten wie ich will, das funktioniert.
Wenn ich jetzt nur noch die Zahlen, die ich da durchrauschen sehe, auch vom anderen Pi auslesen könnte. Es gibt da ja Netzwerk-Nodes. Aber die habe ich allesamt nicht wirklich verstanden, bzw. diese sind wohl irgendwie für andere Dinge gebaut worden, als einzelene Werte zur Verfügung zu stellen. Aber wie gesagt, ich habe gestern erst angefangen, mit Node-Red. Vielleicht komme ich ja noch selbst drauf. Aber jede Hilfe ist sehr willkommen...
Ich selbst nutze die Tibber Nodes nur zum Auslesen der Preise, da ich einen separaten IR Lesekopf verwende und die Daten direkt auslese und die Daten manuell an Tibber sendet.. funktioniert seit über 2 Monaten tadellos.
Ich mache mir heute Abend mal Gedanken, wie Du die Daten sonst noch auf deinen externen Pi bekommst.
IBN: 07/2021
Fronius Symo 20.0-3-M : 13.2kWp S 45° + 3.96 kWp S 15° (Verschattung) &
Fronius Primo 3.0-1 : 2.97 kWp N 15° (Verschattung)
06/2023 : Speichererweiterung 14,34kWh DIY (EEL Gehäuse) LiFePO4 EVE LF280K @ Victron MP II 48/5000 - Seplos 10E BMS
######
Wallbox: 11kW echarge Hardy Barth Cpμ2 Pro - Überschuss-Steuerung via evcc.io
Peugeot e-208 Allure Pack seit 11.11.22!
Kia Niro EV Edition 7 seit 28.04.23.
quick and dirty http-endpoint 😉
Der Wert selbst liegt in einer globalen Variablen (global.get("fronius.meter")).. zu setzen z.B. mit global.set("variable",wert);
[ { "id": "edeb5b596a7cec77", "type": "http in", "z": "03ddae67b0473922", "name": "", "url": "/api", "method": "get", "upload": false, "swaggerDoc": "", "x": 160, "y": 120, "wires": [ [ "7bf4ca40c5400086" ] ] }, { "id": "7bf4ca40c5400086", "type": "function", "z": "03ddae67b0473922", "name": "json", "func": "msg.payload = {gridpower: global.get('fronius.meter')};\nmsg.headers = {};\nmsg.headers['content-type'] = 'application/json';\nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 330, "y": 120, "wires": [ [ "7883d17ca80f0090" ] ] }, { "id": "7883d17ca80f0090", "type": "http response", "z": "03ddae67b0473922", "name": "http Response", "statusCode": "", "headers": {}, "x": 560, "y": 120, "wires": [] } ]
IBN: 07/2021
Fronius Symo 20.0-3-M : 13.2kWp S 45° + 3.96 kWp S 15° (Verschattung) &
Fronius Primo 3.0-1 : 2.97 kWp N 15° (Verschattung)
06/2023 : Speichererweiterung 14,34kWh DIY (EEL Gehäuse) LiFePO4 EVE LF280K @ Victron MP II 48/5000 - Seplos 10E BMS
######
Wallbox: 11kW echarge Hardy Barth Cpμ2 Pro - Überschuss-Steuerung via evcc.io
Peugeot e-208 Allure Pack seit 11.11.22!
Kia Niro EV Edition 7 seit 28.04.23.
Hier hat sich jemand das Node-Red in den IOBroker heineingeladen und sich dann die Tibber Nodes nachinstalliert. Funktioniert dann aber genauso. Mit einer kleinen Funktion
var newmsg = {payload: msg.payload.power}; return newmsg;(function-node) schiebt er mir nun ständig den aktuellen Tibber Pulse power-Wert ins debug-Fenster.
..zusätzlich noch in eine globale Variable geschrieben, die du dann für den http-Endpunkt verwenden kannst.
var newmsg = {payload: msg.payload.power}; global.set("tibber.power",newmsg); return newmsg;
IBN: 07/2021
Fronius Symo 20.0-3-M : 13.2kWp S 45° + 3.96 kWp S 15° (Verschattung) &
Fronius Primo 3.0-1 : 2.97 kWp N 15° (Verschattung)
06/2023 : Speichererweiterung 14,34kWh DIY (EEL Gehäuse) LiFePO4 EVE LF280K @ Victron MP II 48/5000 - Seplos 10E BMS
######
Wallbox: 11kW echarge Hardy Barth Cpμ2 Pro - Überschuss-Steuerung via evcc.io
Peugeot e-208 Allure Pack seit 11.11.22!
Kia Niro EV Edition 7 seit 28.04.23.
Hi @mdkeil
Ja, vielen Dank!! Das sieht ja schon mal ganz gut aus. Leider kann ich es gerade nicht wirklich testen, da Tibber wohl gerade ein Serverproblem hat. Weder kann sich der Node verbinden, noch bringt der APi Explorer bei Tibber selbst Werte ("Your subscription data will appear here after server publication")
Vielleicht gibt sich das ja noch im Laufe des Tages.
Allerdings, so fürchte ich, musst Du mich, was das Füllen der Nodes angeht, noch ein paar Meter weiter vorne abholen. Ich habe das mit dem HTTP Request noch nicht ganz verstanden. Macht es Sinn, wenn ich die Felder so fülle?
Inbesondere bei der Function sollte das ja so nicht gehen. Ein json-Format ist ja keine Funktion. Das werde ich sicherlich so falsch gemacht haben. Aber auch die http-Nodes werde ich wohl falsch ausgefüllt haben.
Aber immerhin habe ich das mit der globalen Variable und dem anschließenden Auslesen verstanden. 😉
Vielen Dank nochmals bisher und auch vorab...
Ich ich viel schreibe.. das was ich oben im Code-block gepostet habe sind die entsprechenden Node als json exportiert.. das kannst Du Copy+Paste so in Node Red importieren.. dann brauchst Du in dem Funktion-Node nur noch die globale Variable anpassen.
IBN: 07/2021
Fronius Symo 20.0-3-M : 13.2kWp S 45° + 3.96 kWp S 15° (Verschattung) &
Fronius Primo 3.0-1 : 2.97 kWp N 15° (Verschattung)
06/2023 : Speichererweiterung 14,34kWh DIY (EEL Gehäuse) LiFePO4 EVE LF280K @ Victron MP II 48/5000 - Seplos 10E BMS
######
Wallbox: 11kW echarge Hardy Barth Cpμ2 Pro - Überschuss-Steuerung via evcc.io
Peugeot e-208 Allure Pack seit 11.11.22!
Kia Niro EV Edition 7 seit 28.04.23.
Tjaa,
leider hat wohl unser (erwiesermaßen leider ganz außergewöhlich dämlicher) Hausmeister meinen Pulse abgezogen und im Keller versteckt. Darauf musste erst mal kommen. 😞
Jetzt läuft alles wieder.
Okay, das mit dem Import war mir neu. Sehr praktisch! 👍
Wie das mit den http request funktionieren sollte kann man prima in diesem kurzen Video sehen:
Leider, leider, leider komme ich nur bis 0:55, wo man eigentlich {} im Browser sehen sollte.
Gebe ich im Broser
venus.local
ein, dann sehe ich die Konsole. Gebe ich jetzt
venus.local:1880/test (oder venus.local:1880/api) ein, dann steht im Browser:
Fehler: Verbindung fehlgeschlagen
Firefox kann keine Verbindung zu dem Server unter venus.local:1880 aufbauen.
Desselbe, wenn ich die Venus-IP angebe. Woran kann das denn nun schon wieder liegen? 😧 Muss man generell noch einen Service im Node Red aktivieren?
Hättest Du sonst mal Lust, die beiden http Nodes auch zu exportieren?
Irgendwie steckt da bei mir immer noch der Wurm drin.
PS: Mir scheint das ein Bug im neuen Raspberry VenusOS zu sein. Ich habe Version 3.13 Large. Vielleicht hat das Problem ja mit dieser Version sont noch jemand. Ich habe die Frage jetzt mal im Victron Forum gepostet. Mal schauen, ob da jemand Rat weiß...
PPS: Ein Update auf Version 3.20~45 (und Node-Red 3.1) hat jedenfalls noch keine Besserung gebracht.
PS: Mir scheint das ein Bug im neuen Raspberry VenusOS zu sein
glaube ich nicht.. läuft bei mir mit der 3.20 ~35 problemlos
Hättest Du sonst mal Lust, die beiden http Nodes auch zu exportieren?
ups.. dachte oben wäre alles komplett.. war ja nur der function-node..
hier einmal komplett.. werde ich oben dann auch ändern /p>
[ { "id": "edeb5b596a7cec77", "type": "http in", "z": "03ddae67b0473922", "name": "", "url": "/api", "method": "get", "upload": false, "swaggerDoc": "", "x": 160, "y": 120, "wires": [ [ "7bf4ca40c5400086" ] ] }, { "id": "7bf4ca40c5400086", "type": "function", "z": "03ddae67b0473922", "name": "json", "func": "msg.payload = {gridpower: global.get('fronius.meter')};\nmsg.headers = {};\nmsg.headers['content-type'] = 'application/json';\nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 330, "y": 120, "wires": [ [ "7883d17ca80f0090" ] ] }, { "id": "7883d17ca80f0090", "type": "http response", "z": "03ddae67b0473922", "name": "http Response", "statusCode": "", "headers": {}, "x": 560, "y": 120, "wires": [] } ]
IBN: 07/2021
Fronius Symo 20.0-3-M : 13.2kWp S 45° + 3.96 kWp S 15° (Verschattung) &
Fronius Primo 3.0-1 : 2.97 kWp N 15° (Verschattung)
06/2023 : Speichererweiterung 14,34kWh DIY (EEL Gehäuse) LiFePO4 EVE LF280K @ Victron MP II 48/5000 - Seplos 10E BMS
######
Wallbox: 11kW echarge Hardy Barth Cpμ2 Pro - Überschuss-Steuerung via evcc.io
Peugeot e-208 Allure Pack seit 11.11.22!
Kia Niro EV Edition 7 seit 28.04.23.
Supi, dann sollte es ja eigentlich klappen.
Bei mir scheint irgendetwas im Netzwerk nicht i.O. zu sein. Wenn ich mich mit ssh auf Venus einlogge und
wget http://localhost:1880/api
eingebe, dann erhalte ich ein Textfile namens api mit dem Inhalt
{}
D.h. er selber kann auf den Port zugreifen, von außen geht das aber nicht. Allerdings ist immer noch nichts in der Klammer.
Wenn ich mir meine Funktion anschaue, dann sehe ich ja
var newmsg = {payload: msg.payload.power}; global.set("tibber.power",newmsg); return newmsg;
D.h. unser Wert wird auf die globale Variable tibber.power gelegt, richtig?
Mit Deinem Knoten
msg.payload = {gridpower: global.get('fronius.meter')}; msg.headers = {}; msg.headers['content-type'] = 'application/json'; return msg;
ließt Du aber fronius.meter aus und gibst den dann weiter. Ist das so richtig? Oder wie kommt der Tibber Wert letzlich nach http://localhost:1880/api ? Oder: wie kommt der Tibber-Power-Wert zur fronius.meter Variable?
HA!!! Wenn ich Deinen Knoten umschreibe auf Tibber-Power, dann klappt's:
{"gridpower":{"payload":173.4,"_msgid":"21538c2f8d15e6e3"}}
😀
Jetzt muss ich das Ganze nur noch von außerhalb des Pis lesen können...
Nochmals herzlichen Dank an mdkell für die unermüdliche Unterstützung!!! Ich denke, dies wird vielen helfen. 😊 👍
Hier also noch mal das komplette Kochrezept in dem nur noch die Home-ID im Tibber-Node angepasst werden muss. Die kann man auch gleich hier schon in Zeile 9 zwischen die Anführungszeichen eintragen.
Um die Abfrage mit einer neueren Node-Red / VenusOS Version zu realisieren, ist dies hier die korrekte Abfrage:
wget https://venus.local:1881/api --no-check-certificate
Bei einem VenusOS Versionssprung (vermutlich bei 3.00) wurde er HTTP Port für alle HTTP-Anfragen auf 1881 gesetzt.
ist dabei die Node-Red GUI, alles andere liegt darunter.
Hier also der Flow:
[ { "id": "f7057bc3c95c55fe", "type": "tibber-feed", "z": "96cffcb4cb06b139", "name": "Tibber-Live", "active": true, "apiEndpointRef": "5e8af9f09e4a2d66", "homeId": "", "timestamp": "1", "power": "1", "lastMeterConsumption": false, "accumulatedConsumption": false, "accumulatedProduction": false, "accumulatedConsumptionLastHour": false, "accumulatedProductionLastHour": false, "accumulatedCost": false, "accumulatedReward": false, "currency": false, "minPower": false, "averagePower": false, "maxPower": false, "powerProduction": false, "minPowerProduction": false, "maxPowerProduction": false, "lastMeterProduction": false, "powerFactor": false, "voltagePhase1": false, "voltagePhase2": false, "voltagePhase3": false, "currentL1": "1", "currentL2": "1", "currentL3": "1", "signalStrength": false, "x": 200, "y": 2500, "wires": [ [ "88cc0f4960d02fde" ] ], "icon": "node-red/feed.svg" }, { "id": "88cc0f4960d02fde", "type": "function", "z": "96cffcb4cb06b139", "name": "extractpower", "func": "var newmsg = {payload: msg.payload.power};\nglobal.set(\"tibber.power\",newmsg);\nreturn newmsg;", "outputs": 1, "timeout": "", "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 410, "y": 2500, "wires": [ [ "25aa143c52267d04" ] ] }, { "id": "25aa143c52267d04", "type": "debug", "z": "96cffcb4cb06b139", "name": "debug 3", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 660, "y": 2500, "wires": [] }, { "id": "edeb5b596a7cec77", "type": "http in", "z": "96cffcb4cb06b139", "name": "", "url": "/api", "method": "get", "upload": false, "swaggerDoc": "", "x": 200, "y": 2680, "wires": [ [ "7bf4ca40c5400086" ] ] }, { "id": "7bf4ca40c5400086", "type": "function", "z": "96cffcb4cb06b139", "name": "json", "func": "msg.payload = {gridpower: global.get('tibber.power')};\nmsg.headers = {};\nmsg.headers['content-type'] = 'application/json';\nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 350, "y": 2680, "wires": [ [ "7883d17ca80f0090" ] ] }, { "id": "7883d17ca80f0090", "type": "http response", "z": "96cffcb4cb06b139", "name": "http Response", "statusCode": "", "headers": {}, "x": 560, "y": 2680, "wires": [] }, { "id": "5e8af9f09e4a2d66", "type": "tibber-api-endpoint", "queryUrl": "https://api.tibber.com/v1-beta/gql", "feedConnectionTimeout": "30", "feedTimeout": "60", "queryRequestTimeout": "30", "name": "TibberData" } ]
Und den importiert man hier. Einfach copy/paste in das sich öffnende Fenster.
Die Variable fronius.meter habe ich nur zur Veranschaulichung genommen, hat also nix mit Tibber zu tun.
Ich habe noch gesehen, was man bei dir noch optimieren kann.. dann ist die Weiterverarbeitung sauberer/einfacher.
+ ggfs statt wget zur Abfrage curl nehmen..
global.set("tibber.power",newmsg); ändern in global.set("tibber.power",msg.payload.power);
IBN: 07/2021
Fronius Symo 20.0-3-M : 13.2kWp S 45° + 3.96 kWp S 15° (Verschattung) &
Fronius Primo 3.0-1 : 2.97 kWp N 15° (Verschattung)
06/2023 : Speichererweiterung 14,34kWh DIY (EEL Gehäuse) LiFePO4 EVE LF280K @ Victron MP II 48/5000 - Seplos 10E BMS
######
Wallbox: 11kW echarge Hardy Barth Cpμ2 Pro - Überschuss-Steuerung via evcc.io
Peugeot e-208 Allure Pack seit 11.11.22!
Kia Niro EV Edition 7 seit 28.04.23.
Und hier noch der PythonCode mit dem man den Wert dann wieder ausließt:
#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ Created on Fri Dec 29 21:01:55 2023 @author: nick """ import requests import json requests.packages.urllib3.disable_warnings() #### Tibber Pulse über Node-Red ######################################################## try: url = "https://venus.local:1881/api" TP = requests.get(url, verify=False, timeout=2) TP1 = TP.text TP2 = json.loads(TP1) TibberPower = TP2['gridpower']['payload'] except: print("No Tibber Data") print("Tibber Pulse:") print(str(TibberPower))
Das Ganze ist jetzt noch einmal anfängergerecht, Schritt für Schritt erklärt, in der Wiki zu finden.