What's a Watt or a Watt-hour?

[autoSteve]

These sensors (excepting the datetime ones)...

It is my reasoning that these are actually Watt-hour measures, and not Watt. They represent power over time. Energy.

[dtswk]

It's a tough one.. I think Solcast is intending it to be a snapshot at a point in time, but it's then most of us translate that to an average over the duration in order to get a forecast of power kWh. I know that translating a snapshop reading into an average over the duration is flawed.. but all forecasts are flawed... argghhh. Personally the snapshot of kW serves little value and the kWh representing the energy is what I think it most of us expect / need. (even if "munged") . I'm a Wh voter.

PS I love the level of thinking, questioning and dilligence, this is my first really active open source exposure and it's bloody awesome.

[autoSteve]

Then select "Yes, definitely!" and click the 'vote' button!

[ProphetOfDoom]

If someone can explain how they are calculated/derived from the raw forecast data (which I believe the api result approximates to a power (kW) value for each 30 min period), then I'll throw my hat in the ring. I do recall that the 30 min periods gave Oziee high blood pressure when people kept saying (wrongly) that the energy values were half what they should be! (A 3kW heater uses 1.5kWh in 30 mins, not 3kWh!)

[dtswk]

Watt is a measure of the instantaneous power needed and Watt hours tells you the energy over time.

So if you have a heater they cycle on and off as they reach temp. So depending on when you measure it might be 2400w, 1200w, 100w. Over the hour thought it needed 800wh total energy to run.

In our case the number from solcast is what the panels are expect to generate at that point. BUT if we translate that roughly to wh over an hour you can't add the two as they are half hourly. Essentially you need to divide by the number of samples in the hour to get back to approx hourly energy.

10kw array
Reading 1 11am is 8kw, reading 2 11.30am is 7kw
Because you are trying to get an approx over an hour you need to add them together and then halve as you have two samples for the hour. If you had 15 minutes samples you would quarter, minutes samples divide by 60 etc

Hope that helps.

Warning, none of that is a good representation as you know the solar fluctuates hugely through the period. That's why on bad days I used the P10 forecast to be conservative, usually we exceed but being offgrid I don't want to risk it.

[gcoan]

I have voted, but from the screenshot above I feel that power now/power next 30/power next hour should be candidates for change.

Peak forecast today I suggest remains at W regardless as it is clear it is a peak power rating at a specific point in time within a time period and is therefore an instantaneous power rating, not a measure of power over a time period.

[isorin]

All these should measure instant power. So, in my opinion: "W" or "kW" is fine for them.
Power now/In next 30 mins - is still peak power (well, as much as we can get from the 30 minutes intervals)

What I think we need to update is the name and description of the "power now" / "power in 30 minutes" etc.
The name should be "Power in 30 minutes" not "Power Next 30 minutes" and the description should be something like "Expected forecast power in 30 minutes"

Also, as a rule, I think we've used:

• W, Wh for all instant / hourly values
• kW, kWh for all daily values

[isorin]

@autoSteve:
I still think it has the characteristic of power, even if it's average power for each 30 minutes interval.

Let's say pv_estimate = 5 for a specific 30 minutes interval (this is what we get from Solcast)
In the middle of that interval, "power_now" will report 5000W. (I say in the middle as towards the beginning/end of the interval it will interpolate with the adjacent intervals)
If we want to report the energy for that 30 minutes interval (in Wh) that would be 2500Wh (which means 5000W for 30 minutes).

So, if we want to change it to "Wh" then we need to update the calculations for solcastapi.get_power_n_mins() and divide it by 2.

I think because the sensors have "power" in their name that they should report the nominal power. (as they currently do)

[isorin]

@ProphetOfDoom I think you got it right! 😄

[ProphetOfDoom]

@isorin This is reminiscent of a series of issues/discussions that Oziee repeatedly tore his hair out over, lol. If the entity was actually an energy value, it would represent the area under each 30 min interval, which I don't believe it does. Opinions welcome.

[dtswk]

The raw data from solcast Idefinately isn't Wh , is the expected w from the panels at that time. We however need to translate that into kWh to be useful. So....

https://solcast.com/rooftop-pv-power-model

[ProphetOfDoom]

If you use a browser to grab the Solcast data for one of your roofs (see recent post on discussion #77) you can use an online JSON to Excel converter and then create a line chart from it to compare with the power chart on the Solcast site, which again shows that the raw values are in kW

[autoSteve]

I do believe the floor has spoken, and that this poll is off the mark. Thank you for those who know what they're talking about 'speaking' up.

IT IS WATTS FOR THE WIN, despite the actual poll result.

I have been schooled, and am now a slightly smarter human being. Yes, the descriptions of the sensors might be a bit lacking, but the data is the data. I eagerly await PRs for better descriptions in the readme, or maybe even a topic in the troubleshooting FAQ #38. Go on. I dare you.

(Ripper drawing, @ProphetOfDoom. Include it in the FAQ. 🤣)

Closing.

[ProphetOfDoom]

@autoSteve How's this! I've taken a screenshot of my predicted solar generation from the Solcast web site, and overlaid that with an Excel staircase chart generated from the corresponding API data obtained via http, lined them up best I can, and added some text callouts to explain what each component is. Boy, what a faff getting Excel to do a staircase chart from DateTime series data!

The 10% and 90% predictions seem counterintuitive to me, but that's what the API data seems to suggest (unless Solcast have got it wrong), so it would be good to have independent confirmation. Hope you like it - all comments and suggestions welcome.

[gcoan]

I've got a PR for the readme that adds an explanation of some of the core concepts of Solcast - estimate 10, 50, 90, sites, etc that would usefully go alongside this

https://github.com/gcoan/ha-solcast-solar/blob/v3/README.md

I just need to add a sample PV chart to it but forgot to screen shot it yesterday so will try again today

[autoSteve]

I like it a lot, @ProphetOfDoom. I'll drop it and a description of the Wattage vs. Watt-hour sensors in an FAQ topic, crediting you, of course.

[autoSteve]

Nice, @gcoan. Some suggested edits?

Solcast will produce a forecast of your solar PV generation for today, tomorrow, the day after (day 3), ... up to day 7. Each of these daily forecasts will be in a separate sensor (see below) and the sensor value will be the total predicted solar generation for your Solcast account >for each day<. Separate sensors contain peak solar generation power, peak solar generation time, and various forecasts of next hour, 30 minutes, etc.

If you have multiple arrays on different roof orientations, these can be configured in Solcast as separate 'sites' >with differing azimuth, tilt and generation<, to a maximum of two >sites for a hobbyist account<.

Three solar PV generation estimates are produced by the Solcast integration , the :

• 'central' or 50% or most likely to occur PV forecast , >(or the forecast)<
• '10%' or 1 in 10 'worst case' PV forecast assuming more cloud coverage , and >(forecast10)<
• '90%' or 1 in 10 'best case' PV forecast assuming less cloud coverage . >(forecast90)<

>The detail of < these different forecast estimates can be found in the sensor attributes, broken down by 30 minute >and hourly< slots >intervals< across the day. Separate attributes sum the different estimates for the >each< day.

[gcoan]

Done, all incorporated.