eKey Binding and compatibility with ekey Multi and/or OpenHAB2

Thanks for the help.

My ekey LAN config tool is not t he home version - it’s the ekey net converter and the software was all the latest last year. The system itself is quite old though.
With regard to the UDP ports, what I’m still not clear about is how I find the port number used by my RPi running openHab. Where are people getting the number 51000 from?

Hi Thomas,

Thanks for the advice. I was a little bit playing with the port numbers, i was actually using the same number on both sides, eg. 21000. My openhab is on address 192.168.0.150 and i’m listening on port 21000.

First i commented the delimiter line

# ip address of the eKey udp converter (optional)
ip=192.168.0.200
# port number for the UDP packets
port=21000
# mode can be RARE, MULTI or HOME depending on what your system supports - RARE is default
mode=RARE
# the delimiter is also defined on the eKey udp converter - use the eKey configuration
# software to determine which delimiter is used or to change it.
# Not defining this is the same as " "
# delimiter=_

changed the ekey naming, installed the NTP binding and added a test object in the items list, without success.

Number test		"test"	(deurstation) 	{udp="<[192.168.0.200:21000:'REGEX((.*))']"}
Number ekey_action				"Letzte Aktion"									<lock>	(deurstation)		{ekey="Action"}
Number ekey_userid				"letzter Benutzer"								<lock>	(deurstation)		{ekey="UserID"}

and enabled the udp port in my RPI as mentioned below.

iptables -A INPUT -p udp -m udp --dport 21000 -j ACCEPT

But still no success. Is there maybe a command to listen to a specific udp port in the RPI?

Thanks for the help so far, Tom

So I played around a bit an openHab is now picking up the UDP datagrams. The Home format appears to be the same as the NET format so I set my LAN converters to NET format and the EKEY config to "HOME format.

The error I get now is:

[ing.ekey.internal.EKeyPacketReceiver] - Error parsing packet
java.lang.IllegalArgumentException: Invalid Packet! Delimiter-match failed
at at.fhooe.mc.schlgtwt.parser.HomePacket.(HomePacket.java:46

The delimiter is set in the config and LAN converter to “_”.

Any ideas?

I’m not sure, if the “test”-item listening on the same Port as your ekey works within OpenHab… Did you restart the OH2-server? In my tests, I had the feeling that just changing the config didn’t work at first, I had to restart the server.

Nevertheless, normally you don’t need anything apart configuring the ekey-binding (ekey.cfg) and adding items with the ekey-actions.

In the events.log I get only the “Userid”, not the “Action”?

2017-05-31 16:03:47.353 [ItemStateChangedEvent     ] - ekey_doorUserid changed from 1 to 2

two Things:

  1. do you use openHABian?
  2. try getting the log-Level of the ekey-Binding to “TRACE”: log:set TRACE <<ID>>

for the latter:

  1. go to the openhab-console
  2. bundle-list
  3. normally the last one should be the ekey-binding the left column is the ID of the bündle

perhaps that leads to a bit more Information.

That’s sadly exactly how far I did come while trying the non-RARE protocols. I tried a bunch of different delimiters, all of which didn’t work out - I opened an issue at github: [ekey] binding works with RARE, but not with MULTI or HOME · Issue #5014 · openhab/openhab1-addons · GitHub - unfortunately without further success until now.
I understand, you use an old Version of the CV LAN (the one with the RS232?) - I don’t know this one, but if it supports RARE, just try this protocol, at least it works for me.

I’ve got RS-485 LAN converters.

At least we both can show the same error. I was about to try a load of different delimiters but I don’t think I’ll bother now.

I couldn’t get RARE protocol to work but I’ll try again.

Tom

just a shot in the dark: but try this deleting the ekey.config in /var/lib/openhab2/config/org/openhab (if you’re using openHAB in a LINUX-environment).

I did this, because sometimes the config wasn’t updated (not sure, if this issue is solved in the meantime, but worth a try!
After that, try restarting the openHAB-server, somehow I had the best results after restarts…

I’ve done that before. I just did it again and got the following when swiping a finger:

054 [ERROR] [ing.ekey.internal.EKeyPacketReceiver] - Error parsing packet
java.lang.IllegalArgumentException: It seems, that you passed an illegal packet!
at at.fhooe.mc.schlgtwt.parser.RarePacket.(RarePacket.java:56)[219:org.openhab.binding.ekey:1.10.0.201704230111]
at org.openhab.binding.ekey.internal.EKeyPacketReceiver.run(EKeyPacketReceiver.java:139)

Oh well. Not sure what to try next.

oh, well. I’m confused also. those two where the last options I came up with in my installation… I’m afraid, I’m done so far.
Have you tried to put the binding into “TRACE”-loglevel? perhaps there’s some more Information?

Just a question about eKey binding.

Can I detect if someone uses unknow fingerprint? I want to know, if someone tries to enter the door by using his finger which is not in the database. Will this trigger an event?

yes, depending on the protocol you’re using (at present I think, only RARE is working), you’ll get all or some of the following items:

  • Action: -1
  • FingerID: -
  • UserStatus: -1 (or -)

with that, you could trigger an action if no known user uses the fingerprint within x minutes or so…

Hello Thomas,

I don’t use openhabian.
I tried to restart my server, without success.

openhab> bundle:list | grep openHAB
167 | Active   |  90 | 2.1.0.201705282306     | openHAB Core
168 | Active   |  80 | 2.1.0.201705282306     | openHAB Karaf Integration
170 | Resolved |  80 | 2.1.0.201705282306     | openHAB Sound Support, Hosts: 112
171 | Active   |  80 | 2.1.0.201705282306     | openHAB Dashboard UI
177 | Active   |  80 | 2.1.0.201705282306     | openHAB 1.x Compatibility Layer
217 | Active   |  80 | 1.10.0.201705220110    | openHAB eKey Binding
219 | Active   |  80 | 1.10.0.201705220110    | openHAB KNX Binding
220 | Active   |  80 | 1.10.0.201705220110    | openHAB MQTT Binding
224 | Active   |  80 | 1.10.0.201705220110    | openHAB TCP-UDP Binding
225 | Active   |  80 | 1.10.0.201705220110    | openHAB Weather Binding
226 | Active   |  80 | 2.1.0.201705282306     | openHAB Cloud Connector Bundle
227 | Active   |  80 | 2.1.0.201705282306     | openHAB REST Documentation
228 | Active   |  80 | 1.10.0.201705220110    | openHAB MQTT Transport Bundle
229 | Resolved |  80 | 2.1.0.201705282306     | openHAB Basic UI Fragment, Hosts: 214
230 | Active   |  80 | 2.1.0.201705282306     | openHAB Classic UI Fragment
233 | Resolved |  80 | 2.1.0.201705282306     | openHAB Paper UI Theme Fragment, Hosts: 216
237 | Active   |  80 | 1.10.0.201705220110    | openHAB RRD4j Persistence Bundle```

Also when i set the log for the ekey binding to TRACE, nothing related to the ekey binding is writen into the log.

I'm not sure if the UDP port is enabled on the RPI.

Thanks for the help so far.

Tom

Hi Tom,
do you use the openHABian image? if not, just give it a try - it’s really a fine piece of work! I use it and it works for all my needs - including ekey!
http://docs.openhab.org/installation/openhabian.html

Have you tried to put the binding into “TRACE”-loglevel? perhaps there’s some more Information?

No more information that way - just the same information, twice.

Hi all,

I have setup the eKey UDP converter in my eKey Multi environment. Everythings works fine so far except the terminalID.

My eKey configuration file

# IPv4 address of the eKey udp converter.  A static IP address is recommended.
ip=192.168.0.99

# port as you configured during the UDP Converter configuration.  For example, 51000 
port=51000

# can be RARE, MULTI or HOME depending on what your system supports
mode=RARE

# the delimiter is also defined on the eKey UDP converter - 
# use the eKey configuration software to determine which delimiter is used or to change it.
# Another option is `_` (underscore)
delimiter=_

My ekey.items file looks like this

Number eKey_UserID 		{ ekey="userid" }
Number eKey_FingerID 	        { ekey="fingerid" }
String eKey_TerminalID	        { ekey="terminalid" }
Number eKey_Action		{ ekey="action" }

I have two terminals

eKey_terminal.map

80187219140023=frontdoor
80156819150360=garagedoor

When I check the openHab event Log I notice that the TerminalID is somehow incomplete or encrypted - the first 6 digits are missing. That’s also the reason why I have to use a string in the item file, before I have changed that from Number to String I always have had an conversion error in the logs.

2017-11-06 23:18:03.710 [ItemStateChangedEvent     ] - eKey_UserID changed from NULL to 1
2017-11-06 23:18:03.711 [ItemStateChangedEvent     ] - eKey_FingerID changed from NULL to 22
2017-11-06 23:18:03.711 [ItemStateChangedEvent     ] - eKey_TerminalID changed from NULL to xxxxxx19150360
2017-11-06 23:18:03.711 [ItemStateChangedEvent     ] - eKey_Action changed from NULL to 0

However, I have tried to replace the TerminalID with xxxxxx19150360 in order to get a proper result from the transformation, but that doesn’t work. Now, I’m confused how to solve this issue.

Anyone and advice?

Thanks in advance.

BR,
Marcel

I have a question to that binding. Is there a way to control the relays? I want to open the door through OH.

it should work like this then, if your ekey_terminal.map includes the xxxxxx as prefix. I don’t use it, as I do have only one terminal. I’ll have a look in my Setup the next days.

The binding gives you control over the ekey setup. Using the ekey UDP converter, you can use the binding for getting information from the binding (UDP Converter is only capable of getting information on users and fingers or non-authorized fingers).
But you can’t control the relays of your controlling unit (like EKEY multi SE REG 4 - 101163). The eKey controlling unit isn’t capable of receiving events from outside. So you have to think of an alternative on how to tell your door to open. What door opener do you use?

Thanks for the reply. I use a standard door opener. I will use a modbus relay to control lthis. Looks like the easiest way.

Hi Thomas,

I have also tried this. Unfortunately, this doesn’t work.

BR, Marcel