Search results

You can use either Pylon or SMA. I recommend SMA for the Solis inverter, mainly because Solis apply some Pylontech specific logic for the pylon protocol. That logic tends to affect how BMS voltage is used, plus prevents (from what I've seen) recharging until the SOC drops to 97%. Of course...

There's no reason you can't test out v1.17.5 and disable Auto Voltage Control, it will still send static voltages appropriate to each charging stage.

57.4v is a high charge voltage assuming a 16s battery. General guidance is to bulk charge at 3.45v per cell, so 55.2v. This will give sufficient headroom for balancing without triggering OVP, etc, but also fully charge the battery.

Hi @paulsteigel, the existing auto charge current control does similar to this already. At the moment, we're working on controlling charge current through dynamically adjusting the requested CVL. That's the more effective way to do it, assuming your inverter regulates CVL properly...

If you are charging at a higher C rate (which a max of 180A would suggest) then yes, charge_v_factor_setting can be set to be more aggressive. At the same time, current control is recommended (with default float voltage and a sensible OVPR setting, but we've already gone through that in some...

Yes please.

Thanks @silverstone, hopefully the new auto voltage control will make it easier for you to keep your battery balanced.

I don't think it's best to leave the old logic in, no. Supporting two sets of logic is more work, plus testing indicates this solution should work effectively when used in conjunction with Auto Charge Current control.

V1.17.5 has been released on GitHub: https://github.com/Sleeper85/esphome-jk-bms-can Changelog: - Auto Charge Voltage Control function rewritten - EOC cycle threshold added to reduce premature triggering of float phase This is a small release whilst we continue to work towards a modular and...

@silverstone, let's move this conversation to GitHub issues. It's making this thread super long for anyone new wanting to come in. Can you create two issues? - Current control oscillation - Premature triggering of EOC

You can save the URL created when you've set up the history plot, that might be the simplest approach. One last request, can you provide a chart showing max cell voltage for the period 13:35 to 13:40?

If you go to the history graph for at least one of the entities, you can set a time range like below. You can add in all the entities that you need to in this pane, then screenshot the whole lot as needed.

I have been unable to replicate your issues. A zoomed in chart focusing just on the oscillation period would be appreciated. Please provide requested current & actual current for that same shortened period, as well as the exact settings used for current control, alongside your max charging...

There's an enhancement issue on the GitHub repository, you're welcome to follow and comment as required. As for every parameter being exposed, I guess that's personal preference. For me, the more that is exposed, the more opportunity there is to make mistakes when tweaking things. Many of the...

I think it is wise to turn on the 'stop on BMS error' or whatever the setting is called on the Deye inverter. Losing CANbus connection with a resulting full voltage and current charge is a Very Bad Idea. I'm testing new voltage control logic at the moment, only implemented yesterday however...

Make sure you're looking at the balancing sensor, not balancing switch. The balancing sensor should only come on when the BMS is actively balancing cells. Did it never come on, even when max cell was over 3.45v?

If you're fighting imbalance now, starting at 3.43v to get it under control then increasing to 3.45v later on makes sense to me. 3.45v is fine if you're regularly going to take cells above that, but if the target is 3.45v then the balance time is much shorter. The float transition is controlled...

Several thoughts for you: Try increasing OVPR to 3.55v - that'll reduce the steepness of the current reduction as you increase the voltage range over which current is reduced. Don't increase the float voltage as that increases the steepness. Current tapering starts from float voltage. Set the...

When you have time, please could you share a graph showing max cell voltage, requested charge current and actual current, covering the period where you had default curve settings? What exactly do you mean by unstable? Regarding 'If BMS charge switch is turned off, then discharge current is sent...

@silverstone, it's alway possible for you to simply disable the auto voltage control if needed. The voltage delta you have the moment is quite large considering most cells aren't even near the knee point yet. You're correct, your battery will not balance with your current settings, especially as...

Interesting, that suggests that either the inverter is not respecting the CCL, or there's a calibration issue on your BMSs, but that would be a hell of a difference... As for the resistor, it's up to you.

Often when the run is short and there are no more than 2 nodes on the CANbus then you can get away without a termination resistor at both ends. The spec calls for it though, and it will likely reduce errors. If / when there's a multiBMS solution over CANbus, it will become more critical.

It's quite a nice unit, the Atom has sockets on the underneath that mate up with the pins on the adaptor. It essentially just plugs in. I've just spotted that it's now marked as EOL on the M5stack site - not great news.

Like I said, feel free to submit a pull request. I don't think we can preemptively document pinouts for hardware that we're not using internally and that isn't tested by us. It'll become a burdensome task rather quickly.

Can you attach your YAML (I'm having some sort of flashback here) and we can review?

Yes, I've been looking at getting that base to use with some of my non-S3 atoms, but it looks like AliExpress is the least expensive option for a standalone base.

Which CAN base are you using? The one referenced in your link is not the one recommended as it precludes any wired connection to the BMS. This is the one recommended: https://docs.m5stack.com/en/atom/Atomic%20CAN%20Base These are the relevant pins used per Atom model. If you have the other...

This is on the list to do, but as you can probably appreciate, life gets in the way. If you want, please feel free to submit a pull request with the requested changes to the readme. We can then review and merge if appropriate.

If you are reviewing logs via the web server, you're likely hitting memory limits on the ESP32. That's likely causing the reboots. As for inverter comms, I don't have a Deye so know nothing about the settings.

Hold on, cell voltages are zero? This means you do not have data flowing from the BMS to the ESP32. If wired, you would check the wiring between BMS and ESP32. If over BLE, ensure that the MAC address set up in the YAML is correct. I don't know for certain but I also think that only one BLE...

What is the CANbus Status sensor state? If off then that suggests that the inverter is not sending an acknowledgement message. If that's the case, either the CAN wiring is the wrong way around or possibly wrong profile is selected on the inverter.

https://github.com/Sleeper85/esphome-jk-bms-can/blob/main/config/config_atom-s3-lite-esp32-s3.yaml If you reference this file, you can see that USB_SERIAL_JTAG is required to make the S3 lite work correctly when using the wired connection to JK BMS. The version under development will be more...

I don't personally run the S3 lite, but I know there's some ongoing discussion on GitHub at the below link: https://github.com/Sleeper85/esphome-jk-bms-can/issues/27 As for the warning during compile, I've seen that since last year without issue.

The logic of the code means it will proportionally disregard a cell that is lower than the majority of cells. If you were to add the 'missing' 50mv to the requested CVL, that additional voltage is unlikely to boost the lagging cell. Instead, it's likely that it'll push a higher cell more...

As it's a bus with the inverter at one end, ESP32 at the other (for now at least), put the 120ohm resistor across the high and low on the ESP32. That will properly terminate the bus, reducing errors.