diy solar

diy solar

Adding Schneider XW Pro

I forgot, I was going to include some screen shots from the EVSE interface.
Yes, those parameters related to charging are part of the EVSE set up.

"home screen" with the "advanced" option checked to display more settings and information
1641257283956.png

"Home screen" Basic
1641257415234.png

"settings"
1641257252140.png


"Services" the bottom right is the section in question.
1641257252140.png
 
fafrd said:
Are you on NEM? Why are you so concerned to avoid export during off-peak hours?
Click to expand...
Yes, I am on NEM 2.0
I am not concerned about exporting. But, the more I export the less I get to charge the batteries.

Edit: And I cannot (by PGE agreement/mandate) charge my home battery from the grid.
 
GXMnow said:
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.
Click to expand...
Thanks, that is the point I was trying to make. My highest priority is the keep the car somewhat charged. That means that some days the home doesn't get to charge much or at all. I think I have the battery sized correctly with enough held in reserve, that I don't think I need to worry about shuffling power around between the car and home batteries and loosing +20% to efficiency with each transition.

GXMnow said:
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.
Click to expand...
Yes, it's in Python. I can only take credit for the ugly few lines of code I have added. The 1000+ lines were written by David, the creator of RPI-Power-Monitor.

I ended up needing to edit something written in C (or maybe C with some plusses?) and it was easy enough to figure out having only ever worked in Python. I was surprised how easy it was to figure out the general differences to make it happen (just a few edits)
 
400bird said:
Yes, I am on NEM 2.0
I am not concerned about exporting. But, the more I export the less I get to charge the batteries.
Click to expand...
Got it. As long as I’m under NEM, I’ll be generating more energy than I need on high-production days to fully charge my battery, so no need to avoid export until I’m pushed to the Successor Tariff…
400bird said:
Edit: And I cannot (by PGE agreement/mandate) charge my home battery from the grid.
Click to expand...
Yes, now I understand - your goal is to maximize AC-coupled PV energy conversion to battery charge, so a Wh exported is a Wh lost…
 
GXMnow said:
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.
Click to expand...

GXMnow said:
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.
Click to expand...
I’ve just started looking into diving into this world and pricing and options of buying Pi’s.

Seems as though nailing down the minimum / maximum memory requirements for an energy monitor / charging control application like this is an important requirement to understand.

When either of us first pulls the trigger on buying something, let’s exchange PMs…
 
Here is the calculations needed (within the already set up and working power monitor) to get available EVSE current.

The program runs through an entire loop in about 1.5-2 seconds or so.
But the EVSE can only receive a command every 10-15 seconds. That is the reason for only running the EVSE calc every 10 rounds.

1641258443976.png

There is some back ground supporting work to do, here I just copied the solar set up and edited it for EVSE
You can see I didn't even change the "20W" label when I moved the threshold to 0 out the EVSE up to 100w.
There are a handful more entries like this where I copied David's "solar" entry and created and EVSE entry.
1641258553910.png
 
fafrd said:
I’ve just started looking into diving into this world and pricing and options of buying Pi’s.

Seems as though nailing down the minimum / maximum memory requirements for an energy monitor / charging control application like this is an important requirement to understand.
Click to expand...

I don't know how much looking you have done, but I've heard reports of delays where they aren't expecting any until 2023

If you get a low spec pi, the program should still work, it will just run a little slower.

Right now the PI is using 100% of one core (4 core CPU) and 5% of memory to run the power monitor.
The other processes (database storage and whatever else) is using about 10% of the remaining CPU and 1 gig of memory.

I have been saying this entire time that I am running this on a pi. That is not entirely true. I am running it on 2 pis ;)
But, that is not needed. I just wanted to have longer data storage so I moved some things around.
For about the first 6 months I ran everything on a single Pi 3
Edit after proofreading: Now its on the same I have the functions split across the Pi 3 and Pi 4
 
Last edited:
Yeah, PI's are hard to get right now, luckily I have a few from another project.

I scanned through but just wanted to make sure, are you using an external device to regular power to the batteries for charging, or communicating with the xw for that by changing a maximum charge rate or something similar?
 
The Pi/energy monitor is sending a max charge rate to the XW.
The logic of the XW performing the bulk/absorb and related current ramp down. I'm just limiting the max wattage available to do so.
 
I spent a little quality time with the battery today.
I got the communication between the BMS and Schneider XW set up. I still need to spend some time proving out the operation and get with Batrium to work out connecting the MM8. But, the battery temp (from the BMS) and SOC are both graphed on Insight Local.

The biggest thing this communication gives me is one step between normal operation and an open breaker.
I have a limp mode set where if the cell voltage gets to high on charging or too low on discharge the XW not make it worse.
If the cell voltage gets too low, it will not pull more power from the pack.
If the cell voltage gets too high, it will either stop or limit charge depending on how high the max cell goes.
I did a quick forced test of both these states and it seems to work. I'm sure there is more playing to do.


1644712240444.png
 
Schneider has another firmware update out for both the XW and Insight.

ooh, ahh
"updated icons"
I may actually do this one because of the incredibly vague "Improvements for BMS dashboard page"
I'm not even sure what that means...

1644712594591.png


Maybe this is the BMS Dashboard page?


1644712726289.png

This sounds like a minor update for the XW, but I feel the the simplicity of the words may be hiding important improvements.
1644712833236.png
 
That's cool to see the Batrium talking to Schneider. With LFP cells, the SOC is very important, but with our NMC cells, the voltage control is working great. Having the single cell protection is a nice feature, how is the XW actually doing that? Is that just part of the Batrium BMS communication that the XW-Pro understands? Or did you have to program something for that to function?

I am still having issues getting my PC to read the XW modbus, but my little Triangle PLC is able to read it just fine, so I know I have the right IP and such. In fact, the little PLC is working better than ever. I can keep clicking on read grid watts, and it keeps updating the reading without having to reset the link each time. Grid wats changes enough, I can see it change. I also have the insight page up, and the value match when I click it. I am going to try and send a command from the PLC. Wish me luck.
 
GXMnow said:
That's cool to see the Batrium talking to Schneider. With LFP cells, the SOC is very important, but with our NMC cells, the voltage control is working great.
Click to expand...
I agree, I am leaving the XW in charge of the charge profile and using voltage control.
The SOC in the Batrium drifts slowly over time and needs to be driven high to correct it occasionally.
So, I have the Batrium set to think 4.1 volts/cell is 100% SOC

GXMnow said:
Having the single cell protection is a nice feature, how is the XW actually doing that? Is that just part of the Batrium BMS communication that the XW-Pro understands? Or did you have to program something for that to function?
Click to expand...
I'm still figuring out the mechanism. I believe the BMS can set a warning fault or something similar to put the XW into limp mode. I hadn't found the BMS status page when I was testing functionality of the BMS comm

GXMnow said:
I am still having issues getting my PC to read the XW modbus, but my little Triangle PLC is able to read it just fine, so I know I have the right IP and such. In fact, the little PLC is working better than ever. I can keep clicking on read grid watts, and it keeps updating the reading without having to reset the link each time. Grid wats changes enough, I can see it change. I also have the insight page up, and the value match when I click it. I am going to try and send a command from the PLC. Wish me luck.
Click to expand...
Nice! Good luck
 
I ran into something unexpected this morning, it's not related to connecting the BMS. But while I was in there I enabled "Grid Peak Load Shave" with the settings below.
It does overlap with the charge block time slot, but I thought that would be fine and it would just start charging when commanded to by the Pi. And it did, everything was fine, charge was commanded slightly after the panels started making power (8:30 ish)
But at 8:55 the battery stopped charging. Luckily I just happened to check it on it at 9:00.
I could not get the XW to charge, no matter how many times I stared at the screen and confusedly pushed both the XW's command bulk charge button and my button in Node-Red/Raspberry Pi.

Changing the grid peak load shave block start to 7:00 did not change anything. But, disabling it allowed the charger to work again.

Maybe I miss understood the function of load shaving, but I didn't expect it to block charging even when blocked by the clock...


This is how I had it set, I changed the "Block Start" to 7:00 am with no change.
1644772655745.png


Right now it's disabled again and working normally.

Here we cam see ot charging normally before 9, the 15 minutes of me staring and clicking things before it started working again. That spike right at the end, is where I enabled load shave with a 7:00 am stop to no avail, and disabled it again.

FYI, those periodic spikes that stop at 8:30, are the drip coffee maker keeping the pot warm slowly burning the left over coffee.

1644772872139.png
 
400bird said:
I ran into something unexpected this morning, it's not related to connecting the BMS. But while I was in there I enabled "Grid Peak Load Shave" with the settings below.
It does overlap with the charge block time slot, but I thought that would be fine and it would just start charging when commanded to by the Pi. And it did, everything was fine, charge was commanded slightly after the panels started making power (8:30 ish)
But at 8:55 the battery stopped charging. Luckily I just happened to check it on it at 9:00.
I could not get the XW to charge, no matter how many times I stared at the screen and confusedly pushed both the XW's command bulk charge button and my button in Node-Red/Raspberry Pi.

Changing the grid peak load shave block start to 7:00 did not change anything. But, disabling it allowed the charger to work again.

Maybe I miss understood the function of load shaving, but I didn't expect it to block charging even when blocked by the clock...


This is how I had it set, I changed the "Block Start" to 7:00 am with no change.
View attachment 83654


Right now it's disabled again and working normally.

Here we cam see ot charging normally before 9, the 15 minutes of me staring and clicking things before it started working again. That spike right at the end, is where I enabled load shave with a 7:00 am stop to no avail, and disabled it again.

FYI, those periodic spikes that stop at 8:30, are the drip coffee maker keeping the pot warm slowly burning the left over coffee.

View attachment 83658
Click to expand...
I’ve always wondered what the consumption of my coffee maker looked like ;).

On a more serious note, when ‘grid peak load shave’ prevents the battery from being charged, does that mean that 100% of incoming DC power is inverted to AC power to reduce grid consumption? (So no charging and no discharging battery - offset loads only to the limit of what DC power allows?).

Or rather, looking at your graph, does it mean invert all DC power even if the result is export to grid?
 
I need to go back and read the manual section on the peak shave function. It should have to do with output, not charging.
But, I'll need to read into that another day.

All of my PV is connected to a Solar Edge inverter, so all of my PV goes to AC voltage.
The XW converts that to DC to charge the battery as commanded. But, not without going through it's own logic checks. For example, there is a max current, time range, and 2-stage charging algorithm that all take precedence. Remember, I am just sending a "max charge wattage" command. The XW is free to do less than that.

So, yes you can see when the battery (purple) stops charging, the grid wattage (blue) goes negative because I am pushing power to the grid.
 
400bird said:
I need to go back and read the manual section on the peak shave function. It should have to do with output, not charging.
But, I'll need to read into that another day.

All of my PV is connected to a Solar Edge inverter, so all of my PV goes to AC voltage.
The XW converts that to DC to charge the battery as commanded. But, not without going through it's own logic checks. For example, there is a max current, time range, and 2-stage charging algorithm that all take precedence. Remember, I am just sending a "max charge wattage" command. The XW is free to do less than that.

So, yes you can see when the battery (purple) stops charging, the grid wattage (blue) goes negative because I am pushing power to the grid.
Click to expand...
Got it (hadn’t understood the PV was grid tied).

So with no Conext present, that same amount of PV power would be getting exported and all the ‘peak shave’ function is doing is to prevent your Pi command to cause the XW+ to charge at whatever wattage.

If you are trying to shave your consumption, I can understand the logic of that preventing increased consumption by allowing AC charging…

I wonder if that same function results in a different outcome if you have either DC-coupled PV or AC-coupled PV connected directly to the XW+?
 
I think the Schneider block and block end times only make things happen when that time actually passes. If you set charge block a few minutes before right now, it keeps charging. But set it one minute from now, and in one minute it will stop. So it was most likely just staying in Load Shave, even though you changed the times, because the time had not happened. But why was it blocking charge under load shave? On my system, I have my microwave on the output side of the XW now. I have the battery charging at 23%, just over 31 amps. That is 1680 watts going into the battery. 20 minutes ago, my solar was just barely breaking even with that, so the AC1 current was close to zero. I put my breakfast in the microwave, which pulls well over 1,000 watts. That took almost all of the solar power, so the charger started to pull from the grid. I think it was Load Shave that then reduced the charge current to 22 amps to minimize (shave) the grid power. As soon as the microwave turned off, the charge current went right back to 31 amps again. A bit later in the day, when the solar is producing more, turning on the microwave is no longer enough to cause any grid current, so the charge power no longer needs to drop off. My question then becomes, did something in the XW load panel turn on and start using a fair amount of power?
 
Maybe I misunderstood load shave.

I thought it would use battery voltage to support home loads that exceeded the amperage set. Hence load shave.
If you have a load of 10 amps and the load shave set to 8 amps, anything over 8 amps (2 amps) would be supported by the battery) in this case you would have shaved off the top 2 amps of your load.

I didn't think "peak load shave" would limit battery charging when it ended.
I was pushing power to the grid (~100 watts) when the load shave block time hit, at 9:00 am.
At that point the battery stopped charging and I was pushing 1,200 watts to the grid.
 
That's is how peak load shave works, it will use battery to cover any load on AC OUT over the set amps. I've played with it some. If you don't want to export you need to set export amps to zero.

Your setup seems advanced, using the Pi and all, so I'm probably not telling you anything you don't know. While the XW is like a swish army knife, it can only operate in one mode at a time. The charger doesn't work while the inverter is engaged, this includes grid support like load shaving.
 
Last edited:
You must log in or register to reply here.

Similar threads

S
US region codes for schneider xw pro
Replies
2
Views
199
Scat
S
W
Schneider XW Pro DIY Resources
2
Replies
39
Views
2K
Cmiller
C
waterflea
Schneider XW Pro commission
2 3 4
Replies
71
Views
2K
400bird
4
K
Schneider XW Pro - Open Loop with EG4 LifePower4
Replies
15
Views
338
BentleyJ
B
P
Schneider XW Pro generator connection progress
Replies
14
Views
1K
dougbert
dougbert
Back
Top