I’m trying to automate loads to increase overall system efficiency and the MPP Operation Mode seems the perfect indicator except that it’s hard to determine exactly why it’s clipping at times.
Later in the day as the batteries approach full this kind of clipping will mean that the battery is not accepting charge fast enough so production has to be ramped down to maintain the grid set point and turning on loads will be useful.
However at this earlier point in the day this rather complicated VRM widget shows the situation: MPP operation mode is yellow, grid is blue and being held stable around a setpoint of 0, red is loads, purple is amount charging the battery, green is PV yield and white is solar irradiance. Clearly loads and charging are mirror images of each other to keep the grid at the setpoint.
Maximum current (SmartSolar RS 450/100) is 100A but it’s only at 89A. Maximum output is more than 5500 per unit in theory (I have two of them in this installation) but output now is a fraction over 5000 and each MPPT is well within their individual 4000 maxima. The MPPT voltages are just under 200. There’s room to charge the battery at a higher rate and it’s still well below full and in bulk. There’s no sign of temperature issues.
It seems logical that this clipping is limiting production to protect the equipment from the oversizing of the panels but since it’s at a lower point than all specified limits how do I detect that fact from within Node Red?
[Note that the MPP operation mode is not normally available in VRM but is being fed in from a virtual device.]
Theres charging mode, MPP mode and error code in the hidden data. But as long as the MPPT does not run into an actual error, the MPP mode just changes between tracking and U/I limit (or off during the night). So it either regulates power based on MPP tracking or because its running into either a voltage or current limit on the battery side.
If you want to compare current MPPT power versus what would be possible based on irradiation, you would need to use a SolarSense 750. So you could in theory switch a load based on “missing” PV power.
Can you be a bit more specific than “hidden data”? I have access to what’s in Node Red and can also check dbus-spy for paths not published to the Node Red implementation - I’m simply looking for something to clearly differentiate between the different reasons it might limit production and go into a value of 1…and not coming up with anything so far…
I meant data thats not directly visible in either VRM or VenusOS. But to be fair, the mentioned modes are not really hidden, they are just translated into text when shown on some UI.
MPP mode 1 is simply U/I limit, meaning the limiting factor is either battery voltage or current. But AFAIK theres not more details as to which exact limit is reached.
I also dont really see why you would need to know the limiting reason. All that matters is that the MPP is being U/I limited, so there is room switch a load on. Even if you would know the exact reason why, you would still not know by how much the MPPT is being held back. And thats something you need to creep up to.
At first i also tried to work with the MPP mode, but switching based on just two states is always a compromise.
On a small Victron setup ive got a variable load. To adjust the load, i simply read the battery voltage, and compare it to the absorption voltage. If the absorption voltage is met, then every 10s i add 1% more load. If the battery voltage falls to absorption minus 0.5V then i reduce the load by 5% every ten seconds, Thats it. Of course its not perfect, the load bounces up and down a few percent all the time, but it lets the system use potential PV power fairly well without the need for any additional hardware or complex algorithm.
You’re making the same assumption that I did - that the limiting will stop if a load is turned on - but that’s not the case…in the above chart I turned on a load at 11:42 and it made no difference to the limiting, just reduced battery charging instead. So I’m looking for a way to distinguish between the conditions at this time and those when closer to battery full later on…that’s the whole purpose of the post.
For example I can read the settings for maximum current and what’s actually coming through but I can’t use that as a way to eliminate this period of limiting from consideration because there’s no hard boundary to test against when actual current is well within spec. I’m seeking how to tell if limiting is happening because of the battery or some other reason basically…meanwhile when the battery is approaching full there’s nothing going on like programmed maxima being reached, it’s simply accepting a much smaller amount of charge and the limiting is happening to keep the grid set point stable.
You’re lucky to have a variable load. All I have is a few different 3000W thermostat controlled options that may or may not actually draw load when switched so I can’t do an approach based on hunting with negative feedback like yours.
And yet nobody is answering the question asked…detecting how much sunlight is falling on my panels is not what I’m asking…I also long ago figured out how to tell when the battery is almost full by checking several different things including the limiting…I can come up with heuristic approaches based on times of day and hard coded numbers and scrape the Solcast API and any number of possibilities but my focus here is on whether I can detect the difference between limiting when output could usefully be increased by adding load versus limiting when load is not the issue…
Can’t answer that for you. It may not be possible and no one may be able to answer that beyond the product engineer who is unlikely to be looking here.
Victron’s own forecasting doesn’t seem able to calculate this sort of information.
The best way to understand what could be used is to have a comparison between the amount of actual sunshine, in real-time, correlated against current production. The mppt will have no clue until it is ramped up to maximum production.
Do you have a three-phase hot-water tank? You could run it with a variable-frequency drive. Variable-frequency drives are designed for motors, so they have to change the voltage depending on the frequency. A motor operated at, say, only 25 Hz may only be supplied with about half the voltage. This can be put to use for power control, because the converters can be controlled.
Try to look at a MPPT as a standalone device. Only itself, without any other connected device in the Kirchhoff’s power network.
Now, looking at the firmware, the MPPT 450/100 and, in fact all Victron’s MPPTs, are looking for the voltage at its terminals.
As long as that voltage is at (near) the set (target) voltage, the MPPTs will sit in the limited mode, producing exactly as it’s needed to keep the voltage there. And it’s reporting to the system the limited mode (1).
Now, when that voltage is decreasing, it doesn’t care who is “dragging” the voltage down. It will just try to bring back the voltage to the set point by two methods, depending on the dV/dt.
If the dV/dt is small, it will pulse the working mode from (1) - limited mode to (2) - full mode for small period of times (1-2 seconds) and look for what’s happening with the voltage. If it’s back, it will remain at (1).
if the dV/dt is big, it will remain in (2) - full mode, up until close the set voltage and then will return to pulse mode and ultimately to (1).
So, you see, you can’t know, from MPPT point of view who’s dragging the voltage down.
You need to implement your own logic for that, if you know what’s happening in your power network.
It could be a place to work on as on that file you have lots of information, ranging from voltages, currents, limits and so on.
Also there is a function there for distribution of currents among chargers/mppts and you can have an idea about how hard a mppt is loaded.
If a Cerbo or Ekrano is in use, my understanding is that data on space-weather irradiance conditions is also used to support the control system. So it’s not quite as trivial as that; depending on the system configuration, other factors are taken into account as well. Exactly how it works is likely to remain company know-how.
Yes Victron’s forecasting is not that good, but you can easily make a far better one. I use home assistant, together with publicly available free coordinate based 15min cloud cover prediction, together with daily coordinate based sunset, sunrise times.
Then look at Victrons data, and you get a very accurate forecasting
@ISavedNoKat “this clipping is limiting production to protect the equipment from the oversizing of the panels but since it’s at a lower point than all specified limits…” - Can you list “all specified limits” that you have considered?
That’s what the fourth paragraph of my original post was - that I could find values in the right ballpark/heading towards maxima but none of them were at any limit that I’ve been able to find including browsing everything in dbus-spy for the solar chargers…basically at around 10kW production for the two RS Solars together that I have at this installation it stops letting any more power through…almost certainly because an algorithm (probably the one in dvcc.py) is coded with margins for error to avoid exceeding spec - it includes a number of comments that hint in the direction of such strategies…
In terms of the exact thing you’re asking 89A isn’t the 100A technical limitation of these devices but it’s close enough to think it may be part of the equation governing the decision to give one example.
I assume your battery has a BMS. You haven’t mentioned one AFAIK. The BMS will be controlling any charging/discharging devices including your MPPTs. From my experience the BMS Charge Current Limit (CCL) will throttle your MPPTs near or at 100% SOC. The CCL is progressive, not ON/OFF. So if you are at 100% SOC with your MPPTs throttled due to CCL (or in fact due to Charge Voltage Limit CVL) and you add a big load, it won’t instantly come from the MPPTs because the CCL is still at or near zero. Instead, the battery will supply the load until the SOC is reduced enough to release the CCL clamp, and only then will the MPPTs kick in.
My remedy is to limit the SOC to 96% or so (whatever keeps the CCL and CVL at max) then your MPPTs are free to supply loads or even Grid feed-in.
CCL doesn’t affect discharging.
The battery will discharge due to voltage drop on the DC bus caused by the load drawing it down, this will trigger the mppt’s to generate again raising the bus voltage and stoping the battery from supplying. It is the ramp time of the chargers that allow this to happen. This will work despite CCL still being 0.
CCL reductions certainly are progressive, but it is a poor way to control charge.
If I look at a popular brand, it is a couple of hops from full charge to 0, not really an elegant way to manage charge.
The right way is to vary CVL, which will inherently throttle PV production and supply from battery when the BMS lowers its limit.
