Has there been any development towards an ELK binding?
Considering the date of the last post should it be assumed that there is not much interest in this?
Just wondering.
Hi Brian
I too was hoping for someone with some coding skills to develop a binding for this. Unfortunately, it never happened.
Like others, I have succeeded in using the TCP parser and the ELK Parser rules mentioned above.
Hi neo,
I have had an Elk for a number of years now. I only have the serial interface and have not been connected to it in a very long time. I hope the serial port still works. I have a user program in it and am using their remote I/O to control some of my homes lighting. It is a little slow to respond for lighting control but is rock solid and I guess I have grown accustomed to the delay between a switch press and a light going on or off.
I would not mind springing for Elks ethernet module if it would make it easier to do some of the stuff yāall are doing.
I always wondered if it would be possible to talk directly to their I/O modules over the RS485 link but it might not be practical to do that. Talking to the I/O through the Elk would be fine and probably much easier.
Has talking to the ELK from openHAB worked out well for you?
I would love to try that but I must first get my Modbus stuff working. I have I/O around the house controlled by ModbusTCP.
Thanks!
It is nice to hear about what others are doing.
Iām working on continuing development of the ELKM1 binding that communicates using the M1XEP. More info can be found hereā¦
Glad to here there will be Elk support in openHAB. Elk seems to make some very reliable hardware.
I would love to try the binding as soon as time allows and I can purchase a M1XEP.
Thanks for all the efforts.
The binding is pretty solid. Iāve been running it for a few years now. I added functionality to send commands back to the alarm panel to set outputs, etc.
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):
- Set āUse Secure Portā to On
- Save the Thing.
- Set āUse Secure Portā setting to Off
- 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?