ELK M1 Security

In the M1XEP settings in ElkRP, do you have the unsecure port (2101) turned on?


Yes, I have both secure and non-secure ports enabled on the elk.

I have tried configuring OpenHab with port 2601 and got the same results, which is to say nothing happened at all. No errors, no logs, no nothing.

Try this in your .items file (copy exactly as I set the IP and port according to your screenshot):
String ElkListener "ElkListener [%s]" {tcp=">[*:192.168.1.210:2101:default]"}

Trigger some stuff on your Elk and check your events.log file to see if the ElkListener item value changes.

If you still don’t see any action on that item, try adding this additional item to your .items file:
Switch ElkRelay3 "Elk Relay 3" {tcp=">[ON:192.168.1.91:2101:'0Ecn0030000000D7'], >[OFF:192.168.1.91:2101:'0Ecf0030000000DF']"}

Then toggle the switch on and off via the sitemap:

sitemap main label="Test" {
    Frame label="Elk" {
        Default item=ElkRelay3 
     }
}

Watch your Elk through ELKRP and you should see Relay 3 switching on and off as you toggle the switch in OH.

Good luck

Just double-checking, do you have the TCP binding installed?

I don’t have any special settings in my tcp.cfg file.

Below is what I see in the logs when OpenHAB boots. Do you see this?

2018-06-19 19:29:53.650 [INFO ] [b.core.service.AbstractActiveService] - TCP Refresh Service has been started
2018-06-19 19:29:53.651 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - Connecting the channel Channel [item=ElkString, command=0, direction=OUT, remote=/192.168.1.106:2101, buffer=, isBlocking=false, isReconnecting=false, channel=, host=192.168.1.106, port=2101]
2018-06-19 19:29:53.981 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The channel for /192.168.1.106:2101 is now connected

@SkipMorrow, @davez34 Makes a good point.
To be sure, type this at your OH console bundle:list
You should see ‘openHAB TCP-UDP Binding’ listed, please report the version listed, it will be something like 1.12.0

OK, here we go.

openhab> bundle:list | grep TCP
218 | Active | 80 | 1.12.0 | openHAB TCP-UDP Binding
openhab>

my tcp.cfg is all comments, so everything is defaults.

Here’s my startup log:
2018-06-20 22:04:36.547 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI
2018-06-20 22:04:46.820 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Stopped Paper UI
2018-06-20 22:04:46.824 [INFO ] [panel.internal.HABPanelDashboardTile] - Stopped HABPanel
2018-06-20 22:04:46.828 [INFO ] [er.internal.HomeBuilderDashboardTile] - Stopped Home Builder
2018-06-20 22:04:46.834 [INFO ] [.dashboard.internal.DashboardService] - Stopped Dashboard
2018-06-20 22:05:24.380 [INFO ] [er.internal.HomeBuilderDashboardTile] - Started Home Builder at /homebuilder
2018-06-20 22:05:26.016 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.1.114:8080
2018-06-20 22:05:26.018 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.1.114:8443
2018-06-20 22:05:28.693 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘elk.items’
2018-06-20 22:05:29.721 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2018-06-20 22:05:30.414 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘elk.rules’
2018-06-20 22:05:30.564 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘main.sitemap’
2018-06-20 22:05:30.582 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘demo.sitemap’
2018-06-20 22:05:30.986 [WARN ] [lipse.smarthome.io.net.exec.ExecUtil] - Execution failed (Exit value: -559038737. Caused by java.io.IOException: Cannot run program “arping” (in directory “.”): CreateProcess error=2, The system cannot find the file specified)
2018-06-20 22:05:30.996 [INFO ] [ternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online
2018-06-20 22:05:31.146 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:ffeaf125
2018-06-20 22:05:31.692 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2018-06-20 22:05:31.764 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2018-06-20 22:05:31.817 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel

So, no, it doesn’t look like TCP binding is starting correctly.

I tried using the new .items line and still nothing:
String ElkListener “ElkListener [%s]” {tcp=">[*:192.168.1.210:2101:default]"}

And when I tried adding the new sitemap, I got this in the log:
2018-06-20 22:17:41.030 [WARN ] [ing.tcp.AbstractSocketChannelBinding] - There is no channel that services [itemName=ElkRelay3, command=ON]
2018-06-20 22:17:43.542 [WARN ] [ing.tcp.AbstractSocketChannelBinding] - There is no channel that services [itemName=ElkRelay3, command=OFF]

I think we are getting somewhere???

By the way, thank you all SO MUCH for the help! I’m a fast learner with this kind of stuff, so I think once we get this working, I’ll be setting stuff up like crazy!

Skip

I messed up the definition of the second item, I forgot to update it to reflect your setup.

Your TCP items file shoudl look like this:

String	ElkListener	"ElkListener [%s]"	{tcp=">[*:192.168.1.210:2101:default]"}
Switch ElkRelay3 "Elk Relay 3" {tcp=">[ON:192.168.1.210:2101:'0Ecn0030000000D7'], >[OFF:192.168.1.210:2101:'0Ecf0030000000DF']"}

Not sure what to make of your startup log. Once you have updated your items file, maybe try an OH restart. That seems to fix weird stuff for me, especially with the TCP binding and is worth a go.

I restarted OH, made the change suggested, went to the basic UI and clicked on the Elk Relay3. Still getting the same channel error:
2018-06-21 06:08:38.498 [WARN ] [ing.tcp.AbstractSocketChannelBinding] - There is no channel that services [itemName=ElkRelay3, command=ON]
2018-06-21 06:08:40.995 [WARN ] [ing.tcp.AbstractSocketChannelBinding] - There is no channel that services [itemName=ElkRelay3, command=OFF]

Does anyone think this is a network setup issue, or is this an OH configuration issue? I was thinking this afternoon I could try using PuTTY to connect to my XEP and see if I can observe the commands and responses there.

Checking with Putty sounds like a great idea! I don’t know enough about OpenHAB to say if its a network or OpenHAB config issue.

Perhaps, try my .items example and not mcquerty’s example?

String ElkString “Elk String [%s]” { tcp=">[192.168.1.210:2101:‘REGEX((.*))’]" }

I don’t have anything uncommented in tcp.cfg

If you want to try mcquerty’s line, try uncommenting the following in tcp.cfg

itemsharedconnections=true
bindingsharedconnections=true
directionssharedconnections=true

I am not sure about the exact meaning of those issues in the log either but it does mean that the TCP binding is not setup correctly to carry out the command.

In addition to the tcp.cfg settings @davez34 suggests, also try adding the following:

postamble=\r\n
updatewithresponse=false
charset=ASCII

Make sure everything else other than those six settings is commented out.

I know it’s a pain, but I would try restarting OH again after making those config changes.

I’m at work, so I can’t test until this afternoon.

In general, I have noticed that changes to the conf/* files get reflected right away by OH, but there have been times that I have needed to restart. I haven’t cracked the code on when restarting is needed, so I have lately been just restarting each time. Fortunately it’s not too much of a pain since it only takes a few seconds.

I was also thinking about using Wire Shark to watch the traffic between OH and the Elk. I hope to get this figured out before Saturday because I am going on vacation and I won’t be able to work on it at all, and I don’t want to have to recall of my troubleshooting efforts when I get back. Crossing fingers.

Great news! I’m getting messages now:

2018-06-21 16:36:59.837 [INFO ] [er.internal.HomeBuilderDashboardTile] - Started Home Builder at /homebuilder
2018-06-21 16:37:01.358 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.1.114:8080
2018-06-21 16:37:01.360 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.1.114:8443
2018-06-21 16:37:04.188 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'elk.items'
2018-06-21 16:37:05.427 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2018-06-21 16:37:06.025 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'elk.rules'
2018-06-21 16:37:06.207 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'main.sitemap'
2018-06-21 16:37:06.223 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'demo.sitemap'
2018-06-21 16:37:06.826 [WARN ] [lipse.smarthome.io.net.exec.ExecUtil] - Execution failed (Exit value: -559038737. Caused by java.io.IOException: Cannot run program "arping" (in directory "."): CreateProcess error=2, The system cannot find the file specified)
2018-06-21 16:37:06.834 [INFO ] [ternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online
2018-06-21 16:37:06.978 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:ffeaf125
2018-06-21 16:37:07.400 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2018-06-21 16:37:07.532 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2018-06-21 16:37:07.564 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2018-06-21 16:37:07.744 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The maximum buffer will be set to the default value of 1024
2018-06-21 16:37:07.744 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The interval to retry connection setups will be set to the default value of 5
2018-06-21 16:37:07.744 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The cron job to reset connections will be set to the default value of 0 0 0 * * ?
2018-06-21 16:37:07.744 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The setting to queue write operation until a channel gets connected will be set to the default value of true
2018-06-21 16:37:07.746 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The port to listen for incoming connections will be set to the default value of 0
2018-06-21 16:37:07.746 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The setting to use address masks for incoming connections will be set to the default value of true
2018-06-21 16:37:07.746 [WARN ] [ing.tcp.AbstractSocketChannelBinding] - The setting to share channels between directions is not compatible with the setting to use address masks. We will override the setting to share between directions.
2018-06-21 16:37:07.746 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The refresh interval of the worker thread will be set to the default value of 250
2018-06-21 16:37:07.758 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - The maximum time out for blocking write operations will be set to the default value of 3000
2018-06-21 16:37:07.758 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - The blocking nature of read/write operations will be set to the default value of false
2018-06-21 16:37:07.760 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - The preamble for all write operations will be set to the default value of ""
2018-06-21 16:37:07.824 [INFO ] [b.core.service.AbstractActiveService] - TCP Refresh Service has been started
2018-06-21 16:37:07.828 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - We will accept data coming from the remote end /192.168.1.210:2101
2018-06-21 16:37:07.830 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - Connecting the channel Channel [item=ElkListener, command=*, direction=OUT, remote=/192.168.1.210:2101, buffer=, isBlocking=false, isReconnecting=false, channel=, host=192.168.1.210, port=2101] 
2018-06-21 16:37:08.080 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The channel for /192.168.1.210:2101 is now connected
2018-06-21 16:37:11.858 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK07371652106181100065
 to match command ON on item ElkRelay3  
2018-06-21 16:37:11.858 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK07371652106181100065
 to match command OFF on item ElkRelay3  
2018-06-21 16:37:41.728 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK37371652106181100062
 to match command ON on item ElkRelay3  
2018-06-21 16:37:41.728 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK37371652106181100062
 to match command OFF on item ElkRelay3  
2018-06-21 16:37:47.500 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 0AZC012900C6
 to match command ON on item ElkRelay3  
2018-06-21 16:37:47.502 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 0AZC012900C6
 to match command OFF on item ElkRelay3  
2018-06-21 16:37:50.259 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 0AZC012300CC
 to match command ON on item ElkRelay3  
2018-06-21 16:37:50.259 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 0AZC012300CC
 to match command OFF on item ElkRelay3  
2018-06-21 16:38:11.842 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK07381652106181100064
 to match command ON on item ElkRelay3  
2018-06-21 16:38:11.842 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK07381652106181100064
 to match command OFF on item ElkRelay3  
2018-06-21 16:38:41.692 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK37381652106181100061
 to match command ON on item ElkRelay3  
2018-06-21 16:38:41.692 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK37381652106181100061
 to match command OFF on item ElkRelay3  
2018-06-21 16:39:11.806 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK07391652106181100063
 to match command ON on item ElkRelay3  
2018-06-21 16:39:11.808 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK07391652106181100063
 to match command OFF on item ElkRelay3  
2018-06-21 16:39:41.919 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK37391652106181100060
 to match command ON on item ElkRelay3  
2018-06-21 16:39:41.923 [WARN ] [ing.tcp.protocol.internal.TCPBinding] - Cannot parse input 16XK37391652106181100060
 to match command OFF on item ElkRelay3  

Here’s my tcp.cfg:

itemsharedconnections=true
bindingsharedconnections=true
directionssharedconnections=true
postamble=\r\n
updatewithresponse=false
charset=ASCII

And here’s my elk.items

String	ElkListener	"ElkListener [%s]"	{tcp=">[*:192.168.1.210:2101:default]"}
Switch ElkRelay3 "Elk Relay 3" {tcp=">[ON:192.168.1.210:2101:'0Ecn0030000000D7'], >[OFF:192.168.1.210:2101:'0Ecf0030000000DF']"}
String ElkString "Elk String [%s]" { tcp="<[192.168.1.210:2101:'REGEX((.*))']"}

I’ll be honest, I don’t fully understand the whole .items entries yet. I would have thought the parts after the ip address:port (":default" or “REGEX__”) was some sort of filter to test incoming messages against. Since default looked like it was the most general, everything would have passed through it, but instead all of the traffic seems to be passing through the Elk Relay 3 item. I don’t get it.

In general, what would be the strategy for doing something when an arming status message (AS) comes in, indicating zone 1 has been armed away (“1EAS1000
”)?

Figured it out. I had to switch the tcp direction.

String ElkString "Elk String [%s]" { tcp=">[192.168.1.210:2101:default]"}

According to the documentation tcp=> should be for outgoing messages though, so it doesn’t make sense. But it seems to be working.

I could still use some guidance on how to best read the incoming messages, decode them, and do something. I hope I don’t have to write a rule for every conceivable message type out there, Looking for an overall strategy here.

Hi all, been following this thread for a while, I am looking at OH as a replacement to HomeSeer, and the M1G integration has been an issue moving forward
 However thanks to the work already done here with the TCP binding I think I’m caught up now - I have incoming messages from the Elk being logged as zone violation and zone normal, however since the motion sensors don’t show up as items/things I’m not sure what the next step would be to make use of the data.

I am thinking that some kind of dummy item needs to be created for each Elk input and then a rule created to set the status of that item based on the incoming messages, possibly as an action in the existing “Elk Parser” rule.

I tried creating a dummy item like this for one of my zones (Zone 003) and made the following changes to dynamically build the item name from the triggered zone:

Switch Zone003 "Zone 003"
rule "Elk Parser"
when
        Item ElkString changed
then
        //logInfo("Elk Parser","Elk status string: " + ElkString.state.toString)
        if (ElkString.state.toString.substring(2,4).equals("ZC"))
        {
                if (ElkString.state.toString.substring(7,8).equals("9"))
                {
                        val zone = ElkString.state.toString.substring(4,7)
                        //logInfo("Elk Parser","Zone " + ElkString.state.toString.substring(4,7) + " violated.")
                        logInfo("Elk Parser","Zone " + zone + " violated.")
                        sendCommand("Zone" + zone, ON)
                } else if (ElkString.state.toString.substring(7,8).equals("2"))
                {
                        val zone = ElkString.state.toString.substring(4,7)
                        //logInfo("Elk Parser","Zone " + ElkString.state.toString.substring(4,7) + " normal.")
                        logInfo("Elk Parser","Zone " + zone + " normal.")
                        sendCommand("Zone" + zone, OFF)
                }
        }
end

But, this only logs an exception

2018-06-22 12:23:18.230 [INFO ] [se.smarthome.model.script.Elk Parser] - Zone 003 violated.
2018-06-22 12:23:18.232 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Elk Parser': An error  occurred during the script execution: Could not invoke method:   org.eclipse.smarthome.model.script.actions.BusEvent.sendCommand(java.lang.String,java.lang.String) on instance: null

Perhaps I am using the wrong type of item
 I’m still getting my head around OH
 OR, is the idea to define each sensor as an item with its own ON/OFF string similar to the relay examples earlier? Not sure how we’d do this with potentially varying checksum info being part of the string


Try this:

...
        logInfo("Elk Parser","Zone " + zone + " violated.")
        sendCommand("Zone" + zone, ON.toString)
...

Awesome - that did it! So I can now use the virtual ‘Zone003’ device in the UI Rules editor and trigger events based on motion. Will need to read up on the toString part - I thought that setting the item type to ‘Switch’ would only allow ON/OFF options (boolean) rather than requiring a string, but this works :slight_smile:

hey all! New to openhab, but not home automation. Wondering what the status of the Elk m1 binding is? Is there a group actively working on it? What things are supported with it? Whats unsupported?
Thanks!

Anyone know if there is a way to get the user that arms/disarms the Elk from a keypad? The “a0” and “a1” commands can be sent to the Elk with a user code to disarm/arm away the system, but the tcp item I have coded up doesn’t seem to see the commands when they are sent from a keypad to the M1.
Elk command manual:
https://www.fixagate.com/assets/m1_rs232_ascii_protocol.pdf

And here’s the elk item I am using to intercept commands:
String ElkString “Elk String [%s]” { tcp=">[192.168.1.210:2101:’’]"}

Have you tried using the log data using (ld) command to get a (LD) response? You can probably read index 001 as soon as you see a a0 or a1 message.

No, I have not tried the ld command, but it looks interesting. Anyone have any examples of how to use it? I’ve not tried sending any commands to the Elk before, but it is something that I want to eventually do. I want to send display messages to the keypads. But for now, if I can figure out the last person to disarm the system, that will be perfect.

I do get the arm/disarm messages no problem, I guess I would send an ld command right back to the system when I get the message that it has been armed/disarmed??? How is that done?