I want to use scheduled charging to ensure I have 40% battery in the morning but I also don’t want to draw power from the grid during the scheduled if the battery is over 40% because it has been a good PV day. I can achieve this by using K1 to drive a contactor to disconnect the mains if the battery is say between 41%and 95% but the I lose the stability of being connected to the grid.
ideas please
I am assuming you don't have ess assistant programmed. With the assistant you can control depth of discharge.
Are you intentionally islanding then by disconnecting the grid?
There is another way besides the contactor relay
This assistant will open and close the grid feed based on SOC and you can disable the internal charger if you don't want it to charge up using the grid. Just some ideas that will need some customizing for what you want.
Alexandra, thanks for looking.
I do have ESS assistant programmed. The islanding comment was just to show the only way I can see of making it work, agreed your option would work as well but both have the effect of losing grid stability. I agree you can control depth of discharge with ESS but not on a timed basis. What I am trying to do is make sure at 4am I have a minimum of 45% in the batteries. If the day before was sunny then I have this left in the batteries. The issue is that if I have scheduled charging on from 2am to 4am (I have 65.2kwh battery storage and 120 panels) and the batteries are at 50% it uses grid power for loads not battery and I only want to use grid when the batteries are below 45% during this time period.
If you don't want to charge from the grid ever then you disable the internal charger.
But on ess if you tell it to only discharge to 45% then it will do so and then only charge on solar. Then the next step would be to control your loads so you reach your target SOC percentage at the target time.
Ess will then draw your full load from the grid untill solar appears again.
If you have been manually connecting and disconnecting from the grid then you have been disabling the ess program anyway.
You can also program scheduled charge to stop on SOC anyway during your charge window. So it does not run if you are on or above target.
Sorry, i am not understanding your reply or making my self clear.
Scenario 1;
At 2am the battery is at 5%. I set the scheduled charging for 2 hours and the SOC to 45% and to end charging when SOC reached. Between the point in time 45% has been reached and the 2 hours scheduled charging has finished the system draws power from the grid such that at 4am after 2 hours scheduled charging the batteries are at 45% and the system them reverts to using battery power until the solar cuts in.
This scenario works just fine but is not what I want.
Scenario 2
At 2am the battery is at 60%. I set the scheduled charging for 2 hours and the SOC to 45% and to end charging when SOC reached. Between 2am and the 2 hours scheduled charging has finished the system draws power from the grid even though i have 15% more in my batteries than needed and at 4am after 2 hours scheduled charging the batteries are still at 60% having taken no charge from the grid and the system them reverts to using battery power until the solar cuts in.
This scenario doesnt work for me as I draw energeny from the grid between 2am and 4am when i have spare capacity in the battery.
What i think it should do is if the SOC is set to 45% in scheduled charging it should either charge batteries to 45% then use grid until the end of the scheduled charging window or discharge batteries to 45% then use grid until the end of the scheduled charging window.
@Johannes Boonstra (Victron Energy Staff)
Johannes, can you help with this.please
Hi @David Gould
That's just the way scheduled charging works.
It might change in the feature, but for now this is it.
Daniel, OK thanks. It would be a great feature to add, I have an electric tariff that would make it very cost effective and environmentally beneficial for me to use
Hi! I have this issue as well, I would only like to draw power from the grid if the SOC is bellow 50% during night and not as it is now it will draw power from the grid on set time even if the SOC is above set limit, though at least it does not charge the batteries. So for me the feature should work as:
When the time occurs in the schedule and a SOC limit is set, the system will only take power from the grid when the SOC falls under the set value. For now I'm also looking into setting up a relay to be able to control if I need to draw power from the grid or not during night...
So please improve this! :)
I am glad other people want to use Scheduled Charging in this way. Has anyone got a good workaround yet?
Obviously setting the shortest possible schedule period will help, but it is still annoying to use the mains when the battery has enough charge in it already.
Also I think it could be improved by a feature similar to BatteryLife: If 90% SOC is not achieved by the end of the day then the minimum SOC to be achieved with cheap night rate electricity should be increased by 5%, if 95% is achieved during the day it should be lowered by 5%. This way it would automatically handle changes in day length and to some extent also variations in the weather.
The battery will not discharge during a Scheduled Charging period. So, as @David Gould correctly highlights, there are situations where either you have reached the desired SoC well before the end of the period, or it was above it to begin with, and in either case you are using grid power un-necessarily.
It is nearly two years since @Daniël Boekel (Victron Energy Staff) said it might change in the future so I would not hold your breath.
As with a number of other infelicities you can work around it with Node Red.
I'd also like a feature like this, as @Henrik Känngård and you @sharpener explained last May (above).
I'm thinking of: keep the "Scheduled Charging" / "SoC limit" at "Active SoC limit" + N%, manually evaluating the N% as the amount needed between the end of the night off-peak hours, and the begining of the serious solar production (I evaluated it at 10 or 15% here).
The method described above seems to be more elegant and self-discoverable: automatically decrease the "Scheduled Charging" / "SoC limit" by 5% when SoC reaches 95%. There must be a means to increase it, much like actual BatteryLife active SoC limit. Maybe both are the same, or just separated by a fixed amount, or similar with different SoC triggers.
What I didn't like once was that the Active SoC limit was just increased that day, which had the impact of ignoring the Multiplus "Input current limit" right during the scheduled charging. The grid current was thus above my self-set goal. Had the grid meter set to actually cut at that current, I couldn't have charged when it was the most important.
I've been using Node Red for many years so the scheduling and timing stuff is easy enough. It's just that having looked through the Victron palette, I'm not seeing the controls to switch to charge from grid.
Thanks
Kind regards
John
Even though I installed VenusOS Large and activated NodeRed, I don't know nothing about it. I'd like to learn ;-)
What I'd say is that you should try to reproduce what you actually do (or what I and others have described above) in the GX console, ie. enable/disable scheduled charging items, and change their SoC limit.
IIRC, there is no "charge from grid" setting in the console, only "keep the batteries charged". I guess that's why you can't find it in the palette.
You can also set "max inverter power" by SOC/time of day, if you wanted to limit dicharge.
Kind regards
John
Hi @nickdb
I've been looking at the ESS Control node - I can see I can choose ESS System Settings, and within that I can see "ESS state" and "ESS mode" (amongst many others)
I'm a bit confused by the "ESS state" values - it is the same list as the equivalent output node but is this the right one to change?
1 - BatteryLife enabled (GUI controlled)
2 - Optimized Mode /w BatteryLife: self consumption
3 - Optimized Mode /w BatteryLife: self consumption, SoC exceeds 85%
4 - Optimized Mode /w BatteryLife: self consumption, SoC at 100%
5 - Optimized Mode /w BatteryLife: SoC below dynamic SoC limit
6 - Optimized Mode /w BatteryLife: SoC has been below SoC limit for more than 24 hours. Charging the battery (5A)
7 - Optimized Mode /w BatteryLife: Inverter/Charger is in sustain mode
8 - Optimized Mode /w BatteryLife: recharging, SoC dropped by 5% or more below the minimum SoC
9 - 'Keep batteries charged' mode is enabled
10 - Optimized mode w/o BatteryLife: self consumption, SoC at or above minimum SoC
11 - Optimized mode w/o BatteryLife: self consumption, SoC is below minimum SoC
12 - Optimized mode w/o BatteryLife: recharging, SoC dropped by 5% or more below minimum SoC
Options 3-8 read more like states than something I should be able to control, likewise with some of the others.
I was expecting to see something more like the 4 choices you get in the GX menu or in VRM. Am I looking at the right "Measurement" or even the right node?
The "Ess Mode" option is even more confusing with the choices being
1 - Optimized mode or 'keep batteries charged' and phase compensation enabled
2 - Optimized mode or 'keep batteries charged' and phase compensation disabled
3 - External control
I want to switch between Optimized with Battery Life, and "Keep Batteries Charges" as you suggested.
Any pointers gratefully received.
Kind regards
John
I guess that "ESS State" are just reporting the current status of the whole system. Not something that you can change.
"ESS mode" looks like what is known from the Multiplus point of view. Whereas "BatteryLife" is more like what a layer the VenusOS adds above the Multiplus ESS. The "External control" setting you see might just be the way the Multiplus sees it when VenusOS "BatteryLife" is enabled.
You probably should check somewhere else for these settings...
Through trial and error I've found that I can use the ESS Control node to set the "ESS State" to 9 for "Keep Batteries Charged", and 2 for "Optimised with Battery Life".
This is clearly poking the ESS state machine in some way, but it seems to work!
Kind regards
John
Hi @johnparVIC
You want to set ESS state, but there are only a handful that matter to you:
State 9 (keep batteries charged)
And state 10 (optimised w/o battery life SOC above minima because you would be charged)
or state 2 if you want batterylife.
Tested it myself:
and it works as desired, 9 sets:
and 10:
Mode was the wrong advice, it has another purpose to do with control.
Now working on the timing and SOC threshold in NR.
Kind regards
John
I'm beginning to experience low-PV-production days lately. Thinking about how to manage it, I tried something else. Instead of changing the minimum SoC and charging the battery during of-peak hours, I also adjusted the "Grid setpoint", in order to prioritize direct PV consumption, instead of discharging/charging the battery.
I usually have "grid setpoint"=20W, and regular baseload here is ~400-450W. Increasing the setpoint to "at most a bit lower than the minimum baseload" smoothen the grid import and do not arbitrarily stress the battery: instead of 20W, then 450W grid import, I can manage ~200W grid import, which seems to be a bit better.
Are there other tuning parameters to evaluate during the winter?
Not sure I understand how the above helps.
I too have seen a sharp drop off in daily PV yield so I have adopted a new approach in order to minimise peak rate usage.
1. Fully charge the battery at cheap rate (0600 - 0800 BST). [Must change NodeRed because of the fan noise so this becomes 7 hrs at 1 kW]
2. If a sunny day follows then on top of the daytime base load of ~400W...
(i) run dishwasher/washer/dryer, we need one or the other most days.
(ii) any excess will keep the battery topped up and beyond that be diverted to immersion heater, this uses ~9kWh/day (of which 2kWh is standing loss despite insulated tank)
(iii) so there will be little if any left to export.
3. If there is not much sun during the day we have more lights on and...
(i) battery has first call on what excess PV there is
(ii) little or nothing left for immersion heater (set to 60C)
(iii) if water temp <55C then oil boiler comes on at 1800 to top up tank (unit price is about the same as off-peak electricity)
(iv) if necessary run dishwasher/washer/dryer overnight
4. From when the clocks go back we will also light the AGA (I know, I know) and this will avoid our using the electric cooker which ATM is the biggest single component of our consumption.
All possible improvements duly noted!
I thus tend to charge during off-peak mainly to keep a minimum amount of energy locally. I also started to tune the "grid setpoint" in order to conserve battery energy until off-peak time (21h10), and draw a fixed amount from the grid.
I do not have electric water heater to act as a black hole for PV power (it is a solar thermal heater, storing way more thermal energy than any PV system). My personnal black hole for PV surplus is the electric car, which may not be there the next day. I thus tend reserve future PV production for the home battery.
I guess all that comes from various system sizing and existing infra. Hence my question about other tuning parameters, or strategies ;-) Thank you for your input !
I have a solution to a slightly different problem but the same approach should work.
Within scheduled charging I wanted to set the SoC dependent on the solar forecast for the next day - trying to predict what the maximum SoC I should set such that I didn't feed in excess solar to the grid.
Solution was to use Node-Red and MQTT. I enabled MQTT on the GX and then used the Node-Red MQTT support. I didn't want to install Venus Large (with native Node-Red) so ran Node-Red on my laptop to test (and will move to a Raspberry Pi when 'in production'). I used MQTT explorer to identify the MQTT topics that needed to be updated (note the topics begin with N when reading which must be changed to W when writing). If you look at the control flag for the scheduled charge slot you are using IIRC it will be 7 (enabled for everyday) and I think it should be -7 to turn off. I don't know if the GX is continuously reading this value so will detect the change though - not something I tested?
Colin
I am facing the same issue as OP. Scheduled charging setup from 1am to 3am to leave at 3am with 30% SOC, and when I enter at 1am with 70% SOC, the algorithm will keep powering everything from grid despite having enough battery to ignore scheduled charging completely.
The main issue I think is the simplicity of the scheduled charing algorithm, for now I think the only option is to use Node RED and enable/disable scheduled charging slot or min SOC based on what the current SOC is.
Because you and only you currently know what load to expect during the scheduled charging slot. I do not think ESS or Victron is observing your daily load and training some AI at the back to learn how to optimise your charing cycles...
but that it what should be done, right? training an ML model daily to determine next day consumption and combine that with predicted solar to influence scheduled charging... :)
just my .2 cents,
Martin
We were just thinking this evening of going down the overnight charging of batteries as our supplied has new tariffs, came on here to find out how to enable/disable it with node-red but ended up finding this post at the top of the list.
I can't believe the system will use the grid during the charge window if the batteries are above soc. That seems like madness. I would expect the system to carry on as normal until it reaches the soc set on the charging schedule.
Does anyone know which node you can use in node red to control the scheduled charging? If not I'll look at mqtt topics to do this. Hopefully that way we can disable the schedule and not consume from the grid when there is battery power available!
My supplier is Octopus energy in the UK and I am on their flux tariff, which means I get to import cheap electricity from 02:00 - 05:00 daily. I set up my Multiplus II GX to do a sheduled charge of my batteries between these time to get me started for the day. I then use any excess solar produced to firstly continue charging the batteries during the day and when full sell it back to the grid, then between 16:00 - 19:00, I force discharge the batteries (using node red code) down to a predetermined SOC. This seems to work for me.
If you have any questions le tme know.
Regards,
Graham.
Of interest could be this feature: https://github.com/victronenergy/venus/issues/970 which is already fixed and documented, and which allows discharging a battery when in a scheduled charge window. If I read things correctly, it may be part of Venus OS 3 which is currently in beta. https://github.com/victronenergy/meta-victronenergy/commit/31ead77ea352966cd59bdccb9c54694b750984dc
Hi @enodev,
I read the same, but must be missing something as I can not seem to get this to work. I have set a low SOC and the only way that I could get the batteries to discharge was to change the gridsetpoint value, which means manual intervention which is not what I want.
Have you had any experience with this, and if so how did you get it to work.
Thanks,
Graham.
This works here.
Hi @nhuillard,
Thanks for the reply.
I have tried again this morning as a test, 'self consumption' set as PV & Battery, SOC set at 40 (bottom pic). The schedule is active (top 2 pics), but I still cannot get the batteries to discharge.
Can you think of anything else that I am missing.
Regards,
Graham
You probably have another charging session during the night, before 8:00.
I just setup a discharge during the morning for a test, hence the 08:00 start time. I have a charge session that runs sucessfully from 02:00-05:00 everyday for the cheap import tariff.
Do you mind sharing you condfiguration settings so that I can check on what I am missing?
Regards,
Graham.
Here are my settings, and the results this morning.
I set the SoC limit to 45%, meaning the SoC won't be lower than 45% at 7h10 (end of schedule slot). This leaves the rest for the battery charge to reach the beginning of the sun production.
Between 5h10 and 7h10, the discharge stopped (SoC reached 46%). During worse conditions (end-of day at 55% instead of 68%), the stopped discharge would start earlier, even charging to reach 45% if SoC was lower at 2h10. During good conditions (end-of-day SoC at 90%+), the low of 45% is never reached and I rely only on PV power + battery storage.
I guess your problem is just your scheduled charge during the night. You should adjust this one to reach the minimum SoC you will tolerate at the end of the off-peak hours (45% at 7h10 in my case).
HTH!
I had a similar requirement as part of a more complicated 'how much to charge the batteries overnight so that the following days PV is not wasted' . My solution was to use NodeRed and MQTT support. I have a Raspberry PI running NodeRed with MQTT support and MQTT enabled on the Venus (via the Cerbo GX settings). My target SoC for the charge window is variable (dependent on the PV forecast for the following day). Just before the charge window starts, a NodeRed flow checks the current SoC and the target SoC. If the target SoC is less than the current SoC, I then use MQTT to reduce the charge window duration. This seems to be working.
Colin
I have managed to cobble together a very simple force discharge outside of the Victron environment. (Home Assistant)
My thoughts were if it could be carried out within the Victron environment then all the better, one less piece of equipment that could go wrong.
Just need to get a reply from Victon support as to how to set this schedule up, unless I am mis-interpretting what was written in the victron firmware v3.0 release notes.
Graham.
I am very new to node red and want to explore the possibilities with solar forecasting and adjusting SOC early morning to utilize the solar during the day.
We cant run soc at 30% in teh evenings because the grid is not stable(Load Shedding) so we need backup power in the evenings, but if we know that its going to be a good day for solar production we can drop the SOC at 5AM in the morning when the pumps etc start up. to use the battery rather than the grid supply.
Unfortunately it's a real hack/mess and not in a sharable state - it's on my to-do list to make a skeleton that is shareable. It is very specific to my daily use pattern which varies according to time of year, shading on solar panels through specific winter months which reduces the predicted output, timing of my cheap rate tariff, ... I started by registering with Solcast then downloaded the Solcast Node (https://flows.nodered.org/flow/a1907502b7256a0e4bcf408fbee93411) to see how it worked. I didn't actually use the flow but just used the http request node as a template to connect and get the forecast data and took it from there. On the Victron side, I enable MQTT (on a production level Venus - I do not do install NodeRed on the Venus system). I then have a separate Rpi running NodeRed which does all the work. I found all the MQTT topics I needed by using MQTT-Explorer and used this guide to help get the MQTT comms working correctly: https://community.victronenergy.com/questions/70837/how-to-bidirectional-integration-of-venusos-and-ho.html All the 'creation' is done on my laptop running Nodered client to the RPi and MQTT explorer.
Hope this helps ... Colin
Is there a follow up on this? It seems like a bug.
Scheduling doesn’t operate correctly:
Even after the set SOC is achieved, victron still draws from the grid?? Surely this negates the whole purpose of scheduling and raises people’s grid bill unnecessarily.
We have an instal with 1000AH bank that draws 1-2KWH overnight from the grid even though it is at its set SOC in schedule(!). Makes no difference if 100% or 60%.
This is familiar to me as wel.
I plan a daily battery charge from 4:00 AM to 5:00 AM. up to 30% battery capacity.
After this time slot I expect the system to stop charging the battery
Unfortunately, the system continues to charge the batteries.
I see in this review that more people have problems with it.
Perhaps a little more attention should be paid to this chapter.
The parameter you set to 5:00 ("Duur", as in "Duration" in my GX), is NOT the time to stop the charging, but the duration of the charge!
Your setting is meant to charge from 4:00 to 4:00+5:00, ie. 9:00
If you want to charge from 4h to 5h, you need to set "Duur" to 1:00
The summary in the first GX screenshot is actually more explicit, with the duration in parenthesis and noted as "5h 0m".
What sets the charge status to 15%?
Where does this value come from?
This limits my battery capacity.
« BatteryLife » limits the minimum SoC. Just change the first item of this screenshot to "without BatteryLife" and this 15% line will disappear, leaving only the 10% setting.
But I suggest that you keep BatteryLife on, or think of a way to keep your battery charged at higher levels. The idea is that is the grid fails and you have only 10%, your battery won't last very long.
Hi,
I used node red and you can add a condition.
in the night I have a low cost Consumption and I keep my battery for in the morning before the sun rise up for a a PV consumption.
if you want more ask me for the flow in NODE RED
best regards
Kroels
see the results of my investigation:
