A few follow up question for Bluetti, based on Craig1’s observations: What is causing the PV input voltage to remain low after the shading has passed and the panels are in full sunlight? Is the MPPT also applying its own voltage to control/balance the charging rate from solar by reducing the potential difference in voltage? If this is the case, then what is the AC200L actually reporting for voltage in the PV screen of the app? Is it what is coming in from the panels, or is it what is the remaining voltage after the MPPT does its thing?
@rgb: I am using a program I found from ftrueck called bluetti_mqtt (GitHub - ftrueck/bluetti_mqtt: MQTT interface for Bluetti power stations). It integrates the AC200L and other Bluetti products into Home Assistant, allowing one to view the output power, input power, control the AC output, DC outputs, and more. Essentially, it simulates the app and acts as a middleman to allow Home Assistant to communicate with Bluetti products over bluetooth. However, I don’t run Home Assistant, but I do manage an Influx DB for another project. It was an “experience” hacking that code to import the data into Influx DB, but I did manage to get it working… eventually. I then use Grafana to generate graphs from the data stored in the Influx DB.
@aaron33: To add a few details to your question - the voltage chart is what the AC200L is measuring (and what the app would display). I believe this is the voltage difference between the PV- and PV+ wires in the DC input port of the AC200L In my specific situation (and I see @rgb’s is a little different), the shade from a tree nearby starts to cover up just a few panels (which are wired in series with panels that are still in the sun. Normally, I would expect the voltage to drop (since these panels come with bypass diodes installed) in this situation as the MPPT controller would decide that it would be more optimal to just use the panels that remain in the sun (and get the full current from them) instead of trying to use all panels in series (but pull a much lower current - essentially treating all panels like they are in the shade). Indeed, on some days the AC200L does do this correctly. In this example from August 31st, between 15:00 and 15:40 you can see the DC input power slowly drops as the shade creeps over each panel.
Moreover, you can see the DC input voltage drop during that time as the MPPT decides that it is more optimal to use those bypass diodes in the panels that are shaded (it doesn’t actually think about this - the MPPT is just looking for the max power point - but it has this effect). Once most panels are in the shade from the first rack, the voltage jumps back up as it is more optimal to use the second rack (which is still in full sun and is in parallel with the first rack). This seems complicated but the AC200L masters this with no problems (on most days), which I find impressive. Good work Bluetti!
However, (and this is a big however), sometimes the MPPT controller glitches out as I described above and I think it is getting stuck at a particular “max power point” value and not “reevaluating” what the new maximum power point should be (because more panels are in the shade now and it needs to check again to find the new max power point). I hope Bluetti can fix this as the MPPT controller on the AC200L is otherwise impressive. I should note that unplugging the PV array from the AC200L and plugging it back into the AC200L has fixed this “glitch” every time I have tried it (as described in the previous post). It is almost like the MPPT controller just gave up trying to find a new max power point until it gets manually reset. This seems like a DSP software bug that hopefully Bluetti can fix.
For some additional context (if this helps), here is what the PV array looks like (each panel produces about 100W of power in full sun and has about 25V open circuit, which puts this array well within the upper limit of the AC200L. The green links represent the panels being joined in series.
Hi @Craig1, We have reviewed the information and believe that the AC200L is functioning properly. The firmware upgrade has also made a positive impact. The drop in charging power may not only be caused by shading but also by reduced sunlight intensity. We recommend placing the solar panels in an area without any shading, as shadows not only affect the efficiency of the panels but can also damage them over time if exposed for long periods.
Additionally, to optimize the solar charging performance, we have pushed a new firmware DSP v2098.22 and ARM v2134.07 for you. Please upgrade the firmware and test if it improves the situation.
Please do not load any device when upgrading it.
1 Like
@BLUETTI_CARE: I checked last night and this morning, but it appears that no updates are available for my AC200L. I figured I probably have to wait 24 hours before updating, but it has been over 24 hours now and no updates are available.
I realize the shading situation isn’t the best right now. Long term, I would like to move the panels to a more optimal location (but this may not be possible for a while). So, for now, having the system pull as much as it can out of the shaded array (in the afternoon) will be beneficial. Thanks again for all your help with this. It is appreciated.
Serial number: AC200L2352000774061
Hi @Craig1, I am sorry we confused your SN number with another customer, that is the reason why you didn’t receive the new ARM and DSP. I have requested our engineer to push them again, please upgrade it later.
@BLUETTI_CARE: Thank you! I can see the update now. In order to monitor the AC200L in person after the update, I plan to delay this update until this weekend if that is OK.
I will report back after I get this installed.
Hi @Craig1, Thank you for getting back to us so quickly.
We are expecting your test result.
Please feel free to contact us if you need our help.
@BLUETTI_CARE: I installed the update last night. Given that this issue doesn’t come up every day, I will monitor the AC200L over the next week and report back after that. So far everything seems to be working, but it was a fairly cloudy day today, so it wasn’t a great test.
Thanks again for your time and help. Hopefully this update does the trick!
2 Likes
Hi @Craig1, Thank you for letting us know. I am glad to hear that.
I hope everything goes well. Please feel free to contact us if you need our help.
@BLUETTI_CARE: I have been monitoring the AC200L over the past week with the latest firmware you sent (DSP 2098.22, ARM 2134.07) and the MPPT controller has been working great. It has tracked the partial shading in the afternoon without glitching out. It also seems to handle clouds better. That is, previously (before the latest update), if the AC200L was pulling in 1.2kW, then a cloud came over quickly, the power would sometimes drop to 0W and would take a few moments to recover. This wasn’t a huge deal (unless there were a lot of small clouds) since it would self-recover eventually. However, it appears that this update also fixed this issue.
Here is a sample of the PV input power for a mostly sunny day with a some clouds moving over.
The AC200L did a great job with the clouds and afternoon shading.
I feel like it would be easy for a company to ignore my complaints, sweep it under the rug and move on with a new product. But you have done the exact opposite, going out of your way to make sure my AC200L is working the best it can. Thank you! Keep up the great work!
1 Like
Hi @Craig1, Thank you for sharing this good news and your encouragement, I am glad to hear that!
That is very kind of you. It is our pleasure to help you.
1 Like
@BLUETTI_CARE: I realize this is an old topic. I can create a new one if needed - let me know what you prefer. I believe this issue is related the the latest firmware update you sent me (DSP 2098.22, ARM 2134.07). Before this update, I didn’t notice any issues with the B300 that I calibrated. The issue is that when charging, the B300 SOC % jumps up - sometimes multiple times. In some cases, I have found a total combined jump in SOC of 34%. This causes the system to reach 100% SOC, meaning I can’t collect any more solar energy. Presumably, if the SOC % was more accurate, I could have used that energy the previous day, allow the B300 batteries to charge all day without hitting 100% SOC. Here is an example from last week when this happened on a sunny day.
The charging starts out looking normal with a gradual charging rate, but then at around 14:15, the blue SOC % line starts rapidly increasing. In this chart, the green line is the AC200L internal pack, the yellow line is the first B300 in the chain, directly connected to the AC200l. The blue line is the second B300 in the chain, connected to the first B300.
During this time, there was no AC input, nothing was directly connected to the B300 batteries to charge them directly, there was a small AC output (less than 5W, so it isn’t reported), and about 10W of DC output, consistently. The PV input to the AC200L was fairly constant during this time at about 1.2kW, as shown below. The sudden drop in PV input to 0W on the right side of the chart is because the SOC hit 100%.
From what I have read, after a firmware update, it is a good idea to re-calibrate the SOC %. So, I did that last weekend. Below is the combined SOC as reported on the AC200L display during the calibration.
I charged the system up to 100%, then disconnected AC power and PV input and drained the system down until the AC and DC output shut off automatically, I then plugged the system back into AC to start charging. In addition, I reconnected the PV input (though it was a cloudy day). I figured this shouldn’t hurt anything as the AC200L is configured in “standard” charging mode, so it should ensure that it charges at about 1200W consistently, no matter how much PV there is. Once fully charged, I disconnected the PV input and AC input and then I drained the system back down to 0% when it clicked off, I began recharging, using a similar procedure. If you are interested, the AC input is shown below during this calibration process.
It looks like the AC200L did a good job balancing the PV and AC inputs to maintain a 1.2kW charge power. The PV input is shown below.
The AC output during this calibration process is shown below.
Right after the calibration process, I noticed that both of the B300 batteries seemed to stay in sync, which looked promising, as shown below.
However, after a few days of charging and discharging using only PV (not hitting 0% and not hitting 100%), the SOC % jump happened again, as shown below at around 14:50.
The jump looks smaller than before the calibration, but this had only been three days of “normal” use since the calibration process. Also, it looks like the AC200L internal pack slow-jumped a bit at around 14:40. I believe that the longer the system is used “normally”, the larger the jump can be. Though, I am not exactly sure what triggers this jump as it doesn’t happen every day. Sometimes it only happens about once or twice a week. Sometimes more often.
Now, I would have figured that this was just normal behavior for this type of battery system because it is hard to estimate the exact SOC %. However, I know that this exact system can do much better. Back when I was using DSP 2098.18, ARM 2134.04 (so this was before September 13th), I had no issues with the SOC % jumping on the first B300 attached to the AC200L The AC200L SOC % also did not jump. However, the second B300 (blue line) did exhibit this behavior, but that is completely my fault because before last weekend, I had not calibrated it. The other B300 and internal AC200L pack had been calibrated way back in May or June (I don’t recall exactly when).
So, I know this system can work, however, I don’t want to go back to DSP 2098.18, ARM 2134.04 because (as described in previous posts), the PV input would glitch when some panels were shaded. Is it possible to have both the PV input fix and the battery SOC % jump fix in one update at the same time? Or, did I not do the calibration properly? let me know what you think or if you need additional information. I can definitely try calibrating again, but I don’t want to keep calibrating the system over and over if it isn’t going to make a difference (and I have already run two calibrations last weekend). Granted, the system is still functional with a broken SOC % indicator, but it is more difficult to use when you don’t know if the current SOC is 30% like the display says or maybe 50% or maybe something else. This means that I can’t use the solar energy I collect optimally because I don’t know how much battery is left and I don’t want to drain the system to 0% all the time as I have heard that can damage the battery.
Update from this morning: I did notice that there was a BMS update for the AC200L, so I attempted that this morning. I will give that update a shot, but there are no release notes, so I am not sure what changed. Moreover, given that the ARM / DSP update broke this, I am not convinced that the BMS update on the AC200L will fix the issues with the B300 BMS. For what it is worth, I upgraded the AC200L BMS to v1043.13. If you know this fixes the issue stated above, I can try calibrating again, but I don’t necessarily want to unnecessarily calibrate given the time commitment required to do so.
Hi @Craig1, The new BMS functions to optimize SOC performance, correct inaccurate SOC readings, and adjust the maximum capacity based on actual conditions.
Upgrading is the right step, as it can help resolve this issue.
We do recommend that customers recalibrate the battery after upgrading the BMS. Please perform the calibration and then test the battery’s performance again.
@BLUETTI_CARE: Thanks for the response. Given the time required to do a calibration, I will give it a try this weekend.
1 Like
@BLUETTI_CARE: I ran one calibration on Saturday (with the updated AC200L BMS v1043.13), draining the system to 0%, then disconnecting all loads, connecting AC and solar (in normal charging mode) and let the system charge to 100% with the 2x B300 batteries connected. The SOC % is shown below for the system (top) and for the individual battery packs (bottom).
It has only been three days since the calibration, but I haven’t noticed any SOC % jumps, which is good. I suppose those could come later, but for now, this looks promising.
However, the second B300 in the chain seems to be exhibiting an issue where it charges slower and drains faster than the first B300 in the chain. Thus, its SOC % of the two B300 batteries slowly drift away from each other even though they are directly connected. Nothing is connected to the B300 batteries input or output. Just the P090A cable connects the AC200L (green line bottom chart) to the first B300 (yellow line bottom chart), which is connected to the second B300 via another P090A (blue line bottom chart).
(Charts shown above are since the Saturday calibration to the time of writing)
I’ll continue to monitor the system. I might try another calibration to see if this fixes the issue.
Otherwise, perhaps I need to swap the B300 batteries so the second one in the chain would now be the first one in the chain.
I’ll provide another update (perhaps in a week). Hopefully the SOC% jumping issue is fixed though.
As always. thanks again for the help!
Hi @Craig1, Thank you for getting back to us so quickly.
Our battery packs maintain a dynamic rather than absolute balance.
A certain amount of SOC (State of Charge) variance is acceptable, and multiple recalibrations can help optimize its performance.
We look forward to receiving updates from you.
@Craig1 How has the system been working since then, for the SOC gap drift between B230 batteries, and the MPPT properly tracking?
I’ve experienced these issues as well with the 200Max, and some were resolved by Bluetti (eg resolved: MPPT tracking getting “stuck”
in a low charge state, and needing to remove/replug the solar cables), and others they weren’t able to fix (eg SOC gap between B230 and main unit).
@jCs: After the updates from Bluetti, I have not had any issues with the MPPT controller - it has been working well. However, like you said, the SOC gap between the battery packs doesn’t seem to be as easy to fix. I think there might be two issues here.
-
The main unit SOC and the expansion pack SOC don’t stay within 10%. For my system, I think this might be because of the limitations of how much power the main unit can send out or pull from expansion packs, but I am not sure on this. I would imagine that an AC300 / AC500 system (if I had one) would not experience this same issue because with those systems, all packs are the same capacity. The AC200L has an internal capacity of ~2KWh, but I have 2X B300 packs plugged into it for a total expansion capacity of 6KWh.
-
The two expansion B300 batteries (that are directly plugged into one another) don’t stay at the same SOC. I’ve tried re-calibrating quite a few times with no luck. The second B300 in the chain always ends up at a lower SOC, given enough time. However, I have some evidence that indicates that this might just be reporting issue. That is to say, the B300 packs might actually be in sync (at the same SOC roughly), but the second B300 is reporting a lower SOC than what it is actually at. Take this chart from a few weeks back. Here, the system was charging from PV. The 2 B300 packs started out way out of sync, but as the charging continued, the second B300 (blue line that started out lower) glitched up to “catch up” to the first B300 in the chain (yellow line). This makes me think the second B300 was just reporting a lower SOC than what it physically was at, but during charging it realized it was reporting the wrong SOC and corrected. Notice how at about 13:45, the two packs were essentially perfectly in sync - and stayed that way (and then proceeded to slowly drift off again). There were no significant changes in average PV input or average AC / DC output during that time to account for the blue line jumping up so much.
One thing I am thinking about trying is swapping the order of the 2 B300 packs in the chain so second pack in the line would be directly connected to the AC200L and the first B300 in the chain currently would be moved to second place. I don’t think this will fix this issue, but hopefully it can provide more information on what might be going wrong - either something with that second B300 or the connection order.
1 Like