question

John avatar image
John asked

EV Charge Station Web-interface Settings - AND - Scheduled charge priority

Hi,

Quick question about accessing the settings on the EV charge station. I see that the extent of settings available varies depending on whether I use VRM/GX, VictronConnect/Bluetooth or local web-interface, with the latter providing the only means to access all settings. Does this mean that in order to be able to access the full settings remotely, I need to set up port forward etc. etc. to the local address - or is there something I'm missing here to get to those settings remotely?

Also - while I'm posting, I think the mode settings for auto and scheduled would benefit from some revisions. My use case is fairly common in that I want the charger to sit in auto to benefit from excess solar gen during the day, but then to always run a scheduled charge in off-peak rates overnight. At the moment, this requires an intervention to change the mode at the end of the day to 'scheduled' and back to auto again in the morning. In fairness, this was fairly easily remedied with a node-red flow, but it would preferable to have it handled in basic settings. The 'prioritization' of schedules is how other such chargers (MyEnergi Zappi for instance) work.

Thanks



John

ev charging station
11 comments
2 |3000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

matt1309 avatar image matt1309 commented ·
Agreed would be a nice feature.


I would also love a ESS SoC percentage in schedule mode. ie a schedule/auto mode that runs until SoC hit as well as based on time criteria, even when grid connected i know off grid exists.
0 Likes 0 ·
John avatar image John matt1309 commented ·

I'm in the middle of playing around with node-red to try and get that sort of thing working - and I'm getting there, but paid work keeps getting in the way. ;)

Your suggestion of an ESS SoC in EV schedule would helps achieve one of my objectives. It would even better if the schedule specific charge rate could also be dynamic (such as in Auto) around the grid set point of ESS - so maximising the charge rate allowing for other AC loads (in my case with little to no import).

My use case for this is as follows: Now that we are in summer; I regularly have a high house battery SoC at the end of the day. At the moment, this is used to charge the car supplementing grid at cheap rate) during its scheduled off-peak period, until the house battery reaches a lower SoC.

This misses two opportunities: 1. When the EV only needs a little top-up; this could be achieved largely from the house battery excess (if set to a lower charge rate to avoid grid use). or 2. When the car needs a lot of charge and it would be handy to be able to use the solar excess in the house battery plus a full 4hrs of off-peak grid.

What I want to ideally do is 'dump' any solar generated excess charge in the house batteries in to the car at the end of the day but before the off-peak period. For me, this is a two-hour window between 2230 (when the house generally settles to base loads) and 0030 when off-peak starts. That gives me scope to 'dump' around 8-9kw (based on both inverter limits and happy the max I could happily expect to have in house battery) in to the car.

When considering all of this - I try to forget how much times an AC-DC/DC-AC conversion has taken place and the inefficiencies.... :)

0 Likes 0 ·
matt1309 avatar image matt1309 John commented ·
I have contemplated node red route. Almost have to recreate auto mode like you said by using grid setpoint, but similar to you i was living in hope it would be natively added before i delved into that.


Know what you mean. Almost as though you could schedule modes as well as just charging rates.

I suppose all these features are purely software so hopefuly they're just in the pipe line. WHen i've previously asked about EVCS features I've had a response from Victron team noting they've added it to their todo lists. So fingers crossed it's soon.

If not it seems node red is our best bet.

0 Likes 0 ·
John avatar image John matt1309 commented ·
I managed to get a broadly effective node-red flow working last night. I have no prior experience of coding, which doesn't appear to be a problem for node-red. It didn't take much work to understand the basics.

I have something that at least activates the EV charger in that late evening window, if there is spare battery, and until it reached a predefined level (above ESS minimum Soc).

I have tried to configure a variable charge rate, which looks to the grid meter and reduces the charge rate on the EV charger to avoid import (for example, when the dishwasher gets put on at the same time and has very variable loading). I'm conscious that I am in this case effectively recreating a very crude alternative to the 'auto' function. This is challenging, because I want it to be responsive, but also not to yo-yo around all over the place. So I've been experimenting with only adjusting every 15 or 30 seconds, and tolerating a level off grid import for that period until the charge rate adjusts.

If you haven't already, I would encourage you to dive in to Node Red, it is incredibly powerful and, assuming as you are here you don't mind tinkering, it is quite fun exploring the options.

0 Likes 0 ·
matt1309 avatar image matt1309 John commented ·

Yeh I'm a big node red fan. (Personally use it on venus os for enabled extra loads when i hit absorption phase/start exporting. Shelly smart switches is what i tend to use, they're good for 16a loads, ideal for water heaters).


I did start to plan it out awhile ago but I think I'd want to add another artificial "mode". Like "auto2.0" and get node red to check if "auto2.0" was active before doing anything else. Maybe by adding my own "mode" localsettings in venus os or in openhab/homeassistant.

My issue was sometimes i do want to charge car when below this SoC but not do it automatically. That's the main reason i decided to wait and see how long official version took came out before i started adding custom local settings.


I'm not 100% sure how auto mode actually works, like how they combat the buffer i imagine it's similar to how you described, like monitoring deficiency/excess over a certain time frame. I'm also not sure on what the latency is for node red to get the data.

I'd say maybe python + dbus reading would be faster but I agree node red is just that much easier/far less programming intensive than python + dbus route.

0 Likes 0 ·
John avatar image John matt1309 commented ·

The slightly more frustrating thing (that I have responded to on another thread) regarding the auto mode, is the lack of prioritisation. I slightly naively assumed that the Victron EV charger would be treated just like another storage device within ESS, such that the user can set preferences of where to divert excess solar, depending on conditions. This isn't the case as you no doubt already know. The EV auto mode will only start functioning when ESS back-up storage is at 100% - there is no way to prioritse the EV.

I thought this might be another use of Node-Red, but the absence of a 'max SoC' in ESS makes this far more complicated than in should be. I've been looking at options to the disable battery charger in other ways at certain SoC, but I'm not having much luck. There is a 'disable charger' function under ESS, but it appears to disable any associated MPPTs as well, which rather defeats the purpose as around half my PV is on the DC side through an MPPT.

I'm afraid my coding skills do not really allow me to even contemplate python etc. I'm proud of myself just achieving anything in node-red, which is drag and drop.... ;)

0 Likes 0 ·
matt1309 avatar image matt1309 John commented ·

I wonder if DVCC charge current limit would work for your Max SoC point in auto mode.

Assuming you left on Feed in excess in ESS (so the MPPTs don't immediately ramp down/turn off), worth a test i suppose. ie set MaxChargeCurrent to a low number when you're not in absorption/full SoC and see if the power gets exported instead. If it does then hopefully the car will pickup the rest. I suppose it depends how the EV auto mode works if it's waiting for excess power of if it's based on SoC.


Limitation is I'm not sure if you can edit DVCC settings via node red though. If you can I'm not sure what node it's under.

You may have to use node red to send the MaxChargeCurrent setting to the Victron system via MQTT or modbusTCP instead assuming there isn't already a node for it

0 Likes 0 ·
John avatar image John matt1309 commented ·
That's the sort of thing I'd be looking for. I have to confess, DVCC is not an area I fully understand. The settings were configured by my equipment supplier in this area.

There is functionality available under the Settings Control node, where you can set the DVCC System Max Charge Current (A DC).

However, I had a quick look at the Remote Console interface and this suggests that it is already configure to a 1A max. However, I think this may be because it is also configured for CAN-Bus BMS (Pylontech batteries) which means the setting are overriden by those provided by the BMS - but I could be wrong. As I say, not really confident in this area. May be worth a try.

I think I need to join the chorus of people asking for a defined Max SoC in ESS. All of the forum discussion on this seems to be a debate about why you shouldn't need protect your batteries from 100% SoC and the risks of imbalance of doing so. It is clear to me that there are legitimate other reasons for this functionality, even if potentially imbedded with BatteryLife or something, to allow some degree of protection against BMS miscalibration or cell imbalance.

0 Likes 0 ·
John avatar image John matt1309 commented ·
Actually - ignore my reply. that might work. I think I must have already set that 1A limit myself when playing around. The DVCC manual indicates that this limit, if lower, overrides CAN-Bus and MPPT should still work if DC export set.

Unfortunately not enough sun to try now....but something to test tomorrow.

Cheers for the idea.

0 Likes 0 ·
John avatar image John John commented ·
Just to update you - limiting DVCC charge current does go some way to achieving my objectives.

Applying a zero or very low max charge current essentially stops any of my AC Coupled PV for going to the battery and instead results in export, which the EV charger picks up. As suspected, this doesn't shut off the connected MPPT, which continues to generate. However, this does continue to be directed to the battery, implying that the DVCC charge current only impacts the inverter/charger, not the MPPT.

This isn't ideal, but it does at least allow me to direct by AC coupled PV to the EV before the battery is full (this represents around 2/3 of the my gen anyway) - and does keep the battery charging a bit.

0 Likes 0 ·
matt1309 avatar image matt1309 John commented ·
Hmmm, that's a shame. I'm guessing changing max charge current in MPPTs just reduces their output rather than reducing their output into batteries.


There's probably a setting somewhere to do both, but I'm not sure where it is.


Tbh I'm surprised the DVCC didnt solve it. Like you said I thought a lot of folk used BMS to control settings in there, which you'd expect they'd want to control both AC and DC coupled. Saying that maybe there's another setting controlled by BMS somewhere that covers MPPTs

0 Likes 0 ·
0 Answers