Awesome, glad to help anyway we can anybody in SRP region shares this problem I am sure. If Tesla doesn't want to fix it might as well take it into our own hands.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Arizona Powerwall Installs
- Thread starter Instaurare
- Start date
-
- Tags
- arizona Powerwall Tesla Energy
Awesome, glad to help anyway we can anybody in SRP region shares this problem I am sure. If Tesla doesn't want to fix it might as well take it into our own hands.
ArizonaJon
Member
Solar does. But the PWs do not as the cost of energy from a PW, considering the depreciation, is more than the cost from TEP. Net billing is no longer available. But the spread between Peak and Off-Peak is not enough to justify the cost.
I put in PWs for backup of our medical equipment when there is a power failure. I have also enjoyed never having to reset a clock due to a power failure (also no day light savings time in AZ, so we never have to reset a clock). I used a local company, Technicians for Sustainability, for my installation. I am sure their cost is more than Tesla, but the service is great and they use the Tesla battery, gateway, etc. They even have PWs in stock.
ArizonaJon
Member
Yes about 10 years. But if you want a faster payback, maybe I can pay your electric bill for you and bill you at the PG&E rate. LOL
Last week Tesla installed solar panels and three PowerWalls in our Phoenix home. The installers placed the batteries in the garage and stacked them to limit their footprint; they still have plenty of airflow. The entire installation takes up quite a bit of wall space, but it's manageable.
After the battery guys left on the second day, one of the solar installers remarked that they would likely need to come back to reinstall the Powerwalls. He said that stacking batteries is against code in Phoenix and that the installation would fail inspection.
Since all the electrical panels were positioned based on the assumption that the batteries would be stacked, relocating the batteries around the garage is going to be challenging. When the installers come back, they're likely going to expand the installation footprint to two or three walls, and run conduit all over the garage. This is all incredibly frustrating. At this point I'm considering dropping the Powerwalls altogether.
Has anyone else in Phoenix run into a similar issue with their Powerwall installation?
I've also asked if the batteries could be relocated outside the garage. I'm waiting to hear back.
After the battery guys left on the second day, one of the solar installers remarked that they would likely need to come back to reinstall the Powerwalls. He said that stacking batteries is against code in Phoenix and that the installation would fail inspection.
Since all the electrical panels were positioned based on the assumption that the batteries would be stacked, relocating the batteries around the garage is going to be challenging. When the installers come back, they're likely going to expand the installation footprint to two or three walls, and run conduit all over the garage. This is all incredibly frustrating. At this point I'm considering dropping the Powerwalls altogether.
Has anyone else in Phoenix run into a similar issue with their Powerwall installation?
I've also asked if the batteries could be relocated outside the garage. I'm waiting to hear back.
charlesj
Active Member
Most folks need more than 1 powerwall, Its an all or nothing proposition due to how demand is priced.
YOu have to see your peak Kwh used in 2-8pm, and subtract what solar will product 2-8pm and the left over is how much battery roughly you need and maybe 5-10kwh buffer additional.
4KW => 10kwh production
1 Battery => 10kwh production
These are summer stats for west facing roof.
I would exercise caution here, SRP is very specific in its billing and demand management is very key.
Battery is 80% part of the equation with solar being a measly 20% or less. Battery is most important, I would get as much batter as you can. I would stay with 3, if your original design and plan called for 3.
Finally the day has arrived and my system is activated as of Saturday!
@blueice89 are your API calls still working? I was messing in python for a bit, but it looks like local api that I was planning to use now requires one to toggle the PW power switch physically to get a token (and it expires regularly).
So I was trying to use the cloud api, and got a token and was able to get info, and even post some changes without getting any errors, but it didn't actually change the mode or reserve %
Version 1.50.2
@blueice89 are your API calls still working? I was messing in python for a bit, but it looks like local api that I was planning to use now requires one to toggle the PW power switch physically to get a token (and it expires regularly).
So I was trying to use the cloud api, and got a token and was able to get info, and even post some changes without getting any errors, but it didn't actually change the mode or reserve %
Version 1.50.2
Yup , i switched completely to cloud API, and control the reserve %
fkhera/powerwallCloud
I also made a youtube video about it using Raspberry PI:
Awesome! I actually setup the peak checking logic all in python myself after using the lock apis successfully, and then when I finished I tried again and realized the token expired and couldn't get a new one again, so just gotta figure out the cloud api calls, but shoot looks like you already got it all packaged up neatly for me to clone onto my pihole. I'll check it out! Awesome!
@blueice89 I actually decided to write my own. It looks like your code still has remnants sticking around unused or relating to the old local api, and I also found the tesla_api for the cloud that seemed a bit neater, and has instant results by calling the mode change (toggling between backup-only and self-powered) instead of adjusting the target battery reserve, which has that delay you were experiencing.
I did enjoy reading through your code though and definitely learned about how to account for holidays, among other things (which I haven't yet implemented, but not too concerned about)...I may throw it up in github if you're interested.
I did enjoy reading through your code though and definitely learned about how to account for holidays, among other things (which I haven't yet implemented, but not too concerned about)...I may throw it up in github if you're interested.
@viperscorpio, yeah keep me posted I would be curious how can change backup or the mode without the 15 minute delay, yeah my code is pretty old, its changed a couple of times and originally someone else code.
@blueice89
bchristian14/tesla_api
fork of the tesla_api repo with `power_manager.py` added.
Edit for clarity:
I forked the tesla_api repo and wrote a power_manager script to check if the current date/time is within a peak period (already configured for SRP's pricing schedule, but easily adjustable), and the script will toggle between "backup-only" (non-peak) and "self-powered" (peak) modes.
Requirements/steps:
a device that supports python running 24/7 with an internet connection, like a raspberry pi.
1) clone repo
2) python 3.7
3) pip install aiohttp package
4) update power_manager.py with appropriate tesla credentials, and any desired adjustments to the peak/season variables
5) call the script via cronjobs.
6) sit back and enjoy minimizing your grid usage during peaks, and prioritizing charging during off-peaks.
bchristian14/tesla_api
fork of the tesla_api repo with `power_manager.py` added.
Edit for clarity:
I forked the tesla_api repo and wrote a power_manager script to check if the current date/time is within a peak period (already configured for SRP's pricing schedule, but easily adjustable), and the script will toggle between "backup-only" (non-peak) and "self-powered" (peak) modes.
Requirements/steps:
a device that supports python running 24/7 with an internet connection, like a raspberry pi.
1) clone repo
2) python 3.7
3) pip install aiohttp package
4) update power_manager.py with appropriate tesla credentials, and any desired adjustments to the peak/season variables
5) call the script via cronjobs.
6) sit back and enjoy minimizing your grid usage during peaks, and prioritizing charging during off-peaks.
Last edited:
My only comment I think the approach is the weekend.
I don't really do anything on the weekend, and I think I might have a more conservative approach maybe?
Weekend is all off peak, so I just run the Crons _Monday -Friday.
And always close every weekday at 9:01PM currently.
So that will close Friday night, and the schedule resumes Monday morning with 0 actions run on the weekend.
I think this might be a little more efficient.
The one thing I want to avoid is any type of discharge between Friday 9:01pm and Monday 440am.
So I was curious why you also run on weekends unless I misread something.
My crontab is:
Winter is:
4:40 am - time of use 0% reserve
9:01 am - backup 100% reserve
4:40 pm - time of use 0%
9:01 pm - backup 100% reserve
(Its also symetric)
#Summer
40 13 * 5-10 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 20 * 5-10 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
#Winter
40 4 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 09 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
40 16 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 21 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
I don't really do anything on the weekend, and I think I might have a more conservative approach maybe?
Weekend is all off peak, so I just run the Crons _Monday -Friday.
And always close every weekday at 9:01PM currently.
So that will close Friday night, and the schedule resumes Monday morning with 0 actions run on the weekend.
I think this might be a little more efficient.
The one thing I want to avoid is any type of discharge between Friday 9:01pm and Monday 440am.
So I was curious why you also run on weekends unless I misread something.
My crontab is:
Winter is:
4:40 am - time of use 0% reserve
9:01 am - backup 100% reserve
4:40 pm - time of use 0%
9:01 pm - backup 100% reserve
(Its also symetric)
#Summer
40 13 * 5-10 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 20 * 5-10 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
#Winter
40 4 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 09 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
40 16 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 21 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
My only comment I think the approach is the weekend.
I don't really do anything on the weekend, and I think I might have a more conservative approach maybe?
Weekend is all off peak, so I just run the Crons _Monday -Friday.
And always close every weekday at 9:01PM currently.
So that will close Friday night, and the schedule resumes Monday morning with 0 actions run on the weekend.
I think this might be a little more efficient.
The one thing I want to avoid is any type of discharge between Friday 9:01pm and Monday 440am.
So I was curious why you also run on weekends unless I misread something.
My crontab is:
Winter is:
4:40 am - time of use 0% reserve
9:01 am - backup 100% reserve
4:40 pm - time of use 0%
9:01 pm - backup 100% reserve
(Its also symetric)
#Summer
40 13 * 5-10 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 20 * 5-10 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
#Winter
40 4 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 09 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
40 16 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py tou > logTou.txt
1 21 * 1-4,11-12 1-5 python /home/pi/powerwallDriver.py backup > logBackup.txt
Yeah there's no reason it needs to run on the weekends, but I already account for it in python so I didn't really care about fixing the from schedule. I actually should've probably made that a variable so if someone does have weekend peaks it would be easily changed.
Instead of changing backup reserve, it actually changes the mode between backup only and self powered, which reflects nearly instantaneously, so I can do it 3 mins before/after peak window.
Also, I found it tidier to have it all in one script, instead of 3 separate files.
Fun fact, the day after I made it, my internet went out for 5 mins while the cron was scheduled so maybe I should see if I can cheaply more the workload to the cloud
We got our SRP demand bill down to $2.44 and total bill is around $92.00 with $32.00 of that being the grid fee so only spent spent around $50.00 on like 1370kwh. That comes to an average of around 3.6 cents per kWh. We love our powerwall automation setup and that we can avoid the peak pricing times and demand fees.
We don’t currently add on more solar panels cause after demand goes to zero the return on kWh for us is only 3-4cents per kWh.
Setup : 7.6kw solar panels and 2 powerwalls
SRP e-15 plan
Current use around :1500-2000kwh per month
Family of 5, 4300sq ft house pool , ev charge, hybrid water heater
Location: Gilbert, Arizona
Here are is a sample bill to get idea of savings.
We don’t currently add on more solar panels cause after demand goes to zero the return on kWh for us is only 3-4cents per kWh.
Setup : 7.6kw solar panels and 2 powerwalls
SRP e-15 plan
Current use around :1500-2000kwh per month
Family of 5, 4300sq ft house pool , ev charge, hybrid water heater
Location: Gilbert, Arizona
Here are is a sample bill to get idea of savings.
Attachments
Last edited:
