I’m not able to import as it keytool command isn’t been found. Any help?
sudo: keytool: command not found
Regards, René
What linux distro are you running?
I’m using the latest stable openhab2 distribution (2.4.0) for Raspberry Pie
Installed using openhabian? or ? keytool is a part of java, so should be installed when you installed java.
This might help:
correct.
openhabian@openhab:~$ java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (Zulu8.40.0.178-CA-linux_aarch32hf) (build 1.8.0_222-b178)
OpenJDK Client VM (Zulu8.40.0.178-CA-linux_aarch32hf) (build 25.222-b178, mixed mode, Evaluation)
but even executing the two lines from the link without failure message, still shows:
openhabian@openhab:~$ sudo keytool -import -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -alias PW2 -import -file mycertfile.pem
sudo: keytool: command not foundOn my Pi (installing from the openhabian image):
openhabian@openHABianPi:~$ which keytool
/usr/bin/keytool
openhabian@openHABianPi:~$ ls -l /usr/bin/keytool
lrwxrwxrwx 1 root root 25 Oct 17 2018 /usr/bin/keytool -> /etc/alternatives/keytool
openhabian@openHABianPi:~$ ls -l /etc/alternatives/keytool
lrwxrwxrwx 1 root root 46 Oct 17 2018 /etc/alternatives/keytool -> /usr/lib/jvm/zulu-embedded-8armhf/bin/keytool
Perhaps this helps?
ok, small steps achieved:
- keytool is correctly linked
[13:30:19] openhabian@openhab:~$ ls -l /etc/alternatives/keytool
lrwxrwxrwx 1 root root 67 Nov 3 11:12 /etc/alternatives/keytool → /opt/jdk/zulu8.40.0.178-ca-jdk1.8.0_222-linux_aarch32hf/bin/keytool - SSL root certificate downloaded and added (throws an exception as PW2 exist already)
[13:39:37] root@openhab:~# openssl s_client -showcerts -connect 192.168.178.111:443 </dev/null 2>/dev/null|openssl x509 -outform PEM >mycertfile.pem
[13:40:13] root@openhab:~# sudo keytool -import -trustcacerts -keystore /opt/jdk/zulu8.40.0.178-ca-jdk1.8.0_222-linux_aarch32hf/jre/lib/security/cacerts -storepass changeit -alias PW2 -import -file mycertfile.pem
keytool error: java.lang.Exception: Certificate not imported, alias already exists - complete restart
- copied code into a tesla.items, same for tesla.things (w corrected IP) and tesla.rules
- copied code into http.cfg (w correct IP)
- installed the http-binding
… still no data from the PW 
Any idea?
got it… exec binding was missing 
Hi All,
For those that would like to test the powerwall binding vs setting up exec, etc - I’ve updated http://smedley.id.au/tmp/org.openhab.binding.teslapowerwall-2.5.0-SNAPSHOT.jar
This now doesn’t need the ‘keytool’ hack to add the certificate of the PW2. It will automatically ‘trust’ hostname powerwall
This means that this hostname will need to resolve to the IP of your PW2.
The easiest way to do this is to edit /etc/hosts and add:
192.168.1.36 powerwall
where obviously, 192.168.1.36 is the IP of your powerwall.
Feedback appreciated.
Cheers,
Paul
1 Like
Dear Paul,
thank you for this great work! I copied the jar-File into my openhab “addons” folder and restarted the openhab docker container on my Synology NAS.
Then I got the following entries in “openhab.log”:
2019-11-10 13:49:13.776 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.teslapowerwall-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.teslapowerwall [216]
Unresolved requirement: Import-Package: com.google.gson; version="[2.8.0,3.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
I not sure weather this is a bug in the binding or I missed something.
Best regards,
Manfred
Hi @ManfredS sorry - I keep forgetting about the gson requirement. I guess you’re running OH 2.4 still, not one of the 2.5 snapshots?
You can install gson 2.8 by following the instructions at [SOLVED] Manually Upgrade com.google.gson from 2.7.x to 2.8.x in OH 2.4
Or, I can see if I can figure out how to rebuild the binding targeting OH 2.4
Cheers,
Paul.
Hi Paul,
thank you for your helpful answer. I installed OH 2.5 milestone 4 and finally after configuring the binding (providing local credentials) in Paper UI it is working! Now testing can begin 
Cheers,
Manfred
Hi @ManfredS,
That’s great to hear! the local credentials are optional, but required to retrieve the operating mode and current reserve level.
On my todo list is to enable changing the operating mode, and changing the reserve settings. I’ll try get to this soon, and hopefully get the binding in a fit state before the release of 2.5 so it can be included.
Cheers,
Paul.
Hi all,
this binding is working very well for me. No problems at all in the last six days.
The only thing are 16 entries in openhab.log:
[WARN ] [rwall.internal.TeslaPowerwallHandler] - This binding is read only
Thanks a lot, Paul!
Br,
Manfred
Hi @ManfredS,
This should be a debug message, not a warning - sorry about that. I keep meaning to fix it 
Once I add support for changing the operating mode and reserve level, it will go away once and for all - I just need to find time to do that.
I’d like to try and get the binding finalised before the release of 2.5 in mid-December - but not sure that’s going to be possible - perhaps I should clean up the code with the current functionality; and changing mode and reserve can be added down the track?
Cheers,
Paul.
seems with 2.5M6 Powerwall binding is not working any longer.
Any ideas?
2019-12-07 11:35:23.402 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Convert JSON to Item Type Number': The name 'PW_InstPower_Site' cannot be resolved to an item or type; line 8, column 5, length 17
solved with reboot
Hey Paul, first off thanks for working on this! I am a relative noob to openhab and have setup a raspberry pi 3 following the most basic instructions. I then installed your binding and set it up using the IP address for my powerwall2 gateway which is 192.168.1.70 in my case. I get “Status: OFFLINE - COMMUNICATION_ERROR Tesla Powerwall returned error while invoking https://192.168.1.70/api/login/Basic” If I go to this address in chrome it returns “Method Not Allowed” as text. Has something changed? Do you have an updated version of your binding? Appreciate any help otherwise will start from scratch…
Cheers, Shane
Hi Shane,
The binding is working for me. I get the same error if I try and access the URL you gave directly in Chrome.
Have you put valid credentials in for login email and password? Perhaps there’s a glitch if these are left blank? If I get a chance tonight, I’ll do some testing without the login/password and make sure the binding doesn’t report errors with this setup - I probably didn’t test that use case thoroughly.
I also need to find some time to allow changing the operating mode and reserve settings from within the binding.
Cheers,
Paul
@shaneprobinson I confirmed your error occurs if the username/password aren’t passed to the powerwall. I’ll try fix this ASAP so that it doesn’t try that command if the username/password are blank