Open gitisgreat2023 opened 1 month ago
Do you agree that the offset should be in percent of the current limit?
When coding the support for multiple inverters, I thought about this already. It would be nice if the DPL learned, for each DPL inverter instance, whether or not the AC output matches the limit closely or not. If not, the relative difference could be recorded for a pre-set time or number of updates or until a range of limits was set, and then that difference could then be taken into account for future calculations. Does that sound reasonable?
No, I would go for an absolute correction. But yes, you're reasoning is exactly like I implemented it! Just add the set/get difference to the DPL value that is going to be set. I'm running now this scheme on two inverters since almost two months. My implementation uses absolute values. However I box this compensation with a max(min(delta,250),-250). I also update the compensation value only every 5 secs, to avoid oscillations.
For beta testing you could implement it say, with the 5 sec update frequency and box it to say +-75W and wait for the testers feedback.
To be honest I see sometimes a kind of oscillation with the charger and inverters going on/off. That happens a sometimes and then it catches itself. So some finetuning is probably still required, I run it with aggressive settings (every 0.9 sec the shelly updates the values), power meters and DTU are read out every second. That can be due to one of these factors, too lazy at the moment to chase it down.
Is your feature request related to a problem? Please describe.
See the issue in this discussion. In DPL, when the set limit value for the inverter doesn't match the actual value, the target value isn't reached.
Describe the solution you'd like
A set/get compensation for each inverter.
Describe alternatives you've considered
I implemented a set/get compensation in a Shelly script, added the difference between the set limit and actual produced inverter power. Every 5 seconds I update that value, thereby avoiding oscillations due to the response time of the inverter setting a new limit. This solution works perfectly fine now for four weeks, applying it on two inverters individually working parallel on a shared battery.
As I currently anyway already need the Shelly script to distribute the power on the two inverters, I'm happy with my current solution. But others could profit from having it available in OpenDTU-OnBattery itself, for example if there is for some reason an asymmetry in the inverter strains (not equal cable lengths etc) which typically causes a set/get mismatch.
Additional context
The DPL convergences to the target value if and only if the get (read) value from the inverter is indeed accurate. If for example cable losses between the output of the inverter and the meter are substantial, the target value won't be reached accurately. I also didn't change the 5 secs over the 4 weeks period, it might be for these relative small changes (say max 100 W) the timescale the inverter reacts is shorter. I didn't study that.