Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Software versions for Powerwall 2?

This site may earn commission on affiliate links.
so i did a quick utility per rest api discussed elsewhere.

for no-solar switching to self-consumption via rest causes the pw to switch to priority discharge. the gateway web page shows flow from battery to house and no flow from grid. I also went out and checked the meter, it shows 0.0. The app starts showing "discharging" mode and the backup menu button goes unchecked; the power flow in the app correctly showing discharge flow as well (with a little delay). Also, no browning/surge with the switch, which is instantaneous -- no more drops in my powerline eithernet.

I guess I'll just wrap this into a scheduled daemon for now. I am tired of flipping switches.I bet their app does no more than this in this case. it took me half an hour (given that i am no rest programmer) and probably another half an hour to figure the auto scheduling part.

I can't believe that's the scope of delay. there's gotta be something else. For an experienced java rest programmer it is actually 15 minutes of work (plus "qa cycle" which of course could be week+).

Gosh.

well i guess the service and android/iphone UI changes are not 15 minute work, i will concede that much. but the controlling logic is actually dead simple.

They probably have a better api for no charge/discharge mode (if they implement it at all) rather than stopping the firewall which also stops logging, but i guess just using stop/start will do for now. Besides, the PW enters the "neither" mode automatically once the reseve in self consumption is met. and in the morning i probably won't need stopping either because the wall would be fully charged by then (if not i can just programmatically lower backup reseve while in backup, that should have an effect equivalent to no charge-no discharge).

PS. switching to backup with <100% reserve (even if it is higher than current level) seems to have equivalent effect to stop button (nether charge nor discharge, and the running status switches to false). Interesting. I bet that's what the stop button really does (even though it does seem to go site master instead of configuration).
 
Last edited:
  • Like
Reactions: NuShrike
plus "qa cycle" which of course could be week+
Week++ :)
I'm just working through a bug that I thought I'd coded for (admittedly I'm doing a lot more than just switching) around handling the transition from daylight savings to standard time (which happened overnight for me in Melbourne).

PS. switching to backup with <100% reserve (even if it is higher than current level) seems to have equivalent effect to stop button
Have you called config/completed after this? If not, changing the mode does stop the powerwall. I assume you have (and you get 202 accepted), but just in case, I thought I'd mention it.
 
It would qualify for SGIP. SGIP requirement is only that you store energy (i.e. store/generate energy)--hence the requirement to cycle the battery x number of times or x about of kw in a year. ITC is the one that requires you to only charge from solar.

I believe if I was able to charge from the grid, the TOU arbitrage benefit would be greater than the ITC benefit.

I’ve been trying to do the math on this but the ITC benefit seems to be pretty large compared to the TOU benefit. Can you walk me through your calcs?
 
I’ve been trying to do the math on this but the ITC benefit seems to be pretty large compared to the TOU benefit. Can you walk me through your calcs?
Really a function of your usage but if you simply take the number of hours you use for peak and non peak and multiply by the difference relative to non peak hours , that is how much you’re saving per year if you could charge from the grid. And the benefit is not a one time but over multiple years. The benefit is obviously much less if you cannot charge from the grid. My estimation was that I could save $5-600 per year. So after 3.5 years, the TOU benefit would outstrip the ITC benefit ( not counting time value of money).
 
One thing to consider is that the ITC requirement only lasts five years. Once you factor in the efficiency loss of the round trip through the batteries and the time value of money I suspect the difference is not huge. Hopefully Tesla will ease the restriction at some point so those who have satisfied the five year requirement can charge from the grid overnight. Of course by then they might also have implemented their grid stabilization program which would hopefully pay more than the arbitrage.
 
Of course by then they might also have implemented their grid stabilization program which would hopefully pay more than the arbitrage.
One would hope, especially in California. As Miimura has mentioned there have been programs for getting paid in a lower rate or some incentive to allow the utility to turn off your AC when the grid is stressed. I have not been able to take advantage of those because I have always lived in a little beach community where we didnt need AC. Recently we purchased a second home in Sonoma Clean Power's territory and I just enrolled in their GridSavvy program which allows them to control my EVSE. I have installed solar at that home and have a Powerall on order. The solar will be on NEM 2.O so I am also hopeful that over the next five years these DER programs will continue to evolve and provide greater returns on my investment.
 
Not in PGE anymore, but way back in the day -- interconnect grid-tied specifically prohibited ANY battery system to grid-tie. That's changed with Powerwall, but looks like it's the ITC stipulations that prohibit grid-tied CHARGING of batteries with PV, not PGE. PGE just doesn't want you to discharge into the grid and have to pay and game the NEM TOU to pay full retail prices. They'll claim grid surge nonsense, but it's really about the arbitrage potential that everyone sees and want to optimize.

Like others, we're hopeful that post 5 years when ITC obligations sunset, we'll be able do what we want with the Powerall charge.

What I REALLY want is Tesla open a port that allows to daisy chain our EVs to the Powerall to allow support. It makes complete sense in the next gen grid support where the local power company can tap a cheap, local clean energy source instead of crazy expensive and polluting peaker plants.

We're on our way with TOU and powerwall shifting. Let's take the next step and supersize this thing with our EV batteries sitting on the driveway during ohmhour alerts.
 
It would qualify for SGIP. SGIP requirement is only that you store energy (i.e. store/generate energy)--hence the requirement to cycle the battery x number of times or x about of kw in a year. ITC is the one that requires you to only charge from solar.

I believe if I was able to charge from the grid, the TOU arbitrage benefit would be greater than the ITC benefit.
SGIP also requires 75% annual charge from solar, if you have on-site PV. That makes TOU arbitrage with grid-charging difficult to manage.
 
SGIP also requires 75% annual charge from solar, if you have on-site PV. That makes TOU arbitrage with grid-charging difficult to manage.
From the 2017 SGIP Handbook Version 6:

5.3.4 Paired with On-site Renewables
To be considered paired with and charging from on-site renewables, energy storage systems must either be claiming the Investment Tax Credit (ITC) or, if not claiming the ITC, charge a minimum of 75% from the on-site renewable generator.

So if you are not taking the ITC, you can choose not to commit to charging 75% from the on-site renewable generator, and the SGIP will not consider your energy storage system paired with the on-site renewables.

The only SGIP benefit I can see to being paired with on-site renewables is that in the event a step is oversubscribed and a lottery occurs (e.g. as in Step 1), paired systems get priority. That situation doesn't seem likely to repeat itself. The downside to being a paired system is that you must submit a preliminary monitoring plan with your SGIP application.

Cheers, Wayne
 
So if you are not taking the ITC, you can choose not to commit to charging 75% from the on-site renewable generator, and the SGIP will not consider your energy storage system paired with the on-site renewables.
So you're saying it's possible to have "unpaired" storage If one is taking SGIP rebate and there's a on-site renewable generator? How does SGIP allow that when the mandate of the rebate is to encourage renewable uptake?
 
Week++ :)


Have you called config/completed after this? If not, changing the mode does stop the powerwall. I assume you have (and you get 202 accepted), but just in case, I thought I'd mention it.
ok i just defined commands "charge" = backup/100, "discharge"=self_consumption/10, "standby"="self_consumption/100", keeping around start and stop as well although standby now should take care of "stop all activities, outage backup only" behavior. The rest should be a matter of putting that into crontab if one has 24x7 unix-based device around.. i might be able to push it to synology, although the model i have is too old to have java installed it seems... if not i will try to get it into roqos router which should be a fully capable debian flavor... I still don't get what the real reason for withholding this functionality could be... it is required for SGIP if not approval, then inspection i gather. How am I supposed to demonstrate i can discharge the PW to a SGIP inspector??? they can't be THAT short-handed... or incompetent... or be out of spec with grid or something... I am not sure what is worse...

Now that i understand how trivial the problem actually is I have a serious problem with trust in the competence of this company. We kind of see same patterns of grand overpromises in M3 release which i am also waiting for... I am not sure i want my next deal with them, although I am all for what they formally declare they stand for.
 
Last edited:
SGIP for energy storage would be available if you didn't have solar, so why should the program requirements be stricter if you do have solar?

Cheers, Wayne
Per the handbook's definition:
Paired: Two or more technologies located on the same electrical circuit and behind the same utility electrical meter.
Otherwise, why would anybody choose paired with its more stringent requirements?

Per your quote and this one:
Systems Pairing with On-site Renewable Generators:
Energy storage systems paired with on-site renewable generators must provide a description of:
• The anticipated charge and discharge schedule of the system demonstrating that the system complies with ITC operational requirements or, for projects not claiming the ITC, will be charged at least 75% from renewables;
75% minimum.

Another definition:
Energy Storage Paired with and Charging from an On-site Renewable Generator: Energy storage system that is paired with an on-site generator and charges at a minimum 75% from the generator

So my original assertion stands and I ask how do you get an installation that's considered unpaired in order to avoid the 75% minimum rule?
 
Otherwise, why would anybody choose paired with its more stringent requirements?
Precisely, there's no reason to choose to. [But if you are claiming the ITC, then SGIP forces you to apply as paired storage.] Unless you want priority in the event of a lottery, that is the one benefit I could find. Those who applied in Step 1 as paired storage are presumably glad they did so, since Step 1 had a lottery.

Note that none of the language from the SGIP handbook you quoted says "if you have solar, you must pair your energy storage from solar and charge the energy storage at least 75% from solar."

I applied for SGIP as my own developer (see the SGIP thread), and I simply indicated on my application that while I have solar, I'm not planning to charge 75% or more from solar.

Cheers, Wayne
 
ok i just defined commands "charge" = backup/100, "discharge"=self_consumption/10, "standby"="self_consumption/100",

Is there any difference between "charge" and "standby?" I'm using self_consumption/50 and self_consumption/100 as the two states and it will still charge at self_consumption/100, albeit only at 1.7 kW per Powerwall. There was a post saying that backup/90 would turn off the Powerwall, but I haven't played with that yet.
 
note thats' without solar. Not sure about stuff with solar.

standby: The idea is that there may be some spans of day when we want neither charge nor discharge. E.g. in the summer i might run AC extensively and my PW capacity may not be enough to cover entire peak+partial peak demand, in which case i may have to devise strategies not to discharge during some of partial peak (but at the same time i don't want to charge the PW from grid at partial peak rates either).

But you are right -- it does seem to keep charging in self_consumption/100 from grid. Maybe, to enter stand-by, i need to read the soe and then switch to self_consumption/<current-soe-read>. That should in theory place it right where it needs to be for standby, only sipping a little bit to keep that soe due to losses from time to time. I will check this ...

Is there any difference between "charge" and "standby?" I'm using self_consumption/50 and self_consumption/100 as the two states and it will still charge at self_consumption/100, albeit only at 1.7 kW per Powerwall. There was a post saying that backup/90 would turn off the Powerwall, but I haven't played with that yet.