SamsungAC: ssl handshake error
ronny332 opened this issue · comments
Are there any known issue for the SamsungAC binding for newer models? In our house we have 3 Samsung devices working, 2 devices are from 2013 and the newest one was introduced in late 2014.
Both devices of 2013 are working (Samsung Flagship Jungfrau), but the newest one does not connect. Openhab is reporting
15:18:16.666 [DEBUG] [.b.s.internal.SamsungAcBinding:267 ] - java.lang.Exception: Cannot connect to 10.0.0.125:2878 : javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
A short curl test shows the same result. I can connect to both older devices, but not to the newest one.
A short wireshark debug recording is showing no "big" data frames anymore. Is it possible samsung has left the XML communication between the remote app and the device?
Hi, I have exactly the same problem (2014 device). I described that here:
https://groups.google.com/forum/#!category-topic/openhab/samsung-ac/K4vKqgz4_cE
Would like to know how to fix it; thanks | Piotr
All my research showed: samsung swapped the protocol/the way they are communicating with the ACs. At least the change is visible by using the remote app on iOS. Connecting to an old device from 2013 takes about 1s, to the new device it takes about 5-10s. Wireshark is showing lots and lots of very small requests (no ssl or anything detected) but in a seemingly unknown encoding or binary format.
In my eyes the module of openhab should be marked as "broken" or "outdated" as it is only able to connect to older devices.
Same here. Worked fine until a few days ago. Log shows:
DEBUG o.o.b.s.i.SamsungAcBinding[:267]- java.lang.Exception: Cannot connect to 192.168.1.147:2878 : javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Some more details:
AC's didn't connect to the router anymore. Restored with WPS. They DO show up in the Samsung app on my Android and are controllable by it.
Enabling SSL logging shows:
[Raw read]: length = 5
0000: 15 03 01 00 02 .....
[Raw read]: length = 2
0000: 02 28 .(
Samsung Air Conditioner service, READ: TLSv1 Alert, length = 2
Samsung Air Conditioner service, RECV TLSv1 ALERT: fatal, handshake_failure
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA]
Samsung Air Conditioner service, called closeSocket()
Samsung Air Conditioner service, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Samsung Air Conditioner service, called close()
Samsung Air Conditioner service, called closeInternal(true)
13:05:59.033 DEBUG o.o.b.s.i.SamsungAcBinding[:267] - java.lang.Exception: Cannot connect to 192.168.1.181:2878 : javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
All internet resources point at importing certificates (which did not help) or something to do with JCE. Trying that now.
Hi, sorry for the delayed answer, I've been on vacation.
I've written the Samsung AC binding, but unfortunately I cannot reproduce the issue on my air conditioner.
@RemcoteWinkel have you upgarded the firmware/software of your AC, since it suddenly stopped working?
Also, is it possible to get the IP-address and MAC-address using the old way:
java -cp org.openhab.binding.samsungac-1.7.1.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery
I can update the wiki with a note that it might not work for newer air conditioner, but all information from you guys with this problem could help med to solve this.
Could any of you post the values you received from the Samsung AC when running:
java -cp org.openhab.binding.samsungac-1.7.1.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery
Just to check if you have a different version than I've got:
SERVICE_NAME=ControlServer-MLib
MESSAGE_TYPE=DEVICEDESCRIPTION
HOST=255.255.255.255:1900
NTS=ssdp:alive
CACHE_CONTROL=max-age=60
SPEC_VER=MSpec-1.00
MODELCODE=SAMSUNG_DEVICE
NICKNAME=536D61727420412F432837383235414431323433424129
SERVER=SSDP,SAMSUNG-AC-JUNG_COLD_13K
Hi Stein Torre,
No worries, I hope you had a pleasant holiday. Mine is about to start, so plenty of time to tackle this issue. I have not consciously tampered with the AC units. There has been a router firmware update though (ASUS RT-AC66U). The binding has always performed well until a few weeks ago. AC's are 8 months old.
The output of your question is surprising!
On my production machine: (Using 1.7.0)
domo@a20-olimex:/prod/openHAB/addons$ java -cp org.openhab.binding.samsungac-1.7.0.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery/prod/openHAB/addons$
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:693)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.sendNotify(SsdpDiscovery.java:112)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.discover(SsdpDiscovery.java:59)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.main(SsdpDiscovery.java:46)
Got the following response from Samsung Air Conditioner: {}
domo@a20-olimex:
Trying with 1.7.1 on a test server:
remco@IBM-PC:/testHAB/test/openHAB/addons$ java -cp org.openhab.binding.samsungac-1.7.1.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery/testHAB/test/openHAB/addons$
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:693)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.sendNotify(SsdpDiscovery.java:112)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.discover(SsdpDiscovery.java:59)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.main(SsdpDiscovery.java:46)
Got the following response from Samsung Air Conditioner: {}
remco@IBM-PC:
Hi: the output from my system is similar:
piotr@piotr:~/openhab/addons$ java -cp org.openhab.binding.samsungac-1.7.0.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:697)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.sendNotify(SsdpDiscovery.java:112)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.discover(SsdpDiscovery.java:59)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.main(SsdpDiscovery.java:46)
Got the following response from Samsung Air Conditioner: {}
Best | P
Thanks for the quick response. Could you try this command:
java -cp org.openhab.binding.samsungac-1.7.1.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery -Djava.net.preferIPv4Stack=true
No success:
remco@IBM-PC:/testHAB/test/openHAB/addons$ java -cp org.openhab.binding.samsungac-1.7.1.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery -Djava.net.preferIPv4Stack=true/testHAB/test/openHAB/addons$
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:693)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.sendNotify(SsdpDiscovery.java:112)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.discover(SsdpDiscovery.java:59)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.main(SsdpDiscovery.java:46)
Got the following response from Samsung Air Conditioner: {}
remco@IBM-PC:
Same here with 1.7.0
piotr@piotr:~/openhab/addons$ java -cp org.openhab.binding.samsungac-1.7.0.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery -Djava.net.preferIPv4Stack=true
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:697)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.sendNotify(SsdpDiscovery.java:112)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.discover(SsdpDiscovery.java:59)
at org.binding.openhab.samsungac.communicator.SsdpDiscovery.main(SsdpDiscovery.java:46)
Got the following response from Samsung Air Conditioner: {}
Here is a wireshark dump.
The dump was created with a macbook air (as hotspot) connected by wifi with the Samsung AC, an usb ethernet nic was used as internet bridge.
My iPhone was connected to the MBA hotspot by wifi, too. The was the solution to record all the traffic between the Samsung App and the AC device.
192.168.2.1 is the MBA
192.168.2.2 is the iPhone 6
192.168.2.3 is the Sammy AC
Just to confirm, the Samsung ' Smart Air Conditioner' app for Android and the site www.samsungsmartappliance.com still function with the airconditioner units. I suspect a different communications method.
I also found Firefox having a difficulty with the AC's. When using https://192.168.1.181:2878/ I get:
192.168.1.181:2878 uses an invalid security certificate. The certificate is only valid for the following names: samsung.com, localhost The certificate will not be valid until 01.01.1960 01:00. The current time is 04.08.2015 22:29. (Error code: ssl_error_bad_cert_domain)
Update: Steintore is investigation the problem. I have provided resources for testing. Hang in there all, we are making progress, albeit with small steps.
Meanwhile I have asked Samsung if they did anything as the binding worked splendidly until a few weeks ago. Awaiting an answer.
@ronny332 Could you download the SsdpDiscovery.class file from here:
SsdpDiscovery.class
Try and check if this discovery version works for you. Run it like this:
java -classpath . SsdpDiscovery
Let me know your findings. Thanks
Thanks. I am getting this:
piotr@piotr:~/openhab/addons$ java -classpath . SsdpDiscovery
Exception in thread "main" java.lang.UnsupportedClassVersionError: SsdpDiscovery : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
Update: Steintore found out there is something wrong with the certificates. When issueing openssl s_client -connect <ip-address>:2878 -msg -tls1 -ssl3 -debug -showcerts it ends with "Verify return code: 19 (self signed certificate in certificate chain)"
Samsung confirmed to me that they did a unattended and automatic firmware update on July 27th. I have now asked them to look into this issue.
For what it's worth, I have a Samsung Triangle unit, and I am looking at a similar issue:
C:\Users\mvander2\Downloads\distribution-1.7.1-addons>java -cp org.openhab.binding.samsungac-1.7.1.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery
Got the following response from Samsung Air Conditioner: {}
@marnikvde If you cannot discover the unit(s), I've created a new test-version of the binding where I've improved the discovery of the units, please find it here: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!category-topic/openhab/samsung-ac/2BZjRB8aSUo
That looks better:
C:\Users\mvander2\Downloads>java -cp org.openhab.binding.samsungac_1.7.0.SNAPSHOT.jar org.binding.openhab.samsungac.communicator.SsdpDiscovery
Sending multibroadcast to all possible network interfaces...
Broadcasting to /255.255.255.255
Retrieving response..........
Response retrieved: {}
Broadcasting to /192.168.0.255
Retrieving response............
Response retrieved: {192.168.0.170={LOCATION=http://192.168.0.170, SERVICE_NAME=ControlServer-MLib, IP=192.168.0.170, MESSAGE_TYPE=DEVICEDESCRIPTION, FIRMCODE=01538A150527, HOST=25
5.255.255.255:1900, NTS=ssdp:alive, CACHE_CONTROL=max-age=60, NODE_ADDRESS=BC8CCD5F0E6C0000, SPEC_VER=MSpec-2.00, MODELCODE=SAMSUNG_DEVICE, NICKNAME=616972636F206C6F7561, SERVER=SS
DP,SAMSUNG-AC-RAC_2013, MAC_ADDR=BC8CCD5F0E6C, ROOT_ADDRESS=BC8CCD5F0E6C0000, GROUP_ADDRESS=BC8CCD5F0E6CFFFF}}
Broadcasting to /192.168.56.255
Retrieving response..........
Response retrieved: {}
Got response from possible air conditioner(s):
{LOCATION=http://192.168.0.170, SERVICE_NAME=ControlServer-MLib, IP=192.168.0.170, MESSAGE_TYPE=DEVICEDESCRIPTION, FIRMCODE=01538A150527, HOST=255.255.255.255:1900, NTS=ssdp:alive,
CACHE_CONTROL=max-age=60, NODE_ADDRESS=BC8CCD5F0E6C0000, SPEC_VER=MSpec-2.00, MODELCODE=SAMSUNG_DEVICE, NICKNAME=616972636F206C6F7561, SERVER=SSDP,SAMSUNG-AC-RAC_2013, MAC_ADDR=BC
8CCD5F0E6C, ROOT_ADDRESS=BC8CCD5F0E6C0000, GROUP_ADDRESS=BC8CCD5F0E6CFFFF}
@steintore
sorry for the late reply, we're are still on summer holidays. SSDP was working, even with a different library written in perl. The reply from the conditioner is a bit different from my older devices but usable.
Everything else after this device lookup seems to be different from older conditioners.
Hello,
i wrote also in google groups. i'm sorry but i don't know where i have to write.
Anyway, i try to gain the token using another way.
i root my nexus tablet and then i go find information in the app folder and i found this:
#?xml version='1.0' encoding='utf-8' standalone='yes' ?#
#map#
#string name="Token-MACADDRESS"#U2FsdGVkX1/V5pno6jBmmEP0TUFQUrhMkX3IQTdn0jhBXK9rLJOeK1BdfO+2J7P9uqXNgp+fn2U=#/string#
#/map#
-> i delete my mac-address; change > and < with #
Then i try with my second AC unit and on the same file there is a new token. So could be the right way.
I try using this token: U2FsdGVkX1/V5pno6jBmmEP0TUFQUrhMkX3IQTdn0jhBXK9rLJOeK1BdfO+2J7P9uqXNgp+fn2U
[samsungac:Cucina.host=IP_ADDRESS
samsungac:Cucina.mac=MAC_ADDRESS
samsungac:cucina.token=U2FsdGVkX1/V5pno6jBmmEP0TUFQUrhMkX3IQTdn0jhBXK9rLJOeK1BdfO+2J7P9uqXNgp+fn2U]
but i got this error:
00:20:55.804 [INFO ] [.b.s.internal.SamsungAcBinding:261 ] - Broken connection found for 'Cucina', attempting to reconnect...
00:20:58.175 [DEBUG] [.b.s.internal.SamsungAcBinding:267 ] - java.lang.Exception: Cannot connect to 10.1.1.246:2878 : javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
00:20:58.180 [INFO ] [.b.s.internal.SamsungAcBinding:268 ] - Reconnect failed for 'Cucina', will retry in 60s
Thanks for your help.
I still think the reason for this is a change in Samsung firmware. This is distributed through the internet so hard to avoid unless you create a separate wifi network for the AC's with no internet connection.
I have contacted my local Samsung dealer and they relayed the issue to Samsung software development department. I hope they will fix it. If not, we will have to find a work around. So far no luck.
I also experienced drop of wifi connection. This is actually a feature of the system. It enters a deep standby when the ac is not working. And thus causing the wifi connection to drop. Amazingly this is default on a system that is supposed to be able to be switched on through the internet. It can be overridden by some settings on the outdoor unit. My mechanic will soon drop by to make the changes.
Hi,
today i try with a port scanner (only 2878 is open). I also create a direct connection to sniff packet (i have it if someone can use it).
If i'll be able to fix the AC, i'll block internet connection with the firewall.
it's absurd what happened.
Think I have spent all that money just for home automation (real consumption are different from those declared) it makes me very angry.....
thanks
You could try and ask for a downgrade of the software and then block internet access. Meanwhile we will have to wait for Samsung or a fix from Stein Tore.
It would help a lot if you (and others here) contact your local Samsung dealership (addresses are in the service manual). The more complaints from customers the more serious Samsung will take this.
Your findings from the rooted tablet steem from after a secure connection has been made. The AC's issue a token to establish your identity as owner because in the authentication process you have the press a button on the physical unit. (If you can touch it you own it). I noticed as well that my Android phone is perfectly capable of communicating over what seems a SSL connection. There might be a clue in there. I already sent Stein Tore (author of the binding) my sniffer files. If possible, upload yours as well.
I'm no expert on this, but from the first to the last communication, the app that i use to sniff packet, didn't report ssl connection (for example, for email and gapp report an ssl connection).
@MrMerlino Can you please attach output from the communcation? What do you use to sniff packets?
Please attach in one of the threads in the google groups discussion forum, and I'll have a look.
Hello,
do u have some news about it?
thanks in advance!
Hi,
Samsung offered to restore software on my units. If this proofs succesfull you can ask for it too. I will keep you posted.
Verzonden vanaf mijn Samsung Galaxy smartphone.
-------- Oorspronkelijk bericht --------
Van: MrMerlino notifications@github.com
Datum:2015-10-06 17:59 (GMT+01:00)
Aan: openhab/openhab openhab@noreply.github.com
Cc: RemcoteWinkel remcotewinkel@hotmail.com
Onderwerp: Re: [openhab] SamsungAC: ssl handshake error (#2863)
Hello,
do u have some news about it?
thanks in advance!
Reply to this email directly or view it on GitHub:
#2863 (comment)
thanks for reporting your experience!
keep us updated! Could be a good solution!
Upp!
News?
There is a way to help u?
thanks :)
No luck. Appointment to install was not met. Now back to seller.
MrMerlino notifications@github.comschreef:
Upp!
News?
Reply to this email directly or view it on GitHub:
#2863 (comment)
Good morning,
i buy a serial rs584 interface to check is if possibile to do something.
Have a nice day
I received the rs485 interface but today it's raining so i'll try tomorrow.
Hi,
I had an extensive discussion with Samsung. Their policy is that access from third parties (like openHAB) is a security threat. That is why they updated their software. They do not support anything else then their own app. They will however look into the handshake error and possibly fix it in time.
Uppp!
do you think there is the possibility to fix this problem?
Hello!
Don't know if can be useful anyway i try extract data from my tablet.
On the app there is:
libopenssl2 library
rootcert.pem
rootkey.pem
cert.rsa and cert.sf file
Not sure but the app lookslike just a webapp.
Thanks in advance
Could be interesting, if the tablet is able to access the AC through SSL. I am still trying to convince Samsung to fix the problem.Their last remark on this issue is "We will improve the function and quality of our procudt step by step based on your opinion.". Once again it will help if others complain as well. For instance by mailing the company that is in your service manual. It is not appropriate for me to disclose the email address of the Samsung Support Representative in Korea here, but through your local service organization you might be able to reach them. Stating a SSL problem after the July update will certainly ring a bell in Korea.
The connection is a normal encrypted connection;
lookslike that works like this:
AC send request to tablet
tablet answer with a certificate (AC14K_M-KeyStore.bks).
The file is a bouncy castle -> https://en.wikipedia.org/wiki/Bouncy_Castle_(cryptography)
Is it possible to extract the AC14K_M-KeyStore.bks-file? In that case we might be able to use it to avoid the handshake exception.
I did already. It is in the .apk file of the app, downloadable from the Samsung site. It is also possible to extract the certificates. I will drop you an email.
Perfect :)
any updates?
No. Samsung continues to use a self signed certificate which is against industry best practices. Please contact you local representative about this. The more we consumers complain the more likely Samsung takes this seriously
I also don't understand why Samsung is adopting this practice! and they don't even make it available on their own Smartthings platform, which is ridiculous.
btw, i've noticed that there are some AC units that have different wifi ap settings.
look: https://itunes.apple.com/en/app/smart-home/id885787515?mt=8
when i install the app and choose to add a AC wall unit. it gives a different SSID!
it would be great to try to create a virtual wifi network with the same mac address as one samsung unit and with the same SSID and capture the traffic to see what happens
Splendid!
I did " openssl pkcs12 -in ack14k_m.pfx -out cert.pem -nodes" hit enter on password and then used the output file like:
openssl s_client -connect 192.168.1.147:2878 -cert cert.pem
I think I actually see my ac talking:
I will try to add the certificate to my standard ca-certs later today. Will let you know the outcome.
Excellent!
At least we got an update :)
Works also for me!
DPLUG-1.6
#?xml version="1.0" encoding="utf-8" ?>#Update Type="InvalidateAccount"/>
Great news!
I do think I'll have to do some alteration of the binding before this actually work, but @RemcoteWinkel let me know your results.
I can make a small java-application to check how to implement it before I actually change the binding.
@steintore
The Answer "InvalidateAccount" means that you are not logged right?
I extract the token from the xml (the same process with which I have got the bks certificate).
This should means that the connection works correctly, right?
How i can try to make communication with the AC?
Thanks in advance :)
The procedure is that you'll get the InvalidAccount something. The you can respond with
<Request Type="GetToken" />
And you should receive a token.
If you get this far, then it the communication should be okay. You can try to get the state of everything by sending this command (after getting the token):
<Request Type="DeviceState" DUID="{{MAC}}"></Request>
(Replace {{MAC}} with the AC mac address
With GetToken, turn AC on i receive the right token, but then with the DeviceState command i didn't receive answer
I'll try again :)
Ok was my fault :)
Now works!
After few seconds i receive this:
<?xml version="1.0" encoding="utf-8" ?><Update Type="Status"><Status DUID="MACADDRESS" GroupID="AC" ModelID="AC"><Attr ID="AC_FUN_TEMPNOW" Value="19" /></Status></Update>
Ok :)
I'm so sorry but i'm really noob about this :D
The right command was:
<Request DUID="MACADDRESS" Type="DeviceState" />
And the AC Answer correclty 💃
Thanks to all man!
We fixed the problem :)
what a beautiful day!!!!!!!
next stop: block with iptables all communication of the AC with the samsung server....don't wont a new firmware update of our AC :)
Really thanks to all :)
@luca-saggese
@RemcoteWinkel
@steintore
MrMerlino,
could you track the connections the ac is doing to samsung?
i'm really worried of blocking any update to my system.
I have the current open connection, I guess this is for the service (control with phone)
tcp 192.168.1.147:54596 112.106.186.251:80
Yes for sure....
I'll try to understand! But i'll come back at home on the last days of february!
i've blocked all outgoing connection, the nice fact is that the ac sense it and sends a status update with AC_SG_INTERNET: Disconnected
voilà!
So we wait for the new binding :)
thanks to all :)
great news! i was starting to look for alternatives, like grab some kind of IR relay controllers, like the broadlink or the harmony
I have been creatively busy with the ac. I guessed that If I can use openssl to get XML, I can just as well get that into openhab. So here is a temporary failover to read (write I will do next) the airco information. You can use it until @steintore figures the java part out. I have only implemented power status, set temp status and current status but the example speaks for itself. You will also need to install some utilities like 'expect', and the exec binding. Here we go:
Create the certificate:
openssl pkcs12 -in ack14k_m.pfx -out cert.pem -nodes
Hit enter for password.
First a script to extract the data from the ac into an XML file, remember to put the cert.pem file you created in the same directory. It is also the directory for the output files. In my case /home/domo/ac
File:remco.exp
#!/usr/bin/expect
set timeout 30
spawn openssl s_client -connect 192.168.1.181:2878 -cert /home/domo/ac/cert.pem -quiet
expect {<?xml version="1.0" encoding="utf-8" ?><Update Type="InvalidateAccount"/>}
send {<Request Type="Authtoken"><User Token="xxxxxx-xxx" /></Request>}
send "\r"
expect "Okay"
send {<Request Type="DeviceState" DUID="BC8CCD54xxxx"></Request>}
send "\r"
expect "</Device></DeviceState></Response>"
exit
Replace token en mac with appropriate values.
Make the script executable
chmod +x remco.exp
This will give you an XML file. So if we run this script from another script, we can store the xml, extract the values and inject them into openhab like this:
file:updateacremco.sh
/home/domo/ac/remco.exp >/home/domo/ac/remco.out
cat /home/domo/ac/remco.out | grep "DeviceState></Response>" > /home/domo/ac/remco.xml
cat /home/domo/ac/remco.xml | awk -F"\"" '{print $26}' | xargs curl --silent -H "Content-Type: text/plain" http://localhost:8080/rest/items/r_ac_p_t -d $1
cat /home/domo/ac/remco.xml | awk -F"\"" '{print $38}'| xargs curl --silent -H "Content-Type: text/plain" http://localhost:8080/rest/items/r_ac_st_t -d $1
cat /home/domo/ac/remco.xml | awk -F"\"" '{print $56}' | xargs curl --silent -H "Content-Type: text/plain" http://localhost:8080/rest/items/r_ac_ct_t -d $1
Make this executable as well.
chmod +x updateacremco.sh
So now to use this in openhab I have the following items:
String r_ac_ct_t "Current temp [%s]"
String r_ac_p_t " Power [%s]"
String r_ac_st_t "Set temp [%s]"
To get this update automatically I have a special switch. Every time this is set On or Off it puts things in motion:
Switch Aircoscript_r "Update" (Heatmiser, gDivers) { exec="OFF:sh /home/domo/ac/updateacremco.sh, ON:sh /home/domo/ac/updateacremco.sh"}
Set the file paths to match your own configuration. Lastly a rule is responsible for turning the switch on and off every couple of minutes:
rule "Every couple of minutes"
when
Time cron "0 0/10 * * * ?"
then
if(AiroScript_r.state==ON) {
sendCommand(Aircoscript_r, "OFF")
}
else {
sendCommand(Aircoscript_r, "ON")
}
end
And yes, it is a long way around the issue, but at least I got my ac back in openhab. So for the time being a good workaround.
The following script can be called with parameters to control the ac, like for setting the temperature:
./setac.exp AC_FUN_TEMPSET 22
File:setac.exp
#!/usr/bin/expect
set timeout 300
set arg1 [lindex $argv 0]
set arg2 [lindex $argv 1]
spawn openssl s_client -connect 192.168.1.181:2878 -cert /home/domo/ac/cert.pem -quiet
expect {<?xml version="1.0" encoding="utf-8" ?><Update Type="InvalidateAccount"/>}
send {<Request Type="Authtoken"><User Token="xxx" /></Request>}
send "\r"
expect "Okay"
send {<Request Type="DeviceControl"><Control CommandID="cmd1" DUID="BC8CCD5xxxx"><Attr ID="}
send $arg1
send {" Value="}
send $arg2
send {" /></Control></Request>}
send "\r"
expect "</Status></Update>"
exit
Set token en MAC to suit your situation. I will supply you with an openHAB implementation soon.
@brunofosi I purchased a Harmony as well but found out the Samsung AC IR codes are a bit to complicated for it. But we are making progress!
Hello,
maybe now we should just wait for the new binding.
The structure dialog looks like the same of the old firmware so shouldn't be impossible the adaptation with the new openssl certificate.
I'm really sorry but I don't know how to start for help now. Anyway if you need me i'm available!
Hi!
Of course we are all waiting for a new binding. Those interested can use my scripts in the meanwhile.
I just wanted to confirm that I've been able to send commands to my new Samsung unit thanks to the hints provided in this thread. Other than the certificate trick, the commands seem the same as in the old units.
(Actually, I just wanted to write a couple of scripts for my own use, but I might end up using openhab if it suits my needs. The only thing that worries me is that maybe it's not the best idea to place the Samsung certificate and private key in the openhab repository, but they are required for it to work...)
Can someone explain how to get from AC14K_M-KeyStore.bks to ack14k_m.pfx ?
Good news! Today I've done some testing together with @RemcoteWinkel and we have found a solution to the problem. I'll try to assemble a test-version of the binding over the next couple of days.
I'll let you know how the status sometime tomorrow.
Luckily there are not many changes to the binding and the communcation, as it seems to work precisely as before.
@luca-saggese Where did you find the ac14k_m.pfx-file? I need to put a link to the file so that people with this issue can download and use it, as I do not want to include it in the actual bindin itself.
@luca-saggese Where did you find the ac14k_m.pfx-file? I need to put a link to the file so that people with this issue can download and use it, as I do not want to include it in the actual bindin itself.
I think is the best way....
pfx file should be created with keytool function from the bks file stored on the apk app.
but i didn't understand how to convert....
I've found it online, cannot rember where, i found it several weeks ago but was'nt able to use it until last week
Il giorno 15/feb/2016, alle ore 22:27, MrMerlino notifications@github.com ha scritto:
@luca-saggese Where did you find the ac14k_m.pfx-file? I need to put a link to the file so that people with this issue can download and use it, as I do not want to include it in the actual bindin itself.
I think is the best way....
pfx file should be created with keytool function from the bks file stored on the apk app.
but i didn't understand how to convert....—
Reply to this email directly or view it on GitHub.
Well, it must be contained in the .apk or derived from it as my phone is able to connect with the "in home" function.
These are the complete steps I took yesterday, in case anyone wants to reproduce them it should be fairly easy:
- I used Apktool (https://ibotpeaches.github.io/Apktool/) to disassemble the Smart Air apk (java -jar apktool_2.0.3.jar d com.samsung.rac-1.2.78.apk). I suppose any other disassembling tool for Android would work.
- From the extracted directory I took the file assets/AC14K_M_KeyStore.bks, which is the keystore in BouncyCastle format containing the certificate and the private key. I also searched for references to that file in the disassembled code in order to find the password to access the private key, and fortunately this was quite easy: it's only referenced in smali/com/samsung/rac/framework/service/SSLSocketFactoryHelper.smali, and the string containing the password is totally evident ;)
- I then installed a BouncyCastle provider (https://www.bouncycastle.org/latest_releases.html) . Take into account that it has to be installed in lib/ext in your Java runtime installation, as keytool doesn't take into account the CLASSPATH env
- I converted the bks keystore to a pkcs12 keystore with this command:
keytool -importkeystore -srckeystore AC14K_M_KeyStore.bks -srcstoretype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -srcstorepass '<the_password_in_the_code>' -destkeystore ac14k_m.p12 -deststoretype PKCS12 -deststorepass 123456 -destkeypass 123456 -alias ac14k_m
- I finally created a .pem certificate+key from the .p12 certificate with the usual openssl command:
openssl pkcs12 -in ac14k_m.p12 -passin pass:123456 -out ac14k_m.pem -passout pass: -nodes
I hope it helps... I didn't want to put the password or the pem certificate here as I'm not sure about the legal implications. But it should be easy for anyone to obtain it ;)
In case anyone needs more help or information, please drop me an email
And for those not wanting to go through the full extract process (which is a bit tedious), I think it won't harm placing here a link to the certificate in base64 format: http://pastebin.com/MKTbFnK5
Just run "base64 -d < pasted.txt > cert.pem" and you are done ;)
A small update. I am beta testing a new binding from @steintore. Looks very promising, some minor issues left.
If u need i can test too!
Here's a test-version of the new binding, there are a couple of things to notice:
There are two new optional configuration parameter, these are certificate and password, use them as this:
samsungac:Livingroom.certificate=cacert.pem
samsungac:Livingroom.password=something
If you use the .pem-file described in this thread you do not need to set the password, it is just there in case we need it later (when they change the certificate again)
The certificate-parameter is the full path to the certificate-file, it should work with both the .pem-file and the .pfx-file. I do not think the .bks-file will work.
If you test it, please check the cpu and the resource use, this needs to be checked on machines that do not have a lot of extra power. This is due to me having to include two external java-libraries to handle the certificates.
If I do not get any complaints or things to fix by friday, I'll post a pull request for this. (I'll then remove the download link as well)
Thanks for testing.
download the test-binding here:
http://bit.ly/20Dabae
For me doesn't works
i'm using openhab version 1.7.1 under windows.
This is my openhab configuration file:
samsungac:Livingroom.host=10.1.1.246
samsungac:Livingroom.mac=EDITED
samsungac:Livingroom.token=d76b7f82-3d31-4635-89a6-2b0ad192866d
samsungac:Livingroom.certificate=C:\Users\Administrator\Desktop\openhab\addons\cert.pem
#samsungac:Livingroom.password=
Items file:
Number ac_current_temp "Current temp [%.1f]" (AC) {samsungac="[Livingroom|AC_FUN_TEMPNOW]"}
Switch ac_power (AC) {samsungac="[Livingroom|AC_FUN_POWER]"}
Number ac_mode "Convenience mode" (AC) {samsungac="[Livingroom|AC_FUN_COMODE]"}
Number ac_op_mode "Operation mode" (AC) {samsungac="[Livingroom|AC_FUN_OPMODE]"}
Number ac_set_temp "Set temp [%.1f]" (AC) {samsungac="[Livingroom|AC_FUN_TEMPSET]"}
Sitemaps:
Frame label="Aria Condizionata" {
Text item=ac_current_temp icon="temperature" label="Temperatura [%.1f °C]"
Setpoint item=ac_set_temp minValue=16 maxValue=28 step=1 icon="temperature"
Switch item=ac_power icon="heating"
}
On debug i just have few messages:
[DEBUG] [.s.internal.SamsungAcActivator:33 ] - Samsung AC binding has been started.
[DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'ac_current_temp (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
[DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'ac_power (Type=SwitchItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
[DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'ac_mode (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
[DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'ac_op_mode (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
[DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'ac_set_temp (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
[DEBUG] [.b.s.internal.SamsungAcBinding:59 ] - Started Samsung AC Binding
[INFO ] [.b.s.internal.SamsungAcBinding:202 ] - No refresh interval configured, using default: 60000 ms
[DEBUG] [.b.s.internal.SamsungAcBinding:208 ] - Configuration key is: camera.certificate
I try also with a clean installation of the last version 1.8.1 with only samsung binding
i try also with pfx file
@MrMerlino This line is strange:
[DEBUG] [.b.s.internal.SamsungAcBinding:208 ] - Configuration key is: camera.certificate
Why does it say "camera.certificate" in the log. Something wrong in the configuration file?
Yes...i try also adding "..."
Like this:
samsungac:Livingroom.certificate="C:\Users\Administrator\Desktop\openhab\addons\cert.pem"
But is the same....don't know how to fix!
If the cert.pem-file is in the same folder as the addon, you could try to write:
samsungac:Livingroom.certificate=cert.pem
are you not getting anything else in the logs? Should print for the other configurations as well..
This is my configuration;
i try also with cert.pem without path!
samsungac:Livingroom.host=10.1.1.246
samsungac:Livingroom.mac=EDITED (right macaddress in configuration, with openssl works correctly)
samsungac:Livingroom.token=d76b7f82-3d31-4635-89a6-2b0ad192866d
samsungac:Livingroom.certificate=cert.pem
#samsungac:Livingroom.password=
Ok, try running in debug-mode to se if there's some more details in the log.
Another thing you can try is to adjust logging of the binding
<logger name="org.openhab.binding.samsungac" level="DEBUG" />
I'm so sorry because probably i'm making a big error but i didn't understand where....
I'm already trying to debugging and yet modified the log file (logback_debug.xml) adding level ="debug" as u suggested!
Thanks for spending your time...
@RemcoteWinkel
Can u post your configuration and debug output pls?
I try also redownloadwing jar and also in another computer :(
Sure @MrMerlino, glad to help.
Configuration:
# Host and port of the first AC to control
samsungac:Remco.host=192.168.1.181
samsungac:Remco.mac=BC8CCD54xxxx
samsungac:Remco.token=2613a007-f322-4093-a05f-49386c403177
samsungac:Remco.certificate=/home/remco/testac/ac14k_m.pfx
(Note: Linux use "/" in the path, Windows "")
Use start_debug.bat to get extra debug information in the log.
Log (relevant parts)
20:18:08.826 DEBUG o.o.b.s.i.SamsungAcActivator[:33]- Samsung AC binding has been started.
20:18:10.493 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_ac_ct (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.499 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_ac_p (Type=SwitchItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.501 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_ac_m (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.505 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_ac_om (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.507 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_ac_st (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.510 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_ac_d (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.519 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_ac_w (Type=NumberItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.521 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_ac_error (Type=StringItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.524 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_add_spi (Type=SwitchItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.530 DEBUG o.o.m.i.i.GenericItemProvider[:341]- Start processing binding configuration of Item 'r_add_ac (Type=SwitchItem, State=Uninitialized)' with 'SamsungAcGenericBindingProvider' reader.
20:18:10.642 DEBUG o.o.b.s.i.SamsungAcBinding[:59]- Started Samsung AC Binding
20:18:10.656 INFO o.o.b.s.i.SamsungAcBinding[:202]- No refresh interval configured, using default: 60000 ms
20:18:10.674 DEBUG o.o.b.s.i.SamsungAcBinding[:208]- Configuration key is: Remco.certificate
20:18:10.676 DEBUG o.o.b.s.i.SamsungAcBinding[:208]- Configuration key is: Remco.host
20:18:10.677 DEBUG o.o.b.s.i.SamsungAcBinding[:208]- Configuration key is: Remco.mac
20:18:10.679 DEBUG o.o.b.s.i.SamsungAcBinding[:208]- Configuration key is: Remco.token
20:18:10.681 DEBUG o.o.b.s.i.SamsungAcBinding[:208]- Configuration key is: service.pid
20:18:10.691 INFO o.o.c.s.AbstractActiveService[:169]- Samsung Air Conditioner service has been started
20:18:19.055 DEBUG o.o.b.s.i.SamsungAcBinding[:286]- Broken connection found for 'Remco', attempting to reconnect...
20:18:20.215 INFO o.b.o.s.c.AirConditioner[:130]- Token has been acquired: 2613a007-f322-4093-a05f-49386c403177
20:18:24.329 DEBUG o.o.b.s.i.SamsungAcBinding[:289]- Connection to Samsung AC: [192.168.1.181:2878, MAC: BC8CCD54FE41, TOKEN: 2613a007-f322-4093-a05f-49386c403177] has succeeded
20:20:38.121 DEBUG o.o.b.s.i.SamsungAcBinding[:303]- Getting status for ac: 'Remco'
20:20:40.183 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_SG_MACLOW
20:20:40.184 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_OPTIONCODE
20:20:40.185 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_POWER
20:20:40.186 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_ac_p gets updated to: OFF
20:20:40.188 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_OUT_VERSION
20:20:40.189 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_SG_INTERNET
20:20:40.190 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_SG_MACMID
20:20:40.192 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_SG_VENDER03
20:20:40.193 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_SG_VENDER01
20:20:40.194 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD_SETKWH
20:20:40.195 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD_STARTWPS
20:20:40.196 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_SG_VENDER02
20:20:40.198 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_DIRECTION
20:20:40.199 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_ac_d gets updated to: 3
20:20:40.201 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_CLEAR_POWERTIME
20:20:40.203 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_USEDPOWER
20:20:40.204 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_MODEL
20:20:40.205 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD_AUTOCLEAN
20:20:40.206 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_add_ac gets updated to: OFF
20:20:40.207 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_FILTER_USE_TIME
20:20:40.209 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_ENABLE
20:20:40.210 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_OPMODE
20:20:40.212 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_ac_om gets updated to: 3
20:20:40.215 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_USEDTIME
20:20:40.217 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_OUTDOOR_TEMP
20:20:40.218 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_WINDLEVEL
20:20:40.219 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_ac_w gets updated to: 1
20:20:40.220 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_TEMPNOW
20:20:40.222 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_ac_ct gets updated to: 18
20:20:40.223 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD_CLEAR_FILTER_ALARM
20:20:40.225 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_ERROR
20:20:40.226 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_ac_error gets updated to: NULL
20:20:40.228 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_COOL_CAPABILITY
20:20:40.229 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD_SPI
20:20:40.230 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_add_spi gets updated to: OFF
20:20:40.231 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_SG_WIFI
20:20:40.233 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_USEDWATT
20:20:40.235 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD_APMODE_END
20:20:40.237 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_SLEEP
20:20:40.240 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_COMODE
20:20:40.243 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_ac_m gets updated to: 0
20:20:40.250 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_FILTERTIME
20:20:40.252 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_PANEL_VERSION
20:20:40.254 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_WARM_CAPABILITY
20:20:40.257 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_FUN_TEMPSET
20:20:40.259 DEBUG o.o.b.s.i.SamsungAcBinding[:352]- r_ac_st gets updated to: 24
20:20:40.262 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_ADD2_VERSION
20:20:40.268 DEBUG o.o.b.s.i.SamsungAcBinding[:311]- Trying to find item for: Remco and cmd: AC_SG_MACHIGH
Stop working here probably:
DEBUG o.o.b.s.i.SamsungAcBinding[:208]- Configuration key is: Remco.certificate
Could be a Windows problem?
Let me dust off my Windows machine and try,
I'm so sorry for that but i really don't know what doesn't works!
Thanks again to all!
Got an error too on my Windows machine. @steintore what can you make of it?
20:51:44.358 DEBUG o.o.b.s.i.SamsungAcBinding[:286]- Broken connection found for 'Remco', attempting to reconnect...
20:51:44.873 DEBUG o.o.b.s.i.SamsungAcBinding[:294]- java.lang.Exception: Could not connect using certificate: D:\testAC\ac14k_m.pfx : javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
What's your logback_debug.xml configuration?
i add this:
but i don't have this debug info!
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} %-5level %logger{30}[:%line] - %msg%n%ex{10}</pattern>
</encoder>
</appender>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>${openhab.logdir:-logs}/openhab.log</file>
<encoder>
<pattern>%d{HH:mm:ss.SSS} %-5level %logger{30}[:%line]- %msg%n%ex</pattern>
</encoder>
</appender>
<appender name="EVENTFILE"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${openhab.logdir:-logs}/events.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- weekly rollover and archiving -->
<fileNamePattern>events-%d{yyyy-ww}.log.zip</fileNamePattern>
<!-- keep 30 days' worth of history -->
<maxHistory>30</maxHistory>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss} - %msg%n</pattern>
</encoder>
</appender>
<logger name="runtime.busevents" level="INFO" additivity="false">
<appender-ref ref="EVENTFILE" />
<appender-ref ref="STDOUT" />
</logger>
<logger name="org.openhab" level="DEBUG" />
<logger name="org.openhab.binding.knx" level="DEBUG" />
<logger name="org.openhab.binding.onewire" level="INFO" />
<logger name="org.openhab.ui" level="INFO" />
<logger name="org.openhab.ui.webapp" level="DEBUG" />
<logger name="org.openhab.ui.webapp.internal.servlet" level="INFO" />
<logger name="org.openhab.io.net" level="INFO" />
<logger name="org.openhab.core.autoupdate" level="DEBUG" />
<logger name="org.openhab.core.persistence.internal" level="TRACE" />
<logger name="org.openhab.core.transform.internal.service.MapTransformationService" level="INFO" />
<logger name="org.openhab.binding.vdr" level="DEBUG" />
<logger name="org.openhab.model.core.internal.folder" level="INFO" />
<logger name="org.openhab.io.dropbox" level="DEBUG" />
<logger name="OSGi" level="WARN" />
<logger name="org.eclipse.jetty" level="WARN" />
<logger name="org.drools.SystemEventListener" level="INFO" />
<root level="INFO">
<appender-ref ref="FILE" />
<appender-ref ref="STDOUT" />
</root>
<logger name="org.openhab.io.dropbox" level="DEBUG" />
<!-- temporary workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=402750 -->
<logger name="OSGi" level="OFF" />
Really don't understand why you have a different debug log.....
Bah!
I have the same problem on a RPI
21:15:32.785 [DEBUG] [.b.s.internal.SamsungAcBinding:294 ] - java.lang.Exception: Could not connect using certificate: /etc/openhab/configurations/cert.pem : javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
pi@raspberrypi:~ $ java -version
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
@MrMerlino I start openHAB from a terminal (click on windows, then run, then type cmd, then enter, then cd \Users\Administrator\Desktop\openhab then enter) with the command start_debug. (Writing it down in full, but maybe you already know all this).
@thomas70 Thanks, I think we can nail it down to a certificate path issue. Did you add the ROOTCA certificate to your ca-certs? If not, I will have to look for the procedure (no SSL expert, but soon to be I am afraid thanks to Samsung), but it comes down to extracting the self-signed certificate from the ac and then adding that to you list of trusted sources in ca-certifcates. I did that on my testing and production machines, as I remember, but never on my Windows machine.
Good news, @steintore and I confirmed this is the issue. A little patience now so we can work out a way to solve this issue. The more impatient amongst us can take a look at https://github.com/escline/InstallCert Performing this procedure with the first certificate from the chain produced by the ac will do the magic.
Thank you @RemcoteWinkel and @steintore :-)
08:28:02.841 [DEBUG] [.b.s.internal.SamsungAcBinding:289 ] - Connection to Samsung AC: [192.168.1.174:2878, MAC: BC8CCDXXXXXX, TOKEN: 3dbe5510-e09f-4ab9-bc28-9685fc7396ff] has succeeded
Great @thomas70 . Could you please post a step-by-step list to get this fixed? I'd like to post it on the wiki-page for the binding.
Here is what i did:
10:24:01.703 [DEBUG] [.b.s.internal.SamsungAcBinding:294 ] - java.lang.Exception: Could not connect using certificate: /etc/openhab/configurations/cert.pem : javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
sudo /etc/init.d/openhab stop
wget "https://raw.githubusercontent.com/escline/InstallCert/master/InstallCert.java"
javac InstallCert.java
java InstallCert 192.168.1.174:2878
keytool -exportcert -alias 192.168.1.174-1 -keystore jssecacerts -storepass changeit -file 192.168.1.174.cer
sudo keytool -import -keystore /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/lib/security/cacerts -alias 192.168.1.174 -file 192.168.1.174.cer -storepass changeit
sudo /etc/init.d/openhab start
10:36:54.562 [DEBUG] [.b.s.internal.SamsungAcBinding:289 ] - Connection to Samsung AC: [192.168.1.174:2878, MAC: BC8CCDXXXXXX, TOKEN: 3dbe5510-e09f-4ab9-bc28-9685fc7396ff] has succeeded
Update?
thanks :)