Copy it into /usr/share/openhab/addons (for OH3) or /usr/share/openhab2/addons (for OH2)
Paul. I’ve got an issue with OH3 and your new binding. The status of the binding is remaining as uninitialized. I can ping the host ‘powerwall’ from the OH3 box (raspi). This was working under OH 2.5 and no other networking changes have been made to these boxes. Is there anything i need to do with the Tesla API authentication?
Sorry guys - it was a Samba share issue - the upgrade to OH3 didn’t change the shares so the .jar file was in the wrong place! #rookie
Thanks.
Whats a bit unclear to me - I’m still using the curl commands + some coding to separate the data w/o the binding. Whats the improvement from using this binding? Is there a documentation avaiblable?
No real advantages - the binding is much easier to setup for a new user than manual rules/text files for curl commands, etc.
1 Like
I’m really glad somebody got this working already, I was planning to try to do it on my own.
But… after initializing I get
Tesla Powerwall returned error while invoking https://192.168.178.80/api/login/Basic
I copied your binding in the post of december 20th to /usr/share/openhab/addons, changed the hosts.conf, a ping powerwall is working.
Creating a powerwall thing with both the IP and powerwall in “Hostname/IP Adress” give the same error message in the browser:
(COMMUNICATION_ERROR): Tesla Powerwall returned error while invoking https://powerwall/api/login/Basic
events.log shows a similar output.
Blockquote
2021-01-24 20:43:57.175 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘teslapowerwall:teslapowerwall:221483abae’ changed from UNINITIALIZED to INITIALIZING
2021-01-24 20:44:28.399 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘teslapowerwall:teslapowerwall:221483abae’ changed from INITIALIZING to OFFLINE
What is missing?
Putting https://IP/api/login/Basic in the browser on the windows machine yields:
{“code”:429,“error”:“Api Limit reached for this endpoint”,“message”:“API Limit Reached”}
https://IP/api/meters/aggregates yields:
Blockquote
{“site”:{“last_communication_time”:“2021-01-24T21:08:42.788858183+01:00”,“instant_power”:295.22999572753906,“instant_reactive_power”:-417.3899917602539,“instant_apparent_power”:511.24862405575976,“frequency”:49.95000076293945,“energy_exported”:9242959.154503893,“energy_imported”:4428325.21617056,“instant_average_voltage”:237.5066680908203,“instant_total_current”:0,“i_a_current”:0,“i_b_current”:0,“i_c_current”:0,“timeout”:1500000000},“battery”:{“last_communication_time”:“2021-01-24T21:08:42.790387843+01:00”,“instant_power”:-10,“instant_reactive_power”:330,“instant_apparent_power”:330.15148038438355,“frequency”:49.985,“energy_exported”:4818880,“energy_imported”:5754140,“instant_average_voltage”:238.10000000000002,“instant_total_current”:-0.2,“i_a_current”:0,“i_b_current”:0,“i_c_current”:0,“timeout”:1500000000},“load”:{“last_communication_time”:“2021-01-24T21:08:42.788858183+01:00”,“instant_power”:301.3757634074399,“instant_reactive_power”:-105.08951748259292,“instant_apparent_power”:319.1726138849343,“frequency”:49.95000076293945,“energy_exported”:0,“energy_imported”:14033475.998055553,“instant_average_voltage”:237.5066680908203,“instant_total_current”:1.2689149564937545,“i_a_current”:0,“i_b_current”:0,“i_c_current”:0,“timeout”:1500000000},“solar”:{“last_communication_time”:“2021-01-24T21:08:42.790852841+01:00”,“instant_power”:5.710000425577164,“instant_reactive_power”:-13.399999678134918,“instant_apparent_power”:14.565853776353356,“frequency”:50,“energy_exported”:19821112.914292533,“energy_imported”:37742.97790364569,“instant_average_voltage”:237.62333170572916,“instant_total_current”:0,“i_a_current”:0,“i_b_current”:0,“i_c_current”:0,“timeout”:1500000000}}
Well, the browser changes
https://IP/api/login/Basic
into
http://tesla.box/api/login/Basic
and this shows the mentioned error:
{“code”:429,“error”:“Api Limit reached for this endpoint”,“message”:“API Limit Reached”}
Today the answer (on https !) is different:
Blockquote
|code|401|
|—|—|
|error|“bad credentials”|
|message|“Login Error”|
which makes sense because I didn’t put my credentials in the browser window.
I tried to import the SSL root certificate as stated above:
sudo keytool -import -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -alias PW2 -import -file mycertfile.pem
Didn’t work.
I found help at https://better-coding.com/how-to-add-ssl-certificate-into-java-cacerts-file-and-jks-keystore/
and used
sudo keytool -importcert -file mycertfile.pem -keystore cacerts -alias “PW”
I had to enter a password manually and got:
#4: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: teg
DNSName: powerwall
DNSName: powerpack
IPAddress: 192.168.90.1
IPAddress: 192.168.90.2
IPAddress: 192.168.91.1
]
What I don’t understand is that im my network 192.168.178.80 is the IP Adress of the powerwall. Could it be that the certificate is only valid if I enter via the WIFI of the powerwall?
Hi Christian,
Note that in OH you need to use powerwall not the IP.
I assume you’ve added powerwall and the correct ip to /etc/hosts (assuming you’re running OH on a linux based system).
Note: with the latest code, you don’t need to manually import the ssl certificate.
Note: https://ip/api/login/Basic gives the code 429 error here too from a browser.
My only other suggestion is to enable debug logging and send me a copy of the openhab.log which might shed some more light.
Cheers,
Paul
Yes, I added “powerwall” and corresponding IP to /etc/hosts, ping to “powerwall” is working on OH on linux:
PING powerwall (192.168.178.80) 56(84) bytes of data.
64 bytes from powerwall (192.168.178.80): icmp_seq=1 ttl=64 time=1.82 ms
, but not on windows where the browser lives to access the webpage because raspi is not configured as nameserver.
I tried with both types of credentials (access to teslamotors.com and the mailadress / Gateway combination to reach the powerwall directly:
events.log with teslamotors credentials:
2021-02-05 15:39:21.326 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘teslapowerwall:teslapowerwall:221483abae’ changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): Tesla Powerwall returned error while invoking https://powerwall/api/login/Basic
events.log with direct credentials:
2021-02-05 16:02:47.372 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘teslapowerwall:teslapowerwall:40cf29644f’ changed from UNINITIALIZED to INITIALIZING
2021-02-05 16:02:49.006 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘teslapowerwall:teslapowerwall:40cf29644f’ changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): Tesla Powerwall returned error while invoking https://powerwall/api/login/Basic
That doesn’t seem enough information for debugging.
I tried:
log:set DEBUG org.openhab.binding.powerwall
in the log console, didn’t change output.
log:set DEBUG org.openhab.binding.teslapowerwall-2.5.0-SNAPSHOT
didn’t change output
log:set DEBUG org.openhab.binding.teslapowerwall
worked … {well, I’m still a beginner}
The log output is not added to events.log, I copied it from the console:
210206_1644_log .txt (45.5 KB)
{I changed the credentials.}
The call to
https://powerwall/api/meters/aggregates
shows output which seems to be OK, even while
Authentication challenge without WWW-Authenticate header
seems to show the problem.
Is there a connection to the recent changes to PW-authentification which is discussed at
https://github.com/enode-engineering/tesla-oauth2
Thank you for looking into this - I get the feeling i’m tip-toeing forward (and sideways) 
Since forums database crashed, I’d like to repeat my findings:
Since SW 20.49.0 I’m faced with the issue not been able to collect data from my PW using curl command, neither through standard terminal or via openhab, even browser using directly the aggregates link
reka@iMac ~ % curl https://192.168.178.152/api/meters/aggregates -k
{"code":403,"error":"Unable to GET to resource","message":"User does not have adequate access rights"}
It seems Tesla is working on some improvements to protect PW2 from hacking.
Was trying to import the SSL certifificate but even there I’m receiving the same feedback.
Mine too just stopped working today - was previously 100% stable in both OH 2.5 and OH 3.0/3.1. My powerwall is also on the 20.49.0 version per my manual login check . I’m not certain of what it was previously but I have a strong feeling they upgraded me and it did this 
…this seems working:
curl -s -k -i -c /tmp/tesla_cookie.txt -X POST -H "Content-Type: application/json" -d '{"username":"customer","password":"mypassword", "email":"xx@xxx.com","force_sm_off":false}' "https://192.168.10.xx/api/login/Basic"
curl -k -b /tmp/tesla_cookie.txt https://192.168.10.xx/api/system_status/soe
curl -k -b /tmp/tesla_cookie.txt https://192.168.10.xx/api/meters/aggregates
…but seems the rules needs to be changed as well??
I’m still on 20.40.3 on both my powerwalls…I’ll investigate once I get upgraded…
2 Likes
Thanks Paul.
@Paul_Smedley - I’m upgraded to 20.49.0 and have the same issue … happy to help with troubleshooting or remote access if you need it. Definitely they’ve added an authentication step as a straight GET to the old API endpoint gives a 403 error. Once I authenticate with the username and password that the installer gave me at the time, then the browser seems to remember it and it’s all fine. The GET within the browser works no problem. Thanks again for all your help on this binding - it’s awesome!
Is this source on github or anywhere so maybe someone with the newer firmware can attempt a test / then you’d be able to test and confirm on the previous version as well for backward compatibility (assuming you don’t get upgraded in the mean time?) I know I’ve seen the python api version seemed to be able to get this updated where all current versions work. Thanks so much for your help with this - I’ve missed having this moving data on my wall displays… I feel like i’m in the dark ages with my 0’s across the board 
Hi @jfrank1845,
I thought I had pushed the code to my github account, but seems it’s only local right now. I’ll aim to resolve that tonight when I get home from work.
I’m fairly time poor right now, but will try have a look over the weekend.
At least we already have fields to capture the username and password - I guess these will need to change from optional to mandatory for 20.49.x firmware. Looks like I need to find an example in the OH codebase where cookies are saved, then it should be pretty trivial. In the first instance, we’ll probably get a new cookie at every refresh of the data - in theory we should only refresh the cookie once the old one has expired - but I think I read that these cookies have a very short effective life anyway.
I’ll update here once the source is on github.
Cheers,
Paul
1 Like
FYI I’m refreshing the cookie once a day and not having any expiry issues - only two days of testing so far thou…
You are truly a lifesaver. I really appreciate your time 