Looking for Elk M1 owners willing to be beta-testers.

[Spanky]

Don't forget to download the descriptions of all the zones, light names, output names, task names etc. This makes it much easier for the user to identify what each thing is. You only need to display an item if it is defined in the M1.

There is a newer ASCII protocol than the August 2007 version in which I will get posted on the ELK website. It includes some additional tricks that are in the latest M1 software upgrade.

Go for it!!

 

[123]

Don't forget to download the descriptions of all the zones, light names, output names, task names etc.
...
You only need to display an item if it is defined in the M1.

There is a newer ASCII protocol than the August 2007 version in which I will get posted on the ELK website.
...

Thanks!

Upon initialization, the Elk M1 Device Driver will acquire the configuration and status of everything the M1 is able to report. The received data will be displayed in the Device Driver's user-interface. So instead of "Zone_1" you'd see the actual zone name, such as "Main_Entry". I may also have this task executed daily to ensure synchronization (not 100% certain this is necessary).

Spanky, I like your idea of displaying an item only if it is defined in the M1. However, I'm not certain I can achieve this with all items using the available M1 commands.

For example, I can't find an M1 command that indicates if an Area is unused. "Reply Arming Status Report Data (AS)" reports the arming status, arm-up state, and current alarm state of each of the eight Areas. But I don't see anything in the reply that confirms an Area is unused. I could use "Reply with ASCII String Text Descriptions (SD)" and if the Area name is non-default (i.e. not simply called "Area X") then it has been customized and is probably in use. Yeah, I know, that's hardly a reliable test.

I suppose I could attack it from another angle and check if there are Zones assigned to an Area. If there aren't any, then that Area must be unused. I'm not an M1 installer so maybe someone can confirm that a zoneless Area is truly an unused Area. If that assumption is correct, then I may use this technique in a future version of the Device Driver.

Outputs present a similar challenge. "Control Output Status Report (CS)" reports the ON/OFF state of all outputs but not if an individual Output is used/unused. Even the flawed "does it have a unique name?" test can't be employed because only the first thirty-two Outputs can be assigned a name.

Tricky stuff!

 

[123]

DEVICE DRIVER UPDATE:

I hope the volunteer beta-testers have finished the video tutorials, installed Premise, and experimented with Builder. I've been tackling the Device Driver whenever I can find a free moment and have some results to report.

Outputs are functional.
It was rewarding to see this work! I bound an M1 output (#14) to a RelayDevice, Premise automatically rendered the relay's UI in the web browser, I clicked "On" and presto, output #14's LED turned on. Ah, the simple things in life! Good thing I didn't use output #1!

With functional outputs, it is now possible to use Michael Lehv's IrrigationPro module. It provides a full web-UI and more functionality and control than can be achieved using the M1's Rules.

Zones are functional.
I'm getting some much needed exercise running around the house and "violating zones". Each Zone's "Triggered" property is activated when the zone is violated. Additional properties report the zone's status, type, definition, etc. (see the attached image)


There's a lot of work ahead of me. For example, Premise disallows certain characters when naming an object. You can't call a Zone "Upper/Lower" because "/" is an illegal character. I'll use Regex to translate illegal characters into underscores "_".

The Device Driver needs a substantial "Discovery" function to poll the M1 for all the data it can possibly deliver (names, states, modes, definitions, etc for every area, zone, light, output, etc). I'll probably expose this function in the Device Driver's UI so that it can be executed on demand.

This is a much bigger project than I had anticipated and I've lost track of how many hours I've invested! Fortunately, I find it relaxing and more rewarding than say, crossword puzzles. :blink:

 

[123]

The Discovery function is almost finished. You can execute it on demand, have it poll the M1 every X hours, or the best way is to simply set the "TriggeredByRP" option. Whenever the driver detects you've exited Installer Mode (using RP or a keypad) it will automatically initiate a Discovery and retrieve the configuration changes you've made to the M1.

All names are "sanitized" for use by Premise. All object names in Premise must comply with VBScript naming rules for variables. So "Bathroom Light" is converted to "Bathroom_Light"; illegal characters are converted to underscores.

Zones can now be bypassed by simply setting the "Bypassed" property. I omitted to include Zone Voltages ... changes in voltage are not broadcasted and you have to poll the M1 to acquire the data. I dislike the idea of frequently polling the M1 to get zone voltages. On the other hand, infrequent polling does not produce timely readings ... so I skipped this feature.

Areas are partially functional. The driver shows an area's ArmingStatus, ArmUpState, and AlarmState and can perform basic arming/disarming. The M1 offers more arming states (i.e. Stay Instant, Night Instant, Vacation) than what Premise's "SecuritySystem' object supports ... plus a few other gaps. The beta release may have to live with some reduced functionality until I figure out how to extend the capabilities of the SecuritySystem object to meet the needs of an M1.

Lighting is almost done. Each Light can be either a Dimmer (default; on/off/brightness/preset dim) or an Appliance (optional; on/off).

Temperature Sensors require some conceptual work. The M1 can provide temperature readings from Probes (Zones 1-16), Keypads, and Thermostats. Probes and Keypads are a good fit for the Temperature Sensor category (a Thermostat's temperature readings will go to, what else but, the Thermostat object). I need to devise a class that will handle the two types (Probe and Keypad) of Temperature Sensors.

Premise does not have a SecurityKeypad object ... it uses a SecuritySystem object that binds to a partition (i.e. Area). So I'm planning to break apart a Keypad's functionality into separate objects such as TemperatureSensor, SecuritySystem, and Buttons (i.e. the Function Keys).

Although I can expose Custom Settings and Tasks, I have not found equivalent Premise objects that can take advantage of them. Nothing prevents me from creating these missing objects ... except maybe a lack of available time.

 

[123]

I just can't leave well enough alone! I decided to revise the way the driver handles temperature sensors and the new technique is simpler. Just like real Elk keypads, my Keypad class now includes a Temperature Sensor class. To use it, simply add a Home-level Temperature Sensor object and bind it to a Keypad in the M1 Device Driver. The Temperature Sensor will display the latest temperature readings from the keypad (assuming you are using Elk KP1 keypads).

I stumbled over an issue I had not anticipated regarding temperature conversion. Premise may be set to display temperatures in Fahrenheit whereas the M1 is set to Celsius (or vice versa). You'd probably set both systems to use the same temperature scale (Celsius for me) but you could overlook this detail and get readings in Premise like -439 F. I did; that nonsensical value is Absolute Zero Fahrenheit plus 20 degrees Celsius! Fortunately, I found an M1 command ('ua') that returns the M1's selected temperature scale and I convert the readings accordingly in Premise.

A similar hiccup occurred with User Code length (4 or 6 digits?). Again, I used the 'ua' command to get the M1's selected Code length. The 'ua' comand is a little odd because its intended purpose is quite different.

I found a bug in the AutomationBrowser (ControlPanelManager module; Global script; OnEnterOrCancel subroutine) that prevents it from recognizing 6-digit user codes. It fails to use the CodeLength property correctly because of a coding error. It uses a variable called "len" which is a mistake because that is a reserved word for the length function (len). The problem would not have occurred had the "len" variable been defined using a Dim statement (but it wasn't). To add insult to injury, the "len" variable is used after "on error resume next" so it fails silently. The simplest correction is to add a "Dim len" at the start of the sub.

I decided to include Tasks and Function Keys because I found they work well with Premise's Button class. To use it, simply add a Home-level Keypad with Buttons and bind any Button to a Task in the M1 Device Driver. Click the Button in the browser and *presto* the Task is triggered! Function Keys will work the same way plus the Button will show the Function key's illumination status.

 

[123]

I've looked at ELK M1 drivers for other HA programs (names withheld to protect the innocent) and realized there is a huge difference between them and a driver for Premise.

Most M1 drivers are basically a simple abstraction of Elk's ASCII RS-232 Protocol and provide the user with a friendlier programming interface. For example, to request the keypad temperature, you use something like a "GetKeypadTemp" function and feed it the Keypad number. Or an "ArmAway" function that takes Area and UserCode as parameters. Lighting is controlled by using some form of "PLCDevice" function that needs House Code, Unit Code, etc plus parameters. This is not how the Premise Elk M1 Driver works!

Premise's Device Driver's create a higher level of abstraction. With the M1 driver you can:

• Bind a Temperature Sensor object to an M1 Keypad, go to the browser and you'll see its temperature.
• Bind a SecuritySystem object to an M1 Area, go to the browser and you get a full keypad to enter your code and an ArmAway button to arm the M1.
• Bind a Light object to an M1 PLCDevice, select Dimmer (other option is Appliance), go to the browser and turn the light on/off or move the dimmer slider to adjust the brightness.
• Bind a Thermostat object to an M1 PLCDevice, go to the browser and view the current temperature, adjust the heating setpoint, set the fan mode, etc.

Sure, there's more initial coding work required at the driver level but it's almost a free ride after that!

 

[123]

I put aside driver development and took time to document the installation, configuration and use of the ELK M1 Device Driver. A pre-BETA version of the documentation is available in the Premise Systems Home Control Forum in the following message where all future comments and versions will be posted.

I invite all beta-testers to download the PDF and become familiar with the driver's capabilities. I also plan to create a "Tester's Guide" to assist you during the testing process.

See you in the Premise Systems Home Control Forum!

 

[cryoteck]

I'd like to install and test the driver.

Let me know the details to get started.

Thanks.