Refactoring the proxy. #143
Conversation
Nexarian
force-pushed
the
re-work-proxy-next
branch
from
673e361 to
3716e1f
Compare
| @@ -16,7 +16,7 @@ <h2 style="color:gray;font-family:verdana;">iFrame Example</h2> | |||
| <script> | |||
| // Get Firmware Version | |||
| function showversion() { | |||
| var pwver = window.location.protocol + "//" + window.location.hostname + ":8675/version"; | |||
| var pwver = window.location.protocol + "//" + window.location.hostname + ":" + window.location.port + "/version"; | |||
There was a problem hiding this comment.
Yes! This needed to be some time ago. Thank you!
There was a problem hiding this comment.
I still occasionally have issues with it not loading and/or reporting correct data, but I feel like that can be solved incrementally and later.
There was a problem hiding this comment.
The change causes the issue or is this something else? Any odd errors in the javascript console?
There was a problem hiding this comment.
-
Sometimes this code path gets executed when
client.session(Or really, thesessionvariable) isNone. I blocked that with a simple if check, but I'm not sure whatsessionis supposed to be in the context of TEDAPI or what this code path is for. Maybe blocking it is indeed the best path. -
Also I've noticed that the first time after server startup, the widget sometimes doesn't load. I have to refresh a few times, I haven't solved that either.
-
Finally, and I think this is more a Tesla bug we have to work around: In the case where my panels generate significantly more power than the house is using (and thus sending a large amount back to the grid) the house shows as a negative load with a warning icon next to it. This is wrong, the house is still using power, my inverters setup is bugged. My installer (and therefore by proxy, Tesla) say that it's a bug with Tesla's monitoring, but they haven't provided any information on when a potential fix may be coming.
I don't believe any are directly related to my refactor; however. Likely just exposed through testing.
There was a problem hiding this comment.
But my house is actually using 1.7 kWh!
| WORKDIR /app | ||
| COPY requirements.txt /app/requirements.txt | ||
| COPY ./proxy/requirements.txt /app/requirements.txt |
There was a problem hiding this comment.
I assume most would build the container from the directory that contains the Dockerfile (proxy), which is where my automation goes to build and push the proxy container. This would break that. Did you have another idea?
There was a problem hiding this comment.
I did this because I needed to test changes to the proxy AND pypowerwall itself and I didn't know of another good way to build them together, did I miss the memo on how to do that?
Anyway, I think what I should do is move this configuration to a different Dockerfile and leave this one alone.
There was a problem hiding this comment.
Fair point. My dev and beta build script copies the library before running the build (cp -r ../pypowerwall .)
- Enable ability to handle multiple gateways. Fixing aggregates and problems with grid status Improvements in accuracy and functionality Changing alerts to be consistent with the -3 suffix
Nexarian
force-pushed
the
re-work-proxy-next
branch
from
3716e1f to
41c6412
Compare
Fixing aggregates and problems with grid status
Improvements in accuracy and functionality
Changing alerts to be consistent with the -3 suffix