Site-level peak attributes

[gcoan]

Is your feature request related to a problem? Please describe. I don't even know if this data is possible and available from Solcast, but thought I'd ask as I have a specific problem.

I have two sites setup in Solcast, one East facing and one West facing (a good long solar day). The East facing array I can experience solar clipping on as the array is larger than my inverter AC capacity (but smaller than the DC capacity). If I know this is going to happen I can either discharge the battery a bit so the inverter charges the battery as well as exporting max AC, or I can slow the battery charge rate that morning for the same effect.

However at the moment I can't work this out from Solcast as I only have peak solar generation and peak generation time for the entire Solcast account.

Describe the solution you'd like My request therefore is to add attributes to the existing sensors (if available in the Solcast data set) for per-site peak time and per-site peak generation (today and tomorrow).

It may be worth considering what other per-site data is useful to expose in this way.

Describe alternatives you've considered Introduce brand new sensors for this data - not really necessary given it's an edge case for many people. Make some kind of manual calculation of this data based on what is available in the solcast entities - possible but unlikely to be accurate. Use a different solar forecast for this - adds duplication.

Additional context (My problem is even more convoluted by having three arrays, one on the East, one on the West, and one with one string on each side, but I can pro-rata the East array peak output to see if it will exceed my inverter capacity)

Solcast website shows individual sites and the peak for East is about 11am, and likely to exceed my 5kW inverter. West peak is about 4pm.

Energy dashboard shows the combined peak around lunchtime

[autoSteve]

The data is there.

The integration has forecasts for each site, and builds a totals dictionary as a summation of the individual sites. The existing sensors get the peak W and time from the summation.

[autoSteve]

Geoffrey, check out https://github.com/autoSteve/ha-solcast-solar.

v4.0.34.1 adds the site detail as an attribute, named as the site resource ID.

[autoSteve]

Or cherry pick coordinator.py and solcastapi.py from the draft PR, and replace those files. To revert, just re-download 4.0.34.

[gcoan]

I'm not seeing this version as an option on HACS. I did update information but I only see 4.0.34 not .1 as a version

I'll just try downloading the specific changed files manually

[gcoan]

Thanks @autoSteve. Github is a pain trying to pull files from a PR. Had to view each file in turn then download it as I couldn't find any way to get them otherwise.

Anyway, brilliant feature. I would get the resource id attribute from sensor.SITENAME and then match that to the appropriate attribute in the peak time/power today/tomorrow

One issue, it appears that one of the resource ids is being capitalised and doesn't match the sensor.SITENAME:

The second seems OK, just the first.

One question, the power is being output in Watts. Does the site attributes respect the unit of measurement set on the peak today/tomorrow sensor? Reason I ask (and have found other HA controls/integrations) that haven't been coded to properly recognise this. I have changed all of the energy sensors I use (battery SoC, solar power output, import/export power & energy, etc) from W to kW UOM. Just because I find it a lot easier to read dashboards of kW than W. The solcast peak sensors I have never used up to now so are defaulting to W, but if I change the UoM to kW, will the attributes follow?

61kW exported today :-)

Cheers!

[autoSteve]

I'm not seeing this version as an option on HACS

You needed to change Github repo to autoSteve. Don't bother with that. Just use the files that you've now successfully grabbed, as that makes for easier reversion to 4.0.34 if needed.

is being capitalised

HA is doing that, not me. It's a display thing. The actual value is all lowercase.

UoM

Make it whatever you want! The raw values as seen in Developer Tools happen to be Watts, but attributes are just numbers. Make a template sensor in configuration.yaml to pull the attribute values out using a value template, and put units/etc. in there to define it. Without doing that they're just numbers. Or use the attribute numbers directly in automations.

Something like

template:
  - sensor:
    - name: "West array peak today"
      unit_of_measurement: "W"
      state: "{{ state_attr('sensor.solcast_pv_forecast_peak_forecast_today', 'b68d-c05a-c2b3-2cf9') }}"

If you want kW? Divide the number by 1000 and change the UoM... After all, it's just a number.

I see where where you're coming from with attributes not following the sensor for unit of measurement, though. That will happen in this case. Do you have an example of an integration where the attributes do follow the primary sensor value? Maybe there's more work to be done... but I can't see how this could be a thing. If these were separate sensors, yes, and it wouldn't be an issue, but we don't want to go the sensor bloat route.

[autoSteve]

With the performance optimisations that @isorin did these peak forecasts get updated at each successful forecast retrieval, and so too the attributes.

[gcoan]

Thanks for clarifying that the capitalisation is just a HA display thing.

but attributes are just numbers. Make a template sensor in configuration.yaml to pull the attribute values out using a value template, and put units/etc. in there to define it.

I know I can just force the attribute from a string to an int and multiply it by the appropriate value to get to W or kW as appropriate, my argument though (petty though it may be) is that the UOM of the sensor and the sensor attributes should be consistent and should follow whatever the attribute UOM is defined as in HA. Me adding *1000's to my code is just a bad hard coding workaround.

I see where where you're coming from with attributes not following the sensor for unit of measurement, though. That will happen in this case.

I tried changing the UOM, and it doesn't recalculate the attributes. TBH I didn't expect it would automatically.

Will it recalculate the attributes with the right UOM at the next Solcast poll?

[autoSteve]

at the next Solcast poll?

It will not. They're just numbers as attributes, which is why separate sensors would be just better. But I'm not going there.

To do so would be fine, I guess, but the knock-on effect is needing language translations for the sensors, increased testing, plus adding to 'sensor bloat'. This way is simple to address a corner case.

I honestly don't know what the solution here should be for values added as attributes.

The answer is probably, "Yeah. The value is in Watts. Embrace it, don't display it, use it as is and you'll be okay."

On a side note, I'm internally grumpy because it's Winter here. And I'm grumpy because you're generating power and I'm not. And I'm grumpy that I'm not currently in Majorca. And I am grumpy because I had to charge my batteries from grid yesterday just to last through peak. I gwumpy. 😖

Phew. Glad that's off my back...

[autoSteve]

the UOM of the sensor and the sensor attributes should be consistent

I have to pull you up on this.

Nope.

The sensor has a UoM, because this is an attribute. Attributes have nothing but themselves. An attribute of a sensor is "unit_of_measurement". Another is "friendly_name". Does "friendly_name" obey the unit of measurement? Nope.

So in this instance I have just created another one named after the resource ID. The sensor and its attributes are as one, but attributes are just attributes of the sensor.

[autoSteve]

(Tokyo booked for a defrost. Not Majorca, damn it.)

[autoSteve]

Geoff, this evening was filled with trying to get a template sensor that uses the published attribute to follow the unit of measurement for the main sensor.

HA is not designed to allow a "dynamic" unit of measurement from what I can gather, so I have failed. It seemingly can't be done in a template.

It is what it is.

Create a template sensor, and convert the raw value to the unit of measurement desired using division. Set the unit_of_measurement to match. Or just use the raw "W" number in an automation.

[gcoan]

Thank you for trying Steve, I will have to live with it 😢

[gcoan]

Created a pair of today/tomorrow template sensors to give me what I wanted, the forecast peak for my inverter 1 which is 6,2kW (16 panels) on a 5kW inverter and is the one that is liable to inverter clipping on sunny days.

There's 22 panels in total on the East side, but the other 6 are a string on inverter 2 which isn't at risk of clipping.

So hence the pro-rata, and I can now write an automation to ensure there is space in the battery for trickle charging when there is a forecast risk of clipping

{{ (state_attr('sensor.solcast_pv_peak_forecast_today', 'bc31-4d4c-e844-6a4e') | int(0)*16/22) | int }}

[autoSteve]

So that is a confirmed kill, I take it? Nailed? It is PR'd awaiting @BJReplay... 😬

[gcoan]

Yep, a useful addition to Solcast functionality, thanks

[autoSteve]

Merged.

[gcoan]

It's a useful addition to Solcast as I said thanks @autoSteve, but seeing this in action it may not be as useful in predicting solar clipping as I hoped it would be ☹️

Over a day I pretty consistently don't achieve the Solcast PV 50% prediction, its usually around 30% of the way between the PV10 and PV50, which is fine, I use a weighted average of the two in Predbat to manage my battery activity.

Today's peak Solcast forecast for my East facing site is 4244W. My lovely new template sensor therefore has inverter 1 (16 out of 22 East facing panels) at 3086W.

Inverter limit 5kW AC so should be no risk of clipping today.

But the sun has other ideas, I've seen peaks over 5kW already today and in the time I've written this comment the power output has swung between 2.8 and 5.3kW:

Appreciate its only a prediction and there's lots of variables at play but seems I will have to add a healthy buffer figure to the site level peak forecast to determine if clipping will occur or not. Hey ho

[autoSteve]

Sounds like you need a psychic, and not a forecast. 😂

That looks like there's fluffy white stuff in the sky. On clear days here, as others have noted, and I'm sure you've witnessed, the forecast peak should be pretty good. Less clipping moments on a partly cloudy day, too.