Premise ELK M1 Device Driver

[kzboray]

I tend to agree with you 123. I think the information that the Apex driver puts out is .. well my dad used to say that my friend Joe was a few tools short of a full toolbox. Which is why I am anxiously awaiting your new Elk module. Here are the results of a few more arms / disarms.

Test Starting State:
LastStateChange: Partition_1 Disarmed ** 04/03/2008 13:36:21.250
LastFunction: Disarm ** 04/02/2008 11:31:38.664
StatusLastFunction: Error: No response to disarm. Please check the disarm code

Series 1
Arm to Home:
LastStateChange: Partition_1 StayArmed ** 04/03/2008 14:08:01.011
LastFunction: StayArm ** 04/03/2008 14:08:00.363
StatusLastFunction: Partition_1 StayArmed ** 04/03/2008 14:08:00.711

Disarm From Home Mode:
LastStateChange: Partition_1 Disarmed ** 04/03/2008 14:09:56.406
LastFunction: Disarm ** 04/03/2008 14:09:55.759
StatusLastFunction: Partition_1 Disarmed ** 04/03/2008 14:09:56.122

Series 2:
Arm to Home:
LastStateChange: Partition_1 StayArmed ** 04/03/2008 14:20:26.725
LastFunction: StayArm ** 04/03/2008 14:20:26.082
StatusLastFunction: Partition_1 StayArmed ** 04/03/2008 14:20:26.443

Alarming from Home mode. Zone 33 (Window sensor) Triggered
LastStateChange: Partition_1 Alarming ** 04/03/2008 14:22:34.640
LastFunction: StayArm ** 04/03/2008 14:20:26.082
StatusLastFunction: Partition_1 StayArmed ** 04/03/2008 14:20:26.443

Disarm from Alarming State: (First second after Disarm)
LastStateChange: Partition_1 Disarmed ** 04/03/2008 14:23:3x.xxx
LastFunction: Disarm ** 04/03/2008 14:23:34.337
StatusLastFunction: Partition_1 Disarmed ** 04/03/2008 14:23:34.698

Disarm from Alarming State: (Two seconds +)
LastStateChange: Partition_1 Alarming ** 04/03/2008 14:23:36.280
LastFunction: Disarm ** 04/03/2008 14:23:34.337
StatusLastFunction: Partition_1 Disarmed ** 04/03/2008 14:23:34.698

Series 3
Panic Medical (Alarm in Off mode):
LastStateChange: Partition_1 Alarming ** 04/03/2008 14:23:36.280
LastFunction: PanicMedical ** 04/03/2008 14:30:13.870
StatusLastFunction: Medical panic in zone 96

Disarm from Medical Alarm (First second after disarm)
LastStateChange: Partition_1 Disarmed ** 04/03/2008 14:33:xx.xxx
LastFunction: Disarm ** 04/03/2008 14:32:59.674
StatusLastFunction: Medical panic in zone 96

Disarm from Medical Alarm (Two seconds +)
LastStateChange: Partition_1 Alarming ** 04/03/2008 14:33:59.997
LastFunction: Disarm ** 04/03/2008 14:32:59.674
StatusLastFunction: Medical panic in zone 96


Here ya go.

Kaz

 

[123]

Kaz,
Thanks for second set of test results; they appear to be more consistent than the first set. I believe I now understand the operating principle.

I'm not sure I completely agree with the way the driver handles panic conditions. In the last example, the Medical panic has been disarmed (i.e. acknowledged) yet the State indicates Alarming and the Status continues to display the panic condition. Odd.


BTW
For those following my progress, the driver now supports Voice commands. You can create a Phrase or a Sentence. A Sentence is a collection of spoken Words. You'll need to specify each Word's index number (i.e. "Trouble" = 435) using the Word and Phrase Table found at the end of the ASCII Protocol document.
I considered creating a dropdown list of words and phrases, but I hesitate to load 473 words and 319 phrases into the driver. It may be convenient but, I feel, it consumes too much memory for the value it provides.

 

[123]

Status Update

I'm very close to releasing the first beta of the ELK M1 Device Driver. Three months and several hundred lines of code later ... a wee bit more work than I had anticipated!

• I've added the ability to synchronize the M1's clock with the host PC (only useful if you aren't using the M1XEP's NTP facility).
• The driver now uses an Access MDB file to provide descriptive information about an M1's events, words, and phrases.

Thanks to Kaz's test results, I'm making progress with displaying a snapshot of the M1's operating status; however, it is proving to be trickier than I thought. I need to learn more about an M1's behaviour under different conditions ... I think I'll let the beta-testers guide me on this topic.

I got my hands on an original X10 dimmer module and started experimenting with it. My gosh, its behaviour is ugly! I found it takes about seven DIM commands to go from ON to OFF ... more or less. Its initial state influences how it will respond to DIM and BRIGHT commands. If it is OFF, then a single BRIGHT command will turn it ON (100%). Whereas if it has been dimmed to OFF, then a single BRIGHT command will brighten it slightly. For the sake of completeness, the driver will offer an "X10Dimmer" option to handle these crusty, old modules. However, if I can't get them to operate transparently from Premise (i.e. move a dimmer-slider and the corresponding light responds accordingly) I may just omit support for them.

 

[Spanky]

Nice Job!!

 

[123]

Nice Job!!

Thanks, I appreciate it!

I hope you, or one of your staff, will find time to torture-test the beta version!

 

[mmcalli]

Wow! All this in your spare time? Can't wait to see the M1 in action with Premise. Keep up the good work!

 

[123]

Thanks!

I've updated the Reference Manual for the BETA1 release. I also created a brief Tester's Guide that shows how to prepare for testing the driver. It also provides some commentary on how a few things work and why I chose to do it that way.

I've also included rudimentary support for traditional X10 dimmer modules (LM465). I don't think anyone still uses those crufty old things hence the qualification "rudimentary".

Today I added the ability to "Unbypass all (bypassed) zones" and "Bypass all violated zones".

The last bit of coding is to report the most recent Alarm in the driver's "Security History" section. I need to disconnect my siren for that so it will have to wait until the weekend when I have more time. Then I'll exercise all of the driver's functions one more time before releasing it.

 

[123]

All of the volunteer beta-testers have received a PM indicating where to download the updated Reference Manual (i.e. the 1st posted message of this thread) and the BETA version of the driver (on SkyDrive).

I've had the ignominious honour of discovering the first bug ...
For now, don't select more than 64 PLC Devices.

The M1 provides the status of PLC Devices in banks of 64 and the driver is failing to properly interpret anything beyond the first bank.

I should have the problem sorted out this evening and I'll re-post the corrected driver.

--------------------
STATUS: FIXED
OK, a simple bug; all fixed. I forgot to subtract 64 and all hell broke loose.
The corrected version has been posted on SkyDrive. The zip file now contains a Corrections.txt file listing the bug fixes.
--------------------

 

[trmitche]

Is it too late to get in on this beta? (*for my home system I mean*)

 

[123]

Welcome Trey! I've sent you a PM with all of the details. Let us know how it works out for you.

 

[123]

The BETA1 version of the ELK M1 driver is now available for download by anyone wishing to test it.

If you own an M1, and aren't using a Home Automation (HA) program, now would be a good time to discover what you're missing!

Details are here.

 

[123]

PROBLEM:
If you're using my Premise M1 driver, via the M1-XEP, and everything is working great and then one day you can't arm the M1, set the clock, perform a Discovery, etc. However, it displays zone states, temperatures, and other received data properly. In other words:
- All data transmitted by the M1 is received.
- All data transmitted to the M1 is ignored.

SOLUTION:
Uninstall/reinstall the LANtronix driver. The M1 driver uses it to establish TCP/IP-based commmunication with the M1-XEP. In my case it entered some sort of receive-only mode.

 

[GraysonPeddie]

Are you still working in Elk M1 driver?

I got Premise running in Windows XP.

 

[123]

I haven't made any significant changes to the M1 driver since its release last Spring. I did make one small modification in July but never posted it (it is needed only if the M1 driver is used with my RampDimmerEx module).

I haven't encountered any major bugs; the only glitch I've seen is when there's a communication hiccup. As posted above, the Lantronix driver (it provides a TCP/IP connection) can go wonky. Also, once in a blue moon, the driver may receive a few scrambled packets from the M1. I'll probably need to add a watchdog to monitor the Lantronix driver and beef up the packet-verification code.

Whenever I upgrade my M1's firmware to the latest release, I'll add support for Counters and System Trouble Status.

PS
RE: Premise
I suggest you watch the Video Tutorials to get a good overview of Premise's capabilities. Should you want it, I have most of the Help documentation and code examples in MS-Word format ... call me a dinosaur, but one of my quirks is that I prefer to learn by reading a paper document as opposed to staring at a monitor.

BTW
If you do adopt Premise for Home Automation, your background in C# programming will be a huge asset. Premise lets you write external apps that can communicate with Premise's innards via "MiniBroker". John in VA's Insteon driver is built this way.

 

[GraysonPeddie]

No, it's okay. I tried the AutoDiscovery, but it's not functioning well. I didn't see the word "true" momentoraly but I did look at the "spy" window for COM1 and it seems to communicate with M1 and received back from M1.

I'm gonna have to move up to Propriety solutions for Windows, as I don't think there are any native home automation applications that supports Elk right out of the box under Linux.

I'm about to digress a bit... Somehow, I was thinking that Elk is Windows-centric. Elk M1 being cross-platform but Elk's software only run in Windows and won't work with Wine or ReactOS? That doesn't make any sense.

Anyway, I tried mControl with Vista Media Center support, but it does not have a lot of functionality. But I might try HomeSeer; however, it's going to cost $100 more. Not to let Premise down, as this may seem promising, but it doesn't have a lot of support; in fact, I don't think I'd rely on a discontinued product.