Announcement

**Threadhead** · January 23, 2005, 01:06 PM

Originally posted by Mark L

Proper device status values being set (for trigger conditions)
Status - Need clarification - All tests show this is functioning.

As discussed in this thread. The ELK plug-in is not setting the DEVICE STATUS correctly. Sorry for the 'values' confusing, I didn't have the info in from of me when I typed it.

If you attempt to create a trigger on the STATUS of the panel, it reports a code of 17 (unknown). It should report the correct status integer value based on the device value list. Without this, you can not create a trigger that examines the current status of the panel, you must use a script. A value change does not suffice in most situations.

**Threadhead** · January 23, 2005, 01:11 PM

Originally posted by Mark L

Zone and area name to HS device population
Status - Need clarification of request

Check out the latest protocol documentation (Revision 1.25, page 22, 4.15 Request ASCII String Text Descriptions), you can pull the zone name, user name, task name, etc. The ELK panel should pull these names when creating each HS device, instead of just "Zone 1", "Zone 2", etc. Also useful when addressing keypads and tasks.

**Threadhead** · January 23, 2005, 01:13 PM

Originally posted by Mark L

Ability to examine ELK log from HS web pages
Status - 3 (Medium Priority)

I'll agree with the medium priority level. It would be nice to be able to check on the panel, without having to RDC into your HS server, shut HS down, run ELK-RP just to check the log.

**Threadhead** · January 23, 2005, 01:25 PM

Originally posted by Mark L

Implement current alarm state of partitions
Status - Need to investigate how to implement this.

**Threadhead** · January 23, 2005, 02:01 PM

Originally posted by Mark L

Interface improvements
Status - Need clarification of request

I may need to add items as they pop into my head, as I don't have a prepared list. But here is what I can think of now:

1) In the Config dialog... requesting the number of zones, thermos, keypads, and probes could be better handled automatically. You can determine by the ELK protocol if a device is 'inactive' and therefore not to create that device.

Why? Well I have all my PIRs on one zone expansion card, so several of the zone ports on the card are not used (inactive) and you have to manually delete these HS devices. Ditto for the keypads. My keypads are not numbered 1,2,3 and thus I have devices for keypads that don't exist.

Every time I add just one device, I need to 'Recreate Devices' and all the havoc that creates (read below).

2) There should be an "Update Devices" so that you can pull names and new devices added instead of destroying all ELK devices and recreating them. If I add one device to my elk panel and 'Recreate Devices' it will destroy all custom device information I have created, add devices that don't exist (see previous item), and wort of all it will destroy all events created on the device triggers that I created (not good). Part of this is HS's fault, as it removes all references to devices that have been deleted (and it should), but this can easily be worked around.

3) For the above, auto-discovery of new devices would be even better, and quite simple to implement. This would eliminate any and all need for the user to specify device quantities or the need to 'recreate' them.

4) The ELK plug-in should set the 'Transmit Zone Changes', 'Transmit Keypad Changes', 'Transmit Lighting Changes', 'Transmit Output Changes', and 'Transmit Task Changes' (but not log changes) upon initialization, as necessary. Some users of the plug-in may not have ELK-RP in order to make these changes manually. Or at least you should notify users via modal dialog that they should make these changes or the plug-in will not function.

5) I know this hasn't come up yet, but it probably will... systems with more than one alarm area. I have already considered doing it with my system. Since each area has distinct zones and a distinct status, the plug-in should reflect this in HS.

**Threadhead** · January 23, 2005, 02:08 PM

Originally posted by Mark L

Preparation for the Ethernet interface (due in a couple of weeks)!!!
Status - Will pursue as information becomes available.

I know there is no docs available on this yet (I just spoke with ELK support last week and they wouldn't release anything yet). But one of the first things I want to do is move my HS computer out of the closet (where the ELK panel is), and the e-net will allow this.

I'm looking forward to see the implementation, and I think they won't fall into the traps that HAI set with the e-net interface with their system. From the scattered references in the latest protocol specs, it appears that it will be TCP/IP based and use all the existing protocol datagram so you will only need to direct the output to an IP address.

We shall see in a week or so

**Threadhead** · January 23, 2005, 02:09 PM

Ok. I've shot off my BFM

Who's next?!?

**MrOcelot** · January 24, 2005, 01:41 AM

Programming API

Mark,
Please add an API to the plugin so that we can write scripts to send strings to the keypad. I would like to route caller ID information from my NetCalledID box so that it displays the callers name and number when the phone rings. I would also like to display the outside temperature etc. Having a way to invoke the functions from a script would be really useful.

**Threadhead** · January 24, 2005, 10:01 AM

Originally posted by MrOcelot

Mark,
Please add an API to the plugin so that we can write scripts to send strings to the keypad.

I'll second that. Great idea Mr. O.

**dsmithut** · January 29, 2005, 12:37 AM

I am working on attaching several items to the outputs. It might be helpful to allow these to be devices with the status monitored and control from homeseer possible.

**Mark L** · January 30, 2005, 09:30 AM

Originally posted by MrOcelot

Mark,
Please add an API to the plugin so that we can write scripts to send strings to the keypad. I would like to route caller ID information from my NetCalledID box so that it displays the callers name and number when the phone rings. I would also like to display the outside temperature etc. Having a way to invoke the functions from a script would be really useful.

This actually exists now. I just haven't told anyone. Let me rummage through the code and remember how I implemented it.

My master's program, work, and family are really getting in the way of my hobbies

**Mark L** · January 30, 2005, 10:59 AM

Elk Plug-in Text to Keypad Scripting interface

Ok, you asked for it. I had programmed this while I was developing the keypad text feature. I just didn't tell anyone. Sorry.

hs.plugin("ELK-M1").texttokeypad "hi&hello&1&0&00060&2"

The format of the string is values seperated by "&".

Message1&message2&keypadnumber&beep&timeout&clear

keypadnumber - a single number that relates to the keypad area you want to send to

beep - 0 = no beep, 1 = beep

timeout - number of seconds to display (must be 5 digits). 00000 = no timeout.

clear - 0 - clear now, 1 - clear with * press, 2 - clear when timeout.

Let me know if you have any trouble with this.

Thanks,
Mark

**Mark L** · February 20, 2005, 07:58 PM

Unfortunately there is nothing sent to the panel during an entry or exit delay. I would have to poll for that data. Since this would result in excessive polling, I don't see a way to implement this one.

Sorry,

Mark

**Threadhead** · February 20, 2005, 08:52 PM

When the state of the panel changes from 'disarmed' to one of the modes that initiates an exit delay (i.e. Armed Away), you start an exit delay polling timer. You would only need a period of 5s (or so) and terminate the timer when the exit delay has completed.

This should work well and not induce an excessive amount of polling.

Announcement

Elk-M1 Feature Request Thread

Elk-M1 Feature Request Thread

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment