ELK M1 Security

Thanks @matchews for providing and enhancing the binding. I have installed it and was able to add an Elk Alarm Connection, but, can’t proceed.

I believe its stuck at configuration pending and can’t add the remaining things. See pic.

Any ideas?

Please send me the debug logs of the binding initializing.

Hey @matchews

Thanks for the quick reply. Unfortunately, whilst setting up my logging files it seems that my openhab pi setup has become corrupt.

I’ll get you some logs once I recover my pi.

Thanks,

Theo

Thanks for making this. I had jerry rigged something before but this will be nicer. However, I am having troubles I am wondering if you can help with. Trying to connect with secure port I am getting an error that is reading “Unable to open socket to alarm error”. User and password are all correct. Do you happen to have any ideas what could be happening?

Honestly I haven’t used the secure port, but tried it just now and get the same error. If you are on a private network behind a router, and not forwarding any ports outside, you shouldn’t need it. I’m finishing up another binding right now, but will be circling back to get this one cleaned up for OH3. Did you try port 2101 with the “Use Secure Port” turned off? That should get you going until I dig into this. You only need a pin code for non-secure communication.

I’ve got an M1G via XEP (both secure+nonsecure ports ready/listening), and just upgraded to OH3 running under full CentOS7.

I ran the old binding after patching it quite heavily to work back around 2.3, so I’m definitely on-board to poke/trial here for 3x when you’re ready.

Alrighty, trashed all my M1 objects/connections/old JAR and got yours installed. At first it did appear to have a socket error talking to the secure port. I was going to change the port/disable security, but the save command for the Thing isn’t working.

It looks like it’s trying to call a shutdown when saving the new config, but there isn’t a connection to shutdown because it wasn’t successfully made to begin with:

2021-01-23 12:16:45.830 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/elkm1:bridge:1f130a9e0a/config'
java.lang.NullPointerException: null
        at org.openhab.binding.elkm1.internal.elk.ElkAlarmConnection.shutdown(ElkAlarmConnection.java:163) ~[?:?]
        at org.openhab.binding.elkm1.internal.handler.ElkM1BridgeHandler.dispose(ElkM1BridgeHandler.java:141) ~[?:?]
        at org.openhab.core.thing.binding.BaseThingHandler.handleConfigurationUpdate(BaseThingHandler.java:105) ~[?:?]
        at org.openhab.binding.elkm1.internal.handler.ElkM1BridgeHandler.handleConfigurationUpdate(ElkM1BridgeHandler.java:119) ~[?:?]
        at org.openhab.core.thing.internal.ThingRegistryImpl.updateConfiguration(ThingRegistryImpl.java:94) ~[?:?]
        at org.openhab.core.io.rest.core.internal.thing.ThingResource.updateConfiguration(ThingResource.java:504) [bundleFile:?]
        at jdk.internal.reflect.GeneratedMethodAccessor111.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) [bundleFile:1.0.9]
        at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) [bundleFile:1.0.9]
        at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) [bundleFile:1.0.9]
        at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) [bundleFile:1.0.9]
        at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) [bundleFile:1.0.9]
        at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) [bundleFile:1.0.9]
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) [bundleFile:1.0.9]
        at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [bundleFile:1.0.9]
        at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267) [bundleFile:1.0.9]
        at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) [bundleFile:1.0.9]
        at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) [bundleFile:1.0.9]
        at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) [bundleFile:1.0.9]
        at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:216) [bundleFile:1.0.9]
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301) [bundleFile:1.0.9]
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:237) [bundleFile:1.0.9]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) [bundleFile:3.1.0]
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276) [bundleFile:1.0.9]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [bundleFile:?]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [bundleFile:?]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [bundleFile:?]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
        at java.lang.Thread.run(Thread.java:834) [?:?]

There is an issue with the secure connection. Does it work without?

Yup, it works without it. I have it up and running, and it seems to be tracking my panel status predictably so far. There’s un-known messages/a few invalid checksums in the logs, but I remember having those before:

2021-01-24 12:00:45.337 [ERROR] [elkm1.internal.elk.ElkMessageFactory] - Elk Message doesn't end as suspected: 1EAS1200000044011111100000001EEF
2021-01-24 12:00:45.337 [ERROR] [elkm1.internal.elk.ElkMessageFactory] - Elk Message Checksum Invalid: Is: -1, Should Be: 0
2021-01-24 12:00:45.337 [INFO ] [lkm1.internal.elk.ElkAlarmConnection] - Unknown Elk message: 1EAS1200000044011111100000001EEF

However the issue I mentioned above happens when just trying to Save the edited Thing in the WebUI. I was able to reproduce how exactly to cause it (it is related to secure connection, but specifically when trying to config away from it):

  1. Set “Use Secure Port” to On
  2. Save the Thing.
  3. Set “Use Secure Port” setting to Off
  4. Hit Save, it stacktraces and doesn’t save the disabled-setting value.

The only way to recover is totally delete the Thing and recreate it, making sure to not pick Use Secure Port (at least that I’ve found so-far).

Edit: Found another way to recover without total elk-Thing rebuild: stop OpenHAB, edit /var/lib/openhab/jsondb/org.openhab.core.thing.Thing.json (at least that’s where it was for me), and set useSSL to false.

I was able to reproduce the stack trace thrown when “Use Secure Port” is enabled. I didn’t develop that code, but will look into it when I get back on this project. However, I was able to turn off “Use Secure Port” and save without any issue.

As for the invalid checksums, I have never noticed one of those in my log. You might want to check your serial connection from the M1XP to the ethernet module. You might be picking up some noise.

I was receiving a few un-known messages that appear to have been added to the protocol since the binding was originally developed. I have added those to the binding to eliminate the un-kown message errors. Hopefully I will get some time to get back on this, finish the development and get it published.

Sorry @matchews for not getting back to you, I am able to get it working with non-secure port thanks. I have it working well in OH3 without too much issues. I have one question about the send command function. If I want to send a command do I include the checksum or does your binding figure that out with the rest of the command? Reason I ask is for use in things like non-saved codes for guests etc. I had made something previously for that including checksum calculations but just wanted to see if that is needed or not? Once I make sure that works I will share the rules I made. Not the prettiest thing but worked lol.

The binding will handle the checksum. For example, here is my command rule to toggle an output.

        //cn = Output On Command
        //045 = Output #45
        //00002 = Output on for 2 seconds
        //00 = Trailing zeros 
        AlarmCommand.sendCommand("cn0450000300")

Works great! Is the source posted somewhere?

Source is located here…

It needs a little work on the null annotations before its ready for a pull request. If you have some time, have at it.

Any updated jar for Openhab 4.1?

@matchews thx for great work on this. Any chance you have a 4.1 available? (the one from Jan 5 isn’t available anymore).

BTW: is there a plan to PR this into the official addons repo? Would be great to see this as an actual binding in the latest stable releases.

Thank you!

Here is the latest compiled version. I will eventually submit a PR, but the code still needs some cleanup.