9 minutes ago, plonkster said:

dbus -y com.victronenergy.system /Debug/BatteryOperationalLimits/SolarVoltageOffset SetValue 0.2

Like so, is it done?

On 2017/08/05 at 12:24 PM, plonkster said:

I have a somewhat improved version of this by now.

Where and how do I install battery.py?

You knew I was going to end here ... 

1) Going to document it.
2) And I going to post suggestions on the V sites.

5 hours ago, The Terrible Triplett said:

Like so, is it done?

Yes, until the next reboot :-) It's only in memory. As you can see, it is a debug value, used to perturb things by people who know what they are doing (most of the time anyway).

You can create a file called /data/rc.local, make it executable (with chmod +x), and put that line into that file. Then it will run every time the system boots.

/data is never cleared during an upgrade, so it will survive updates.

Then your solar chargers are always set 0.2V higher than the Multi, which aids in feeding in the excess.

But this is being worked on as we speak. Main reason: Pylontech wants a charge voltage of 53.2V and the BMS disconnects at 54V. So it has room for a mere 0.8V. Add a couple 100mV valibration issues, a couple 100mV loss on a cable here and there... and the damn thing either doesn't work, or it overvolts the battery.

But keep ears on the ground. The plan is to solve this by the time 2.20 is booted out the door.

20 minutes ago, plonkster said:

The plan is to solve this by the time 2.20 is booted out the door.

I'm om v2.20~67 - did the reboot, will keep my ears to the ground.

Question: Cron job. Want to run this, but dbus dir is not there.

0 2 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue 50
0 6 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue -- -1

What I want to play with:
At 2am, run off batts, max 50w.
At 6am, switch back to full power, leave them batts alone.

Point me in a direction please?
And how to delete them the above cron jobs?

1 hour ago, The Terrible Triplett said:

dbus dir is not there.

/usr/bin/dbus is a binary, what in windows speak would be a .exe.

Quote

root@ccgx:~# ls -l /usr/bin/dbus
-rwxr-xr-x    1 root     root         11303 Sep 12 22:22 /usr/bin/dbus

Quote

root@ccgx:~# which dbus
/usr/bin/dbus

Well actually it is a python script cleverly disguised as a binary.

1 hour ago, The Terrible Triplett said:

0 2 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue 50
0 6 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue -- -1 

Remember the timezone of the device is in UTC. So 2AM would be 0 0, and 6am would be 0 4.

The first will set the limit to 50W. The second will remove the limit and run full power from the batteries (or solar).

1 hour ago, The Terrible Triplett said:

And how to delete them the above cron jobs?

Presumably you added that snippet to a file that you created in /etc/cron.d. If you did, then deleting the cron job is as easy as deleting that file. No need to restart anything, crond notices by itself.

If you use the crontab command instead, then you must remove the root column. Crontabs installed using the crontab command runs as the user who installed them, no need to specify it. Deleting a crontab is done with crontab -r.

You can also look in /var/spool/cron/crontabs. All the crontab command does is drop a file in that directory :-)

Remember that these files will be lost on update. So ideally you want to keep a copy in the /data directory and copy it to /etc/cron.d on each boot.

7 hours ago, The Terrible Triplett said:

Where and how do I install battery.py?

Battery.py, any use in my setup?

So to sum up:
1) Have set the 0.02v settings, DVCC is on, will wait for fix, but theoretically tomorrow it should keep the batts fully charged, with all panel watts going to Ac-out1?
2) Between 2am en 6am, 50w will be used by inverter from batts sent to Ac_out1, back to normal at 6am?

21 minutes ago, plonkster said:

Presumably you added that snippet to a file that you created in /etc/cron.d

Yes, like so, see pic, with the 2 lines and UCT time correction. That's it?

crond might ignore files with funny characters in the name. I don't think _ is such a character, but just so you know. Reason: It allows you to disabled something by simply renaming the file and adding a .disabled extension or something weird, or if your editor drops a backup copy (as is quite common) it will be ignored too.

Should work fine. Easiest way to check is to set a job for 2 minutes from now... and then watch the ESS page on the gui and check if it changes value.

12 minutes ago, The Terrible Triplett said:

2) Between 2am en 6am, 50w will be used by inverter from batts sent to Ac_out1, back to normal at 6am? 

When ess mode is set to keep batteries charged, the max power setting is ignored. It makes no sense to set a max discharge value when you also tell it to not discharge but keep things charged. So this bit is not going to work.

You will have to set the mode back to optimised fist. Simply set /Settings/CGwacs/BatteryLife/State to 1 (that restarts the state machine), and then set the power limit. You can execute two commands after one another in a cronjob by separating them with a semicolon (;).

Then when you want it back in KeepCharged mode, set the state to 9. No need to worry about the power level since that is ignored.

Edit: Also check out dbus-spy, which allows you to browse the entire service tree.

Edited September 27, 20187 yr by plonkster

3 minutes ago, plonkster said:

It makes no sense to set a max discharge value when you also tell it to not discharge but keep things charged. So this bit is not going to work.

Makes perfect sense. Either full batts OR evening limited discharge.

I think at this moment in time, that daytime all power to the AC-out1 with full batts, is the biggest saving generator. Call it: Winter setting.

Come summer that changes. Then use the low discharge with batts on 95%.

Lets see how it goes. At THIS point in time ... before this change, the blerrie data said I need more panels ... 

 

 

Just now, The Terrible Triplett said:

Either full batts OR evening limited discharge.

Remember that when you switch to KeepCharged, the inverter will charge using AC power.

Small trick (but this conflicts with the max charge current setting so you cannot use both): Look for the vebus service, on the venus-gx I think it is com.victronenergy.vebus.ttyO5, and on that there is a path /Dc/0/MaxChargeCurrent. Set that to 0. This stops the Multi from charging, but the rest of the system is still in KeepCharged mode and will charge from solar only.

1 minute ago, plonkster said:

(but this conflicts with the max charge current setting so you cannot use both)

Mmm, problem, it is set to 29amps max, charging at 13% of 225ah.

How much would the batts need from Eskom you recon, per day? 1kwh?

2 minutes ago, The Terrible Triplett said:

How much would the batts need from Eskom you recon, per day? 1kwh?

Easy solution. switch back to optimised mode a little later after the sun has had some time to work.

Or switch the max charge current to -1 at night too, right before you limit the Multi to zero.

It gets very complex, yes, but that is why it is all hidden behind a gui.

1 minute ago, plonkster said:

It gets very complex, yes, but that is why it is all hidden behind a gui.

The more I see, the more I recon it is like being in a chocolate factory, everything is free - if you cron it.

But, as with life, there are tradeoff's. 

Optimized had the issue that the batts took more power, power that could have gone to the house, as charging is really inefficient.

The REAL issue: Bank is too small, the array too.
Tradeoff: Use all the power in the day, lose some by using Eskom to keep the batts topped up evenings.

Next steps:
- Get more panels, keep the exact same setting, then go optimized and tweaking the shiiite out of it all.
- Trojans go, get Poly's, then batts are sorted too.

What I want: Cpt rain / cloudy days, whatever the panels can give, give it to the house. Basta the T's - Trojans.
Summer, the rules change, use the T's. :-) 

Funny that each time I tamper it is winter when irradiation at it's worst.
Best time to do that, I think, to tune it to perfection.

11 hours ago, The Terrible Triplett said:

The REAL issue: Bank is too small, the array too.

In my case, the battery bank is now well sized. The array is too small. The array is only large enough to restore 25% of the battery capacity while also powering loads in the house during the day. So I have batteries that are good for many cycles down to below 50% and cannot use it just yet. At least this is the lesser of the two problems to have.

I see the batts take about 5, 8, 11w over 24 hours, take 11w x 24h = 0.264wh - bleh, negligible.

Question: Setting the charge amps at 13% on controllers and inverter and keeping the batteries fully charged at all times, what would you recon the effect will be if one say has say a 3kw array and a 225ah battery bank @plonkster ?

The 3k current will "skip" over the batts to the loads?
And if they need recharging, the 29amps max on controller and inverter sorts that.

@plonkster , I have same issue. What am I missing?

If I switch to Optimize Batteries: 682w incoming from panels, no grid usage.

 

If I switch back Keep Batteries Charged: 221w from panels, using grid.

Increase the solar voltage offset until it starts working properly. For now, it is a workaround. Powering the loads while keeping the batteries charged is a new thing. It never worked before 2.20, and even now it has teething problems :-)

2 minutes ago, plonkster said:

Increase the solar voltage offset until it starts working properly. For now, it is a workaround. Powering the loads while keeping the batteries charged is a new thing. It never worked before 2.20, and even now it has teething problems :-)

No problem! Teething problems are good, means it is there, just a few unforeseen scenarios.

Can do the volts yes ... here is what I tried, and so far it seems to be working.

Any potential issues I must be aware of?

See, works nicely ...

@plonkster settings as per the posts above, close, but not yet there where I want them.

For future readers: Goal is to keep the batts fully charge and send ALL the panels can give to the AC out at all times.

So when I tested today, full lekker sunshine, AC loads at >2kw, SOC at 100% in float, panels only giving +-475w max.
When I switched back to Optimize and SOC at 95%, same parms as above, panels reacted jumped to over 1kw.

So I increase the SolarVoltageOffset SetValue to 0.4 ... rebooted ... better, like now +-650w ... still not nirvana.

Then pay-dirt! Setting for my system is 0.3:

Lets see how this goes now ...

On 2018/09/27 at 9:33 PM, plonkster said:

You can create a file called /data/rc.local, make it executable (with chmod +x), and put that line into that file. Then it will run every time the system boots.

/data is never cleared during an upgrade, so it will survive updates.

Right, I cannot get this right. File is there, all rights given, if I reboot, reverts back to old settings, so I must manually run the line again. 

What am I missing?

 

5 hours ago, The Terrible Triplett said:

What am I missing?

Don't know. Usually a shell script must have the interpreter at the top, so the first line must start with:

#!/bin/bash

But I don't think that is necessary if the calling script is also bash, which it is in this case. So you could try that?

It could also be that the line just runs too early. Maybe it runs before the Multi is even detected and just fails... in which case you can hack it by adding a "sleep 10" or something before the command on a separate line. I'm guessing...

1 hour ago, plonkster said:

It could also be that the line just runs too early.

Ja, I did see that.

VGX, if you reboot, it take a few seconds to show all the tiles on the screen.

Will try both. Thanks.