Strategies for Powerwalls and Utility Demand Plans

[miimura]

The plan I'm on has cheap kwh rates for both off-peak ($0.05) and on-peak ($0.08). Where they get you is the peak demand charge...$17.50/kw during the on-peak hours. So I'm less worried about small losses and more worried about having the batteries 100% charged so I can make it through the 5 hour window running the A/C nearly full-time (I'm in Phoenix, it's 110+ outside, and it's monsoon season where we get afternoon storms that can block solar production and potentially knock out power after the sun goes down), and pull zero or as close to zero as possible from the grid. That's my motivation to prioritize charging the batteries first.

Once I get through the rest of the summer seeing how this system performs, I may re-evaluate the plan I'm on and see if I could do better on a different plan with higher kwh rates and lower or no demand charges, which would change my strategy. TBC/Cost Savings could be a better route then.

If you're on this kind of demand plan and don't want to export during Peak like TBC wants to, then you should use the external automation to change the Self Powered Reserve between 100% during Off-Peak and 10% during Peak. This will actually save you more battery energy during Peak because it won't export your solar and instead let it power the A/C to the extent that it can.

 

[destructure00]

If you're on this kind of demand plan and don't want to export during Peak like TBC wants to, then you should use the external automation to change the Self Powered Reserve between 100% during Off-Peak and 10% during Peak. This will actually save you more battery energy during Peak because it won't export your solar and instead let it power the A/C to the extent that it can.

That's exactly what I'm doing, using @Darwin Powerwall Manager on my Hubitat hub.

Desired behavior during off-peak is:
- Solar charges battery first while house pulls from grid
- After batteries are full, solar powers house with any excess being exported to grid

Desired behavior during on-peak is:
- Solar powers house first
- If demand exceeds solar production, pull from batteries
- If solar production exceeds demand, recharge batteries if needed
- If batteries are full and solar production exceeds demand, export to grid

 

[destructure00]

How long are you guys seeing for a mode or reserve level change to take effect? My Hubitat rule triggered at 3. Attributes in Hubitat updated immediately, Tesla app also shows correct settings (Self-Powered, 0% reserve), but gateway still shows PWs inactive with some power being pulled from the grid instead of the batteries.

 

[destructure00]

Well now that I'm looking at my usage chart, I had mistaken power from grid for power to grid, looks like solar was providing a little bit more than the house was consuming. 23 minutes into the mode change and solar is still producing just enough to power the house with AC running, hasn't touched the battery yet. Will keep an eye on it as solar tapers off this afternoon.

 

[Darwin]

From what I've read, it sounds like Backup Only mode and Self-Powered with 100% reserve should operate the same and prioritize charging the battery first, then powering the house, then exporting any excess. Is there any advantage to using your Powerwall manager to set one over the other, with the assumption that I'm going to set Self-Powered with 0% reserve during peak times?

I'm not sure why, but with Self-Powered 100% Reserve, every once in awhile some solar was being sent to the home instead of charging the Powerwall. I didn't investigate the few times I saw this happen. It may be that the Powerwall didn't really accept the 100% reserve setting, even though it showed as 100% and plenty of time had passed. I did, however, change my automated schedule to set my off-peak hours to Backup Only mode just in case it makes a difference and haven't seen the issue since. I still set on-peak hours to Self-Powered 0% reserve.

Also, FWIW, I made a virtual switch in Hubitat that turns on at midnight on peak days and off at midnight on off-peak days. I have the APS holiday schedule integrated into the scheduler for this switch rather than following a strict Mon-Fri schedule, and want to use it to conditionally set the PW modes based on the combination of day of week and APS off-peak holidays. I didn't see a way to use a switch as a restriction in the PW manager, so for now I'm using Rule Machine to set the PW mode and reserve levels. Maybe something to consider integrating at some point.

Using a switch as a schedule trigger or restriction would definitely be useful for many. I've been trying to keep from adding more clutter and complexity to the scheduling options interface, but maybe there is a way to implement without adding too much more UI complexity. I'll put it on the enhancement list and give it some thought. Thank you.

 

[miimura]

I'm not sure why, but with Self-Powered 100% Reserve, every once in awhile some solar was being sent to the home instead of charging the Powerwall. I didn't investigate the few times I saw this happen. It may be that the Powerwall didn't really accept the 100% reserve setting, even though it showed as 100% and plenty of time had passed. I did, however, change my automated schedule to set my off-peak hours to Backup Only mode just in case it makes a difference and haven't seen the issue since. I still set on-peak hours to Self-Powered 0% reserve.

Self-Powered with 100% Reserve does not have the same PW charging effect as Backup. Self-Powered will still minimize grid draw whenever possible. That means that it will only charge with Surplus Solar, not All Solar. Backup and TBC can charge from All Solar. If you want to charge the batteries as fast as possible from Solar, switch to Backup Mode.

 

[woferry]

I'm not sure that's true, at least it wasn't true for me at lower levels, I didn't try it at 100%. In my usage, the PW charging policy seems to be driven by the Reserve level. So in Self-powered, with the current SoE at say 5% (app), raising the Reserve from 0% to 20% results in the PW taking all available solar power (I was producing less than 5kW at the time) until it reached the new Reserve, then it went back to only charging from excess solar. So it seems to me that raising the Reserve to 100% should be the same, but I'll admit I've never taken my Reserve above 20%, so I have no direct proof. But raising my Reserve from 0-20% caused my PW to charge from all solar when I last did that this past winter.

 

[miimura]

I'm not sure that's true, at least it wasn't true for me at lower levels, I didn't try it at 100%. In my usage, the PW charging policy seems to be driven by the Reserve level. So in Self-powered, with the current SoE at say 5% (app), raising the Reserve from 0% to 20% results in the PW taking all available solar power (I was producing less than 5kW at the time) until it reached the new Reserve, then it went back to only charging from excess solar. So it seems to me that raising the Reserve to 100% should be the same, but I'll admit I've never taken my Reserve above 20%, so I have no direct proof. But raising my Reserve from 0-20% caused my PW to charge from all solar when I last did that this past winter.

I don't normally use Self-Powered, so the actual behavior may be different than what I said. Of course, firmware changes can change the behavior too. Anyone who wants a particular behavior needs to try it for themselves and see how their system reacts to their own settings.

 

[destructure00]

@Darwin , another question for you, I think I know the answer already but going to ask anyway. Is there any provision for full local control of the Energy Gateway from your app? Or is it cloud-dependent? Since I'm on Hubitat, was thinking it would be nice to stay completely local and send commands directly from the Hub to the Gateway. Wondering if there's a simple way to point your app to the Gateway's IP address rather than https://owner-api.teslamotors.com

I just got done stringing ethernet cable across the attic to the Gateway...3 days in and it seems like the WiFi connection drops a few times a day for 20-30 minutes. So far not an issue since it hasn't happened at 3 or 8pm when mode changes are sent, but it was just a matter of time.

 

[Darwin]

@Darwin , another question for you, I think I know the answer already but going to ask anyway. Is there any provision for full local control of the Energy Gateway from your app? Or is it cloud-dependent? Since I'm on Hubitat, was thinking it would be nice to stay completely local and send commands directly from the Hub to the Gateway. Wondering if there's a simple way to point your app to the Gateway's IP address rather than https://owner-api.teslamotors.com

Full support of the local gateway interface is on the to-do list of potential enhancements for the Powerwall Manager (when running on Hubitat at least. SmartThings currently appears to have an issue with handling the local gateway self-signed certificate). The local gateway API is different enough that this will require some work and I unfortunately can't commit to any timelines right now. I know this is important to many users, especially for those running on Hubitat. For me, the interface with https://owner-api.teslamotors.com has been pretty solid as of late, but I know that may not always be the case. It would also good to be ready with an alternative in case Tesla changes its web access to 2FA or otherwise changes the authentication requirements.

There's been a little progress on this front though. The latest (July v0.2.8) Powerwall Manager when running on Hubitat does provide the following option to connect directly to the local gateway, but it is currently limited to reading (only) the non-authenticated data such as the meter aggregate data (solar, load, grid, etc power) and SOE/battery percent. It does not currently support requests requiring local gateway authentication such as reading or commanding operational mode (Backup-Only, Self-Powered, etc). If you use either of the local gateway connection options with this latest version of the Powerwall Manager (when running on Hubitat), it also provides the option to display a dashboard tile that grabs an iframe from the local gateway web page. The dashboard tile was a bit of an afterthought, but I've found it to be a pretty handy addition to my Hubitat dashboard running full time on a wall-mounted Fire 10 tablet:

I just got done stringing ethernet cable across the attic to the Gateway...3 days in and it seems like the WiFi connection drops a few times a day for 20-30 minutes. So far not an issue since it hasn't happened at 3 or 8pm when mode changes are sent, but it was just a matter of time.

Good call. I noticed several issues with the gateway Wifi connection when my Powerwall was installed about 1.5 years ago and I ended up running a direct ethernet cable the first week or so. The biggest issue I found was that the gateway would often fail to re-connect if my WifI was re-started. None of my other WiFi devices had this issue. I'm not sure if that issue has since been resolved, but the direct ethernet connection has been rock solid and I haven't looked back.

 

[destructure00]

The local gateway API is different enough that this will require some work and I unfortunately can't commit to any timelines right now.

No worries, totally understand. Thanks for all your work on this!

 

[bobbyclee]

We had a powerwall installed three weeks ago and I had all sorts of software issues for the first couple of weeks. One thing I didn't realize was that it takes an hour or two for a setting entered into the app to make it to the powerwall. I didn't figure this out until I used a computer to directly connect to the powerwall gateway via wifi and look at the settings using the web-based powerwall UI. I also had a situation where things would seem to work after Tesla would visit and tinker with the powerwall. But then I would play with the app and the powerwall would start to misbehave and show obviously incorrect data in the app (solar energy was correct, but home consumption was shown as exactly matching solar and grid energy was shown as zero which didn't match the electric meter or common sense). I could also get things to behave again by hitting the reset button on the gateway and then re-entering the wifi info and other stuff through the web-based powerwall UI. I was able to get self-consumption mode to work as long as I didn't try to change the reserve setting in the app. I also turned off storm watch just in case that was messing things up. Eventually I gave the Advanced time-based control a try (with the cost saving option) and much to my surprise it worked perfectly! I haven't changed the settings in the app since then and the powerwall now does exactly what I want it to given our time-of-use plan.

In the morning before peak prices start, all the solar is being used to charge the battery and the power to run the house is coming from the grid. When the battery fills up then the excess solar is sold to the grid. Once we hit 2 pm when peak prices start, the powerwall switches to using the battery to run the house and sells ALL the solar to the grid. Once the sun goes down, the house is powered exclusively by the battery until 9 pm when the peak prices end. Then the house switches back to the grid.

In order to qualify for the federal tax credit and/or to make our local utility happy it seems like the powerwall is only able to charge from solar and can only use this stored energy to power the house rather than selling it back to the grid. Under these constraints, the powerwall seems to be behaving optimally.

I can't be completely sure if rebooting the gateway + leaving the setting on the app alone is what fixed the problem. I also sent lots of emails to Tesla technician who installed the system and he escalated things to his manager so it's possible Tesla did something remotely to fix things.

The TL;DR version is to try rebooting the powerwall gateway, connecting directly through wifi to the gateway, and leaving the settings on the app alone as tempting as it is to tinker with things.

Hi all,

I'm new to this Tesla Motor Club forum... but I'm a huge Tesla fan, and eager to participate.

This is a Solar + PowerWall + TOU Rates + Net Metering + SAVE MONEY topic.
My PowerWalls are not behaving as expected (as I want them to behave.) I've been searching the forum and trying to see if anyone out there is encountering my use case with Time-of-Use rates and Net-metering:

I recently had a 4x PowerWall system installed (I think it's PW2), adding to my existing Tesla solar panel system of 11 kW. I got Permission To Operate on August 16, and turned on the PowerWalls then.

I'm in Las Vegas, Nevada, and my utility is NV Energy. I'm on TOU rates, where the summer peak price is $0.435 (with +$0.407 credit for net-metering), and off-peak rates are just $0.053 (with +$0.045 credit for net-metering).

As you'll notice from the rates I've posted, the net-metering credits during the summer (at +$0.407) are huge multiples from the evening off-peak prices ($0.053), at almost 8x. This means that for every 1 kW I send to the grid via net metering during my peak hours (from 1 pm to 7 pm), I can get credit from NV Energy, and it's worth like 7.6 kW of electricity off-peak.

Using my PowerWalls, I'm simply trying to arbitrage the rate differences using net metering:
1) Mornings during off-peak (until 1 pm):
a) Use solar to charge up the PW battery (the morning solar is enough to fully charge the PW)
b) Send excess solar to grid for +$0.045 / kW.
2) Afternoons/Evenings during peak (from 1 pm to 7 pm):
a) Use 100% of PW to power 100% of house (My fully charged PW battery has enough to power the house)
b) Send 100% of solar to the grid, to earn the net-metering credits at +$0.407 / kW.
3) Evenings off-peak starting at 7 pm:
a) STOP discharging PW, and save the remaining battery level for next day
b) Use the Grid for 100% of load for the whole off-peak duration

Is this possible? I ASSUME the answer is YES, as it's so simple! (the post quote above seem to show evidence that this DOES indeed work for some people out there...)

The Time Based Controls + Cost Savings mode should do it.... but the reason I'm posting this is because my PW system is NOT doing it for me.

Here's what happens on my system, referencing the 3 points I listed above:
1) Yes, (a) and (b) both happen.
2) No. Here is what happens during peak period:
- When Solar output is higher than the Household load, only the excess solar goes to the grid, and PowerWall doesn't contribute at all. This means that there's valuable Solar that is NOT going back to the grid for net-metering credits, whereas my charged up PW is sitting idle.
- When Solar output is lower than the Household load, then the PW kicks in to supply the difference of what the Solar produces, from what the Household load requires. Yes, there is no pull from the grid (which is good), but unfortunately, the Solar still is NOT sent to the grid for net-metering credits (which would be awesome), as I would GLADLY prefer to use PW to power the house during the whole Peak period, and sending ALL 100% Solar to the grid for the high-rate of net metering credits.
3) Nope... the PW will sometimes continue to discharge at night, which is mind-boggling, because we all know that charge-discharge of PW results in at least 10% penalty due to inefficiency.


Why is my system not behaving the way I like? Any clues?
I'm already on TBC and Cost Saving mode. I've set the Peak times properly in the app.

Do I need to reboot the Gateway or are there better ways to fine-tune what the PowerWalls do?

thanks,
Bobby

 

[bobbyclee]

In the morning before peak prices start, all the solar is being used to charge the battery and the power to run the house is coming from the grid. When the battery fills up then the excess solar is sold to the grid. Once we hit 2 pm when peak prices start, the powerwall switches to using the battery to run the house and sells ALL the solar to the grid. Once the sun goes down, the house is powered exclusively by the battery until 9 pm when the peak prices end. Then the house switches back to the grid.

This is EXACTLY what I want.

Can someone (or wraithnot?) please TEACH me how to get this working on my PowerWall setup?
My current PowerWalls are NOT behaving like this.

My setup:
- NV Energy with TOU rates and Net Metering
- 11 kW Solar system
- 4 x PowerWall (PW2)
- Advanced Time-Based Controls, set to Cost Saving mode
- Reserve set at 50%
- Price schedule: Peak is 1pm to 7 pm (weekdays only)

and I've tried both using Shoulder (from 8 am to 1 pm, and from 7 pm to 10 pm) and also NOT using Shoulder (so just Peak and non-Peak).

Still no avail... so any help would be appreciated.

thanks,
Bobby

 

[Dukeybootie]

This is EXACTLY what I want.

Can someone (or wraithnot?) please TEACH me how to get this working on my PowerWall setup?
My current PowerWalls are NOT behaving like this.

My setup:
- NV Energy with TOU rates and Net Metering
- 11 kW Solar system
- 4 x PowerWall (PW2)
- Advanced Time-Based Controls, set to Cost Saving mode
- Reserve set at 50%
- Price schedule: Peak is 1pm to 7 pm (weekdays only)

and I've tried both using Shoulder (from 8 am to 1 pm, and from 7 pm to 10 pm) and also NOT using Shoulder (so just Peak and non-Peak).

Still no avail... so any help would be appreciated.

thanks,
Bobby

This is my same strategy. It has been working exactly as intended using TBC-cost savings with no shoulder and peak hours set to 2-8pm. Not sure what is preventing you from duplicating what I am getting. Maybe the app needs more time to adjust to your system?

 

[bobbyclee]

This is my same strategy. It has been working exactly as intended using TBC-cost savings with no shoulder and peak hours set to 2-8pm. Not sure what is preventing you from duplicating what I am getting. Maybe the app needs more time to adjust to your system?


View attachment 582041

Is it typical for the app/system to need to time learn & adjust to your system? How long does that take?

I called Tesla Energy, and frankly they just weren't being very helpful. They keep insisting that my PW system is working as intended.

 

[Dukeybootie]

Is it typical for the app/system to need to time learn & adjust to your system? How long does that take?

I called Tesla Energy, and frankly they just weren't being very helpful. They keep insisting that my PW system is working as intended.

It took one or two days IIRC. Don't forget that weekends and weekdays are different. I tried experimenting with shoulder periods before realizing it would never do what I wanted it to do that way. Bottom line with TBC-cost savings mode is that there should never be any PW discharge during off peak hours, and the home should draw solely from PW during peak hours while sending all solar back to the grid. If that is not happening, something is wrong with your settings or the app.

 

[Eddie Lee]

Full support of the local gateway interface is on the to-do list of potential enhancements for the Powerwall Manager (when running on Hubitat at least. SmartThings currently appears to have an issue with handling the local gateway self-signed certificate). The local gateway API is different enough that this will require some work and I unfortunately can't commit to any timelines right now. I know this is important to many users, especially for those running on Hubitat. For me, the interface with https://owner-api.teslamotors.com has been pretty solid as of late, but I know that may not always be the case. It would also good to be ready with an alternative in case Tesla changes its web access to 2FA or otherwise changes the authentication requirements.

There's been a little progress on this front though. The latest (July v0.2.8) Powerwall Manager when running on Hubitat does provide the following option to connect directly to the local gateway, but it is currently limited to reading (only) the non-authenticated data such as the meter aggregate data (solar, load, grid, etc power) and SOE/battery percent. It does not currently support requests requiring local gateway authentication such as reading or commanding operational mode (Backup-Only, Self-Powered, etc). If you use either of the local gateway connection options with this latest version of the Powerwall Manager (when running on Hubitat), it also provides the option to display a dashboard tile that grabs an iframe from the local gateway web page. The dashboard tile was a bit of an afterthought, but I've found it to be a pretty handy addition to my Hubitat dashboard running full time on a wall-mounted Fire 10 tablet:

View attachment 578776 View attachment 578796



Good call. I noticed several issues with the gateway Wifi connection when my Powerwall was installed about 1.5 years ago and I ended up running a direct ethernet cable the first week or so. The biggest issue I found was that the gateway would often fail to re-connect if my WifI was re-started. None of my other WiFi devices had this issue. I'm not sure if that issue has since been resolved, but the direct ethernet connection has been rock solid and I haven't looked back.

Darwin, how did you access the WIFI port? Also which Gateway do you have 1 or 2?

 

[blueice89]

V3 Tesla auth api went live last night breaking all automation.

i updated my code and timdorr updated their documentation :
fkhera/powerwallCloud

Timdorr
Authentication

 

[MikeBur]

V3 Tesla auth api went live last night breaking all automation.

i updated my code and timdorr updated their documentation :
fkhera/powerwallCloud

Timdorr
Authentication

just installed @Darwin ’s smart app and device controlle4 for smartthings and for the life of me cannot get the Tesla u/pw for work with the smart app setup within smartthings. I would have imagined others would have same issue if this was root cause. I’m on app version 0.2.8e 20200702. I’ve tried setting up oauth in smartapp settings, just in case, though doesn’t work. Anyone getting similar?

 

[blueice89]

That is not the behavior I want. It wish Tesla would keep things simple and implement scheduled self-consumption before jumping into estimating my needs tomorrow. My observations are that they are not taking local weather conditions into account (today and tomorrow) when deciding how much to discharge. My area is looking at 6 days of cloudy/rainy weather. I have seen the powerwall drain itself in similar situations. That is a bad move for someone on a demand plan.

In self-consumption mode, the batteries do not seriously begin to discharge until 4pm for cloudy days and 6:30pm for sunny days. With 6 days of clouds and rain, time based control could leave me without enough to traverse the demand period.

Darwin died many moons ago, see my other posts for alternatives, i personally use Raspberry pi.