4 hours ago, rowesley said:

Ericson, the French,

If you already have microinverters connected to each PV (photovoltaic pannel) why do you want to install a hybrid solar inverter? This conversion method (PV to AC direct) is better than using a hybrid inverter.

However, if you want to switch from microinverter to a hybrid inverter just to connect a battery, then definitely I will not buy Vevor. You need an inverter which should be suitable for HV string (12x40V=480V at limit). Most low cost inverters have 500V maximum PV input. So perhaps you can go with 10 or 11 series connected PVs.

One good inverter is Anenji 6.2Kw/48V at 500V input. https://anenji.com/products/6200w-48v-hybrid-solar-inverter-on-grid-off-grid-with-wifi

The Anenji 4000w 24v is also a nice unit, if @ericson is looking for 24v specifically.

It's also one of the quieter all-in-one inverters I've tested. No need to change the fans on this one, and it support higher PV voltage than the Vevor 3500 (although externally they look similar).

Do note that it supports only around 3500-3800w maximum from battery alone. If you add PV, then it can support the full 4000w.

Edited April 28, 20251 yr by meetyg

48 minutes ago, meetyg said:

The Anenji 4000w 24v is also a nice unit, if @ericson is looking for 24v specifically.

It's also one of the quieter all-in-one inverters I've tested. No need to change the fans on this one, and it support higher PV voltage than the Vevor 3500 (although externally they look similar).

Do note that it supports only around 3500-3800w maximum from battery alone. If you add PV, then it can support the full 4000w.

It seems to be based on the hardware by Sumry. Sumry inverter are generally quieter than Voltronic inverters

Hello,
Thank you for your responses. I am carefully reviewing the suggested UPS devices.
Have a nice evening.

9 hours ago, ericson said:

Hello,
Thank you for your responses. I am carefully reviewing the suggested UPS devices.
Have a nice evening.

You should know that you can keep the PV+microinverters circuit unmodified and to charge/discharge a Li-Ion battery from the existent circuit in an OFF grid fashion. The microinverter AC output need to synchronize to the frequency of a provider grid. If the provider grid fail, you can not use the PV energy even it is full sun. This is the stupidity of all prosumers systems. The workaround for this is (free advice, but with carefully documentation read prior to buy anything):

a. connect the AC output of microinverters to the AC input of hybrid solar inverter ( the suggested Anenji), beware to have compatible voltage levels.

b. connect to the same AC input of the hybrid solar inverter a small AC sinusoidal output, 50Hz, UPS. The UPS power should be minimum 100VA. This is only for the microinverters synchronization, it should be a proffessional UPS with frequency stabilization.

c. connect the hybrid inverter battery input-output to your 24kw Li-Ion battery, 48V is must at this power, beware that you will be able to use only 12kw for a 50% DoD (deep of discharge), meaning around 8-10 years of use.

d. do not connect anything to the PV input of the hybrid inverter or connect other PV string that the one you actually have

The above solution might work or not, it depends on the specification of your microinverters.

Hey,

I'm using Vevor EML3500-24L for over two months now, in a pretty fun setup (more on that later).

So far I noticed two odd behaviours regarding battery pack communication:

• If you use battery with comm (eg Pylon) and don't have comm cable connected on inverter cold start, it will not start - even to bypass mode - until there was a successful communication at least once. It will stay in "Standby". Note that this also applies if inverter reboots due to overload, etc.

• but... if you disconnect comm cable during regular runtime it won't shut down. It will instead use values configured for "no communication" mode, and follow those (program 2, 12, 26). So if your BMS failed but mosfets are still open, inverter will still try to use/charge the battery like it was no-comm one - which seems to be a potential hazard.

What I also noticed is that even though I have Overload bypass enabled (program 23), on overload inverter immediately rebooted (program 06), not sure how those two are related. Both programs are enabled by default.

My issue is that I run a bunch of custom Pace BMS based LFP4 batteries and wrote my own Pylontech protocol emulator (fun fact, that's actually a Pace protocol, just older version) which acts as battery pack master for inverter.

But since this is running on external box plugged between batteries and inverter - it needs power to run and if power goes out I have a fun riddle to solve to turn it back on as I need to temporary power back my console server & SBC which runs the software just to turn the inverter on. I wonder if I'm missing some settings combination or this is just the way it is.

As for my setup - it is mostly summarized in readme.md of the public repo I made for my code on github. The interesting part is in vevor.py - I discovered many more Modbus registers than were provided in this thread already.

Other fun facts:

• Inverter over Pylontech protocol will get separate "max amps" for charge and discharge but completely ignore the discharge value. It is visible on inverters modbus registers, but it threads charge amps as limit for both charge and discharge.

• The (dis)charge limit on Pylontech can be set below 30A, while program 02 (charge amps for no-comm) allows at minimum 30 amps...

• Inverter uses undocumented commands over Pylontech protocol (0x61, 0x63) to receive data from battery. Fortunately Sunsynk documented those in their document named "Sunsynk Battery Compatibility" (you wouldn't ever guess by the name that it contains protocol docs)

• To make sure that after battery communication is lost inverter doesn't do anything stupid, adjust programs 2, 12, 26 to some insane low voltages and the minimum 30A current. If you choose them wisely, in such a situation inverter will not try to charge battery above 24-ish volts and keep unit in bypass/grid modes.

• Inverter seems to overshot battery voltage by 0.1v - I saw this claim earlier and I see a similar story in my case - battery voltage reading is consistent between all batteries and a coulombmeter, but inverter always claims 0.1 higher.

Edited October 14, 2025Oct 14 by kitor

On 2025/10/14 at 10:56 AM, kitor said:

Hey,

I'm using Vevor EML3500-24L for over two months now, in a pretty fun setup (more on that later).

So far I noticed two odd behaviours regarding battery pack communication:

• If you use battery with comm (eg Pylon) and don't have comm cable connected on inverter cold start, it will not start - even to bypass mode - until there was a successful communication at least once. It will stay in "Standby". Note that this also applies if inverter reboots due to overload, etc.

• but... if you disconnect comm cable during regular runtime it won't shut down. It will instead use values configured for "no communication" mode, and follow those (program 2, 12, 26). So if your BMS failed but mosfets are still open, inverter will still try to use/charge the battery like it was no-comm one - which seems to be a potential hazard.

What I also noticed is that even though I have Overload bypass enabled (program 23), on overload inverter immediately rebooted (program 06), not sure how those two are related. Both programs are enabled by default.

My issue is that I run a bunch of custom Pace BMS based LFP4 batteries and wrote my own Pylontech protocol emulator (fun fact, that's actually a Pace protocol, just older version) which acts as battery pack master for inverter.

But since this is running on external box plugged between batteries and inverter - it needs power to run and if power goes out I have a fun riddle to solve to turn it back on as I need to temporary power back my console server & SBC which runs the software just to turn the inverter on. I wonder if I'm missing some settings combination or this is just the way it is.

As for my setup - it is mostly summarized in readme.md of the public repo I made for my code on github. The interesting part is in vevor.py - I discovered many more Modbus registers than were provided in this thread already.

Other fun facts:

• Inverter over Pylontech protocol will get separate "max amps" for charge and discharge but completely ignore the discharge value. It is visible on inverters modbus registers, but it threads charge amps as limit for both charge and discharge.

• The (dis)charge limit on Pylontech can be set below 30A, while program 02 (charge amps for no-comm) allows at minimum 30 amps...

• Inverter uses undocumented commands over Pylontech protocol (0x61, 0x63) to receive data from battery. Fortunately Sunsynk documented those in their document named "Sunsynk Battery Compatibility" (you wouldn't ever guess by the name that it contains protocol docs)

• To make sure that after battery communication is lost inverter doesn't do anything stupid, adjust programs 2, 12, 26 to some insane low voltages and the minimum 30A current. If you choose them wisely, in such a situation inverter will not try to charge battery above 24-ish volts and keep unit in bypass/grid modes.

• Inverter seems to overshot battery voltage by 0.1v - I saw this claim earlier and I see a similar story in my case - battery voltage reading is consistent between all batteries and a coulombmeter, but inverter always claims 0.1 higher.

"So if your BMS failed but MOSFETs are still open" what that exactly means? BMS protection should work with or without communication, through a hardware loop. If the voltage exceed the cell max value or if the cell voltage is below the discharge limit, the corresponding MOSFET group (charge or discharge) must be OFF. If in your BMS that is not happening, you have a defective or bad designed BMS. If discharging MOSFET group is OFF and your BMS is hibernating, then you have to wake it up first. AFIK wakeup can be done by initiate a communication or by starting a charge or a discharge sequence. BMS bluetooth is also OFF during hibernation, so without any communication between BMS and battery, once the inverter is loading the BMS, the BMS it should start. Unfortunately on Vevor I do not have LiFePo4 pack, so you are the leader here. Cool for other MODBUS registers findings!

On 2025/10/14 at 10:56 AM, kitor said:

Hey,

I'm using Vevor EML3500-24L for over two months now, in a pretty fun setup (more on that later).

So far I noticed two odd behaviours regarding battery pack communication:

• If you use battery with comm (eg Pylon) and don't have comm cable connected on inverter cold start, it will not start - even to bypass mode - until there was a successful communication at least once. It will stay in "Standby". Note that this also applies if inverter reboots due to overload, etc.

• but... if you disconnect comm cable during regular runtime it won't shut down. It will instead use values configured for "no communication" mode, and follow those (program 2, 12, 26). So if your BMS failed but mosfets are still open, inverter will still try to use/charge the battery like it was no-comm one - which seems to be a potential hazard.

What I also noticed is that even though I have Overload bypass enabled (program 23), on overload inverter immediately rebooted (program 06), not sure how those two are related. Both programs are enabled by default.

My issue is that I run a bunch of custom Pace BMS based LFP4 batteries and wrote my own Pylontech protocol emulator (fun fact, that's actually a Pace protocol, just older version) which acts as battery pack master for inverter.

But since this is running on external box plugged between batteries and inverter - it needs power to run and if power goes out I have a fun riddle to solve to turn it back on as I need to temporary power back my console server & SBC which runs the software just to turn the inverter on. I wonder if I'm missing some settings combination or this is just the way it is.

As for my setup - it is mostly summarized in readme.md of the public repo I made for my code on github. The interesting part is in vevor.py - I discovered many more Modbus registers than were provided in this thread already.

Other fun facts:

• Inverter over Pylontech protocol will get separate "max amps" for charge and discharge but completely ignore the discharge value. It is visible on inverters modbus registers, but it threads charge amps as limit for both charge and discharge.

• The (dis)charge limit on Pylontech can be set below 30A, while program 02 (charge amps for no-comm) allows at minimum 30 amps...

• Inverter uses undocumented commands over Pylontech protocol (0x61, 0x63) to receive data from battery. Fortunately Sunsynk documented those in their document named "Sunsynk Battery Compatibility" (you wouldn't ever guess by the name that it contains protocol docs)

• To make sure that after battery communication is lost inverter doesn't do anything stupid, adjust programs 2, 12, 26 to some insane low voltages and the minimum 30A current. If you choose them wisely, in such a situation inverter will not try to charge battery above 24-ish volts and keep unit in bypass/grid modes.

• Inverter seems to overshot battery voltage by 0.1v - I saw this claim earlier and I see a similar story in my case - battery voltage reading is consistent between all batteries and a coulombmeter, but inverter always claims 0.1 higher.

8 minutes ago, rowesley said:

If in your BMS that is not happening, you have a defective or bad designed BMS

Yup, I know what is BMS role and what they are supposed to do. But that's what I was trying to say. In case your BMS fails catastrophically (no comm, open mosfets), vevor will still try to charge the battery with its no-comm settings, instead of going "hey, I lost the comm, I should assume fail-safe and stop using battery immediately!"

And that's why I'm surprised it will not start the inverter without initial battery comm but it is happy to work blindly if the comm is lost later. A bit of contradiction in my book.

Of course the entire "startup sequence" is the design problem of my set up where between actual BMSes and inverter sits AC powered console server (which allows me to plug all 12 batteries into my BMS emulator). At least it runs internally on 12v and since that's a rack equipment it has two power supplies - so I can plug one before and one after the inverter.

Edited October 15, 2025Oct 15 by kitor

I do wonder though: RS232 port is (theoretically) dedicated for WiFi dongle and provides some kind of 12-ish volt power. If this can provide around 5W of power then I could power up my SBC (which runs bms emulator) via step down converter directly from that port and it would solve all the issues.

19 hours ago, kitor said:

I do wonder though: RS232 port is (theoretically) dedicated for WiFi dongle and provides some kind of 12-ish volt power. If this can provide around 5W of power then I could power up my SBC (which runs bms emulator) via step down converter directly from that port and it would solve all the issues.

Hi @kitor The RS232 port is for inverter control only

You can use an USB to RS232 with the solar Assistant software (solar-assistant.io) for control the inverter (you can even change the inverter parameters with this way). The inverter is a Sumry rebranded inverter.

Using the power from the RS232 port is not recommanded as you could destroy the serial chip of the device

Best Regards

1 hour ago, fhocorp said:

Hi @kitor The RS232 port is for inverter control only

You can use an USB to RS232 with the solar Assistant software (solar-assistant.io) for control the inverter (you can even change the inverter parameters with this way). The inverter is a Sumry rebranded inverter.

Using the power from the RS232 port is not recommanded as you could destroy the serial chip of the device

Best Regards

1 hour ago, fhocorp said:

Hi @kitor The RS232 port is for inverter control only

You can use an USB to RS232 with the solar Assistant software (solar-assistant.io) for control the inverter (you can even change the inverter parameters with this way). The inverter is a Sumry rebranded inverter.

Using the power from the RS232 port is not recommanded as you could destroy the serial chip of the device

Best Regards

The RS232 has a separate isolated power supply on this inverter. Just open it and look inside. Yes, you can use RS232 for anything you want as long the EIA232 standard is not violated. To check the power capability of the supply from the RS232 board, proceed as follows:

• without load, the output voltage should be somewhere between 12.5 and 13.5V, in one of the previous posts I mentioned the exact value in my units.

• connect a variable resistive load (start with 100 ohm or so) and slowly decrease the resistor value, measure the current and voltage in the same time, until the output voltage drops between 11.5V and 12V,

• product between the measured current and measured voltage is the output supply delivered power.

As I remember,the SMPS transformer size looks enough big for 5W but you have to check if indeed can supply 0.4A without heating the switching transistor.

Just an update: There was not enough power for Raspi 2B. I did not measure exactly how much was available, but while booting voltage was sagging to roughly 10.5v (staying at 12 where idle) and I saw one of SMD elements on RS232 board getting visibly warm on thermal camera (iirc something in sot-23, since it was obvious it won't handle it I didn't check closely).

Anyway, it seems this should be enough for something like ESP32 or Pi Pico (which is not surprising if the port is dedicated for WiFi module) but entire SBC is too much.

On 2024/09/01 at 12:28 AM, rowesley said:

Ok attached the internal registers of Vevor 3500W MODBUS inverter. Yours should be more or less the same.

communication parameteters 9600,8n1, reading holding registers ( address 03) useful data starting from addr 200 to 323. Between addresses 247 to 292 all registers values are 0.

Can I ask how you obtained the map (ie names) of Modbus registers. I have a new version of the EML3500-24L which has builtin wifi (no exposed RS232 port), so only RS485. I am able to see the data from addr 200.

Do you know the mapping for writing values?