Part II - using the solcast API with Node-Red (flows and how its done)
....using the solcast API is faily uncomplicated.
I've created two flows, one for posting measurements and one for collecting forecast data.
As data source for measurements, as well as data destination for solcast estimates, I've used an influxDB, which I already populate with data from my infrastructure.
If you want to use other means to manage your data, your mileage may vary and you will have to adopt to your specific setup, of course.
flow A) sending measurements from influxDB to your solcast rooftop acount
Originally the data for measurements is coming from my solar inverter.
As I have a quite sophisticated EV-Charging station that is capable of charging the vehicle optimized to the current flow of solar power available, the data is already collected there, including some more information.
Therefore I refrained from directly accessing my inverter (via modbus-tcp) but integrated with my EV charging station to collect the data and transfer this to influxDB (via mqqt-telegraf-influxDB toolchain).
The destination is described in the solcast API, here: Solcast API
This is a simple HTTP(S) request to the API, sending the data as an array in JSON format.
You can invoke the API-service as often as you want (it is not counting against the number of 20 allowed API calls per day with your free hobbyist rooftop account). Also re-sending measurements already sent earlier is not a problems, as these will simply be overridden.
I finally resorted to collect and send data for from the last 25hours in an interval once every 24hours.
The flow offers some predefined injection-nodes with dataseries from other time-spans, that can be invoked manually.
My flow for posting measurements to solcast looks like this:
The different influxDB queries are defined manually inside the change-nodes.
The minimum intervall that can be given for a measurement is 5minutes, which is what I choose in the queries.
This is the influxDb query for the 25hrs recurring collection interval:
SELECT mean("value") / -1000 FROM "autogen"."mqtt_consumer" WHERE ("topic" = 'openWB/pv/W') AND (time >= now()-25h AND time <= now()-7m) GROUP BY time(5m) fill(0)
As my data is stored in W, but measurements are expected in kW units, notice the "* 1000" math operation inside the query. Also non existing data in that interval (when its dark, normally no solar data will be captured from the inverter) will be filled with "0" (number zero).
My data/influx measurements is stored via telegraf from mqtt topics, so in my example the measurement from influxDB is "openWB/pv/W". You will need to select the correct measurement in your own query.
I noticed, that the solcast API-Service can be sometimes "flaky", so an API invocation might fail occasionally . I catched the HTTP-response and if not a status 200, the message gets recreated after 5mins....works every time so far.
Inside the HTTP-Request node, you will have to specify the URL and credentials.
The URL is based on/comprised of your rooftop account ID and you can use basic identification with the use of your solcast API-Token as Username. Both information you can easily get from your solcast account info.
This is what the setup of the node looks like:
...and here's the flow:
solcast-measurements-flow.json (7.1 KB)
flow B) retrieving solcast estimates/forecasts and storing in influxDB
The flow for retrieving the forecasts is similar.
This is what the flow looks like:
I am using a special inject node from here: [ANNOUNCE] Ultimate (Swiss-Army-Knife) Node-Red Timer based flow control where I can run a number of events between dates (sunrise/sundown).
The hobbyist rooftop account will allow for 20 queries per day, so a counter-node is introduced to match/route this requirement, while events are created (using node-red-contrib-counter (node) - Node-RED).
Also other inject nodes are there to allow for manual injection and/or resetting the counter, which is nice for testing (during the first three month of your rooftop account, the limit will not be enforced until he first 1000 API-calls are used up).
Again, like in the measurement flow, of the API-call fails occasionally, a retry will be scheduled after 3mins. I found, that even when the call fails, the attempt will be counted against the number of calls, so the retry will increase the counter...just in case.
The API has two separate services, estimated actuals and forecasts.
The HTTP(S) node is configured similar, but with a GET Method and waiting/parsing a JSON response. using rooftop-id in the URL and API-Token as Username with basic authentication.
After a successful retrieval, the data (JSON array) gets re-formatted to be fed into the influxDB-node.
Here I opted to send each individual data point/message into the node. My current influxDB and node-Red instance would easily cope with the "stress", but generating a single bulk-message for influxDB is certainly possible. A single API-Call will create 336 data points.
Here's the flow:
solcast-estimates-flow.json (23.9 KB)
..and here are some pics from my grafana dashboards.
PV-Tuning kicks in only after some days (my site took 10 days) of feeding measurements, but the results are pretty impressive, I think.
...forecasts this week:
...values from last week:
...hope you enjoy it...feel free to ask questions or details I missed.
regards,
Fred
