Getting data from my Tesla Powerwall

Looking for some guidance here.

I would like to pull data from my Powerwall 2 into emoncms but reading through the forums has left me confused. The posts seem old and imply that recent changes have left most of the solutions invalid.

So question 1 is - Can you currently pull things like state of charge etc from a powerwall gateway 2?

The next problem is more case of my lack of knowledge. I have decades of programming experience on everything from timeshare systems, PCs, minis and most recently arduinos and a little bit of Raspeberry Pi, but I never got into things like python, json, php and all that. Hence I’m struggling to understand how to get my emonpi to pull data from a powerwall. It seems to be something to do with the node data on the conf file, but what else do I need to do? Some pointers or a guide would be good if this is at all possible!

I’m happy to use google to learn, just need some starters to understand the basics of the process!

Many thanks in advance


Hi Steve,

have a look at the post from John Banks in this thread post #10 Powerwall State of Charge Interfacer stopped working - Tesla updated their software

I only use the Powerwall SoC, as input to the Solar Battery app, has worked fine for me.


I can confirm that my script ( referred to in the previous post is still working for me.
And I hope that statement is not tempting fate.

1 Like

Hi Steve, you may find some useful information here. I had a powerwall installed a couple of weeks ago and the installer told be that interfacing has got a bit harder recently because Tesla have upped security.

I have not got into the tesla API yet but hope to do so in the future.




Thanks, I will check this out, but I did work through Stuart’s excellent instructions and code and the Tesla feeds are working just fine in my system these days - so go for it!

Now I am starting to look at pulling the half hourly data from Octopus and see what I can gain from that! It is going to be an interesting few months trying to keep the energy bill under control, but the power wall and solar have radically eased the situation for us.


Hi John,
I’ve had your script running collecting data every 30 seconds via the api for months, and logging to feeds. I don’t use the feeds much as I have OEM kit to provide equivalent data. I needed to do some battery troubleshooting today so compared the PW feeds with the CT feeds, only to find that there have been repeated, many days long breaks in the PW feeds. I’m wondering if there is an api limit which is reached, then variable length timeout. It looks like c. 60hrs data followed by 120hrs break. Do you see this at all?
Thanks in advance!


I haven’t had yr problem of long breaks in the feed but then I check my system daily.

When I do have a problem, the usual fix is to restart the powerwall.service by doing: sudo systemctl restart powerwall.service in a terminal.

So in yr case it might be a good idea to alter line 41 in my script to read:

restart_hrs = “2.0”

Use yr judgement here as to the number of hours.

Thinking about other possibilities …

Power cuts happen and yr Raspberry Pi will reboot. Is powerwall.service enabled in this case? Do: sudo systemctl enable powerwall.service in a terminal to ensure the service restarts on each reboot.

IP addresses seem to wander for reasons I don’t understand. Is yr PowerWall Gateway address fixed in yr internet router? It’s set in my script at line 48:

gateway = … in my case … yrs will be different.

You can discover yr Gateway address by doing a nmap scan on yr network. The Gateway has a MAC address starting CC 88 which will help identify it.

(line numbers will vary if you’ve made changes to my script).

Hope this helps

Thanks for the helpful guidance.
The powerwall.service shows as enabled and running via systemctl, and I am currently seeing data. I’ll need to check this regularly and see what the status is when the data drops out again. Judging by past performance, this will be on Sunday!

For now I’ve left the restart_hrs at 48

Powerwall is using DHCP on an ethernet connection but has a reservation on the router so always gets the same IP address. The ethernet MAC begins 98ED (via arp -a), but WiFi is CC88 as you noted.

I’ll report back on this soon.

Thanks again.


Not so soon as the data kept coming! Then it dropped off the chart again. However, this is a display issue, not a data issue. I mistakenly set the feed up as a 10sec fixed, but the script is only run every 30sec so the feed is partially populated. Using the csv output in the graphing module I can see that the blank graph periods are where the feed slips an increment, so from being :00 and :30 secs to :10 and :40 secs. The display of the data is “aliased” to the fixed interval set for the graph, so this step in the populated data results in all nulls. Careful change of start time can reverse the issue!
So, no problem with your fine script, just with my setup!
One day I might work out how to export the feed and sort this out!

Thx for the update and yr compliment :slight_smile: