Tesla Powerwall 2 Integration

OK, GitHub - psmedley/openhab-addons at teslapowerwall should be up to date…

Note - this is as per the last 3.0 binding… no attempts to make it work with the latest firmware…

What do you think, should the four Channel names I* be corrected into “Instantaneous”= Or will that mess up existing installations?

Hey Jared,

Fantastic! Are you able to raise a PR against my repo?

Cheers,

Paul

Just submitted my first github pull request :smiley: - I had to change your POM file to remove the reference to sony in order to get the build to work so you can feel free to disregard that.

Thanks - the reference to sony was a screw up - I’m not great at git :confused: I’ll take a look later today!

edit: funny, I’d forgotten I was already using a token for some functionality :man_facepalming:

Seems to run fine here with firmware 20.40.3 - github is updated with @jfrank1845 's code.

1 Like

By the way - is there a plan to submit this into the distribution? It would be great to have this available out of the box :slight_smile:

1 Like

New build: https://smedley.id.au/tmp/org.openhab.binding.teslapowerwall-3.0.2-SNAPSHOT.jar

I was planning to submit it, but was too slow to get it in for 2.5.x; then got busy - now seems a good time to prep it for submission :slight_smile:

2 Likes

I also need to create a readme.md…

Is there a format that they want for the read me file? I don’t mind helping out :smile: I also submitted a PR to add the grid services active channel - I was inspired by them activating it for me last night with our impending winter storm. This also has me thinking - do we think it would be useful to also add a basic switch type for grid status (ie grid online and synced == On else it’s off? Could then rename the current grid status to grid info to keep that level of granularity. I’m mostly thinking in terms of simple logical rules / analyze options

Hey Jared!

I’ll take a look at your PR ASAP - in terms of a readme - I started updating it at https://github.com/psmedley/openhab-addons/blob/teslapowerwall/bundles/org.openhab.binding.teslapowerwall/README.md

PR’s welcome - I got to the section on documenting the text based configuration and lost interest :slight_smile:

Cheers,

Paul

Great stuff - just downloaded the new build (3.0.2) and its working great. Just so that others are clear, you need to use the installer password rather than your customer Tesla account details - but the username can be anything i think. Easy mistake to make, as i did :slight_smile:

Hey Pete - I’m not using an ‘installer’ password - the installer login actually requires a physical toggle switch to login. you should be able to change your password from the default (serial number) to anything you like. This is independent of your online tesla.com account though - perhaps that is the confusion. This is the one that you would use if you go to the Gateway local website and select customer login

1 Like

Ah yes, your right. I must have the same password for the customer login on my powerwall.

It’s a fair point thought that we need to highlight in the readme that it’s a LOCAL account on the powerwall, not a tesla.com account…

I tried to use the new snapshot 3.0.2 posted above.
My powerwall still is on 20.40.3
This new snapshot requires email and password, without it I cannot create the thing.
Putting the installer mail and password in results in a communication error:
2021-02-17 21:23:18.311 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘teslapowerwall:teslapowerwall:PW’ changed from UNINITIALIZED to INITIALIZING

2021-02-17 21:23:20.518 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'teslapowerwall:teslapowerwall:PW' changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): Tesla Powerwall returned error while invoking https://powerwall/api/login/Basic[210217_PW_error.txt|attachment]

Atttached you find debugging text:
210217_PW_error.txt (7.7 KB)

Doesn’t look like it saved/used the logon:
2021-02-17 21:54:27.560 [DEBUG] [ll.internal.TeslaPowerwallWebTargets] - logonjson = {“username”:“customer”,“password”:“PASSWORD”,“email”:“EMAIL”,“force_sm_off”:false}

Ahh seems it needs to be a customer logon… perhaps we need to support customer & installer logon types…

I didn’t want to supply my credentials in the logfile, so I put EMAIL and PASSWORD in. In the original logfile those appear correctly.
The error occurs with both types Installermail/installerpwd and teslamail/teslapwd.

Well, I could use the older snapshot, but that wouldn’t help to solve this problem generally.

So when you log in locally on your local gateway IP you only select ‘installer’ and provide a username password? For me in the US I have to select ‘customer’ and provide a username and password. If I were to try logging in locally as ‘installer’ it prompts for an email but then when you hit next it requires a flip of the powerwall switch to continue the login process

I also have another idea of channel addition - should we also include the battery frequency as well? I see there are also items like reactive power though i feel the usefulness of those is even less (but then again it is little effort to just include them anyway)

I’ve found battery frequency to be very useful in the sense that you can clearly see when your system is suppressing solar via keeping the frequency up at 65hz (for the us model at least). I was able to see it slowly ease the frequency down to 60hz as battery got down to around 90 percent in island mode and as that target was reached solar flipped back on as expected. I’m not certain if the range of battery percentage the system reserves is always 10% but it was still nice info to have. (I learned a lot in these past few days going through these texas rolling blackouts. Just racked up 51 hours running on backup over the period of Monday through Wednesday.)

I’d push a PR with it all there but alas I accidentally merged my own onkyo customization with the powerwall one by accident and the website is trying to force me into pushing all of those to you in the PR