Open jasonacox opened 1 year ago
@jasonacox Hey wanted to let you know that I was able to get this working about 90%. Unfortunately it is a pretty major change, and was easier done in InfluxDB 2.x.
Happy to give you a preview of my progress, however I am not quite sure how to export InfluxDB 2.x work.
Awesome! Thanks for the update @nberardi ! Feel free to share details (or even screenshots). 😁
What caused you to move to InfluxDB 2.x? I attempted to upgrade and saw that it was a fairly steep breaking change. For example, all the continuous queries need to be converted from QL to Flux and moved to tasks. It also failed to run on older ARM RPis, but that is likely less of an issue now. Would love any tips as part of your effort!
@jasonacox It was actually less of a breaking change than you would expect, and in many respects I was able to eliminate most of the CQ's, and simplify the dashboard queries without loss of functionality.
The only CQ's I kept were autogen
and kwh
. The others were easily represented as standard queries with aggreateWindow mean queries.
The main reason for the move is that I was going to need to rewrite the entire dashboard to make the powerwall gateway's selectable via a variable, and the QL's were very complex compared to the Flux counter parts for introducing a new filter. I will post what I have in the morning to give you an idea of what changed. But what I have should be backwards compatible.
Awesome! Thanks @nberardi !
Count me in for some beta testing if a move to Flux is afoot!
I'm hoping this will allow for dynamic tracking of ToU billing and valuing internal consumption (at least a lot more easily than this can be done in InfluxQL).
if you have a fork/branch of the repo to share, i would love to try it out.
Let me get this started. I have put it off too long. I have the entire dashboard working off Flux at the moment.
On Mon, Feb 27, 2023 at 8:31 AM Lev Sterkis @.***> wrote:
if you have a fork/branch of the repo to share, i would love to try it out.
— Reply to this email directly, view it on GitHub https://github.com/jasonacox/Powerwall-Dashboard/issues/148#issuecomment-1446330329, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACEH5HA2RSQPFW3XXPQXADWZSUCZANCNFSM6AAAAAATQKUVFI . You are receiving this because you were mentioned.Message ID: @.***>
Just wondering where this sits? I just had a system finish install today sat my home with split panels so I had to have two gateways and batteries split between my two electrical panels :( Not ideal but wanted to see if this application can help make monitoring easier.
I know there are several in the community who have made this work with quite a bit of customization. Naturally you could se tit up as separate install (someone used separate RPI's) with no change, but that doesn't seem ideal.
If we built multi-PW gateway support, would 2 be enough?
Two gateways is what I have and would seem to be the most common multi-gateway setup for newer homes with split service. I think this is becoming more common in new construction.
How would the TEDAPI setup work? Clearly both gateways can't be on the same 192.168.91.1 address EDIT: Actually it is the same, since they are on their own networks. The only thing that changes is the IP address of the powerwall you use as the bridge.
There are Tesla Solar + Powerwall installations with 400A service connections, where two separate gateways are required. Currently, to get a dashboard, you need to run two instances, representing each gateway. I'm opening this issue to track the addition of support for this setup and the addition of a feature to provide a combined view.
Assumptions:
Originally posted by @jasonacox in https://github.com/jasonacox/Powerwall-Dashboard/discussions/62#discussioncomment-4587716