Acuario

I doubt with your 4050W array you will actually achieve 4000W. I usually allow for a 15-20% reduction in power from the panels stated power so I would imagine your arrays will produce less than the 8K.

Probably for a different discussion but... Have users of IOT devices ever really thought about the implications of what they are doing/connecting? I'm a true lover of IOT and think it is wonderful BUT I don't want control of my devices in the hands of some unknown company, no matter how much they say they are trusted. I have full control over ALL my devices as I write my own software to run them, always with both remote and local control of the device, and NEVER use any of the hosting companies. eWeLink claim to have 30,000,000 users in 172+ countries. Tuya (another similar platform) probably have as many or more, and there are other platforms as well. Most are Chinese companies. Every time you register a device your data is stored on their servers. Even if you use their device locally (some such as SonOff can be used this way), using their default firmware does not prevent your device being registered with the manufacturer. This bit of javascript is from a SonOff S26R2 IOT smart socket, from the HTML that is embedded in the device that you use to initially set up WiFi on the device: postReport: function(e, t) { return fetch("https://apia.coolkit.cn/report/ops_mode", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ deviceid: e, sign: t }) }).then(function(e) { return 200 != e.status ? Promise.reject("status error " + e.status) : e.json() }) a.postReport(e, t).then(function(e) { e.error || (i = !0, s.showDialog("Success", "WiFi configuration is completed.", !0)) This is part of the code that is run when you configure and connect the device to your WiFi. As you can see, your device is being registered on their server without your knowledge and as soon as it is connected to your WiFi, in fact if it can't register itself it causes an error. So combined these companies probably have control of several 10's if not 100's of millions of devices. This 'power' could easily be abused should their government wish. Imagine many millions of devices set to switch on/off at the same time - what sort of chaos would this cause on a countries power grid? And what happens should these companies go out of business (that has happened in some cases) - you end up with a pile of scrap if you can't re-program the device. ..and when they decide they want to charge for their currently 'free' service? ..worth considering

Then they should be ok as they are nearly new, it's unlikely you'll notice anything unless the old(er) batteries have been seriously abused.

Due to the problem with BMS comms between Axpert and Pylontech I ran a test on a Pylontech US2000C battery. I was concerned about over charging as the RS485 BMS reports the maximum charge current to the inverter and the inverter progressively reduces its maximum charge current setting automatically based on the values coming from the BMS. My concern was that setting USE for battery type, and then voltage, it would not be sufficient and that the batteries would continue to charge. The result was that as the battery approached 100% it automatically reduced the charge rate without any intervention. My conclusion was that the USE settings are fine and overcharging will not happen.

I understand this means means you are adding 2 new 12V batteries (to provide 24V) in series with 2 older 12V batteries (providing the original 24V) to get a 48V battery pack. How old are the original batteries that provided the 24V system? As with any lead acid battery it isn't recommended to add to the pack when the batteries are more than X months old - X is 6 months or a year depending on who you talk to.

Are they both the same style, i.e. low maintenance, gel, regular 'top up' batteries or sealed? Also why? Are you replacing an old dead battery and keeping an old working battery, or just 2 different makes but both new? It's not recommended to add new batteries to old batteries as the old battery will tend to drag the new battery down. If they are both new, both the same style and both the same Ah rating then you should be fine.

Yes correct. This is one of the common failures made when batteries are connected in parallel. The rating is per battery both charge and discharge so it needs to be multiplied by the number of batteries.

Depending on the version of firmware on the inverter it may or may not be able to communicate with the batteries using the BMS - it seems they introduced a bug so they don't communicate. For the charge current, in the booklet it will say the maximum recommended charge current. As you have 2 batteries this will be that value x 2. The BMS takes care of reducing the charge current when the batteries reach 100% To set the timer for setting output source priority check program 99 in the booklet for the inverter, here you can change the output source. Note however that if the inverter is connected to a grid supply it will still consume power from the grid, possibly up to 1.5kW. The only way to avoid this is to physically disconnect the grid supply.

This is what can happen when lightning strikes.. the molten mass at the bottom is the remains of a 3-phase professional lightning surge arrestor. Did it work? Well, nothing in the house got fried so you could say that yes, it did it's job.

If you plug it into your pc it won't see it as a new device as you are plugging into an existing com port, not adding a com port. You will need a bluetooth adaptor for the PC, this will show up as a new com port on the PC. The data speed that Watchpower uses is only 2400 baud so your old pc should be fine. With the adaptor plugged into the pc you can use something like termite to use the com port. If you install a serial bluetooth terminal on your phone then the pc and phone should be able to communicate across the bluetooth connection. If this works then when you get the bluetooth adaptor for the pc you can try the same from phone to pc. The female/female adaptor should be fine to connect the JINOU to the inverter.

If you search for BT-JINOU you'll get several hits. You can find out the pinout for the DB9 connector etc. If you link TX and RX on the adaptor it will work in loopback. You can then connect from the bluetooth on the pc (built in or dongle) - you need to pair the devices - usually the code to pair is 0000 or 1234 When they are paired use a terminal program such as Termite to see if you can get a response to the loopback - what you type should come back on the received data. If this works then connect tx/rx/gnd from the adaptor to the inverter and try to get a response from it - you can use the MAX protocol, you need to send a command with checksum - elsewhere on this forum that is described. You could skip this step and try Watchpower, changing the COM port to the Bluetooth com port. In theory it should all work.

The box he has is not running 2.71 but he is upgrading it to show the process. He says it is version 2.71 that has problems. The box he upgrades is running 2.61 and upgrades to 102.73 @CoulombI thought I read somewhere that versions 1XX were for a different processor than 0XX versions due to the chip shortage so were incompatible?

The King 5kW I have at the moment (it's a customers so will be gone soon) was bought in November last year. Firmware U1: 71.93 U2: 2.60 This works perfectly with the BMS cable on Pylontech setting - Brown/White -> 5, Brown ->3 (inverter end) I'm wondering if they have migrated the MAX II bug that stops it working with Pylontech to the version of firmware your inverter is running.

After running some tests today it seems the CAN data does not change the charge current limitation value when it approaches 100% SOC so it's not possible to use this as a way to regulate the charger on the inverter. It seems this is only available on the RS485 protocol. However, it seems the BMS automatically limits the charge when the battery approaches 100% - the readings from register 356 reduce down at the battery approaches 100% and finally drop and stay between 0A and 2.1A (no load on the inverter). This is good news as my concern was overcharging. I set the maximum voltage to 53.0V and it holds steady and charges to 100% at this voltage. The CAN data is useful as it can be used to set the charge limit of the inverter based on the BMS charge limit X number of batteries (both of which are on the CAN data). It also reports the real SOC, the inverter reports much lower as soon as the voltage drops from 53.0V

Additionally I've incorporated an RTC and SD card. I use the EEPROM to record hourly and daily statistics and the SD card to record solar and system performance that can be shown on a graph via the system web interface.

It sounds roughly the same as what I have designed/developed. This is with an ESP32. The white sockets are for an LCD display and a touch switch. The user relay can be programmed to switch on/off depending on the SOC. I don't know how much 300 rands is - but according to the currency calculator it's just over 16 euros - I don't know the price of the raspberry pi but I thought they were more than that.

PBMS on the round display versions returns NAK. The only BMS message that works is QBMS. It returns QBMS: (0 051 0 0 0 532 532 450 0150 0220 which fits with the PBMS data as documented.

From my tests to date I've not seen any activity from the Axpert on the CAN port, only on the RS485 where it requests data from registers 0x46, 0x61, 0x62, 0x63 in the case of the MAX and 0x42, 0x46 and 0x92 in the case of the King. The Pylontech outputs CAN data ID: 0x351, 0x355, 0x356, 0x359, 0x35c and 0x35e in a continuous stream. I've tried using the RS485 connection and requesting data but it has proved complex for some reason - the receive buffer on my ESP32 does not seem to want to play kindly so I end up with responses out of sync with requests and as the reply frame does not contain any indication of what it is replying to it's impossible to guarantee the results. It seems to be related to the RTOS tasks as in a non RTOS program it works happily.. So moving to CAN some of the same data is available (or at least what I need to simulate the BMS link). Fortunately when I designed my PCB I made provision for a CAN interface so it was fairly easy to move to that. I now have code running that reads the CAN data and based on the data sets the inverter charge current. As an additional extra it also sets the battery type and float/bulk/shutoff voltages so these can be changed from the defaults that the BMS sets (which, in another topic, were deemed to be too high).

A good point. I guess that is already catered for as when the charge current changes as a result of the BMS message the inverter saves the setting (this can be confirmed by going into the programming or reading the QPIRI message). I don't know where they would store the valued, it could be in flash or EEPROM, the latter has a much higher maximum number of write cycles (over 1 million) so even at 20 changes a day it would last over 130 years. It depends on the storage medium but I don't think it's something to worry about.

That's what I suspected. So bad news for anyone setting USE with voltages on Lithium batteries then... I did see mention somewhere that Pylontech require that their batteries are correctly charged (I guess according to the values from the BMS) for the warranty to be valid. Can anyone confirm this? Do other manufacturers stipulate the same conditions?

..an update Interestingly the King inverter interrogates the CID 92 and 42 values rather than the '6X' series. 92 is almost identical to 63 and the Pylontech responds to both. On initial startup both the MAX and King interrogate 4F, protocol version. The reduction in charge current limit (from Pylontech BMS) starts from 90% SOC and reduces to 10% at 100% SOC. It is not linear however and does not correspond to the SOC readings. From 92% to 99% it stays at 80A and when it first hits 100% it is still at 40A. Simulating the charge reduction can be done in 3 ways, reading the SOC from the console port and just using the SOC to approximate the charge reduction or from the RS485 or CAN ports and more accurately setting the charge current (as the inverter/BMS link does normally - when it works!) I read in various places that the common way to overcome the problems with BMS communications is to set the inverter to USE and then set the corresponding voltages. This obviously works but there is no control over charge current. The batteries are obviously attempting to change this from the values observed from reading the charge current limit value from the BMS. Question is; will continuing to charge at a higher charge rate than the charge current limit when the batteries are approaching full charge have any adverse affect on the life of the battery?

So here is the story to date - and a work in progress fix for the brave.. No update on a firmware fix - I'm not holding my breath.. So how to fix? Simulate what happens when the inverter works correctly. First step - capture the BMS messages and see what's happening - the critical phase is when the batteries are close to full charge - the charge current is slowly reduced from 150A to 10A. The inverter continually polls the batteries for frames CID 61, 62 and 63. The CID2 frame 63 contains the upper and lower voltage limits (53.25V and 45.00V respectively) and the current charge limit. The current charge limit is in A but seems to be 10% of the value set by the inverter. The inverter has various possible settings that can be obtained with the QMCHGCR command - in the case of the MAX II the values are 010 020 030 040 050 060 070 080 090 100 110 120 130 140 150. The chosen value is the nearest to the value that is available, i.e. if the value from the battery is 5.18A then the inverter sets the charge to 50A. Reading the value from the frame 63 it is possible to send MNCHGC messages to the inverter to control the charging current. For anyone that wants to know the SOC from the batteries then this is available in frame 61 It seems that when the SOC is at 100% the inverter stops charging. In the QBMS message the battery stop charge flag gets set, and the charging status in QPIGS changes. Monitoring the QPIGS and QPIGS2 messages it seems it doesn't stop totally as the power from the solar exceeds the power used. According to the MAX Communication Protocol it should be possible to control charging (and discharging) using the PBATCD command but I just get a NAK when I try. I have seen this response from commands when they can't be used for some reason so maybe the conditions are preventing it's use - that's still to be investigated. ..to be continued..

From what I see the Pylontech CAN protocol is very different from the RS485 one. The inverter (certainly the Axpert MAX II), as far as I'm aware, only works with RS485, 2 wires (inverter pins 3, 5, Pylontech pins 7, 8. Cable is in the B/RS485 socket on the Pylontech. You would need to insert something in between the inverter and battery. You could use an Arduino (or one of the many variations such as an ESP) and would need 2 x serial ports with RS485 interfaces (such as the cheap boards with the MAX485 chip). Capture the incoming frame from the battery, modify it and send it onwards. Any outbound frames from the inverter could just be passed through.

@TinbumImpressive setup, thanks for the explanation, I guessed it was for grid charging. I'll take a look at Solcast, might be something to integrate into my system at some stage. @WallKI have spent some time tapped into the BMS link between the Pylontech and MAX. I also checked and although the MAX has pins available for RS232 and CAN in addition to RS485 it appears it only uses the RS485 for the BMS. The MAX continually polls for data from CID2 commands 61 (Module discharge volt state includes SOC @ position 22/23), 62 (Alarm info status) and 63 (Battery charge/discharge management) Frame 63 has the upper limit voltage data (reads 53.25) so you would need to modify this frame on it's journey from the battery to the inverter.

No it's not. I've not used a battery balancer but from what I read it is more suited to lead acid technology. A lithium battery should have some form of battery management system (BMS) to manage the individual cells inside the battery. The commercial batteries (Pylontech etc.) allow you (or the inverter) to communicate with the BMS and read battery status - voltage, current charge/discharge, state of charge, alarms, temperature and other parameters. Due to the different technologies of lead acid v lithium the discharge curve is very different (as shown in the graph above). In systems with lead acid the recommended maximum discharge is between 40% and 50% of the batteries capacity. As the capacity reduces so does the voltage. This can be used to trigger a recharge of the batteries (typically using a generator in an off-grid installation). In the case of lead acid, if a large load is connected while the batteries are approaching the 40-50% discharge the batteries will have capacity to continue supporting the load (and a recharge will probably get triggered). In the case of lithium this doesn't happen. The battery voltage stays high throughout the discharge of the battery (see graph) , only dropping very close to fully discharged. If you use the voltage to trigger a recharge as with lead acid, and a load is connected then the battery will have insufficient capacity to run the load so will shut down. Also, typically, lithium batteries can be discharged to around 90% (Pylontech US3000C and US2000C state 95%) so connecting a load at this level of discharge will most likely shut down the battery. So what is the solution? Obviously not the traditional voltage trigger but as the battery can be interrogated to find out it's SOC it is easy to use this to trigger the recharge. This is what the system I have designed does. It sets upper and lower thresholds for SOC and when they are reached it starts or stops a recharge. In my case this is from the grid but as it is just a relay operating this can be used to auto start a generator. In my system I also have what I call 'Solar Stop'. I have a system with solar panels. Typically a charge will start overnight or early morning. The 'Solar Stop' monitors the power consumption of the load (the power out of the inverter) and the amount of solar generation (power in to the batteries). When the power in exceeds the power out it stops the recharge from the external source so the 'free' energy is used rather than the 'bought' energy. From what I see, the system you have is an Axpert inverter. This has a communication connection you can use to monitor the performance of the inverter but I don't think it can communicate with lithium batteries (the King and MAX (at least the one that doesn't have a bug!!) have a BMS connection). The system I have designed caters for this as it has 2 inputs that can be used to connect to the Axpert inverter and Pylontech batteries and communicates with both to control recharging.