New Python plugin: Domoticz SolarEdge_ModbusTCP

[AddieJanssen]

You asked for a plan; well, here's a plan

I have dusted off and upgraded my development environment and found several topics that need attention:

1. There are outstanding pull requests on the master branch that address issues that multiple users encounter.
   • Key not found issues.
   • Incorrect values when inverter goes to sleep at night.
2. The detection of meters and batteries in the meters branch may not work for all inverters.
   • The meters branch requires the user to enter if they only have an inverter or if there are also batteries or meters attached. This is a result of a false response from the solaredge_modbus library for my own inverter.
3. The meters branch needs merging into master resulting in a release of version 2 of the plugin.
   • Upgrading from v1 to v2 will result in error messages as a result of changes in parameters. There's not a lot that can be done from a plugin perspective - needs to be documented as part of the upgrade instructions.
4. The solaredge_modbus library has been archived and needs attention.
   • The solaredge_modbus library does not verify the response of the inverter when reading batteries and meters. As a result, my plugin may "see" a non-existent battery or meter and collect random data from the inverter.
   • The solaredge_modbus library depends on another library: pymodbus. Since pymodbus has introduced changes in their API, the solaredge_modbus library will not work with the latests versions of pymodbus.
5. Domoticz has introduced a new plugin framework named "Extended Framework" and the framework used by my plugin is based on what is now named the "Legacy Framework".
   • Although there are no reported issues with my plugin using the Legacy Framework, it makes sense to migrate to the Extended Framework at some point.

Time for a plan. I do not want to make further changes to v1 (the master branch); instead focus on getting the v2 version released as soon as possible. The initial version will still use the solaredge_modbus library and will require an older version of pymodbus (although newer than currently set for v1).
I need testers who (although they may not have meters or batteries attached to their inverter) start upgrading their v1 plugin to v2 (meters branch) and report issues (here in the Domoticz forum please - not on GitHub).

Next to that, I would like to get in touch with users that do have one or more batteries or meters attached to their inverter. I have found a potential solution for the detection of batteries and meters that should work. It needs testing. To do that, I have created a standalone python script which has nothing to do with Domoticz.
I am looking for users that know (without my help) how to create a virtual environment, install specific versions of pymodbus and run a python script.

Once v2 has become mainstream and it is clear how to correctly detect batteries and meters, I would like to focus on replacing the solaredge_modbus library in order to keep up with newer releases of pymodbus.

There are clones of my plugin that introduced additional functionality. I have not yet looked into that topic and first want to make sure the plugin works and can be installed and maintained properly.

That's the plan. Do share your thoughts - provide feedback and let me know if you can help out with the 2 above mentioned tasks.

[imautohuttraeger]

Wow, that indeed sounds like a great amount of work and time that has to be done.

I have a complete SolarEdge system (since one year now), including

- Inverter

- Meter (integrated into the emergency power backup interface)

- Battery

I would very much like to participate as a tester.

I am looking for users that know (without my help) how to create a virtual environment, install specific versions of pymodbus and run a python script.

I’m just a layperson of the type "copy - paste - hoping", but I managed to install @jvanderzande’s fork with step-by-step help of AI (Claude).
https://github.com/jvanderzande/domotic ... ree/meters

Environment that finally worked after some trials and errors:
Python: 3.13.5
pymodbus: 3.5.4
solaredge_modbus: 0.8.0

So I have a python virtual environment. PYTHONPATH is permantly set in /home/pi/domoticz.env so that Domoticz finds the virtual environment.

So I will not ask for such basic here - AI is my assistant.

I need testers who (although they may not have meters or batteries attached to their inverter) start upgrading their v1 plugin to v2 (meters branch) and report issues (here in the Domoticz forum please - not on GitHub)."\

I only have to find out first if both plugins can run in parallel or if and how I must update or delete jvanderzande’s fork.

If you really go through with updating your plugin, I would greatly appreciate it!

[AddieJanssen]

Hi all,

I have just published v2.0.5 on GitHub.

The meters branch has been merged into main, meaning that v1.x.x is no more and we will continue with v2.x.x.

There are no functional changes compared to v2.0.4, however, this version should fix the "key not found" issues.
The requirements have been upgraded to match the latest supported versions by the solaredge-modbus library.

If possible: upgrade your plugin or run this version next to your current version and share your feedback.

I am eager to find out if the "key not found" issue is gone with this version.

Meanwhile, I'll be beavering away at my "to-do" list as shared earlier.

[JayDotR]

Hi Addie,

I added two more sockets to my modbusproxy, and your 2.0.5 will run in // with the 2.0.4 of the meter branch on a distinct raspberry.

I will keep you updated of eventual findings or suggests if they appear

Jan

[JayDotR]

NB : since debian12, using pip3 to install modules works fine in .venv, however some of the modules exist in never versions natively, so no more need to --break-system-packages if you wont .venv the plugin

[imautohuttraeger]

Unfortunately I am traveling, but I hope to install it tomorrow and will give feedback.

[hjzwiers]

I'm eager to test this version, and i'm specifically looking into chaging the ev without interaction to the battery and pv, so during the winter i can charge leaving the pv and battery untouched. I've done som work with AI and it came up with the following question:

The current MetersDev plugin exposes Storage Control Mode, Remote Control Mode, and Storage AC Charge Policy, but doesn't expose the SolarEdge rc_discharge_limit register.

The bundled solaredge_modbus library already defines:

rc_discharge_limit = (0xe010, 2, HOLDING, FLOAT32, float, "Remote Control Command Discharge Limit", "W", 6)

and its write implementation supports FLOAT32 via add_32bit_float().

Would you consider exposing rc_discharge_limit as a writable numeric inverter device in the MetersDev plugin?

The intended use is to set the SolarEdge remote battery discharge limit to 0 W while an EV is charging in a "Direct" mode, so grid power supplies the EV deficit without discharging the battery.

I would prefer an upstream implementation rather than modifying the plugin locally.

Is it a possibility to implement this? I also see the the battery is switching to different modes when I'm in Time of use, it switches to Charge from PV and AC, which is fine but i was wondering if it is normal behavior.

[jvdz]

@AddieJanssen,

In case you are interested in what I have done in my version, there is a thread here where the first post describes the changes I made.
I can make a PR for the "Active Power" change from value to Dimmer device, so you can dynamically update the production from Domoticz when you want.
I will decommission my other development branches when you are picking up your development again to avoid any confusion!
Thanks for all your efforts, and let me know when I can assist..... but I "only" have an inverter setup to test with.

[imautohuttraeger]

EDIT: Sorry. Forget this. It is defined in requiremtns.txt. pymodbus: 3.6.9. I just installed v2.0.5 and it works. Will report later.

Currently, with @janvanderzandes fork, I am running

Python: 3.13.5
pymodbus: 3.5.4 (newer versions produced errors)
solaredge_modbus: 0.8.0

Which pymodbus version must be used for testing @AddieJanssens Pre-release version v2.0.5?

[AddieJanssen]

Regarding the following snippets:

... I've done som work with AI and it came up with the following question: ....
... Is it a possibility to implement this?...

In case you are interested in what I have done in my version, there is a thread here where the first post describes the changes I made. I can make a PR for...

I am currently processing the changes in the pull requests that were made in the past.
The next step is to replace the, archived, solaredge_modbus library.
Once that's done, we should have a version of the plugin were new functionality can be added to again.
So, please hang on to these questions and we will come back to it in due time.

Regarding this question:

... I also see the the battery is switching to different modes when I'm in Time of use, it switches to Charge from PV and AC, which is fine but i was wondering if it is normal behavior.

I am not sure if this is a question related to the plugin or the behavior of your inverter/battery setup.
If it is related to the plugin, it would help to share relevant snippets of the json response from the Domoticz log.
The json response will only show up in the log when the Log Level is set to (at least) Verbose+.

It's been great fun to start working on the plugin again. Getting feedback and people offering help is the incentive that makes it worth investing time into it! Thanks for that - much appreciated.

[jvdz]

Regarding this question:

I also see the the battery is switching to different modes when I'm in Time of use, it switches to Charge from PV and AC, which is fine but i was wondering if it is normal behavior.

I didn't write that and should be:

I also see the the battery is switching to different modes when I'm in Time of use, it switches to Charge from PV and AC, which is fine but i was wondering if it is normal behavior.

[AddieJanssen]

Oops... corrected

[imautohuttraeger]

.
.
Managed to get v2.0.5 running. 82 devices created receiving data. No errors so far. Let's see tomorrow at daylight.
.
.

It's been great fun to start working on the plugin again.

[imautohuttraeger]

Thank you for the work so far!

All inverter, battery and meter devices are working here without any error in the log and they receive data.

"I am eager to find out if the "key not found" issue is gone with this version."

--> I have no "key not found" error.

"Incorrect values when inverter goes to sleep at night."

--> Only had a quick look last night, so I will oberseve it tonight and report

It also works with the energy dashboard and energy widget - see screenshot of the devices I am using.

However, unfortunately there is no pure solar production device as these devices are adding or subtracting battery usage. But this is not related to the plugin. SolarEdge simply does not provide this as a separate value.

I used to solve this already in the past by a virtual device that receives data via a script that subtracts or adds the battery values.

"The solaredge_modbus library depends on another library: pymodbus. Since pymodbus has introduced changes in their API, the solaredge_modbus library will not work with the latests versions of pymodbus"

--> At least from my user's point of view there doesn't seem to be any problem right now using the old pymodbus 3.6.9.

.

[imautohuttraeger]

I have to cancel my claim that there are not errors. Yesterday evening at 21:34, there were th following ones:

Code: Select all

2026-09-18 21:34:22.398  Error: SE_Modbus_Neu: Call to function 'onHeartbeat' failed, exception details:
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu: Traceback (most recent call last):
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu:   File "/home/pi/domoticz/plugins/solaredge_modbus_tcp_v2/plugin.py", line 709, in onHeartbeat
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu:     _plugin.onHeartbeat()
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu:     ~~~~~~~~~~~~~~~~~~~^^
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu:   File "/home/pi/domoticz/plugins/solaredge_modbus_tcp_v2/plugin.py", line 251, in onHeartbeat
2026-09-18 21:34:22.421  Error: SE_Modbus_Neu:     meter = self.inverter.meters()[device_name]
2026-09-18 21:34:22.421  Error: SE_Modbus_Neu:             ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
2026-09-18 21:34:22.421  Error: SE_Modbus_Neu: KeyError: 'Meter1'

No new errors since then. Will watch it, if it always comes ones in the evening. Maybe always due to lack of sunpower.

Statistics of inverter, battery and meter power devices do not show any strange values at 21:34

[AddieJanssen]

I have to cancel my claim that there are not errors. Yesterday evening at 21:34, there were th following ones:

Code: Select all

2026-09-18 21:34:22.398  Error: SE_Modbus_Neu: Call to function 'onHeartbeat' failed, exception details:
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu: Traceback (most recent call last):
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu:   File "/home/pi/domoticz/plugins/solaredge_modbus_tcp_v2/plugin.py", line 709, in onHeartbeat
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu:     _plugin.onHeartbeat()
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu:     ~~~~~~~~~~~~~~~~~~~^^
2026-09-18 21:34:22.418  Error: SE_Modbus_Neu:   File "/home/pi/domoticz/plugins/solaredge_modbus_tcp_v2/plugin.py", line 251, in onHeartbeat
2026-09-18 21:34:22.421  Error: SE_Modbus_Neu:     meter = self.inverter.meters()[device_name]
2026-09-18 21:34:22.421  Error: SE_Modbus_Neu:             ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
2026-09-18 21:34:22.421  Error: SE_Modbus_Neu: KeyError: 'Meter1'

No new errors since then. Will watch it, if it always comes ones in the evening. Maybe always due to lack of sunpower.

Statistics of inverter, battery and meter power devices do not show any strange values at 21:34

That's interesting. The error states that the plugin did not receive any information of Meter1. Meters in general don't "just" disappear.

Would you be so kind to set the log level of the plugin to Verbose+ and if the error occurs, include the latest json output before the error in your message? That gives context to why the error occurred.