[Solved] Samsung AC binding - OH3

manettino · January 17, 2021, 9:08am

Hi all,

I’ve just updated from OH2 to OH3 my setup, but I’ve just discovered that OH1 samsungAC binding is not present anymore (why I haven’t read the documentation before pressinf upgrade button !!)

I’ve tried to install the binding just putting the jar file into /usr/share/openhab/addons , but I get this error:

2021-01-17 09:36:27.490 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.samsungac-1.14.0.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.samsungac [270]
Unresolved requirement: Import-Package: org.openhab.model.item.binding

    at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

Is there a chance that somewhere in time this binding will be supported in OH3 or there is some sort of workaround to be applied, or I should consider to revert to OH2?

Thanks!

alexxio · January 17, 2021, 12:11pm

I think @jag is working on his version for OH3.

But I don’t know if or when he could release a stable working version.

We can just wait and bother him occasionally to check the progress.

jag · January 17, 2021, 6:38pm

@alexxio The Samsung AC binding is not mine. I’m developing the Samsung Digital Inverter.
Currently in the process of doing some minor tweaks.

alexxio · January 18, 2021, 12:19pm

I’m sorry I mixed them up.

Anyway the Samsung Digital Inveter is the only binding option we have to control such devices in OH3.
Looking forward to try it.
Thanks

manettino · January 18, 2021, 12:28pm

I think Samsung Digital Inverter is not supporting actualy old samsung AC (2878 port one).
@jag is there any chance that also these old equipment will be supported by your binding?

jag · January 19, 2021, 10:10am

@manettino I do not have access to the Samsung AC.
I do think there are som major differences.
Samsung AC is using XML, Samsung Digital Inverter is using json.
There might be other differences as well.

mleon71 · February 8, 2021, 6:24pm

@manettino Just to recap the lost messages. I’m in the same situation. Hoping and waiting for an official version supporting the older 2878-port devices, I modified the samsungac binding to work with OH3 (3.0.1-2 on Raspbian GNU/Linux 10 (buster)). As I said, I’m not a developer but the result seems working for my needs and with my devices (models arxxhssdbwkneu, ver 01, port 2878). As a temporary workaround, if you want to give it a try, you can download it at https://drive.google.com/file/d/1XR00g6sZcZADqDmJUmAL-gnIp8YMWvGY/view?usp=sharing.
Just a few remarks on that:

The key file should be in p12 format, the same format used by the new official Samsung Digital Inverter binding (which is different with respect to the one used by the previous binding). You can covert it using OpenSSL.
Some channels are now supporting the String format instead of Number used in the previous version of the binding (see the following exmaples).

You can configure the things using both the UI or the text files.

[samsung.things]

Thing mysamsungac:arxxhssdbwkneu:ac-pt-sala "AC-PT-Sala" [mac="AABBCCDDEEFF", ip="192.168.1.130", port="2878", token="11223344-5566-7788-99AA-BBCCDDEEFFAA", keystore="/etc/openhab/services/samsung.p12", keystore_secret="your password", refresh="60" ]

[samsung.items]

Switch iACPTSala_Power "AC Sala Power"                                          (AirCond, gAllAirCons)  {channel="mysamsungac:arxxhssdbwkneu:ac-pt-sala:power"} 
Number iACPTSala_Current_Temp "AC Sala Temp. [%.0f °C]"                            (AirCond)               {channel="mysamsungac:arxxhssdbwkneu:ac-pt-sala:temperature"} 
Number iACPTSala_Set_Temp "AC Sala Temp. (M) [%.0f °C]"                            (AirCond)               {channel="mysamsungac:arxxhssdbwkneu:ac-pt-sala:setpoint_temperature" }
String iACPTSala_Mode "Convenience[]"                                           (AirCond)               {channel="mysamsungac:arxxhssdbwkneu:ac-pt-sala:comode"}
String iACPTSala_OpMode "Mode[]"                                                (AirCond)               {channel="mysamsungac:arxxhssdbwkneu:ac-pt-sala:operation_mode"}
String iACPTSala_Direction "Direction[]"                                        (AirCond)               {channel="mysamsungac:arxxhssdbwkneu:ac-pt-sala:winddirection"}
String iACPTSala_Windlevel "Windlevel[]"                                        (AirCond)               {channel="mysamsungac:arxxhssdbwkneu:ac-pt-sala:windspeed"}

[samsung.sitemaps]

Switch      item=iACPTSala_Power                                                                                            icon="switch"
Text        item=iACPTSala_Current_Temp                                                                                     icon="mytemperatureblue"        
Setpoint    item=iACPTSala_Set_Temp                         minValue=16 maxValue=28 step=1                                  icon="mytemperatureblueman"
Switch      item=iACPTSala_OpMode                                                                                           icon="myautomation"         mappings=[Auto="Auto", Cool="Cool", Dry="Dry", Wind="Wind", Heat="Heat"] 
Switch      item=iACPTSala_Direction                                                                                        icon="flow"                 mappings=[SwingUD="SwingUD", Rotation="Rotation", Fixed="Fixed", SwingLR="SwingLR"]
Switch      item=iACPTSala_Windlevel                                                                                        icon="mywind"               mappings=[Auto="Auto", Low="Low", Mid="Mid", High="High", Turbo="Turbo"]
Selection   item=iACPTSala_Mode                                                                                             icon="myairquality"         mappings=[Off="Off", Quiet="Quiet", Sleep="Sleep", Smart="Smart", SoftCool="SoftCool", TurboMode="TurboMode", WindMode1="WindMode1", WindMode2="WindMode2", WindMode3="WindMode3"]

manettino · February 8, 2021, 11:15pm

I’ve tried your binding but I’m facing some problem after configuring the first thing. In fact I get this error:

Cannot connect to 192.168.0.121:2878 (DH ServerKeyExchange does not comply to algorithm constraints)

I’ve tried removing “DH keySize < 1024” from jdk.tls.disabledAlgorithms in java.security , but it only changed the error message:

Cannot connect to 192.168.0.121:2878 (Could not generate DH keypair)

Have i done something wrong with certificate? I’ve converted to P12 using:

openssl pkcs12 -export -out samsung.pkcs12 -in cert.pem

am I missing something?

manettino · February 8, 2021, 11:21pm

another hint: in samsungac binding I wasn’t using any certificate and it was working properly, maybe my 2878 AC isn’t using certificates?

I was only setting mac, ip and token.

mleon71 · February 9, 2021, 8:20am

Unfortunately, I don’t know if all the old 2878 port devices work in the same way. What is the version of your devices? And which OH3/platform are you using?

Anyway, in my case, all the devices request the client authentication during the ssl handshake, as you can see in the following pictures (last row, Certificate Request (13)).

I would suggest to check if your devices are working this way too.

Regarding the p12 format, yes, I used a similar command (although I don’t remember exactly what). For any doubt, you can convert it again in PEM format, checking if the result is correct.

Finally, regarding the java security policy error, I solved similar issues related to algorithms and keylengths following this link: https://www.azul.com/products/zulu-and-zulu-enterprise/zulu-cryptography-extension-kit/. In fact, I’m not sure if this issue is just limited to the DH keySize.

Let me know.

manettino · February 9, 2021, 11:39am

Thank you for your support!

I’ve tried to capture some packets and it seems that my raspberry 4 is sending a “insufficient security” packet back to samsung AC

It seems that my samsungAC is not requesting a certificate from client, but somehow the client is considering not secure this connection (probably due to old algorithm used) and is dropping ssl session.

I’ll try to play with java.security file, maybe it’s possible to fix it reducing security,

manettino · February 9, 2021, 2:29pm

I was checking on old samsungac source, and it seems that, when certificate isn’t provided, a different way to create SSL socket is used:

 private void connect() throws Exception {
    if (isConnected()) {
        return;
    } else {
        logger.debug("Disconnected so we'll try again");
        disconnect();
    }

    if (CERTIFICATE_FILE_NAME != null && new File(CERTIFICATE_FILE_NAME).isFile()) {
        if (CERTIFICATE_PASSWORD == null) {
            CERTIFICATE_PASSWORD = "";
        }
        try {
            SSLClient client = new SSLClient();

            client.addTrustMaterial(TrustMaterial.DEFAULT);
            client.setCheckHostname(false);
            client.setKeyMaterial(new KeyMaterial(CERTIFICATE_FILE_NAME, CERTIFICATE_PASSWORD.toCharArray()));
            client.setConnectTimeout(10000);
            socket = (SSLSocket) client.createSocket(IP, PORT);
            socket.setSoTimeout(2000);
            socket.startHandshake();
        } catch (Exception e) {
            throw new Exception("Could not connect using certificate: " + CERTIFICATE_FILE_NAME, e);
        }
    } else {
        try {
            SSLContext ctx = SSLContext.getInstance("TLS");
            final TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
                public X509Certificate[] getAcceptedIssuers() {
                    return null;
                }

                public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
                }

                public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
                }
            } };

            ctx.init(null, trustAllCerts, null);
            socket = (SSLSocket) ctx.getSocketFactory().createSocket(IP, PORT);
            socket.setSoTimeout(2000);
            socket.startHandshake();
        } catch (Exception e) {
            throw new Exception("Cannot connect to " + IP + ":" + PORT, e);
        }
    }
    handleResponse();
}

I’m not an expert, but it seems that trustAllCerts is used in this case.

@mleon71 , are you using this code to create your binding? maybe can you add a case when no certificate is provided using this code (if it’s possible, sorry but I’m not an expert).

mleon71 · February 9, 2021, 6:59pm

I changed this part of the code removing the execution paths which I was not able to verify or test. Anyway, I can change the code to try to handle also your case if you are available to make some tests. Unfortunately, I do not have access to devices behaving like yours.

mleon71 · February 9, 2021, 10:48pm

You can download the new version. Now the key store and the corresponding password are optional parameters. Of course without debugging it’s particularly challenging…

manettino · February 12, 2021, 12:55pm

I’ve tried again but with no luck, but I think the problem isn’t related with your binding.
In fact I’ve tried to install OH2 again, with samsungac binding and, looking to log files, the same problem is happening:

2021-02-12 13:51:51.129 [DEBUG] [.samsungac.internal.SamsungAcBinding] - Caught exception: java.lang.Exception: Cannot connect to 192.168.0.121:2878 : javax.net.ssl.SSLHandshakeException: DH ServerKeyExchange does not comply to algorithm constraints

So I think is something related to java SSL, it seems that something is changed and now it cannot use anymore some unsecure protocol.

manettino · February 13, 2021, 4:40pm

I’ve furher investigate the problem using openssl. If I connect using:

openssl s_client -connect 192.168.0.122:2878

I get:

3069558800:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1929:

If I force using TLS1 i get:

3070062608:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2150:

If then I force NOT using DH, then I can connect:

openssl s_client -connect 192.168.0.122:2878 -tls1 -cipher 'HIGH:!DH'

I’ve looked in openSSL documentation and it seems that:

This is caused by the SECLEVEL 2 setting the security level to 112 bit. This means that RSA and DHE keys need to be at least 2048 bit long. SHA-1 is no longer supported for signatures in certificates and you need at least SHA-256.

So I think that the only solution is to force openhab binding NOT to use DH, looking to handshake packets it seems that

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

is working, instead:

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

Is not.

Certificate check in my environment isn’t done (I’m not passing pem file but I can connect anyway).

alexxio · February 13, 2021, 7:06pm

I don’t know if could be related (because I’m not using the binding) , but in order to make my bash script work with my digital inverter I had to lower the security level and restore TLS v1

In my rapberry I edited this file /etc/ssl/openssl.cnf

At the end you should see the “system_default_sect”, I commented out the default entry and added mine…at the end that section looks like this

[system_default_sect]
#MinProtocol = TLSv1.2
#CipherString = DEFAULT@SECLEVEL=2
MinProtocol = TLSv1
CipherString = DEFAULT@SECLEVEL=1

Of course this configuration it’s not ideal for security reason…but it’s the only way I could control my AC again via bash script.

mleon71 · February 14, 2021, 6:09pm

@manettino I think you have to change your java security policy in order to enable less secure cryptosuites (see my previous link on Zulu CEK - Cryptography Extension Kit). You can also make a quick test installing the Zulu11 JDK through the openhabian-config tool (sudo openhabian-config -> 40 openHab Related -> 45 Install Zulu 11 OpenJDK ....). This installation script also includes the Java Zulu CEK to enable unlimited cipher strength. I tested the binding aftern installing the Zulu11 JDK this way and it seems working. Let me know.

manettino · February 20, 2021, 8:58am

Finally I have found some spare time to perform some tests.

I’m testing again OH2 with the old V1 binding and it seems that installing Zulu 8 OpenJDK everything is working perfectly!
As I’ve read that OH3 is supporting only Java 11, I’ve tried AdoptOpenJDK 11, and it seems that this one is working too.

I’ll try to test again OH3 with @mleon71 binding with AdoptOpenJDK 11 to be sure that the issue is introduced in zulu 11.

Now the questions are:

is AdoptOpenJDK a good alternative to Zulu11 or I will face some performance issue on OH3?
why AdoptOpenJDK is working but zulu 11 not?

manettino · February 20, 2021, 5:30pm

With AdoptOpenJDK and OH3 @mleon71 's binding is finally working !!
In my environment is sufficient to avoid insertind certificate and I can retrieve current temperature and configure AC.

I will test it today, if everything works correctly I think someone should consider to add to official OH3 binding!

Thank you again @mleon71