Solar PV Monitoring/Automation Thread

Seems you need their docker unit to have Home Assistant OS otherwise its only the Core version.😕

This is what I have and is running.... but you cannot run anthing outside of it for example solismod on the same RPI as its a docker, this is the issue I am facing..... once I can figure this out I will be good to go.

Thanks :)

Oh this is interesting for me too, I think I'm in the same boat as scuzzie there, got my HA OS running a pi4 and then a pizero2 with raspbian that I use to execute pysolarman5 and mqtt on.

Would like to have it all run the pi4 but my python skills are close to 0 and I also hate linux 😂

Do you have the appdaemon stuff somewhere on github perhaps?

Is anyone using tesla-style-solar-power-card with Solarman.sensors in HA? if so could you share what have you got set to? i cannot get my head around what need to point to what and getting some very unrealistic numbers.

The following shows how to configure inverters (write holding registers) from Home Assistant using a custom AppDaemaon app, exposed as simple script in HA.

My own setup is on a Solis Hybrid 5G inverter, and its working well on that. It'd probably work for other setups too, but that hasn't been tried.

No coding knowledge should be required to get this running.

Prerequisites

• Have HA setup and be comfortable doing basic configuration/automation
• Have a file explorer/editor in HA (I use Visual Studio Code)
• Have AppDaemon (AD) installed in HA, and ideally a basic Hello World AD app working
• Know how to access the AppDeamon Web UI and look at logs (in case you need to do any debugging)

Setting up the App

• Extract the attached "apps.zip", and place the files your appdaemon->apps folder, preserving the folder hierarchy (note, if you already have your own apps, you'll need to merge apps.yaml)

• In the file inverter.py, change the INVERTER_IP and INVERTER_SERIAL to match yours
• Then, you need to tell it how to find the umodbus lib. Go to HA->Settings->Addons->Appdaemon->Configuration
• Add python packages "datetime" and "umodbus". It should look like this (ignore the mysql one, that's for a different app)

That should be the app all setup.

Calling the app

You can't easily call directly from HA to AD, so instead, we call a dummy script on the HA side, and listen for its invocation on the AD side. You could listen for any event; I'm using a script invocation event as it seems the most natural. To do it, put the following into your scripts.yaml

# ----------------------------------------------------------------------
# AppDaemon
# ----------------------------------------------------------------------
appdaemon_passthrough:
  alias: "AppDaemon Passthrough"
  sequence:
    delay:
      milliseconds: 1

inverter_write_holding_register:
  alias: "Inverter Write Holding Register"
  sequence:
    - service: script.appdaemon_passthrough
      data:
        action: inverter_write_holding_register
        register_addr: "{{ register_addr }}"
        register_value: "{{ register_value }}"

And that's everything done.

When calling this, you can ignore all the AppDaemon stuff, and the fact that its a dummy script. Just treat it as a regular HA script that you can call from buttons/scenes/automations. For instance to set holding register 43110 to value 33 at 8pm, you call it like this.

- alias: 'random test automation'
  trigger:
  - platform: time
    at: '20:00:00'
  condition: []
  action:
  - service: script.inverter_write_holding_register
    data:
      register_addr: 43110
      register_value: 33
  mode: single

Other Notes

In inverter.py there is a commented out line (line 21) which would verify registers and values being passed in. Recommend you uncomment this line and update _verify_safe_register to allow only the registers and values you plan on setting. This should help prevent mess-ups if you change a register by accident while testing your automations.

If does a lot of retries internally, but ultimately there is no guarantee it'll succeed. In my own experience, is has been solid; it has not failed since started using it a couple of months ago. You can verify by reading registers using solarman or SolisMod.

I use the passthrough script and ActionReceiver for a bunch of other actions, like updating a SQL DB when a user presses a button. So if you do have other random python tasks, you can expand on the actions you pass in. You can call the appdaemon_passthrough script directly (the inverter one is just a wrapper for convenience)

Thanks to @Jonathan for pysolarmanv5. It is included as source, grabbed from GitHub a couple of months ago. The only modification made was for logging.

Important: this is test code, provide as-is. It hasn't hadn't had any testing, and has only been run by a couple of people, so the usual disclaimers go with it. Writing to inverters changes stuff, so make sure you know what you are changing and are comfortable doing it (and backing yourself out of it in case of issues)

@connesha Great work, looks like it will do exactly what I want. Got an issue though. I believe I have followed everything you wrote but getting errors when trying to run a script. Any ideas?

Thanks. For some reason, the file was not saving when I was adjusting values. Restarted everything and now all sorted :)

# ----------------------------------------------------------------------
# AppDaemon
# ----------------------------------------------------------------------
appdaemon_passthrough:
  alias: "AppDaemon Passthrough"
  sequence:
    delay:
      milliseconds: 1

This goes into the scripts.yaml 👍

Almost Chris ;-). I added the wrapper/utility script inverter_write_holding_register after we set you up, so you may not have seen that before. It doesn't change anything in the operation of it, its just a trivial wrapper that makes it all a little more readable when you're making your automations.

So, all of this goes into your scripts.yaml @SD_DRACULA :

# ----------------------------------------------------------------------
# AppDaemon
# ----------------------------------------------------------------------
appdaemon_passthrough:
  alias: "AppDaemon Passthrough"
  sequence:
    delay:
      milliseconds: 1

inverter_write_holding_register:
  alias: "Inverter Write Holding Register"
  sequence:
    - service: script.appdaemon_passthrough
      data:
        action: inverter_write_holding_register
        register_addr: "{{ register_addr }}"
        register_value: "{{ register_value }}"

The first script (appdaemon_passthrough) is the generic dummy / no-op script that AD listens for. You could call this directly if you like, and pass in the "action" parameter as well as the 2 register ones. (this is what Chris is doing now, and I was doing at that time too)

The second script (inverter_write_holding_register) calls the first (appdaemon_passthrough) with a hard-coded action, and passes the 2 register parameters straight through as-is. It just means the caller (your automations) gets a nicer looking script with a specific name, and it sets the action so you don't have to.

Chris, if you want to update yours, you can do this: (this part applies only to IrishChris):

Add the inverter_write_holding_register script to your scripts.yaml

Then, anywhere you were calling this before:

 - service: script.appdaemon_passthrough
    data:
      action: inverter_write_holding_register
      register_addr: 43110
      register_value: 33

call this instead:

 - service: script.inverter_write_holding_register
    data:
      register_addr: 43110
      register_value: 33

There was no functional change since you got the drop a few weeks back IrishChris, so you don't need to do this, or update anything else; this is all just cosmetic. Great to hear its working well for you 👍️

Yesterday I have checked how my solar prediction worked over last 30 days and it looks pretty good. There are outliers but overall I am happy with it. It would be a bit more accurate if the prediction was done close to sunrise and also if I had not chimney shadow. In my case prediction is done at 2am since this is when automation kicks in. Automation checks prediction and then deciceds if battery should be charged and also how much.

There are three scenarios overnight

1. Discharge the battery charged via solar during the day (going 24hrs day after day on Solar generated power

2. Discharge during expensive units periods, and stop discharge and use the grid during the cheap period (generally when following day forecast poor during the summer)

3. Discharge during expensive units periods and use the grid to recharge the battery during the cheap period (generally all winter)

I use solcast as Forcast.Solar was way off. I still needed to tune it based on observations.

The only thing I might be doing differently is that I am using Backup mode for the battery, so I have that set to 15% which will power the backup supply in case of an outage and the lowest battery SOC is set to 10%.

Might be the reason for the 49 there?

I will go up and change it to the other settings and see what values comes in then.