Replies: 2 comments 2 replies
-
Interesting idea @JohnJ9ml ! It would be fairly easy to add this route to the proxy (and mapping to functions). As you probably guessed, the issue with your script is less about the different calls since pypowerwall will cache the data (instead of calling the PW every time) for a default of 5s, so for your example it will make the minimal number of calls. However, the bigger difference is that pypowerwall will keep the TCP connection open (actually a pool of them) to handle subsequent HTTP requests. That reduces load (and latency). |
Beta Was this translation helpful? Give feedback.
-
I did figure out how to do this. I've got a copy working locally that I will look over more for completeness and some more testing. Once I'm confident I've done this right, I'll figure out how to submit it. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm posting this here even though the proxy appears to be something that generally surfaces as part of the dashboard. That said, it's sitting in the pypowerwall source tree....
I realize I'm off on my own tangent with my PW work, but I've got years of data and years of analysis done with my own similar time series-like data in my own database. As such, I've been using both the Dashboard as well as my own instance of code against pypowerwall to fetch data from my PW3. I'd seen mentions of the proxy, but just hadn't pursued it, and was trying to keep the bicycle wheels spinning on my own deployment.
Now that I'm looking around more, watching firmware updates drive many of us batty, and multiple connectivity points, I realize maybe what Tesla is trying to defend against is me specifically: I've got at least two computers beating on their poor little CPU continually. Perhaps in their eyes, life is just not fair!
As I poked about looking at the proxy endpoints, I found that I could probably make most things work, but what I really wanted to do (and really defined 'make most things work' as 'make most things look exactly as they are now') was end up with the same JSON data structures coming back from endpoints as I was currently getting from the Powerwall() API inside pypowerwall.
Currently, at periodic intervals (probably far too periodic for Tesla's PW CPU), I'm basically doing the following:
Has anybody already extended the proxy such that all of these ended up coming back the same way via proxy endpoints?
I was thinking of something along the lines of mimicking the Powerwall() calls as:
/pw/level /pw/power /pw/site /pw/solar /pw/status /pw/battery_blocks ...etc...
I know some of them are somewhat already present, and in some cases part of the data is there, or in different form. I've not yet figured out what of these I can make full use of, but I figured while I was in town, it was better to start gathering everything I could and then sort it out down the road.
Yes, I know... it's just crying out for me to be a contributor, right? I've written exactly one thing in python, and it's the wrapper I'm using to do this work, and I'm quite convinced it's a terrible hack. (Plus, this damned whitespace meaning something important and nesting is absolutely eating my braces-loving Java-coding lunch!)
I just didn't know if someone had already put a nice little bow on the thing and made it so that convenience endpoints matched up exactly with the Powerwall() API.
I have noticed over time that the proxy connection is more resilient than my own, and maybe it's time to stop abusing that PW CPU and just take advantage of the data already being fetched.
Beta Was this translation helpful? Give feedback.
All reactions