Feature request - Solaredge power throttling

[kyros32]

Hello, please implement power throttling for Solaredge. At the moment it will be the most deployed system in Europe because of its string simplicity, design simplicity AND safety - safe dc.

Power throttling over modbus is available since before 2018 - see the attached document.

I don’t understand, why it is not implemented already. Seems like everything needed is in the attached document.

ramp-up_down_and_active_power_control_02-01-19.pdf

[mpverrijt]

I also really wanted this, so got to work on it myself. Luckily we only need a couple of device id defines from velib to compile it ourselves with the SDK.

I made an implementation on my fork and have tested it a bit, it seems to work. It could do with a bit more testing and tweaking of certain settings I guess. You can find it here in the solaredge branch. There is also a solaredge-mbs branch for which I made a tool I can used to read and write registers of the solaredge manually via dbus-spy.

[kyros32]

Hi @mpverrijt thanks a lot for this! Much appreciated. Could you please outline a process on how to install this package on Cerbo GX and what limitations it has in terms of firmware updates for example? I am very much a newbie in Cerbo GX customizations. Thank you!

[mpverrijt]

Here is a quick(start) outline if you wish to compile and test yourself:

1. Install the SDK Note that the SDK is for usage on a x86_64 linux system, not the cerbo itself.
2. Clone the fork of dbus-fronius with submodules: git clone --recurse-submodules https://github.com/mpverrijt/dbus-fronius.git.
3. Optionally checkout the solaredge-mbs branch depending on what you want (solaredge-mbs has the extra tool to manually read/write registers on the solaredge inverter via dbus-spy, but be careful, I suggest only to use it if you know what you are doing).
4. In a terminal go to where you installed the sdk and enter source environment-setup-cortexa8hf-neon-ve-linux-gnueabi
5. In the same terminal window go to the base directory of the dbus-fronius clone and enter ./alt-build.sh
6. You should now have a new exectuable (build/dbus-fronius/dbus-fronius) if all went well.
7. Get root access to your cerbo-gx.
8. Copy the newly created executable to the data directory of your cerbo (via scp for example: scp build/dbus-fronius/dbus-fronius root@YOUR_CERBO_IP_ADDRESS:/data/).
9. ssh to your cerbo-gx (ssh root@YOUR_CERBO_IP_ADDRESS)
10. There make a copy of the original executable and link the one you copied to the data directory instead:

     cd /opt/victronenergy/dbus-fronius
     cp -a dbus-fronius dbus-fronius.orig
     ln -sf /data/dbus-fronius

11. Restart dbus-fronius by killing the current running process (pkill dbus-fronius), the supervisor will restart with the new executable. Alternatively you can reboot your cerbo.

With respect to firmware updates, the whole root file system gets updated. This means you need to rerun step 10 (and 11) once after a firmware update.

When dbus-fronius gets updated and you want/need these updates we need to merge/maintain these updates in the fork and recompile the executable.

All of this can be made a lot simpler by creating a package and installing it via the package manager tools (opkg). I'm quite limited in the amount of time I can work on this right now, but I do want to do this when I can.

Also, I need to mention it is required to enable advanced power control on your solaredge inverter. This can be done via the SetApp or with writing registers via modbus. If you are using it with the original dbus-fronius and frequency scaling (when grid fails / standalone) this should already be enabled. All of the enhanced power control settings and enable I now send once on a inverter connect, but I believe the settings atleast can be set once (in non-volatile memory). For testing purposes I have left left them there for now. For example, I have disabled the rate of change as I believe this is also how it works for the other inverters via sunspec model 123, but I am not 100% sure.

I will also post this in the modifications space on the community.

[kyros32]

Hello @mpverrijt - thank you for your thorough walk-through. However, anytime I try build, I get this error during compilation: ../../software/src/main.cpp:4:10: fatal error: veutil/qt/ve_qitem.hpp: No such file or directory 4 | #include <veutil/qt/ve_qitem.hpp> Seems like some files are missing in the fork? I checked dbus-fronius original repo and it is not there either. Any help appreciated.

[mpverrijt]

Ah yes, you need to also pull in the submodules. Only the submodule for velib you cannot get (it is closed source). Luckily dbus-fronius only requires 4 defines from velib, and I have added them to the fork. So disable the submodule velib and pull in the others (see software/ext folder).

Here is some more info on submodules to get you started: https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/How-to-clone-a-git-repository-with-submodules-init-and-update .

Regards, Mark

On Sat, Mar 23, 2024, 8:18 PM kyros32 @.***> wrote:

Hello @mpverrijt https://github.com/mpverrijt - thank you for your thorough walk-through. However, anytime I try build, I get this error during compilation: ../../software/src/main.cpp:4:10: fatal error: veutil/qt/ve_qitem.hpp: No such file or directory 4 | #include <veutil/qt/ve_qitem.hpp> Seems like some files are missing in the fork? I checked dbus-fronius original repo and it is not there either. Any help appreciated.

— Reply to this email directly, view it on GitHub https://github.com/victronenergy/dbus-fronius/issues/6#issuecomment-2016580424, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGFHZ5JGHFGCDA762FDQADLYZXIQPAVCNFSM6AAAAAA7H4HD7OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGU4DANBSGQ . You are receiving this because you were mentioned.Message ID: @.***>

[kyros32]

@mpverrijt thank you again. However, by disabling a module "velib" you mean removing or commenting its section in the file called .gitmodules? If yes, i tried that, however I still get the same compilation error. I think the reason is that veutil won't download -->

I managed to initialize and update submodules, however, veutil won't download because of the following error:

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@github.com:victronenergy/veutil.git' into submodule path '/root/dbus-fronius/dbus-fronius/software/ext/veutil' failed
Failed to clone 'software/ext/veutil'. Retry scheduled
Cloning into '/root/dbus-fronius/dbus-fronius/software/ext/veutil'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@github.com:victronenergy/veutil.git' into submodule path '/root/dbus-fronius/dbus-fronius/software/ext/veutil' failed
Failed to clone 'software/ext/veutil' a second time, aborting

Therefore, still the same error while compiling :-(

../../software/src/main.cpp:4:10: fatal error: veutil/qt/ve_qitem.hpp: No such file or directory
    4 | #include <veutil/qt/ve_qitem.hpp>

[mpverrijt]

I checked what I did back when I first cloned it. I also changed veutil submodule to grab via https git@github.com: --> https://github.com/.

git clone https://github.com/mpverrijt/dbus-fronius.git
cd dbus-fronius
git checkout solaredge</del>
git rm -rf software/ext/velib # disable velib submodule
sed -i 's,git@github.com:,https://github.com/,g' .gitmodules # use https
git submodule init 
git submodule update

I will add these changes to the fork soon.

Has been added to the fork. Can now use

git clone --recurse-submodules https://github.com/mpverrijt/dbus-fronius.git

[kyros32]

@mpverrijt you are the man! I tested it today with Solaredge SE16 K and it works flawlessly with Venus v. 3.30!Thank you.

[mpverrijt]

I'm glad to hear that. The more people that test this, the better :smiley:

[trpkosj]

I have tested it with SolarEdge SE9K-RW0TEBEN4 and it works perfectly. Thank you very much.

The only improvement might be... I struggled a bit to find out I need to install Ubuntu / Linux for the first part of the process (compilation of dbus-fronius using SDK). At first I tried to do it on Cerbo itself, which is different architecture.

[kyros32]

@mpverrijt if this ever gets to OPKG optional packages, it would be awesome. Lot of our customers started to use DynamicESS, which requires to update the system very often. In the end, we have to obtain local LAN access (Teamviewer, port forwarding, VPN, proxy,...) in order to SSH into Cerbo and to reinstall freshly compiled package.

mpverrijt, I know you pushed this quite far, but OPKG would be the next step :-) Just saying. I know time resources are scarce.

[mpvader]

hey all, just a brief note that we've seen this, and I've asked for a short review to see if its feasible to get this in by default.

[mpverrijt]

I forgot to push my updates after testing on an older solaredge inverter (with LCD) last month, so I just did this now. It seems it doesn't allow setting the ramp limit to -1 (which allows instantaneous changes on newer setapp inverters), so I set it at the next best thing (100 [%/min]) there. The older inverters also don't have the the sunspec part which gives the inverter rated power, so I added this aswell. It was the last available firmware for these types of inverters (July 2020, see here)

@trpkosj: Thanks for the suggestion, glad to hear you got it working in the end.

@kyros32: If the package doesn't need recompiling (you don't need new features, or there isn't a major change to any of the dependencies) you can use "rcS.local" so it keeps using the custom version (even after updates).

See here for explanation: https://www.victronenergy.com/live/ccgx:root_access

And here for what I using: https://github.com/mpverrijt/dbus-fronius/blob/solaredge/sandbox/rcS.local

@mpvader: That would great! Please keep us informed.

[izak]

Hi guys, I have some questions/suggestions about this.

1. Since this is not a feature available on all Solar Edge inverters, is there an easy way to detect if the limiting is present, so that the feature can be disabled for inverters that don't have it? This was one reason it power limiting was never supported on some SMA inverters: The older ones did not properly support it, and detecting support was not trivial. I'm hoping it will be easy in this case?
2. Some of the changes you made, it seems I was heading in a similar direction last year already. The plan was to implement support for the 2018+ sunspec models in the 700 series, and to do that I already split out the limiter into a sub-component. Can you take a look at this branch, so we don't end up doing this twice?
3. Eliminating the need for velib, I agree. Since we only use a few product ids, I've been meaning to do this myself, so we need only depend on veutil.

I'll take a look at this and see if we can easily add it. But to be honest, the main sticking point for me is to easily detect that it is available.

[izak]

also, @mpverrijt , I assume you replaced the static const int with just const int because in C++ there is no difference at file scope?

[kyros32]

Hi guys, I have some questions/suggestions about this.

1. Since this is not a feature available on all Solar Edge inverters, is there an easy way to detect if the limiting is present, so that the feature can be disabled for inverters that don't have it? This was one reason it power limiting was never supported on some SMA inverters: The older ones did not properly support it, and detecting support was not trivial. I'm hoping it will be easy in this case?
2. Some of the changes you made, it seems I was heading in a similar direction last year already. The plan was to implement support for the 2018+ sunspec models in the 700 series, and to do that I already split out the limiter into a sub-component. Can you take a look at this branch, so we don't end up doing this twice?
3. Eliminating the need for velib, I agree. Since we only use a few product ids, I've been meaning to do this myself, so we need only depend on veutil.

I'll take a look at this and see if we can easily add it. But to be honest, the main sticking point for me is to easily detect that it is available.

I think this could be achieved via some list of supported devices / device ID's / models might help?

I attach Modbus document and Power Throttling Document. Probably it is not the latest version though.

3_Modbus_SunSpec Implementation Technical Note.pdf

3.1._Application Note - Dynamic Active-Reactive Power and Power Factor Control over Modbus v1.1 (1).pdf

[izak]

@kyros32 What I will do in the coming days, so that this is not disruptive to you guys, is allocate a Product ID for Solar Edge. Then the detection can be cleaned up a bit.

Looking a bit at the code already written, you can probably check for the existence of the required registers, and if that doesn't return a modbus error, then simply leave /Ac/PowerLimit and /Ac/MaxPower invalid, and the rest of the system will then not attempt to limit it.

[mpverrijt]

also, @mpverrijt , I assume you replaced the static const int with just const int because in C++ there is no difference at file scope?

If I remember correctly I did this together with adding it as extern in the corresponding header so I could access it from the extended updater class.

1. Since this is not a feature available on all Solar Edge inverters, is there an easy way to detect if the limiting is present, so that the feature can be disabled for inverters that don't have it? This was one reason it power limiting was never supported on some SMA inverters: The older ones did not properly support it, and detecting support was not trivial. I'm hoping it will be easy in this case?

My understanding here is that the older solaredege inverters (with Display/LCD) are firmware versions 3.X, and the newer inverters (SetApp Enabled) are firmware versions 4.X.Y. I'm assuming the support for 'Enhanced Dynamic Power Control' was introduced at some versions of both the older and the newer inverters. Maybe it can be conditional on the version (if the approach of modbus errors isn't enough)? Note that for the older inverters I did make some changes, and have only tested this on an SE6K with firmware version 3.2537), and although the instantaneous changing of the limit is not possible, it does work with a rate of change of [100% of rated power / min]. Also the 'Max Power' is read from F304 there instead of getting it from '702: // IEEE 1547 DERCapacity page' as for the newer inverters.

2. Some of the changes you made, it seems I was heading in a similar direction last year already. The plan was to implement support for the 2018+ sunspec models in the 700 series, and to do that I already split out the limiter into a sub-component. Can you take a look at this branch, so we don't end up doing this twice?

I don't work on this as much as I would like to, due to being quite busy at work, so the chance of me doing additional work on my fork is quite low. If I do, I will however look at this branch first / let you know. Chances are my fork will be obsolete by then anyway ;).