Solar PV Monitoring/Automation Thread

I don’t remember the details, but the XML packs a few variables like cloudiness and radiation per sqm, which is a proxy for solar production. Like Brian I’m just taking 15% off that latter figure, but this certainly can be improved. I don’t want to start parametrizing the Met Eireann data because I prefer to model the raw data towards the end of the prediction model. I haven’t include a model yet because I only have a few weeks worth of data, but the next thing for me is to transform the best.guesstimate variable in a Bayesian model. It should be pretty straightforward with more data.

It shouldn't be. The model will be based on your data, not mine. For clarity, the dependent variable is actual production, which the model reads from your Solis (but it could be other brands of inverter), with the independent variables being the many forecasting services available, again queried with your data (lat, lon, slope, kwp, and orientation). My expectation is that the accuracy of the model will vary over the year, particularly as seasons change, so I'm guessing a temporal series of a few weeks may perform better than the annualized solar return. But I need more data to get to the point where it's fun to start looking into this.

i use the xml from met eireann as does connesha. Basically for every hour there's something like.....

<time datatype="forecast" from="2021-08-26T10:00:00Z" to="2021-08-26T10:00:00Z">
         <location altitude="28" latitude="53.0000" longitude="-9.0000">
            <temperature id="TTT" unit="celsius" value="19.1"/>
            <windDirection id="dd" deg="33.8" name="NE"/>
            <windSpeed id="ff" mps="2.3" beaufort="2" name="Svak vind"/>
            <globalRadiation value="448.2" unit="W/m^2"/>
            <humidity value="86.4" unit="percent"/>
            <pressure id="pr" unit="hPa" value="1025.7"/>
            <cloudiness id="NN" percent="11.7"/>
            <lowClouds id="LOW" percent="11.7"/>
            <mediumClouds id="MEDIUM" percent="0.0"/>
            <highClouds id="HIGH" percent="0.0"/>
            <dewpointTemperature id="TD" unit="celsius" value="17.0"/>
         </location>
      </time>

The way i did it was to add up all the "globalradiation values" for a day. Above you can see it's 448 watts for that hour. When you add all of them up you get a figure like 4604 (or something). You can then equate that back to the actual output that you did for that day, so you can generate say a 10 pt moving average of the number Kwhr produced / 1000. Then with tomorrows forecast you can equate that to a value. No mapping of angles, etc.

and from that you can see that it's (relatively) good.

We had a thread on this last year.

This should be a drop in to HA for overnight-charging a battery to a target battery SOC.

Its the same logic as the earlier post; but packaged as a script that should be easy to setup.

To use:

Put this into your scripts.yaml

inverter_set_energy_storage_mode:
  alias: "Inverter Set Energy Storage Mode"
  sequence:
    - service: script.inverter_write_holding_register
      data:
        register_addr: 43110
        register_value: "{{ storage_mode }}"

inverter_set_charge_current:
  alias: "Inverter Set Charge Current"
  sequence:
    - service: script.inverter_write_holding_register
      data:
        register_addr: 43141
        register_value: "{{ current_da }}"


set_night_charge:
  alias: "Set Night Charge"
  icon: mdi:flash
  variables:
    charge_voltage: 53
    charge_hours: 9
    night_usage_wh: 3000
    battery_capacity_wh: 20000
    lower_soc_limit: 20
    now_soc: "{{ states('sensor.battery_soc') }}"
    target_soc: "{{ states('input_number.target_soc') }}"
    soc_to_wh: "{{ (battery_capacity_wh / 100) | int }}"
    now_battery_usable_wh: "{{ ((now_soc - lower_soc_limit) * soc_to_wh) | int }}"
    target_battery_usable_wh: "{{ ((target_soc - lower_soc_limit) * soc_to_wh )| int }}"
    energy_storage_mode: >-
      {% if (now_battery_usable_wh - night_usage_wh) > target_battery_usable_wh and is_state('input_boolean.force_always_charge', 'off') %}
        33
      {% else %}
        35
      {% endif %}
    charge_needed_wh: "{{ target_battery_usable_wh - (now_battery_usable_wh) }}"
    current_needed_a: "{{ ((charge_needed_wh/charge_hours) / charge_voltage) }}"
    current_needed_deci_amps: >-
      {% if current_needed_a < 0.1 %}
        0
      {% elif current_needed_a > 100 %}
        1000
      {% else %}
        {{ (current_needed_a * 10 ) | int }}
      {% endif %}
  sequence:
    - service: script.inverter_set_energy_storage_mode
      data:
        storage_mode: "{{ energy_storage_mode }}"
    - delay:
        seconds: 30
    - service: script.inverter_set_charge_current
      data:
        current_da: "{{ current_needed_deci_amps }}"

Change:

• charge_hours to how long you are charging for in hours
• night_usage_wh to how many watt hours you generally use during this time (ideally how many watt hours get discharged from your battery during this time)
• battery_capacity_wh to your battery capacity, in watt hours. (5kwh would be 5000)
• lower_soc_limit: how low do you let your battery go (most common is 20%)
• if your storage mode register values are not 33 and 35, then change them

Create an input_number:

  target_soc:
    name: Target SOC
    min: 40
    max: 100
    step: 5
    initial: 50

Create an input_boolean:

  force_always_charge:
    name: Force Always Charge

Manually set the charge times on the inverter and leave them set.

Call script.set_night_charge from an automation, ideally a couple of minutes before your charge window starts.

This script will try to charge your battery to close to the target_soc level by the end of the charge window. (Note: it will not be exact, but should come reasonably close. You can vary the charge voltage to adjust if yours behaves differently)

It will set the registers on the inverter to enable/disable charge, and to set the charge current.

If there is enough battery to last until morning, it will discharge over night. You can override this behaviour by setting force_always_charge to On: this means that it'll "charge" at 0A even if there is sufficient battery, so that it does not allow discharge overnight. (useful if you want to run heavy loads at night and not use battery)

You can vary the target_soc by changing the input_number.target_soc (recommend putting this in your UI as a slider, as well as input_boolean.force_always_charge)

If you want to link it to a solar forecast, the easiest way will be to have the solar forecast update input_number.target_soc (so no change is required in the script)

Good luck!

Disclaimer: This hasn't been tested, and its not what I'm using myself, so try it out first.

Thanks for these, will get them in there.

Yes I have 49/51, it's basically toggling between Backup mode and Self Use.

What's 96 for?

Yea, mine is quite similar. Probably the main difference is that I try to use a selection of the "most similar days to today" from the recent period for the calculation (where the size of the "recent period" varies according to the time of the year). This is the thread, and a link to the reasoning behind it: #64

Here is how it has worked since spring:

Its been very successful in automating night-time battery charging; almost all electricity purchased has cost 5.7 cents (between 2am and 5am, on BG EV smart plan)

And just out if interest, I started tracking Forecast.solar at some point for comparison purposes (its not used in any calculation anywhere), see it in the blue... (its rubbish... completely unusable...)

The hourly radiation levels are also useful to track. Here is a screenshot from HA:

At a glance, it can tell:

• whats it like now (the vertical red dotted line is "now")
• what time of the day, roughly, will there be higher radiation (and hence higher generation). On bad days like last Sunday, the line never want above 100...
• how does the met.ie forecast from 1:45AM this morning (that we used for charging automation) compare to now (the solid line is the level locked in at 1:45AM forecast time, and the dotted line is updated from met.ie every 10 minutes). When the solar forecast is out, you'll most often see a deviation between solid and dotted line

Also, for automating night time charging, it allows a few more conditions to be covered, especially this time of year. For instance, yesterday, the forecast was more than we needed for the day. BUT the generation started a little late. So, morning time would not have been covered.

So, the charge automation has a second condition:

It looks for the hour that "real generation" starts, and if the battery has not got enough to get to that time (regardless of total daily generation), it tops up the battery enough to get there. Specifically, it looks for the first hour where radiation is over 50. It makes sure that the battery has base_load * hours to get there. AND, if that hour is 8am or later, then add a bit extra (i.e. add a bit extra for breakfast)

I think there's something up with my HA Energy dashboard config 😁

Got the Solarman linked up and the data looks fine in the individual entities.

Started out like this after dashboard config, then I had a couple of days where the values were ok and now they've reverted to crazy numbers.

🤣 .

@unkel what are you planning on mining now that ETH is ded?

You must have a massive gaff :) Take it you mean based on your gaff, if scaled to X houses it would have prevented about a million liters of gas being burnt this winter.

Tbh it makes sense to use heat from one thing to heat the living space. So in a well insulated house (not ours) the dishwasher is a kitchen radiator. Time it to be nearly finished when you get up in the morning and room would be warmer. Same for clothes dryer if used. If the primary purpose of the mining rig is heating (I guess it is now while it seems mining profits are low) using largely renewable sources, and 2nd purpose is to make a few quid - I'm good with that.

I never thought of that......going to change my habit there instead of launching at 00:05, to launch at 07:00 (takes about 2 hrs for a wash/dish cycle). Makes sense that the heat losses go into the kitchen especially for the dish washer, instead of being "lost" at 2am.

It's the little things.

Holy Cow, I had no idea that 22000kWh = 2000m3 = 2 million liters. I thought you had a typo!! That save a 'million liters of gas per house' should be the marketing campaign to get us all weaned off gas so we all firstly realise the volumes per house. Because it's piped we never see the volume. Maybe if I had gas tanks, likes places that don't have mains gas, I'd see it differently.

All setup and working now. Cheers for that! what would be the best way to handle setting the attributes on the new entities (UOM,unique id, device class) and also rounding. They're pretty raw. I tried to figure out how to set it in the meteireann_solarforecast.py script but couldn't get it to work.

The alternative I was thinking is to pull out the calculation and just bring in the radiation totals and use those in template sensors to format etc. Also leaves room for ease of adding a variable in the formula. 🤔

In other news - my feed-in priority switch is now setup and working. The value is 112 on mine which was confirmed by making the change on the inverter itself and checking.

Here's my YAML for the automation. Everything is manual for now. I'll get to automation later when I'm happy with the forecasting setup.

alias: Solis Grid Feed-in Priority
description: ""
trigger:
  - platform: state
    entity_id:
      - input_boolean.solis_grid_feed_in_priority
    id: "on"
    to: "on"
  - platform: state
    entity_id:
      - input_boolean.solis_grid_feed_in_priority
    id: "off"
    to: "off"
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id: "on"
        sequence:
          - service: script.inverter_write_holding_register
            data:
              register_addr: 43110
              register_value: 112
      - conditions:
          - condition: trigger
            id: "off"
        sequence:
          - service: script.inverter_write_holding_register
            data:
              register_addr: 43110
              register_value: 49
    default: []
mode: single