It (Solcast’s website + the customer component) allows you to:
register a free residential service with your system details (location, AC/DC system side, angles etc.)
submit readings from your system to “tune” their prediction model towards your actual system
request an estimated PV yield for the rest of the day (up to 10 or 20 times a day for residential accounts), taking into account estimated cloud coverage, location, time of day, time of the year etc.
So I use it to boost my geyser’s temperature:
when my batteries reach 100%, ask the Solcast sensor for the estimated PV yield left (for my system, for today)
when there’s enough, run the geyser for 15 mins. It is a 4kw element, so it uses 1 kWh.
repeat until the geyser is super hot (70 degrees in my case) or there’s not enough PV yield left (3 kWh in my case) – that way I get to “store” more of my PV energy and keep the geyser hot for subsequent cloudy days.
Of course, you do not need to use it with a geyser (I had to get the temperature of my geyser into HA too). You can use it to run a borehole, run an aircon, run a crypto miner etc. using your “free” energy.
Here’s my forecast for the rest of the day (and tomorrow and the day after):
The sensor.solcast_post contains the kW output of my system, averaged over the last 5 minutes.
The URL is based on what Solcast’s API needs, but basically something like: solcast_tune_url_auth: 'https://api.solcast.com.au/rooftop_sites/<rooftop ID>/measurements?api_key=<api_key>'
Then to send the REST command I basically call the service generated:
I use the Solcast custom component to request the history and the forecast. It isn’t the greatest – definitely room for improvement – but it works. Getting the rest of the day’s forecast is basically what I need.
In terms of sending the data back, I submit every 5 mins during daylight, as long as I know I’m getting max PV use. In my case, this is if I am in Bulk mode and the batteries are not yet charged – I know my batteries pull most of the current from the panels. Once I reach absorb or float I stop pushing updates, because I don’t want to “train” Solcast that I have less PV than what they predict. This is why my “actuals” on Solcast falls mid-day.
I have a sensor which averages the PV yield over the last 5 minutes:
##5 minute average for production
- platform: statistics
entity_id: sensor.victron_pv_power
name: pv_stats
max_age:
minutes: 5
Then I have this automation which actually submits (i.e. calls the service created by the restful component):
- alias: solcast-upload
trigger:
platform: time_pattern
minutes: /5
condition:
condition: and
conditions:
- condition: sun
before: sunset
before_offset: +00:30:00
- condition: sun
after: sunrise
after_offset: -00:30:00
- condition: state
entity_id: switch.force_charge
state: 'off'
- condition: state
entity_id: sensor.victron_inverter_state
state: Bulk
for:
minutes: 5
action:
service: rest_command.solcast_tune
Thank you very, very much @ebendl for the detailed info above. I just today managed to get it working, after half heartedly messing with it the last few weeks. Now to let it run for a bit and wait for the tuning to start working.
Just need to understand how to get from pv_stats to sensor.solcast_post.
I assume that’s building the json body that goes to the measurements endpoint, but I’m unclear on how to do that exactly.
Thanks, that actually also includes the /1000, which is needed if your modbus is reporting W, not kW (had to break out Postman to work out why nothing was going through…)
Been following this a bit - long shot but does anyone have a Node-Red flow working with Solcast? I have tried the one on discourse.nodered.org but with no luck.
Question: should the “discharging” state not also be included (as well as “bulk”), since the panels are also working as hard as they can in that state?
I find that ensures you submit measurements at less solar-optimal times, which will give a better tuning picture.
Unless I’m missing something?
Edit: Nevermind, I see that what VRM reports as “Discharging”, the modbus still reports as “Bulk”, so it’s all good.
For users of the Rooftop PV sites product, we will be decommissioning this endpoint for future commercial use. However, we will retain it for use by hobbyists for modelling and forecasting the power output of their home PV systems. Since we will be removing the PV Tuning capability, we are now providing hobbyists with the ability to add a second PV site at their home location, in order to handle split-array set-ups.
If you would like to activate a second PV site for your home, simply contact us using the ‘chat bubble’ at the bottom right of your screen with your request. Be sure to include the email address you are using for your API Toolkit account!
So am I correct that they’re removing the commercial Rooftop PV option altogether, except for the free hobby accounts? And in those instances we can get 2 sites?
Mmm, fine I guess. I wonder what will happen with all the tuning data that I’ve already sent through. It was definitely way more accurate than the original values I had on the website.
