Replies: 3 comments
-
Nice! Thanks for raising this. We should do a top level route. Maybe something like: elif request_path in ['/ha', '/json']:
# JSON - Grid,Home,Solar,Battery,Level,GridStatus,Reserve
values = {
'grid': pw.grid() or 0,
'home': pw.home() or 0,
'solar': pw.solar() or 0,
'battery': pw.battery() or 0,
'soc': pw.level() or 0,
'grid_status': int(pw.grid_status() == 'UP'),
'reserve': pw.get_reserve() or 0
}
if not neg_solar and values['solar'] < 0:
# Shift negative solar to load
values['home'] -= values['solar']
values['solar'] = 0
message: str = json.dumps(values) |
Beta Was this translation helpful? Give feedback.
0 replies
-
I opened a PR: #174 |
Beta Was this translation helpful? Give feedback.
0 replies
-
Thanks for your help @jasonacox @erikgieseler! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I have rooftop solar with PW3 and soon to have two EV chargers of different brands utilizing a software-based load sharing. My design has Home Assistant / NodeRed querying pypowerwall to execute decision paths to manage the load sharing via smart amperage control on the charging units.
My current design uses pypowerwall's proxy, but I've been annoyed at the overcomplexity of multiple endpoints, size of payloads discarded, and the engineer in me is concerned about multiple points of failure. Probably negligible, but querying at high frequency and not confident about the receivers' garbage collection techniques, I thought I would try to simplify it.
I'm currently querying
/api/meters/aggregates
for.solar.instant_power
/api/meters/aggregates
for.battery.instant_power
/api/meters/aggregates
for.load.instant_power
/api/meters/aggregates
for.site.instant_power
/soe
for.percentage
/pod
for.time_remaining_hours
I was prepared to write my own, but then a few weeks ago I was diving into the release notes and noticed a
/csv
endpoint appear and thought, that's exactly what I need-- but it’s csv. One endpoint that directly pulls from the internal proxy cache with a single point of failure in case of future breaking changes. And actually,/csv/v2
is slightly better, but that incorporation is less clean.Beautiful - I was able to mock up a code change for extending
/csv
endpoint to produce json instead, but wanted to inquire with codeowner(s) where the enhancement makes sense. Here's what I did (and I don't like it, but it is POC)I dislike placing it in the conditional block with
request_path.startswith('/csv') or request_path.startswith('/csv/v2')
inproxy/server.py
because that block is entirely about csv. But! that block already makes the python calls to populate the values. Placing it outside this block would be duplicate code (bad) [question mark].Any suggestion on where to put this logic? There's not already a
/json
endpoint, so that is an option. But I also want to think about larger implications / implementations with this conditional./csv/v2/json
seems like a silly name, but organizationally, that is where it would go. Welcome to suggestions!For now a local implementation is allowing me to continue development and testing on the integration pieces, but I'm prepared to take suggestions in order to contribute this enhancement so that I can continue to cleanly take future changes from upstream.
Beta Was this translation helpful? Give feedback.
All reactions