diy solar

diy solar

Adding Schneider XW Pro

My system is “off grid”, so I can’t sell back to the utility.
DC coupled PV.
What I need is a “software diode”, so I can supplement our loads from the grid, but never send energy to the grid.
The “Grid Support” option works perfectly, the inverter decides when it needs to extract energy from the grid (rare event), but most of the time, loads are supported by the PV and battery only.
If the utility does not notice the tiny amount of export, I’m not going to worry about it, just weird to see that statistic pop up.
I use IotaWatt to monitor the current flows, but the CT don’t register such tiny amounts of current flowing “backwards” to the grid.
With the XW-Pro, to get true zero export while pushing back to a main panel before the inveter, you will probably need to use the Continental Controls WattNode Modbus.


I may be getting myself one for Christmas.
 
Thanks!
The video displayed a configuration page I had never seen before.
When I was able to locate the page, it had a “Zero Sell Config Enable”
that was set (defaulted) to disable.
So I set it to “enable”, will let it run and see if the XW Pro stops sending energy to the grid.

conext_gateway_zerosellenable.png
 
I am not sure it will do anyting without the WattNode connected.
 
Single digit watt hours exported. I'm not sure it gets much better than that.

I'm curious if making that change does anything for you.
 
The effect of enabling “Zero Sell Config” was bad.
It separated the DC coupled PV and batteries into one "zone", and the inverter and grid into a second "zone".
Thus the PV could no longer power the load, all the power for the load was sourced from the grid.
So I disabled "Zero Sell".
Now the system works like it should, PV and batteries power the load, until more power is needed, then the inverter makes up the difference from the grid.
I'm not going to worry about the tiny amount of "leakage" back to the grid, as shown in the stats.
I suspect those stats are errors/noise anyway.
 
I've been slowly, quietly progressing on parts of the project.
The heating/cooling is in process without much to show.

But, I got the EVSE (car charge) installed!
I went with OpenEVSE
This specific unit is great because it is nearly the lowest cost 40a EVSE I could find, it's got US made parts (not entirely, but still) and most importantly, I can adjust the charge current via MQTT. I am already employing MQTT as part of my charge control system.

PXL_20211231_001842449.jpg

There are two circuits in that conduit. 240 for the EVSE and 120 for the outlet.
 
I've been slowly, quietly progressing on parts of the project.
The heating/cooling is in process without much to show.

But, I got the EVSE (car charge) installed!
I went with OpenEVSE
This specific unit is great because it is nearly the lowest cost 40a EVSE I could find, it's got US made parts (not entirely, but still) and most importantly, I can adjust the charge current via MQTT. I am already employing MQTT as part of my charge control system.

View attachment 78099

There are two circuits in that conduit. 240 for the EVSE and 120 for the outlet.
Nice!

What is MQTT?
 
Nice!

What is MQTT?

The short version is that it is some random way that computers can talk over the network. I've got a Raspberry Pi with a handful of current sensors measuring power generation (PV) and usage. I've got two different calculations going. How much can be used by the EVSE to charge the car and how much can be charged into the home battery by the Schneider XW.

I know MQTT seems like it must be complex, but this is my first real programming project. The MQTT part was easy enough.

I told the downloaded RPI Power Monitor software to send the EVSE charge limit (in watts) to "home_power/evse/mqtt_solar"
 
I have linked to my power monitor before, but here it is again.
Software:
Hardware:
Plus, you'll need a raspberry pi (good luck, that's a tough one right now!)

So, maybe $120? Depending on how many current sensors you need and if you can comfortably assemble the PCB.
I've got more into it because I've got 6 current sensors.

None of that includes a case, I 3d printed a case, decided I didn't like it (the pi is still attached to the white base if you look closely) and haven't yet returned to that. I will eventually...
I also have a POE hat to power the Raspberry Pi
I did this because my switch/POE source is on the same UPC as my desktop. This provides some extra security if the XW switches too slow or whatever. It's a line of security and it pushed the raspberry pi order up into free shipping...

Raspberry Pi with power monitor and POE hat on the right you can see the exposed PCB because I haven't printed a case yet.
Ethernet on the right, current sensors in the other RJ45 on the left and bottom. The AC adapter is for voltage sensing/measurement.
The unplugged black connector on my Schneider Insite Home is the can communication line to my BMS (yet another work in progress) it goes down to the "definitely necessary" extra 15' loop of cable gently shoved in the conduit below the XW.
I didn't even notice the cable on the top left ?
I'm sure that's normal.

PXL_20211231_001749964.jpg

The junction/wire box pre-dated the XW and Isn't in the greatest location, but it is workable.
This is an exterior wall in my garage and on the outside here is my service entrance, meter, and main panel.
The EVSE is basically the only thing connected in the main panel. You'd never know it by how much work is in this stupid box.

Here you can see the 6awg (? it's been a few weeks, so I'm going from memory) going out the tip right conduit.

PXL_20211231_001435063.jpg

Edit:
Doh, I'm posting from mobile and accidentally posted before I was done.

PXL_20211231_001353826.jpg

Then I have 3 more current sensors in here.
2 monitoring the 2 phases powering the sub panel (everything in the house is in this sub panel)
This sub panel is also after the XW, so the entire house is in the XW for back up/emergency loads.
The remaining current sensor in the Schneider mini PDP is on one leg of the PV input for my AC coupled solar (Solar Edge, 6kw)

Then I have two sensors in the main service entrance. The two 3.5mm audio style jacks facing down on the Pi go behind the board, through the wall and into the back of the service entrance to grab the mains. Sorry no pic, it's not worth it to pull the meter again.
 
Last edited:
Does anyone have a recommendation or link to something to put together a line drawing of the system?

Grid
| (current sensors here)
Main panel -- EVSE and rarely used welder outlet (definitely not a drier outlet!)
|
XW with internal transfer relay and bypass breaker -- 48 v battery, LG chem, currently 14kwh. I've got another 14kwh waiting to be installed
| (more current sensors here)
"Emergency loads panel" this is the entire house, including the central AC
|
AC coupled PV (6kw)


While I put the PV in the sub panel here, it actually lands on a dedicated breaker in the XW's power distribution panel. But, it is on the "output" side, so it's the same as if it was in the sub panel.
 
found a partial solution: moved GEN input to grid input. This works great. I would still like a source and schematic to buy a replacement AC relay. Love the product not the support.
 
And here's a beautiful shot of a "cold" (for California, be nice, we don't do cold well. It was like 45°f) day charging the car, home battery, and our normal loads.

The sun basically came out at noon.
The legend is at the bottom
Yellow is PV
Orange is the EVSE
Purple is home battery
Green is home usage (sub panel)
Blue is grid usage


Screenshot_20220102-180726.png


I've got it set up so that when the sun is up, the two batteries are going to try and use PV current to drive the grid close to 0, but I don't want to pull power from the grid. So I'm aiming for 50-100 watts.

Screenshot_20220102-184321.png
Positive numbers are pulling from the grid. (Buying)
Negative is pushing power out the the grid. (Selling)
Once 4 pm hits peak rate starts and both the batteries stop charging, anything remaining at that time goes to the grid.
I've also got the XW set to push a little power out to the grid during peak rate time.

Here's battery current.

Screenshot_20220102-184647.png
Positive is charging and negative is discharging.
The car stops charging at 3:00 to give this battery a little dedicated charging time.
At 4-5, we can see dinner starting. After that th current trails off as I hit the "grid support" cut off. This ensures that I've got about 60% SOC remaining if the power goes out overnight.

At peak, I only got to 72% SOC today and was done discharging just in making dinner. This is why I'm looking to add DC coupled solar. We're driving more and the car needs to be charged more. Previously, we were using the little level one charger. It would max out at ~1400 watts and left a lot remaining to charge the home battery. Not so much now that the car can charge at it's full 7.6kw. I can't do that from the sun, but it means the car can soak up a lot larger share of my sun.


The EVSE min current is 6 amps and it's on 240 volts. So it can't start charging until there is an extra ~1.4kw and it moves in 1 amp steps.
Screenshot_20220102-185447.png

And here is the home load over the day.
The short 1000 watt spikes all night are the temporary battery warmer. The longer, 500 watt bumps are the home furnace kicking on.


Screenshot_20220102-185954.png

I feel like maybe the the grid current is upsidedown, not sure if that would help any of it make more sense.

But, today we charged the car some and charged the home battery some too.
 
Last edited:
And here's a beautiful shot of a "cold" (for California, be nice, we don't do cold well. It was like 45°f) day charging the car, home battery, and our normal loads.

The sun basically came out at noon.
The legend is at the bottom
Yellow is PV
Orange is the EVSE
Purple is home battery
Green is home usage (sub panel)
Blue is grid usage


View attachment 78103


I've got it set up so that when the sun is up, the two batteries are going to try and use PV current to drive the grid close to 0, but I don't want to pull power from the grid. So I'm aiming for 50-100 watts.

View attachment 78104
Positive numbers are pulling from the grid. (Buying)
Negative is pushing power out the the grid. (Selling)
Once 4 pm hits peak rate starts and both the batteries stop charging, anything remaining at that time goes to the grid.
I've also got the XW set to push a little power out to the grid during peak rate time.

Here's battery current.

View attachment 78105
Positive is charging and negative is discharging.
The car stops charging at 3:00 to give this battery a little dedicated charging time.
At 4-5, we can see dinner starting. After that th current trails off as I hit the "grid support" cut off. This ensures that I've got about 60% SOC remaining if the power goes out overnight.

At peak, I only got to 72% SOC today and was done discharging just in making dinner. This is why I'm looking to add DC coupled solar. We're driving more and the car needs to be charged more. Previously, we were using the little level one charger. It would max out at ~1400 watts and left a lot remaining to charge the home battery. Not so much now that the car can charge at it's full 7.6kw. I can't do that from the sun, but it means the car can soak up a lot larger share of my sun.


The EVSE min current is 6 amps and it's on 240 volts. So it can't start charging until there is an extra ~1.4kw and it moves in 1 amp steps.
View attachment 78106

And here is the home load over the day.
The short 1000 warr spikes all night are the temporary battery warmer. The longer, 500 watt bumps are the home furnace kicking on.


View attachment 78107

I feel like maybe the the grid current is upsidedown, not sure if that would help any of it make more sense.

But, today we charged the car some and charged the home battery some too.
This is a really helpful and complete description - thanks for going to the effort.

Your system is a reference for exactly the system I hope to build, so I’ll be bookmarking this post and following in your footsteps.


Just to be certain I’ve understood correctly, it is the simple MQTT algorithm you’ve written for your Rasberry Pie which is telling the EVSE charger when to charge as well as at what current level, correct?

So AC-coupled PV as well as DC-coupled PV is slaved to the Conext XW Hybrid but the charging power of the OpenEVSE charger as well as the battery charging current of the XT are both slaved to the Rasberry Pie ‘brain’ (through RJ485 communication protocols), correct?

There are just two things I’m hoping to achieve that may extend a bit beyond what you’ve implemented:

1/ you are keeping your EVSE charging power below your excess AC-coupled PV power but I am hoping to sometimes complement with some DC-coupled inverter power (so reduced DC-battery charging when additional power needed for EV charging). This should allow me to start EV-charging earlier and drive more AC-coupled PV generation to the EV’s battery during daylight hours.

2/ Using EV as ‘generator’ for sufficient battery extension to power through the night. I’m planning to get an EV with a G2L output which I am planning to control through a relay to an AC charger using my SCC’s ‘generator’ contact. So once the battery is drained from offsetting overnight loads, the EV’s G2L power can keep it charged at a minimum SOC level in order to contributing powering loads until the sun starts generating.

Obviously when the EV is out for the night and/or there is an extended period of poor weather that would drain the EV below the few kWh level needed to offset the average daily consumption, that extended capability will not be available, but I think it’ll be a straightforward way to get to all-night power with my not-quite-all-night-sized LiFePO4 battery without needing to invest more in battery capacity.

The key capability being delivered by your Raspberry Pi ‘brain’ is to control your two battery chargers in a manner that maximizes the absorption of generated power while minimizing export power (and grid import).

I was a software programmer in another life (~40 years ago) and I think you’ve given me the motivation to dust off those old skills and plunge into the world of Raspberry Pi;).
 
Last edited:
This is a really helpful and complete description - thanks for going to the effort.

Your system is a reference for exactly the system I hope to build, so I’ll be bookmarking this post and following in your footsteps.


Just to be certain I’ve understood correctly, it is the simple MQTT algorithm you’ve written for your Rasberry Pie which is telling the EVSE charger when to charge as well as at what current level, correct?

Yes, when there is 0 watt of extra solar available, it doesn't charge. I think that's the missing detail? Let me know if I can clarify that any more. I'll probably grab a screenshot from the EVSE interface and share the code showing the calculations on my end.

So AC-coupled PV as well as DC-coupled PV is slaved to the Conext XW Hybrid but the charging power of the OpenEVSE charger as well as the battery charging current of the XT are both slaved to the Rasberry Pie ‘brain’ (through RJ485 communication protocols), correct?
No DC coupled solar. *Yet
Charging is wattage limits are set by the raspberry.
The XW has some timers involved for when it will charge and when it will discharge. But, the current is controlled by the pi.
The communication to the XW is via their gateway/"Insite Home"
The Pi communicates with the Insite via modbus over Ethernet.

Going into this I was planning for RS485, then in an email conversation with Schneider tech support (I was requesting the RS485 or CAN protocols) they pointed out a tiny release note in the firmware (something like): We couldn't be bothered to make RS485 work. So, while the connections are there, we haven't written the software yet, bugger off. "Under development"

The modbus works ok, that's what took me the longest. It's still on the pi, but involves a program called Node-Red. I can't believe I didn't mention it. But basically, I'm using Node-Red is just a middle man with a nice user interface.
I'm sure everything I'm using Node-Red for could be programmed into the power monitor program by someone above my pay grade.

There are just two things I’m hoping to achieve that may extend a bit beyond what you’ve implemented:

1/ you are keeping your EVSE charging power below your excess AC-coupled PV power but I am hoping to sometimes complement with some DC-coupled inverter power (so reduced DC-battery charging when additional power needed for EV charging). This should allow me to start EV-charging earlier and drive more AC-coupled PV generation to the EV’s battery during daylight hours.

I can't charge the EV from DC sources (through the XW obviously) but that's a programming limitation.

The interface of the EVSE has an easy override, you can set it to charge at any speed you desire. But, I'm not sure how that would drive more PV to the car. My charge script is only a couple lines shoved into the rpi-power-monitor, there's miles of room for change as you see fit.
2/ Using EV as ‘generator’ for sufficient battery extension to power through the night. I’m planning to get an EV with a G2L output which I am planning to control through a relay to an AC charger using my SCC’s ‘generator’ contact. So once the battery is drained from offsetting overnight loads, the EV’s G2L power can keep it charged at a minimum SOC level in order to contributing powering loads until the sun starts generating.

Well, that doesn't exist currently and my EV doesn't support it. The EVSE doesn't either
Seems like a lot of unnecessary work and would leave you with less range if you needed it. There's a reason why I'm set up to prioritize EV charging.

Obviously when the EV is out for the night and/or there is an extended period of poor weather that would drain the EV below the few kWh level needed to offset the average daily consumption, that extended capability will not be available, but I think it’ll be a straightforward way to get to all-night power with my not-quite-all-night-sized LiFePO4 battery without needing to invest more in battery capacity.

The key capability being delivered by your Raspberry Pi ‘brain’ is to control your two battery chargers in a manner that maximizes the absorption of generated power while minimizing export power (and grid import).

It's pretty straightforward

EVSE = PV - home loads - 250 watts (for a little buffer, the EVSE moves slowly)

Home battery looks at grid current and drives to 50-100 watts.

I was a software programmer in another life (~40 years ago) and I think you’ve given me the motivation to dust off those old skills and plunge into the world of Raspberry Pi;).
You've this for sure! I've said it before, but this was my first actual project involving programming.
 
Yes, when there is 0 watt of extra solar available, it doesn't charge. I think that's the missing detail?
I read the OpenEVSE website and it sounds as though the charge level can be controlled directly through the use of CT sensors. So just wanted to clarify you are using a communication protocol to control from your Rasberry Pi ‘brain’ rather than using the native controls…

Let me know if I can clarify that any more. I'll probably grab a screenshot from the EVSE interface and share the code showing the calculations on my end.

No DC coupled solar. *Yet
Charging is wattage limits are set by the raspberry.
So the XW allows charging watts to be set and you program that level using a communication protocol from the Rasberry Pie.
The XW has some timers involved for when it will charge and when it will discharge. But, the current is controlled by the pi.
The communication to the XW is via their gateway/"Insite Home"
The Pi communicates with the Insite via modbus over Ethernet.
OK, so another box…. I see a Schneider box above the Pie (on the left, I think), but there is another all-white box above the Pi to the right - what is that?
Going into this I was planning for RS485, then in an email conversation with Schneider tech support (I was requesting the RS485 or CAN protocols) they pointed out a tiny release note in the firmware (something like): We couldn't be bothered to make RS485 work. So, while the connections are there, we haven't written the software yet, bugger off. "Under development"

The modbus works ok, that's what took me the longest. It's still on the pi, but involves a program called Node-Red. I can't believe I didn't mention it. But basically, I'm using Node-Red is just a middle man with a nice user interface.
I'm sure everything I'm using Node-Red for could be programmed into the power monitor program by someone above my pay grade.
OK, so you’ve had some screwing-around to get the Rasberry Pie communicating properly with the XW, but in the end you found a solution. What about the communication with the OpenEVSE?
I can't charge the EV from DC sources (through the XW obviously) but that's a programming limitation.
So the XW can’t be controlled to supply the EVSE with AC PV + as much inverter Battery Energy (or eventually DC-coupled PV energy as needed? If the Pi tells the OpenEVSE to charge at a power level exceeding available excess AC-coupled PV energy, the only option is to supply the gap from the grid?

The interface of the EVSE has an easy override, you can set it to charge at any speed you desire. But, I'm not sure how that would drive more PV to the car.
In my case, if I need to wait until I have an excess of 6A / 1.44kW of AC-coupled PV to begin charging the EV, that means later in the morning and more energy that had to get exported before then.

If the DC-coupled array is also producing enough DC-energy, that can be used to get the EV charging earlier (1kW of AC-coupled power + 0.44kW of DC-coupled power, for example).

Especially on low-production days like what we’re getting in the Bay Area now, starting to charge the EV earlier should translate to less energy exported and more energy stored in the batteries.

My charge script is only a couple lines shoved into the rpi-power-monitor, there's miles of room for change as you see fit.

Well, that doesn't exist currently and my EV doesn't support it. The EVSE doesn't either
Seems like a lot of unnecessary work and would leave you with less range if you needed it. There's a reason why I'm set up to prioritize EV charging.
Yes, obviously personal driving requirements will dictate what makes sense.

We typically drive so little that using the EV for a bit of (mobile) storage capacity is attractive. We’re talking about 2-3 kWh per night to ‘close the gap’ or the equivalent of less than 10 miles of driving daily.

So if you need to take off first thing in the morning, you start out with 10 miles less range (less than 5% of full range),

V2L does exist and we’ll start seeing the first EVs supporting it hit the market this year (Ford F-150 Lightening and Hyundai Ionique 5 are the two I’m aware of).

V2G (Vehicle to Grid) may require support from the EV charger (operating in a bidirectional fashion synced to the grid) but V2L is much simpler and does not involve the charger. It is an AC outlet on the EV putting out 120V or 240VAC that is islanded from the grid. So with an extension cord and an AC charger, you have a ‘generator’ which is your EV driving the charger on an isolated island of AC power.
It's pretty straightforward

EVSE = PV - home loads - 250 watts (for a little buffer, the EVSE moves slowly)

Home battery looks at grid current and drives to 50-100 watts.


You've this for sure! I've said it before, but this was my first actual project involving programming.
This stuff has all been evolving so quickly…. I’m impressed with what you’ve managed to achieve - I didn’t think the technology was really ready yet.
 
I read the OpenEVSE website and it sounds as though the charge level can be controlled directly through the use of CT sensors. So just wanted to clarify you are using a communication protocol to control from your Rasberry Pi ‘brain’ rather than using the native controls…
Read again. I believe that involves an "Open Energy Monitor"
That performs the same basic function as my Pi set up, and you may have noticed it in reading the creator's write up, he credits Open Energy Monitor as the basis for his project.


So the XW allows charging watts to be set and you program that level using a communication protocol from the Rasberry Pie.

OK, so another box…. I see a Schneider box above the Pie (on the left, I think), but there is another all-white box above the Pi to the right - what is that?
That's an Ethernet switch. Not really related.

OK, so you’ve had some screwing-around to get the Rasberry Pie communicating properly with the XW, but in the end you found a solution. What about the communication with the OpenEVSE?
I was already using MQTT, so adding the MQTT topic for the charger was straightforward and quick.

So the XW can’t be controlled to supply the EVSE with AC PV + as much inverter Battery Energy (or eventually DC-coupled PV energy as needed? If the Pi tells the OpenEVSE to charge at a power level exceeding available excess AC-coupled PV energy, the only option is to supply the gap from the grid?
Not that the XW "can't"
It's out of my skill set/desire. I'm 100% sure it's possible.

In my case, if I need to wait until I have an excess of 6A / 1.44kW of AC-coupled PV to begin charging the EV, that means later in the morning and more energy that had to get exported before then.

If the DC-coupled array is also producing enough DC-energy, that can be used to get the EV charging earlier (1kW of AC-coupled power + 0.44kW of DC-coupled power, for example).

Especially on low-production days like what we’re getting in the Bay Area now, starting to charge the EV earlier should translate to less energy exported and more energy stored in the batteries.

I'd probably look into powering the EVSE with 120 volts. That puts the minimum charge at ~720 watts.
I'm right there with you, I went 4 days without charging the car at all. Which was fine, no long drives planned and if it wasn't Christmas we still could have done the normal shopping and kids to school stuff. But, because it was Christmas we had no driving to do, the extended family comes to us.
Yes, obviously personal driving requirements will dictate what makes sense.

We typically drive so little that using the EV for a bit of (mobile) storage capacity is attractive. We’re talking about 2-3 kWh per night to ‘close the gap’ or the equivalent of less than 10 miles of driving daily.
So if you need to take off first thing in the morning, you start out with 10 miles less range (less than 5% of full range),

V2L does exist and we’ll start seeing the first EVs supporting it hit the market this year (Ford F-150 Lightening and Hyundai Ionique 5 are the two I’m aware of).

V2G (Vehicle to Grid) may require support from the EV charger (operating in a bidirectional fashion synced to the grid) but V2L is much simpler and does not involve the charger. It is an AC outlet on the EV putting out 120V or 240VAC that is islanded from the grid. So with an extension cord and an AC charger, you have a ‘generator’ which is your EV driving the charger on an isolated island of AC power.

This stuff has all been evolving so quickly…. I’m impressed with what you’ve managed to achieve - I didn’t think the technology was really ready yet.
 
This just happened today.

1641242731621.png

The sun came out, the minimum threshold to start charging the car was hit. But, it turns out the "minimum charge time" setting in the EVSE was 10 minutes. In theory this helps keep wear and tear down for the EVSE relay. I adjusted it down from 10 minutes to 2 minutes.

I also adjusted the "attack smoothing" down to ramp up the current more slowly. From 0.4 down to 0.1
I increased the "decay smoothing" up to 0.2 from 0.05.
If I have my theory correct, this should help slow down the EVSE ramp up and increase the cut back.
Combined with the shortened EVSE minimum timer. I don't think it will be as long lasting next time.

But, big picture, it doesn't matter. That was roughly 60 watt hours from the grid. Doesn't matter in the slightest.
 
Last edited:
The Schneider XW-Pro is a single converter bridge device.

It can either take DC from the battery buss and invert it into AC
OR
It can take AC from the Grid or Output terminals, and convert it to DC to charge the batteries

So with AC coupled solar like 400bird and I have, the XW has to decide if it is charging or discharging. So if the sun is up, we direct it into charging mode to take some of the power to minimize the export to the grid. Adding in the EVSE car charging, we can direct more of the AC solar into the car through that, but it has nothing to do with the XW. To be able to take DC buss power to AC, the XW would have to switch into invert mode.

If you also do have DC solar charging, then the DC coming from the solar would keep charging the batteries, and then the XW could go into invert mode and help supply AC power to the EVSE car charger. It all becomes a balancing act of where the power is coming from and where you want it to go.

This may be my build thread, but now I am following. I really need to get my control system up and working. I used to actually be able to learn and program, but over this past year, messing with my Modbus PLC unit, I still don't have it reliably talking to the Schneider gear.

I am enjoying this discussion going on here, and it is looking more and more like I will be doing a Pi as well. Are you doing your code in Python? I should probably start reading.
 
This just happened today.

View attachment 78189

The sun came out, the minimum threshold to start charging the car was hit. But, it turns out the "minimum charge time" setting in the EVSE was 10 minutes. In theory this helps keep wear and tear down for the EVSE relay. I adjusted it down from 10 minutes to 2 minutes.
Yeah, that’s a bit of a concern I have charging right at the minimum. But also the reason I want to complement the AC-coupled charging power with DC energy from my DC-coupled array.
I also adjusted the "attach smoothing" down to ramp up the current more slowly. From 0.4 down to 0.1
I increased the "decay smoothing" up to 0.2 from 0.05.
Are these parameters of the EVSE?
If I have my theory correct, this should help slow down the EVSE ramp up and increase the cut back.
Combined with the shortened EVSE minimum timer. I don't think it will be as long lasting next time.

But, big picture, it doesn't matter. That was roughly 60 watt hours from the grid. Doesn't matter in the slightest.
Are you on NEM? Why are you so concerned to avoid export during off-peak hours?
 
Back
Top