Elk M1 (and M1 M1EZ8) Alarm Panel Plugin

Cool! Thanks!

Another useful type would be “Switch”. I have some zones set up with switches instead of door sensors so that I can use zones to turn on and off relays. The switches have three positions so that I can achieve more with one switch by including an End-of-Line resistor in one circuit.
I suggest that the zones have a status for each “orientation” (for lack of a better word), if possible. For example: open, closed, EOL, short. Having a status to show a short would not only be useful for applications such as mine with the switches, but also help detect problems with the security system early, should a wire be damaged while doing renovations, etc.

Thank you for considering my suggestion.

Elk has the wireless crystal frequency add-on for the M1. If I get this to incorporate my current GE wireless sensors, will they also show up individually in Vera?

Sent from my SPH-D710 using Tapatalk 2

If the panel can report them as zones, then yes.

[quote=“mcvflorin, post:80, topic:168585”]Hi Quixote,

Currently yes, I used only sensors of type SecuritySensor. I will add support for temperature sensors and waterleak sensors in the next plugin version.[/quote]

Any ETA on this @mcvflorin?

Nope. Sorry.

If anyone is willing to get involved and add the requested features sooner I’d be happy to give him access to the repository.

[quote=“rweisback, post:68, topic:168585”]Hi Mcvflorin,

I definately have “disarmed” in armed detail state, but I just tried “No” to the answer for armed state and it work, then went back to disarm for armed detailed state and it stop working![/quote]
I have the same issue.

I’d have to see how to add in climate sensors with Luup, but I’ve got some java code that I wrote that will parse the temperature data from a keypad.

public static void parseTemperatureData(String data){ char group = data.charAt(0); int address = Integer.parseInt(data.substring(1,3)); int temp = Integer.parseInt(data.substring(3,6));
	l.debug("Group:" + parseGroup(group) + " Address:" + address + " Temp:[" + fixTemp(group, temp) + "]");
}

public static String parseGroup(char group){
	if(group == '0'){
		return "Temperature Probe";
	} else if (group == '1'){
		return "Keypad";
	} else if (group == '2'){
		return "Thermostat";
	} else {
		return "Unknown";
	}
}

public static double fixTemp(char group, int temp){
	if(group == '0'){
		return temp-60;
	} else if (group == '1'){
		return temp-40;
	} else if (group == '2'){
		return temp;
	} else {
		return 0;
	}
}</blockquote>

I just installed a new M1G. Have it interfaced to Vera via the plugin and have only 3 devices showing up. The Elk Alarm Panel, Partition 1 and 2 door sensors. I have 5 door and 1 smoke (currently) enrolled but they are not showing up. These are all wireless via the ELK wireless module. I have restarted the Luup engine, rebooted Vera etc… Why am I missing the 3 other doors and the one smoke detector?

Hard to tell without looking at the logs. You should enable Verbose Logging and look in LuaUPnP.log for lines starting with 52.

tail -f /tmp/log/cmh/LuaUPnP.log | grep '^52'

Search for messages containing ZD. This is the Zone Definition data. Post here or send me an e-mail with these messages.

Just wondering if you had any luck resolving your missing zones?

John

[quote=“jwiz, post:90, topic:168585”]Just wondering if you had any luck resolving your missing zones?

John[/quote]

No Just set a log to @MCVFLORIN.

52 06/10/12 17:26:19.448 intercept 0x2bef898c: 0x44 0x36 0x5a 0x44 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x33 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x38 0x34 (D6ZD00000000000000001030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000084) <0x2e2f9680>

How are you connected with Vera. If you are using the M1XEP which firmware are you using? I did have issue with the latest firmware and had to roll it back to 1.3.26

John

Sent from my iPad using Tapatalk HD

[quote=“jwiz, post:92, topic:168585”]How are you connected with Vera. If you are using the M1XEP which firmware are you using? I did have issue with the latest firmware and had to roll it back to 1.3.26

John

Sent from my iPad using Tapatalk HD[/quote]

I am using the latest… So I should roll back? Is that easy? Any thing lost if I do?

[quote=“aschwalb, post:93, topic:168585”][quote=“jwiz, post:92, topic:168585”]How are you connected with Vera. If you are using the M1XEP which firmware are you using? I did have issue with the latest firmware and had to roll it back to 1.3.26

John

Sent from my iPad using Tapatalk HD[/quote]

I am using the latest… So I should roll back? Is that easy? Any thing lost if I do?[/quote]

I would try to roll back and see if that fixes it. I had upgrade to ver. 1.3.28 and that caused all sorts of communication issues with vera. A soon as I rolled it back to ver 1.3.26 everything was back to normal and running stable. Ver 1.3.28 list as an update for ip communications to a DSC SurGard receiver. The firmware is easy to due under module enrollment in the Elk RP software.

John

[quote=“jwiz, post:94, topic:168585”][quote=“aschwalb, post:93, topic:168585”][quote=“jwiz, post:92, topic:168585”]How are you connected with Vera. If you are using the M1XEP which firmware are you using? I did have issue with the latest firmware and had to roll it back to 1.3.26

John

Sent from my iPad using Tapatalk HD[/quote]

I am using the latest… So I should roll back? Is that easy? Any thing lost if I do?[/quote]

I would try to roll back and see if that fixes it. I had upgrade to ver. 1.3.28 and that caused all sorts of communication issues with vera. A soon as I rolled it back to ver 1.3.26 everything was back to normal and running stable. Ver 1.3.28 list as an update for ip communications to a DSC SurGard receiver. The firmware is easy to due under module enrollment in the Elk RP software.

John[/quote]

@jwiz & @mcvflorin, I did fix my problem, this was completely a user error. While I had correctly enrolled the other sensors in the wireless section I guess I did not save them in the database. I went and looked last night and they were listed as not configured… So I re-configured them and they show up in the interface… I/O error I guess (incompetent operator)

@aschwalb good to hear your up and running now

John

Can someone with a panel and some lights connected to the panel let me know if they receive any update of the light’s status from the panel? The documentation is pretty confusing and I don’t want to implement something based on assumptions. Even if the polling request works, it will be pretty ugly, because it will require that the users specify which lights are active. The protocol doesn’t offer any control command for the lights.

To see if the panel sends updates for the lights you should SSH into Vera and look in the LuaUPnP.log file.

  1. First you must enable verbose logging with the command:
    [tt]VerboseLogging.sh enable[/tt]

  2. Then watch the logs for lines starting with 52:
    [tt]tail -f /var/log/cmh/LuaUPnP.log | grep ‘^52’[/tt]

The messages with the lights status contain the DS letters, e.g. 0BDS001990094
This one means: Reply lighting status of device 001, set to a dim level of 99%

0B – Length as ASCII hex
DS – Reply Lighting Device Status data
001 – Lighting device number 001 to 256, base 1, device A1 = 001
99 – Lighting status. 00 = Off, 01 = Full On, 2 to 99 = Dim level
00 – future use
94 – Checksum

  1. After you’re done watching the logs you should disable verbose logging:
    [tt]VerboseLogging.sh disable[/tt]

Thanks!

@mcvflorin

I have a zwave interface connected to my panel that is setup as a secondary controller to my Vera 2 and I can control all my lights via my elk panel. I can test with that or I can reconnect my old x10 interface and test with that if you would like.

John

@jwiz

Thanks, but I decided to drop support for lights because of the many limitations and time restraint.

I think that as long as we have a Vera Elk plug-in with all of the other functionality that the Elk offers, we can just work around the lighting situation using tasks. The key is two way communication with the Vera and the Elk.
We can even use virtual relays for certain things.