p_i

I see you posted screen grabs from the Sunsynk web site. Those stats are only updated every 5 minutes, or maybe 60 seconds if your installer asked Sunsynk to give you quicker updates. You'll see the same when using the Sunsynk app, since it uses the same data as the web site. Also the stats are often delayed by hours when Sunsynk experiences issues with their data store. You'll see more up to date stats when you use the inverter screen or your own monitoring solution.

I can't think why this would NOT work?! Surely they would be separate systems, each with their own set of PV panels and batteries. So it will run as if they it was the only unit there, except that they will share the same AC "network". Yes, the one inverter might feed a little a bit more power compared to what's needed in the house but that's why you have separate CT's, so each inverter can sense when you're feeding back to the grid and throttle back its output. Bus-bar is the best solution in my opinion, as long as you have enough fuses for safety (between battery and bus-bar AND between bus-bar and inverter). Each battery's BMS will handle its own charging. I would put a communication cable between the inverter and its bank of batteries so the inverter knows what the SoC is for its bank of batteries as well as communication cables between each battery. AFAIK these are normal CAT5 type cables so quite easy to source/make. Yes, it is my opinion as well (maybe I didn't phrase it correctly in my previous answer) that different models/sizes CAN'T be connected in parallel. Note that with parallel I meant one model connected to the same model with a communication cable in-between so they sort-of run as a unit. Agreed that Sunsynk should be able to do that given that they know the communication protocol between the units but it sounds that even Sunsunk themselves don't know whether that's possible or not. 🙄 I'm fairly sure running units separately as in your case without any communication in-between should be able to work but I hope there's maybe there's some expert in the group who can confirm that since I'm by no means an expert.

I'm not sure if I understand your situation entirely, but here's some of my comments: There should be nothing stopping you from having a bank of batteries connected to the 8kw inverter and another bank of batteries connected to the 5kw inverter. I don't think you should have the same bank of batteries connected to two inverters though. Yes, you might have a situation where there's extra solar capacity on eg. the 8kw inverter when its bank of batteries is fully charged and the 5kw bank is not charged yet, but it could always provide that extra power on the AC side to run the house. The DC cables between batteries should be as close as possible to the same length/resistance if you're using a battery bus-bar. If you're not using a bus-bar, you should connect the positive cable to the one end of the bank of batteries and the negative to the other end of the bank, but you will need thicker cables for that since cables in a daisy chain setup will carry more current. The only limit to communication cables are whatever that protocol's limit is, eg. CAN and RS485 limits, depending on how you handle inter-battery and battery-inverter communication. I'm using CAN between inverter and battery and RS485 between the batteries, but mine are all close by and not in different buildings like yours. However, I have no idea whether communication between different model inverters can work and whether they can run in parallel. Sunsynk should be able to answer that. My two are the same unit and hence they run in parallel but even then I see some odd behaviour at times.

I used to only get the disconnect notices, but now I also get the restored notices too. At last...

Maybe start with a description (and include a rough drawing) on how the 3 inverters are connected? Are they linked on the AC side? Are they linked together in any other way? Do you have any communication cables between the 3 inverters? If they're not linked together in any other way and in effect separate systems that merely provide AC power, each with their own PV strings, I can't see any reason why each inverter can't have their own set of batteries.

According to the manual, energy meter communication. I've never tried the bottom-right port since all the howto's I read indicated that the top-left one should be used.

Top left.

CT should go onto phase 1 in my opinion. But yes, get the stove moved to the same phase. And then maybe change your council feed from three phase to single phase, unless there's some reason why you need three phase power?

I hope this will be added to Sunsynk 5kw as well.

Lovely graphs. Where are you sourcing the cloud cover and load shedding information?

This thread should be merged into this one since JP Solar is mentioned on those sites too:

Definitely scammers too. The About Us page has standard photos that can be found on many of the scam sites.

Is your timer still ticked under system mode? Maybe show your system mode setup screen? The system app not showing up to date information is nothing new since they have issues with that service every now and then.

I've been monitoring some weirdness on my system. I have 2x 5kw Sunsynk inverters connected to 2x 5kwh Sunsynk batteries via a copper busbar. Battery communication is via canbus on the primary unit of each and I believe the battery charging voltage is changed via this. The 2 inverters are connected via the parallel ports and the 2 batteries are connected via their RS485 ports. Each inverter has 1 PV string connected. The problem is that at certain times of day/conditions, the secondary inverter becomes parasitic and mainly gets its power from the battery (positive readings on graphs) instead of its PV string where the primary inverter sends power to the battery (negative readings on graph) which the secondary slurps up. The PV on the secondary throttles back too. I've tried to collect all the conditions and graphed it in the attached. 13:20 - secondary inverter is parasitic with charging voltage set to 54.4V 14:40 - charging voltage is changed to 56.1V and parasite is no more and both units provide PV to charge batteries (14:48) 15:00 - battery is charged and charging voltage drops to 54.4V and parasite is back 16:04 - loadshedding hits and somehow both are sucking from battery now? (16:28) 17:00 - charging voltage changes to 56.1V and both units are providing PV to charge battery (17:12) 17:42 - battery charged and both units providing PV to carry load and battery movement is minimal 18:02 - loadshedding ends and the parasite is back? (18:10) Does anybody have any idea what's going on?

@gimme_power did the latest firmware solve this problem for you or is it still persisting?

And I managed to get it to work with my single W17286 RS485-USB device. I simply had to add a 2 second delay between querying the first and second inverter. 1.5s would have worked but I opted to give it a little bit more time to complete the first hit before hitting it again. Without this delay it appeared like the modbus became clogged and nothing got through. I'll experiment some more with the various modbus-getter parameters to see if the queuing to mbusd can be handled more graciously. PS: this is a temporary fix so I have some figures whilst I wait for my second W17286 device to arrive. 2s delayed/offset figures are better than no figures.

I think I got my answer from @kellerza here: https://github.com/kellerza/sunsynk/issues/39#issuecomment-1229449999

Here's another interesting observation: According to https://www.waveshare.com/usb-to-rs485.htm the "Transmission mode" of the W17286 is "Point-to-multipoints (up to 32 nodes, it is recommended to use repeaters for 16 nodes or more)". Does this mean you could use one W17286 to talk to two inverters, each with their own unique modbus ID, which is the default scenario in a parallel installation? The same applies to the RS485-3P device as per the manual https://handsontec.com/dataspecs/module/USB-RS485.pdf: "Supports Multi-point Communication".

Redid the one cable and even doubled up the wires but still no go. Will have to source me another W17286...

I was using the same cabling that was working perfectly until 2am when the power bank died. As a test I now swapped out one of my https://www.robotics.org.za/communication-wireless-Industrial/RS485-devices/RS485-USB/RS485-3P devices with my old https://www.robotics.org.za/communication-wireless-Industrial/RS485-devices/RS485-USB/W17286 and immediately it worked. Swapped the RS485-3P unit back in and it refuses to work. Back to the W17286 unit and it works. So I think I need to source a second W17286 unit somewhere and it seems I might have to import it since I don't see them available anywhere in South Africa at present. PS: I also tested the continuity on the CAT5 cable and the cable is fine so it's not that. So somehow 2x RS485-3P units simply stopped working? PPS: Seems it's available locally as https://www.takealot.com/waveshare-industrial-usb-to-rs485-converter/PLID93157151 which is a bit of a rip-off in terms of pricing. Hmm...

I backed off and now I'm only reading every 5 seconds. But this morning my battery bank (that I used to power my RPI3b with mbusd) ran out so I took the time to run a power lead to the RPI3b but now mbusd refuses to talk to the inverter. I put mbusd in debugging mode and it appears the commands to the inverters are timing out. And yes, I've rebooted the RPI3b multiple times and plugged and replugged all my cables. I even put it back on the battery bank as a test but no go. Any idea other than to reboot the inverters?

I now have the same thing: 2 inverters each with 1 string and only the master is actively drawing power from PV and feeding it towards the battery. Instead of the slave also drawing from PV, it's merely using the power being sent to the battery by the master. Earlier when the geyser was active, the master provided almost 3kw from PV whilst the slave provided almost 1kw, so the PV on the slave is not broken. It's almost as if the slave prefers the power from the battery instead of PV? I did a soft reset (blue button off and back on) on the slave, but that had no effect, other than dropping all the power to the house. Maybe the slave needs to be shut down entirely for it to reset? Did you find a solution to this reported problem? My software is M 3.3.8.4 / S 1.5.1.5 / C E.4.3.0 if it makes any difference to someone.

Thanks for the inspiration. Turned up the heat here and I'm managing about 30 modbus (x2 inverters) requests every 2 seconds, without timeouts! It's almost a constant stream of modbus requests. The load on the mbusd RPI3b has increased slightly to 0.17 but that's not really busy. Not sure if the RPI4 sdcard is going to be happy with all the influx writes but this is proof of concept for now.

I got two of these https://www.robotics.org.za/communication-wireless-Industrial/RS485-devices/RS485-USB/RS485-3P and ran my jacauc-based node-red flow via serial but I kept getting random timeouts on my HA RPI4. None of my attempts at staggering my modbus requests had any effect, not random delays, increased queuing times, nothing. I suspect the RPI4 with HA simply isn't fast enough to keep up with the load, maybe due to other HA stuff running on there. So I tried option B: installed mbusd on a RPI3b to expose the serial ports via TCP/IP and now there's no timeouts, even with me polling every 10s for ALL the data (was 15s before). I think I should even be able to even pull data at 5s intervals, if I decrease the default mbusd inter-request delay a bit more (was 100ms default, already dropped to 50ms). My proof of concept via grafana is coming along nicely too but I still have lots to learn...

Just use pin 1 for B and pin 2 for A and pin 3 for Ground (if your adapter has a ground, otherwise ignore). Another thing: the pins are numbered from 1 on the left to 8 on the right if you hold the RJ45 connector with the clip away from you.