Aber ein Plugin, mit dem ich die Power-Daten über die Tibber-API ins VenusOS bekomme ist mir so auch noch nicht über den Weg gelaufen.
Da auf dem large-image von VenusOS auch ein Node Red läuft.. es gibt dort einen fertigen Flow, die sämtliche Tibber-Daten abholen können.. in Kombination mit:
könntest Du dir aus den Tibber-Daten ein entsprechendes Grid-Meter erstellen und in VenusOS einbinden-
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.
@zx6r Hi, ich habe auch einen MPP Solar WR und Tibber im Einsatz. Die Tibberdaten kann ich ohne Probleme abrufen 🙂 Mich würde interessieren über welchen Weg / Programm Du den MPP Solar WR mit den optimalen Ladedaten versorgst. Beste Grüße und schon mal Danke für eine Antwort!
Hi.
Also, bei mir macht eigentlich alles ein zentrales, selbstgebasteltes Python-Script. Das ließt Daten vom Venus-OS und z.B. von Discovergy aus. Leteres ist in letzter Zeit etwas instabil, deshalb der Versuch, alternativ Tibberdaten auszulesen.
Dieses Pythonskript steurt dann auf den Raspberry Pi entsprechend dem aktuellen Verbrauch, dem Strompreis etc. den Soyosource WR über USB -> RS485 direkt an.
Aber ein Plugin, mit dem ich die Power-Daten über die Tibber-API ins VenusOS bekomme ist mir so auch noch nicht über den Weg gelaufen.
Da auf dem large-image von VenusOS auch ein Node Red läuft.. es gibt dort einen fertigen Flow, die sämtliche Tibber-Daten abholen können.. in Kombination mit:
könntest Du dir aus den Tibber-Daten ein entsprechendes Grid-Meter erstellen und in VenusOS einbinden-
Tja, hätte ich mal das Large-Image installiert! 😉 Das wäre dann auch noch eine Möglichkeit. Das ließe sich ja noch schnell flashen. Allerdings müsste ich mich da noch in Node-Red einfuchsen. Eleganter fänd ich die Möglichkeit, mein zentrales Python-Script die Daten selbst abholen zu lassen. Das funktioniert ja auch schon fast...
Aber ja, falls alles andere nichts klappt, dann wäre das womöglich der nächste Schritt. Vielen dank also auch dafür! 👍
Geht relativ einfach, wenn man Solpiplog am Laufen hat.
Das Skript https://github.com/christian1980nrw/Spotmarket-Switcher läuft Stündlich und schaltet zu den billigen Zeiten ja standardmäßig z.b. Steckdosen an oder aus .
Hier habe ich angesetzt und das Skript um die passende Zeile erweitert um per MQTT über Solpiplog den MPPSolar WR von SBU auf UTI zu schalten.
(mosquitto_pub -u emonpi -h localhost -t solpiplog/pip/status/set -m sbu)
https://github.com/njfaria/SolPipLog/blob/master/docs/mqttvalues.md
Das war’s auch schon J
Klappt prima .. hab es aber trotzdem nicht mehr laufen .. weil ich meinen Akku nur mit max 30-40A laden möchte .. dann braucht es halt ein paar Stunden bis er einigermaßen voll ist!
Da reicht es dann wenn man im Winter immer zwischen 0 und 6 Uhr lädt.
Das kann man recht einfach in Solpiplog einstellen und bedarf keiner weiteren Handstände 😉
@zx6r Wie oben beschrieben: Ich kann problemlos alle Daten von Tibber auslesen. Nur mit den Power-Daten, also der Realtime Subsciption, hapert es noch.
@luchbewohner Hi.
Tjaa, ich hab jetzt alles versucht, was ich kann. Ich bin jetzt noch mal auf den Original-Code zurückgegangen, benenne kurz token und home-id. Wenn das Skript läuft, dann kommt entweder der Too many connections Fehler oder eben nichts. Was aber auch nicht verwunderlich ist, es gibt ja im gesamten Skript keine Ausgabe der Werte. Wo müsste ich also wenigstensein "print" anbringen?
Wenn ich's hier hinsetze:
try:
for result in ws_client.subscribe(subscription):
print(result)
console_handler(result)
dann kommt dabei heraus:
tibberpulse-influxdb
Sleep for 5 secs.
Run GQL query.
{'liveMeasurement': {'timestamp': '2023-12-21T14:24:34.000+01:00', 'power': 2210.4, 'accumulatedConsumption': 4.1975, 'accumulatedCost':
0.939531, 'voltagePhase1': None, 'voltagePhase2': None, 'voltagePhase3': None, 'currentL1': None, 'currentL2': None, 'currentL3':
None, 'lastMeterConsumption': 3742.3657}}
Exception ignored in: <async_generator object Client.subscribe_async at 0x754d0a30>
RuntimeError: async generator ignored GeneratorExit
Mehr will ich ja eigentlich gar nicht. Power ist ja da. Aber danach ist eben minutenlang Ebbe. Was die Fehlermeldungen angeht: keine Ahnung. Damit kann ich jetzt auch nichts anfangen. Aber vielleicht liegt der Hase ja genau dort im Pfeffer(?)
Ich rufe übrigens das pulse.py direkt von der Konsole aus auf. Das sollte wohl ok sein. Oder ist das der Fehler?
Hättest Du Lust, mir mal Dein Skipt zu geben? Irgendwo ist bei mir ja Wurm drin und ich komm' nicht drauf, was genau ich mit dem console_handler abrufen muss und wo besser keine Schleife laufen sollte... 🤔
PS: Die Connections scheinen sich übrigens so halbwegs zurücksetzen zu lassen, wenn man die RealTimeSubscription im API Explorer nutzt. Da kommt dann auch erst noch dieselbe Fehlermeldung. Anschließend funktioniert es dann, und dann (manchmal) auch wieder mit dem Pythonscript.
@zx6r Vielen lieben Dank für die schnelle Antwort! Kann es sein, dass der Installationfolder "sol" im Projekt solpiplog" fehlt?
habe es gefunden 
https://github.com/njfaria/SolPipLog/releases
Hab das ganze in Github abgelegt.
Viel Spass damit.
@solarffm Möglich ist das .. Ich hatte zunächst eine älter Version laufen und bin erst später auf 3.11 umgestiegen.
Am ende sollte es so aussehen! Glaube man musste auch die Benutzerrechte damals anpassen.
Es gibt aber auch Fertige Images für den Pi. Da ist dann gleich Emoncms mit drauf! Musst mal im www.photovoltaikforum.com suchen.. da hatte ich es auch bekommen
https://www.photovoltaikforum.com/core/attachment/175407-handbuch-emoncms-pdf/
Das sieht dann am ende z.b. so aus
Hab das ganze in Github abgelegt.
Viel Spass damit.
Hey,
vielen Dank! Damit spiele ich mal herum, sobald der Weihnachtstrubel vorüber ist. Da stecke ich schon mittendrin. 😉
Ich werde mal berichten.
Allerdings läuft auf meinem Pi auch Python 3.7. Mir 3.9.x läufen einige andere Routinen wieder nicht, deshalb kann ich da nicht upgraden. Ich werd's mal testen...
Aber ein Plugin, mit dem ich die Power-Daten über die Tibber-API ins VenusOS bekomme ist mir so auch noch nicht über den Weg gelaufen.
Da auf dem large-image von VenusOS auch ein Node Red läuft.. es gibt dort einen fertigen Flow, die sämtliche Tibber-Daten abholen können.. in Kombination mit:
könntest Du dir aus den Tibber-Daten ein entsprechendes Grid-Meter erstellen und in VenusOS einbinden-
Hi mdkell.
Okay, ich habe mal alles installiert was man dazu wohl braucht und mir dieses, für Node-Red Anfänger wirklich sehr lehrreiche, Video angeschaut:
Das hier beschriebene ist tatsächlich leicht nachzuvollziehen und ich kann, zumindest im debug-Fenster so ziemlich alle Daten sehen.
Wie das mit den Live-Daten geht, lässt sich hieraus ableiten:
https://forum.iobroker.net/topic/63092/tibber-pulse-livedaten-mit-nodered-abholen
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.
Das einzige das mir nun noch fehlt ist: wie lese ich den Wert von außen wieder aus? Ich ziehe mir die Batterie- und Solarcharger Werte mit python über Modbus-TCP vom Venus in meinen Pi, der eigentlich die Hauptaufgaben erledigt. Das macht man über die ID und die auslebaren Register, die dahinter stehen.
Das scheint hier aber nicht der richtige Weg zu sein. Weiß also jemand, wie ich "von außen" einen Wert, der im Debug-Fesnter bereits ständig korrekt aktualisiert wird, ganz simpel mit einem anderen Pi, bestenfalls über Python, auslesen kann? Vielleicht über http? Dummerweise stehe ich bei dieser Aufgabe bei Node-Red, die doch nun wirklich die allereinfachste von allen sein sollte, wieder mal wie der Ochs vor'm Berg. 😑
Vielen Dank vorab...
Läuft auf deinem pi z.b. ein MQTT Broker?.. dann schicke es einfach via MQTT.. es gibt dafür einen fertigen Node..
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. 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.
Läuft auf deinem pi z.b. ein MQTT Broker?.. dann schicke es einfach via MQTT.. es gibt dafür einen fertigen Node..
Du meinst, auf dem auslesenden Pi? Nein. Eigentlich wollte ich den auch so schlank wie möglich belassen. Was mich ärgert, ist dass das hier:
https://flows.nodered.org/node/node-red-contrib-victron-modbus
irgendiw nicht funktioniert. Damit soll mal, so wie ich das lese, bereits vorhandenen Geräten unter ser entsprechenden ID und dem entsprechenden Register, wie z.B.
ID 100 (Venus System) und den Register 820 (/Ac/Grid/L1/Power) beschreiben können. Allerdings steht in der List auch explizit, dass dieser Werte eben nicht writeable ist. Das gilt aber für so ziemlich alle Werte. Wenn ich ihn aus lese, dann bekomme ich immer "0" als Antwort.
So habe ich's gemacht (siehe untere Kette):
Irgendetwas verstehe ich da offensichtlich falsch.