Solaredge Modbus Configuration for Single Inverter and Battery

[WillCodeForCats]

@shoei600

Could your modbus module (or does it) have a relay function to make all SE values received available to EVCC or other app? Perhaps Modbus to MQTT or is there another way I should be looking at this?

No, it does not have a proxy function and I would not add one since there is at least one modbus proxy addons available that can do it. I don’t use any proxy personally so I can’t remember the name of the proxy addon I’ve seen before.

The solaredge-modbus-multi integration can coexist with other things that access an inverter over modbus as long as the following conditions are met:

• The modbus connection is not held open by any other program accessing the inverter.
• The integration polling time is greater than 10 seconds.
• The “keep connection open” integration option is disabled.

When I’m doing development work I usually have 3 copies of solaredge-modbus-multi accessing the same inverter (1 on my home system and 2 virtual machines for dev/test work) and they coexist with minimal connection collisions which it handles with retries. But it’s the first condition that other programs fail since they take over the connection and don’t release it between polling cycles. When configured with a polling interval greater than 10 seconds and the keep connection open option disabled, solaredge-modbus-multi will release the modbus connection every time it finishes a polling cycle.

[stickybyte (Marcel)]

OK, i figured out, that I have to use the default “Energy” Dashboard too.
So are these the correct values?
How can I hide the default Energy Dashboard from the menu?

[uhae]

First of all: Thank you @WillCodeForCats and @Remko for your excellent work!

I’ve been running this setup for a few months now and it is really making life easier

However, I’ve been experiencing an unusual behavior of the sensor “solar_exported_power_yearly” recently: On Sept. 30 at 12:00 am (beginning of day), the sensor dropped to zero. The “weekly” and “monthly” sensors stayed at their expected levels.

Is this intended behavior or a bug?

Thanks and keep up the good work!

[WillCodeForCats]

Utility Meter helper does have a reset cycle option, so that can happen if it’s set to do that.

[uhae]

I just checked the configuration and the reset cycle option is not set.
It’s not a bifgdeal and I’ll try to investigate further once I have time for it.
I just wanted to check if anyone else is experiencing similar issues.

[Schlichi83]

Hi shoei600,

I have the same setup as you and I’m using the modbus-proxy Addon and it works perfectly.

The modbus-proxy connects to the SE inverter and both, Home Assistant and EVCC, connect to the modbus-proxy.

Here is a thread, that discusses this solution (although in German):

Koexistenz HA und evcc

Hallo in die Runde, (english below) ich suche nach der besten Möglichkeit, beide Systeme zu nutzen. Das Problem stellt mein Wechselrichter dar, den möchte ich per Modbus TCP auslesen, aber es geht halt nur ein Client und ich bräuchte für beide eine Verbindung. Ich habe EVCC am laufen, das funktioniert auch soweit, wenn EVCC die alleinige Verbindung zum Wechslerichter hat. Das ggleiche betrifft HA. Ich habe dort ein schönes Dashboard eingerichtet, dass mir alles Wissenswerte anzeigt. Prinzipiel…

[shoei600]

Good advice, thank you. I’ll try some things.

[shoei600]

Is there a method to change the target IP address for SolarEdge Modbus to the new proxy without deleting and reinstalling please? I have searched the file directory and can’t seem to find any files with current IP address. It’s been working so well I’m reluctant to delete and reinstall in case the variables change or do not match as the same afterwards. when I hit ‘configure’ it skips the step for the IP address.
Thanks.

[WillCodeForCats]

The integration will raise a repair issue asking you to verify connection settings if it can’t connect.

If you want to do this proactively, break the network connection to your inverter (unplug its network or turn it off) and wait for the repair issue to appear.

[jayjay1]

Hi @uhae, I had the same issue at the same time and I just figured out why: there is a cron in the file energy_utilities.yaml

# Electricity Export
  solar_exported_power_yearly:
    source: sensor.solar_exported_power_kwh
    name: Solar Exported Power Yearly
    cron: "0 0 30 9 *"

[Schlichi83]

Hello you all,

Winter is coming and my battery storage (BYD) will probably very often not charge that much during the day (due to my heatpump). So I’m asking myself if there might be a configure the setup, so the battery doesn’t discharge below 30 or 40%. Because otherwise it will always charge a little and discharge a few minutes later back to the minimum (10%). This can’t be good for the battery.

Is there a way to change this?
And is there a way to reduce the maximum discharge permanently (or at least longer than for an hour)?

[P6Dave (Dave Forrester)]

@Schlichi83

And is there a way to reduce the maximum discharge permanently (or at least longer than for an hour)?

I don’t know if the storage modes are the same for BYD batteries, but if they are, an automation that triggers when the numeric state of the battery is below 40 (or 30 if you prefer) then sets the storage mode to solar only, effectively turning off the battery, would achieve what you want. For an hour long time period, the same numeric state trigger could also start a 1 hour timer. When that timer ends, that triggers the storage mode back to MSC.

Something like:

trigger: 
  - platform: numeric_state
    entity_id: sensor.your_battery_state_of_charge
    below: 40
    id: Stop 
 - platform: event
   event_type: timer.finished
   event_data:
      entity_id: timer.your_one_hour_timer
    id: Go
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
             id: Stop
        sequence:
          - service: timer.start
            data: {}
            target:
              entity_id: timer.your_one_hour_timer
          - service: select.select_option
            data:
              option: Solar Power Only (Off)
            target:
              entity_id: select.solaredge_i1_storage_command_mode
      - conditions:
          - condition: trigger
            id: Go
        sequence:
          - service: select.select_option
            data:
              option: Maximize Self Consumption
            target:
              entity_id: select.solaredge_i1_storage_command_mode

You’ll also need to:

A: Make sure you put your own entity_ids in the relevant places.

B: Create a timer helper for the one hour countdown. Whatever you call that helper is the entity_id you put in the timer.your_one_hour_timer

If you want to turn the battery off for longer than one hour just set the timer helper for a longer period.

You might also want to consider preventing this automation from running under certain conditions etc.

I’ll leave that to you to determine.

One final thing to consider is the storage_command_timeout value. It defaults to 3600 secs, or 1 hour. So if your storage_default_mode is MSC and this automation changes the storage_command_mode to Solar Power Only (Off), after 3600 secs, or 1 hour, it will revert back to MSC no matter how long you set the timer for. So if you want to turn the battery off for longer than 1 hour, you would either have to also set the storage_command_timeout value to a higher number, or instead of changing the storage_command_mode change the storage_default_mode to Solar Power Only (Off).

Hope that makes sense.

[Schlichi83]

THANK you very much! You made me thinking and I did the following:

I created a helper called “Winter-Mode”

And I created two automations:

alias: Wintermodus Batterie - Timeout auf 24h
description: ""
trigger:
  - platform: time_pattern
    hours: /1
condition:
  - condition: state
    entity_id: input_boolean.wintermodus_batterie
    state: "on"
action:
  - service: script.solaredge_timeout_24h
    data: {}
mode: single

That runs a script that sets the timeout to 24h, if winter mode is on.

And I created a second automation:

alias: Wintermodus Batterie - Moduswechsel
description: ""
trigger:
  - platform: time_pattern
    minutes: /1
condition:
  - condition: state
    entity_id: input_boolean.wintermodus_batterie
    state: "on"
    for:
      hours: 0
      minutes: 0
      seconds: 0
  - condition: state
    entity_id: select.solaredge_i1_storage_control_mode
    state: Remote Control
action:
  - if:
      - condition: numeric_state
        entity_id: sensor.power_solar_generation
        above: sensor.power_consumption
      - condition: state
        entity_id: select.solaredge_i1_storage_command_mode
        state: Solar Power Only (Off)
        for:
          hours: 0
          minutes: 0
          seconds: 0
    then:
      - device_id: REMOVED
        domain: select
        entity_id: REMOVED
        type: select_option
        option: Maximize Self Consumption
  - if:
      - condition: numeric_state
        entity_id: sensor.power_solar_generation
        below: sensor.power_consumption
      - condition: state
        entity_id: select.solaredge_i1_storage_command_mode
        state: Maximize Self Consumption
        for:
          hours: 0
          minutes: 0
          seconds: 0
      - condition: numeric_state
        entity_id: sensor.solaredge_b1_state_of_energy
        below: 40
    then:
      - device_id: REMOVED
        domain: select
        entity_id: REMOVED
        type: select_option
        option: Solar Power Only (Off)
mode: single

This does the following:

EVERY minute it checks the following:

• Condition: Winter Mode is On
• Condition: SolarEdge Storage Control is in Remote Control Mode

ACTION:
IF
the solar panels produce more energy than the house consumpts
AND
the Storage Command Mode is currently in “Solar Power Only (Off)” mode
THEN
switch to “Maximize Self Consumption Mode”

but
IF
the solar panels produce less then the house consumes
AND
the Storage Mode is currently set to Maximize Self Consumption
AND
the State of Energy of the Battery is below 40%
THEN
The Storage Command Mode is set to “Solar Power Only (Off)”

I think this should work, right?

[P6Dave (Dave Forrester)]

I’m just working though that first automation:

So every hour, if “Winter Mode” is on, run a script that sets the timeout value to 24h?

Why every hour? You only need to set the timeout once before you change the storage command mode for it to work. Resetting it every hour may cause issues. In my experience, the system doesn’t like it and will do some weird things. It’s almost like the system wants or needs the timeout to return to the default regularly.

So in it’s current form, here’s what will happen: -

Every time your second automation changes the storage command mode, and that could be every minute, the system will start the timeout counting down from whatever value it is set at, in this case, 24hrs. My understanding of the system is that the timeout value is set in one register and held there. The actual countdown involves the transfer of the value in the timeout register into a counter that counts down. That happens when the storage command mode changes. The fact that the timeout value is held in a separate register allows the system to always be able to check what the value is set to before it starts the countdown. It doesn’t continue from where it left off last time it ran.

Remember, that’s my understanding of how it works. I’m an electrical/electronics engineer, but I didn’t design the SE system. There are probably many ways of running a countdown system that I haven’t even heard of.

Anyway, if we go on the premis that my understanding is correct, I would set the timeout to max once every day and then check the history after a couple of days to see what it’s actually doing. You might have to adjust the frequency to every 12 hours if it starts acting strangely, but once every 24 hours should do it. I know at least one other SE system user who holds his system’s timeout at 24 hours. I’m not sure how he does it, or how often he changes his system’s storage command mode, but it works for him.

In your second automation:

The condition to check the storage control mode is “Remote Control” is probably not needed. I leave my system in “Remote Control” all the time and it never changes. Why would you need to check it?

Additionally, you could potentially have the storage command mode changing every minute if conditions are such that supply and consumption levels flip every minute when the battery is below 40%. In my opinion, that’s probably not good for your system and could be problematic.

That said, you’ve created quite an adventurous automation. I’d be interested to see how/if it works as expected. My guess is that the timeout may be an issue and the storage command mode potentially flipping every minute might also be an issue.

I think all you can do is run it and see how it goes.

[Schlichi83]

First of all - THANK YOU very much, for thinking my automations through and for your valuable hints and advice.

I changed the first script to every 12 hours. But are you certain, that running the script really resets the countdown? Because regularly is set to 24h before and it’s still 24h after. So I assumed it doesn’t change. I also built the following automation to have a viewable timer (countdown) and it doesn’t get reset, when the script is being launched, when the timeout was already set to 24h before:

alias: Set Timeout Timer
description: ""
trigger:
  - platform: state
    entity_id:
      - number.solaredge_i1_storage_command_timeout
  - platform: state
    entity_id:
      - number.solaredge_i1_storage_discharge_limit
  - platform: state
    entity_id:
      - select.solaredge_i1_storage_command_mode
  - platform: state
    entity_id:
      - number.solaredge_i1_storage_charge_limit
condition: []
action:
  - service: timer.start
    data:
      duration: "{{states('number.solaredge_i1_storage_command_timeout') }}"
    target:
      entity_id: timer.solaredge_timeout_timer
mode: single

But I changed it to 12h anyway, because the only reason I set it to 1h was, so that when I activate Winter Mode, the timeout is being set to 24h more quickly. But of course you could also achieve that by simply making another automation, that sets it to 24h the moment you activate Winter Mode, right?

Now to the second automation:
The reason I have “Remote Control” as a condition is due to my Energy Dashboard:

When winter mode is off, you can manually change the timeout and see a timer:

In Auto-Mode the System is set to the Default Mode, in Manual Mode to Remote Control. You can only activate Winter Mode in the Manual Setting. However, the helper of course could be active even though you can’t see the switch. By making it necessary, that Remote Control is active, I make sure, that nothing runs in the background when it’s set to “Auto-Mode”. At least that was my thinking. On the other hand, when the system is not set to Remote Control, all the other things (changing timeout, changing storage command mode) wouldn’t work anyway. But it doesn’t do any harm, doing it this way, right?

About the switching every minunte:
YES - that is what was actually happening this morning. What do you think could happen?
And do you have ANY other idea, how to achieve what I want? The easiest way would be an option in the SolarEdge system, to set the minimum battery level up from 10% to 30 or 40%. Some other systems seem to offer this option.

[P6Dave (Dave Forrester)]

@Schlichi83

But are you certain, that running the script really resets the countdown?

Okay, perhaps I wasn’t clear. Running the script every hour doesn’t reset the countdown itself. It resets the timeout value, ie the value the countdown will start from. As far as I’m aware, we can’t actually see the value of the internal SE countdown as it’s counting down. Creating a timer is of course a great way of monitoring it for yourself. Just be sure to make sure your own countdown timer resets every time the storage command mode changes. That way, your countdown will mirror the internal SE countdown timer.

@Schlichi83

But I changed it to 12h anyway, because the only reason I set it to 1h was, so that when I activate Winter Mode, the timeout is being set to 24h more quickly. But of course you could also achieve that by simply making another automation, that sets it to 24h the moment you activate Winter Mode, right?

Right.

@Schlichi83

About the switching every minunte:
YES - that is what was actually happening this morning.

Excellent. I’d expect it to do exactly that, I’m just not sure what sort of strain, if any, it might put on your system to have it switch modes so frequently. I might be doing SE a huge disservice in that their system might be robust enough to handle that. Time will tell I guess.

Brilliant work on the dashboard BTW. I like your flip style countdown timer

[Schlichi83]

Thanks again for your reply. I changed automation 1 to running every 23 hours. This way, I still make sure, that it get’s checked before the 24h are over. And I made another automation that activates the “set timeout to 24h script” when the winter mode button is being activated (for at least one minute).

I will give a feedback in a few weeks/months how it’s been working for me.

And thank your for the feedback to the dashboard. I’m really happy with it!

[P6Dave (Dave Forrester)]

@Schlichi83

And do you have ANY other idea, how to achieve what I want?

Actually, there is another way to do it that doesn’t require changing any storage modes or messing about with timeouts. I don’t know why I didn’t think of it before, because it’s something I use.

The storage discharge limit. You can set this to any number up to the ac rating of the inverter the battery is connected to. It’s something I use in a couple of scenarios:

1. If I want to charge the EV battery overnight but don’t want to drain the battery, I set the storage_discharge_limit to 100W. This stops the battery from outputting more than 100W regardless of the storage mode.

2. If I simply want to preserve charge in the battery because grid prices are super cheap, or even negative, I do the same. Set the storage_discharge_limit to 100W.

I know some people who set it to just cover overnight base load, eg 250W etc, but it is perhaps an easier, and less stresfull on your system, way of achieving what you want.

So rather than having your automation switch between storage modes, have it set the storage_discharge_limit to a low number when the battery is under 40% and consumption is greater than production, then set it back to the inverter ac rating (in my case 5kW) when production is greater than consumption.

Leave the timeout at default (3600) and the storage_command_mode at MSC as they don’t need to be changed to change the storage_discharge_limit

Here’s an example from last night. I set the storage_discharge_limit to 100W from 0030 to 6am to preserve charge in the battery and gave the battery a half hour top up at 5am. Top line is the storage_discharge_limit bottom line is the battery_state_of_charge

[Jeza]

Hi All,

Im trying to resume control and use my system to charge and dicharge my batteries, but im not 100% sure as to why my system would stop the remote command staying on and keep resetting to max self consumption.

I took a screenshot ot the setting change to remote and it sets back constantly and i cant get the system to work under my command.

I also cant see if an outside source is asking it to be maximum self consumption, unless there is a log im unsure of?

[markpurcell]

@Jeza

im not 100% sure as to why my system would stop the remote command staying on and keep resetting to max self consumption.

Are you with Amber Electric or another VPP provider who provide Grid Services signalling to your system?

A few of us on Amber have had this issue of resetting when we try and control SolarEdge via the local ModBusTCP interface as the remote VPP commands would override.

The fix was to get the SolarEdge inverter unenrolled which then allows local control.