kitor

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.

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.

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.

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.