Premise ELK M1 Device Driver

Motorola Premise
Very excited about this dirver. I took a VERY quick look at the docs and will take more time later. One thing did look questionable to me on page 16 under Thermostat.

HeatingSetPoint R Heating activated if Temperature falls below this value

I believe this should read RW not just R.
 
You're absolutely correct, HeatingSetPoint is a writable property. I've updated my master copy of the Reference Manual and I'll post a revised version after I've accumulated several corrections.

Good catch!
 
Status Report

Simple Dimmer
I now realize I need to add a third PLC Device type, namely the "Simple Dimmer". The existing "Dimmer" type tells the M1 to dim a light to a given value. However, for old-fashioned X10 dimmers you need the number of DIM levels. The M1 knows how to do all this but you have to instruct it properly. You won't have to muck about with these details; just pick "Dimmer" or "Simple Dimmer", depending on the physical device type, and the driver takes care of the rest.

Function Key Lights
A function key's illumination status (on/off/blinking) will be exposed as a property. Premise's Button object has a Status field for this purpose but it only supports ON/OFF. I might stash the BLINKING status in the ExtStatus property ... inelegant but the best I can think of short of creating a new Button object (a future TODO).

Area Beeping/Chime
I found this information in the "KC" command and it tells you if Chime and Beep are activated for a given Area. I'm not sure where to stash this yet ... probably as properties of Area.

Thermostats
I don't have a programmable thermostat so (attention BETA-testers!) my thermostat code will go out the door untested. Yes, I can throw some commands at it and ensure the code is executing correctly but I can't be sure it will drive a real thermostat correctly. I'm counting on feedback from the testers to sort this one out.


The finished product will behave like Premise's existing HAI driver. If you experiment with the HAI driver, you'll get a good sense of how easy it will be to control an M1. Plus most of the M1's services will gain a web-UI without you having to write a single line of code.
 
The finished product will behave like Premise's existing HAI driver. If you experiment with the HAI driver, you'll get a good sense of how easy it will be to control an M1. Plus most of the M1's services will gain a web-UI without you having to write a single line of code.

Stop with the teasing!! Please...:(
 
I want the first beta-release to be full-featured and solid. Everything in the Reference Manual must work as described. The beta-tester's role will be to confirm that the driver's services work correctly in their test-environment which will undoubtedly be different from mine. I suspect that this is where the driver will require corrections because I failed to anticipate all possible ways an M1 can be used.

At the moment, I'm still fine-tuning the driver for my M1 environment. Most things work and a few are incomplete (mostly because they seemed easy and I skipped them and moved on to harder stuff). Thermostat functionality will definitely be released untested because, as mentioned, I don't have access to one.

HA is my hobby and I work on this project in my spare time. As a consequence, it is difficult for me to commit to a firm release date. My best guess is that I'll be able to issue a beta-tester's manual and the first beta within two to three weeks.
 
I want the first beta-release to be full-featured and solid. Everything in the Reference Manual must work as described. The beta-tester's role will be to confirm that the driver's services work correctly in their test-environment which will undoubtedly be different from mine. I suspect that this is where the driver will require corrections because I failed to anticipate all possible ways an M1 can be used.

At the moment, I'm still fine-tuning the driver for my M1 environment. Most things work and a few are incomplete (mostly because they seemed easy and I skipped them and moved on to harder stuff). Thermostat functionality will definitely be released untested because, as mentioned, I don't have access to one.

HA is my hobby and I work on this project in my spare time. As a consequence, it is difficult for me to commit to a firm release date. My best guess is that I'll be able to issue a beta-tester's manual and the first beta within two to three weeks.

*Cries :angry:

Well, I am just glad someone is working on it. I was hoping for an earlier release, but I look forward to being able to use Premise as it is a great HA software package. Keep us updated, 123!
 
Teasing? Nah!

Enticing people to try Premise? Yup!

:unsure:

You've enticed me back!! I'd been using Premis back when I had a Caddx system, one that I'd since replaced with an Elk M1.

I'm very excited to try your beta when it becomes available.

Thanks for your development efforts!

Used to be "HighTestHome" in the old forum.
 
Welcome home, HighTestHome! :unsure:

I'm currently adding the ability to send a text message to a keypad's LCD display.

I've also added direct-control for PLC Devices. Via scripting, you can issue the "ALL_LIGHTS_ON" function or use the M1's Device Timeout capability (i.e. turn light on and then off in X seconds).

I'm thinking of supporting voice in the beta-release. Something like a SayWords property that holds a space-delimited string of numbers representing the words to speak (i.e. "197 208 54 198 127" = Goodbye have a great day).

There are some timing issues I have to sort out first. I found that a Discovery operation, which throws a slew of requests at the M1, can overwhelm the M1's buffer. Chucking fifty commands at the M1, each spaced apart by 50ms, was too much for the M1 and it would drop requests.

Throttling the transmissions, by spacing them apart by a half-second (500ms), cures the problem. Unfortunately, it screws things up for speech (500ms delay between words is undesirable). I'm going to try to make the delay time dynamic; it's length will be based on the operation: long delays during a Discovery, short delays (100ms?) for normal use.
 
Status

Areas: More testing is needed
You can disarm and arm an Area (in any mode). I've encountered some unexpected behaviour that demands more testing: if you leave a door open and attempt to Stay Arm from a keypad, the M1 will refuse but if you Stay Arm programmatically, the M1 accepts the request! More exploration is needed. I'll have to disable my exterior siren in order to exercise all arming sequences ... :)
I can't figure out what's supposed to go in a few special Premise properties. Someone volunteered to see what happens to the properties when using an existing CADDX/HAI/ADEMCO driver. I'll leave the properties blank if I don't get results within the next two weeks.

Zones: OK.
Each zone displays its logical and physical status as well as its definition and assigned Area.

Outputs: OK
View and control the output's current state.

PLC Devices: Mostly OK
You can control Dimmers (Brightness and PowerState) and Appliances (PowerState). You also have direct-control of PLC Devices (meaning you can control them using a function call ... like in other HA apps). Only dimmers that support PRESET_DIM (like X10 Switchlincs) have been tested. I still need to provide support for old-school X10 dimmers that support DIM/BRIGHT commands exclusively. I'll have to dig up an old dimmer module ...

Keypads: Mostly OK
Shows keypad temperature (if available) and function keys. Triggering a Fire/Police/Medical alarm has been sorted out but not tested (not until I disconnect my siren).

Thermostats: Not ready but ...
I've got most of it working but, without a real thermostat, I can't be sure the code will work perfectly.

Temperature Probes: Not done yet
I don't have one but I don't anticipate any problems because it is very similar to a keypad's temperature sensor.

Tasks: Not done yet
Trivial; I don't anticipate any problems.

Other goodies:
Send text messages to a keypad's LCD screen. OK
Display the details of the M1's latest log entry. OK
 
Testing the Panel
In the Explorer window, navigate to: Devices > Ademco > Existing > Partitions > Partition_1.
In the Properties window, scroll down to the SecurityHistory section.
Exercise the panel by arming/disarming it, triggering zones, etc. and record whatever is written to the following properties:

LastStateChange
LastZoneTriggered
LastFunction
StatusLastFunction

Results with an APEX 6100 looking at partition 1. The Alarm is setup with split arming only on 4 zones (Heat detectors). All sensors with the exception of the heat detectors are on Partition 1. I moved the heat detectors to individual partitions so that the alarm panel would report their individual locations in the event of a problem or fire. Zone 22 is the occupancy detector in my office where I am working on this. This is why you see it in most cases as the LastZone.

Arm to Home with no code entered for //sys/Devices/Ademco/ApexDestiny6100/Users/User_1/Code
LastStateChange : Partition_1 Disarmed ** 04/02/2008 08:42:32.252
LastZoneTriggered : 22
LastFunction : SatyArm ** 04/02/2008 08:42:32.938
StatusLastFunction : Error: User_1 has no passcode

Arm to Home with a valid code in //sys/Devices/Ademco/ApexDestiny6100/Users/User_1/Code
LastStateChange : Partition_1 StayArmed ** 04/02/2008 10:49:53.025
LastZoneTriggered : 22
LastFunction : SatyArm ** 04/02/2008 10:49:53.400
StatusLastFunction : Partition_1 StayArmed ** 04/02/2008 10:49:53.760

Disarmed from Home mode
LastStateChange : Partition_1 Disarmed ** 04/02/2008 10:54:04.097
LastZoneTriggered : 22
LastFunction : SatyArm ** 04/02/2008 10:54:03.472
StatusLastFunction : Partition_1 StayArmed ** 04/02/2008 10:54:03.831

Armed to Away with code entered for //sys/Devices/Ademco/ApexDestiny6100/Users/User_1/Code
LastStateChange : Partition_1 Armed ** 04/02/2008 11:01:45.241
LastZoneTriggered : 22
LastFunction : Disarm ** 04/02/2008 10:54:03.472
StatusLastFunction : Partition_1 Disarmed ** 04/02/2008 10:54:03.831

Alarm Activated by Motion Detector in Zone 21 Again the LastZone is displaying my office occupancy sensor even though zone 21 is what set off the alarm. I had to move from my office to the stairway to get zone 21 to trigger. Upon returning to my desk I activated zone 22 again.
LastStateChange : Partition_1 Alarming ** 04/02/2008 11:04:35.784
LastZoneTriggered : 22
LastFunction : Disarm ** 04/02/2008 10:54:03.472
StatusLastFunction : Partition_1 Disarmed ** 04/02/2008 10:54:03.831

Disarmed alarm panel while alarming. This is a special case in that the LastStateChange shows first Partition_1 Disarmed ** date/time and then immediately displays the items below. I have a remote 4 button controller and I was using it while watching the Premise server. So I was able to see the 1 sec between the disarm and alarming messages being displayed. This brief change must be a special case for when the alarm has been set off. Otherwise there would never be a history of the the alarm going off in LastStateChange. It would always show either Disarmed, Armed, or StayArmed.
LastStateChange : Partition_1 Alarming ** 04/02/2008 11:06:07.250
LastZoneTriggered : 22
LastFunction : Disarm ** 04/02/2008 10:54:03.472
StatusLastFunction : Partition_1 Disarmed ** 04/02/2008 10:54:03.831

Opened the garage door zone 5 Alarm Disarmed
LastStateChange : Partition_1 Alarming ** 04/02/2008 11:06:07.250
LastZoneTriggered : 5
LastFunction : Disarm ** 04/02/2008 10:54:03.472
StatusLastFunction : Partition_1 Disarmed ** 04/02/2008 10:54:03.831

Panic Fire button Pressed Zone 96 is the Zone dedicated to the Keypads on the Apex 6100. They are on a shared serial bus.
LastStateChange : Partition_1 Alarming ** 04/02/2008 11:23:32.192
LastZoneTriggered : 22
LastFunction : PanicFire ** 04/02/2008 11:23:31.802
StatusLastFunction : Fire Panic in Zone 96

For the Police and Medical panic buttons you get the same results with the exception of the name. Fire Panic / Police Panic / Medical Panic are the three possibilities.


If the Alarm is in one of the three panic modes alarming it can not be disarmed from the AutomationBrowser. If you try to you get this message StatusLastFunction : Error : No response to disarm. Please check the disarm code.. I am pretty sure this is a bug. You have to disarm the system at one of the keypads or with one of the 4 button remotes when the alarm is in this state. It can not be disarmed from the AutomationBrowser while in a panic alarm mode.

If you need other information let me know.

Kaz
 
Kaz, thanks a million! Other than LastZoneTriggered, it was difficult for me to guess what is supposed to be written in the fields.

I will look at the results in detail later tonight but a quick check shows that:
LastStateChange -> the Partition's state and a timestamp
LastZoneTriggered -> the ID number of the last zone triggered
LastFunction -> name of the recently executed action (i.e. one of the Partition-related properties found in SecurityFunctions) and a timestamp
StatusLastFunction -> result of the executed action and a timestamp

Thanks for tip about the "can't disarm when in Panic mode" bug. I'll see if there's anything I can do to resolve that with the ELK M1 driver.

As mentioned in another post, I also encountered a bug in the AutomationBrowser. It ignores 6 digit user codes ... it always takes the last four digits.
 
Kaz,
I'm puzzled by the test results. Either I have not fully understood the operating principle or the Ademco driver is inconsistent.

If you StayArm the first partition successfully, the Ademco results are (from test result #2):
LastStateChange: Partition_1 StayArmed
LastFunction: StayArm
StatusLastFunction: Partition_1 StayArmed
That makes perfect sense to me. The last function was to StayArm the panel, it was successful so the status is StayArmed. As a result, the partition's State is StayArmed for Partition_1.

Now if you Disarm the panel you'd expect to see similar results:
LastStateChange: Partition_1 Disarmed
LastFunction: Disarm
StatusLastFunction: Partition_1 Disarmed

However, the actual results (from test result #3) are different:
LastStateChange: Partition_1 Disarmed <-(OK)
LastFunction: StayArm <-(?)
StatusLastFunction: Partition_1 StayArmed <-(?)
The Ademco driver appears to have ignored the Last Function (Disarming) and displays the second-to-last function (i.e. StayArming).

Now if you proceed to Arming the partition in Away mode, you'd expect the following:
LastStateChange: Partition_1 Armed
LastFunction: Arm
StatusLastFunction: Partition_1 Armed

However, the actual results (from test result #4) are quite different:
LastStateChange: Partition_1 Armed <-(OK)
LastFunction: Disarm <-(?)
StatusLastFunction: Partition_1 Disarmed <-(?)
The State shows that the panel was Armed but the Function and Status are showing Disarmed. The Disarming operation was the second-to-last function performed in your test and not the last function.

If you press the Panic Fire button, LastFunction clearly shows "PanicFire" and not the second-to-last function! So make up your mind, Ademco driver, which is it? Last or 2nd-to-Last? :huh:

So there is the source of my confusion. Whereas LastStateChange appears to show a partition's last change-of-state, LastFunction shows the second-to-last Function executed ... but not always!

Frankly, I disagree with the Ademco driver's implementation and don't see the purpose of displaying the second-to-last function.

Could you please put the driver through a few more arm/disarm cycles and confirm its operation?
 
Back
Top