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

I'm in the process of writing a driver to interface the Elk M1 with a free Home Automation (HA) program. I'd like to know if any M1 owners would be willing to test it.

What you'll need:

1. A PC with Windows XP. Anything built in the last 5 years is adequate.
2. An Elk M1 with a free serial port or the XEP Ethernet Module.
3. Premise Home Control software (free from http://www.premisesystems.com) from my SkyDrive.
4. Spare time to evaluate the driver and report your results.

The best candidates would be M1 owners currently using an HA application like CQC, HomeSeer, or PowerHome (i.e. products that work with the M1). Experienced users would be best suited to spot faults and deficiencies. However, I won't turn down anyone who is volunteering their time ... even if they don't currently use an HA program. Premise installs quickly and is easy to learn and use.

The initial version will probably be limited to Areas, Zones, Outputs and basic Arming/Disarming. My goal is to add support for everything that is accessible via the M1's serial-protocol including Lighting, Thermostats, Tasks, Keypads, Custom Values, Speaking words and phrases, etc.

Any volunteers?

From http://www.premisesystems.info/

"At the present time, Premise Home Control Software is no longer actively supported by Motorola."


Is this unsupported software good enough to get involved with? Have you been using it long?

Photon said:

From http://www.premisesystems.info/

"At the present time, Premise Home Control Software is no longer actively supported by Motorola."


Is this unsupported software good enough to get involved with? Have you been using it long?

Click to expand...

I'd reported a while back about how I liked Premise 2.1. At the time there wasn't as much interest in the Cocoontech forums, but there's been a very growing community in Yahoogroups. A large number of third-party plug in developers have add-ons available for Premise. Even a free insteon add-on exists for the software.

Check http://tech.groups.yahoo.com/group/PremiseSYSCommunity/

The only reason I'd stopped using the system was when I'd replaced an older, failed GE NX-8 security panel with an Elk M1G. If the development of a premise driver for the Elk is successfully completed, I may very well go back to Premise again.

The only reason Premise was discontinued is that Motorola does that with a very large percentage of their company purchases. The software was used for a large number of "high-end" installations, and is still performed by some installers that had heavy investment in the development of HA using Premise. The bonus for the customer is that they don't have to spend $900.00 for the software anymore. See Electronic House's 2006 Gold winner home using Premise and a special "avatar" plug-in here:

http://www.electronichouse.com/article/an_...ar_is_born/C203 And this was developed using Premise 2.0. 2.1 is available for free and so is the .NET development kit for the system, so enthusiasts like the OP can develop new plug-ins and features for the system.

Plus....... It works on Vista. I've run it successfully on the 64bit Home Premium edition.

I am interested in testing this. I have an ELK M1 Gold with XEP. I currently have 3 thermostats, UPB lighting, outputs, and various security setup on it. Looking forward to helping you out with this.

Photon said:

From http://www.premisesystems.info/

"At the present time, Premise Home Control Software is no longer actively supported by Motorola."


Is this unsupported software good enough to get involved with? Have you been using it long?

Click to expand...

This is an excellent home automation program that is just not officially supported anymore, if you know how to write your own drivers you can pretty much add support for any hardware you want. I think you need Visual studio 2005 for the hardware SDK to work. The software comes with a lot of good drivers and if you go through the forums at both Motorola's site and the Yahoo group you can find a bunch of good stuff in there. The software seems as stable as a rock to me also. The main things that are missing right now I would say are a Zwave driver and Elk support, the GUI out of the box looks dated but it is possible to make your own screens.

If more people begin to actively use this program it could grow to be an even better program. It is free for now so why not download it and give it a try, also download the training materials on the Motorola site. If you watch the videos it is very easy to get a working system going very quickly.

ph0n33z, Hightest, Waynedb, thanks for your support!

Photon,
Motorola discontinued Premise development and support in 2006. As mentioned by others, it was a high-end product that, despite the lack of official support, continues to have a following.

For the last two years I've used an open-source HA application called MisterHouse. There is no "official support" for an open-source project and it survives only if it develops a community of active volunteers. MisterHouse does not have an official "product roadmap" and relies upon its users to develop new features. Learn how to program in Perl, become familiar with MisterHouse's theory of operation and you can also contribute to its growth.

MisterHouse's strength is Perl, the 'swiss-army chain-saw' of programming languages. With access to all of the source-code and a huge library of Perl modules (http://www.cpan.org) at your disposal, you can make MisterHouse do whatever you want. Then again, always having to write code to get anything done can become a drag. Commercial applications provide a nice GUI in order to get the simple things done without resorting to programming.

-----------------
Premise has a superb GUI called Builder. Here is what blew me away:

Builder introduces the concept of virtual and real devices. A "Thermostat" is a virtual device whereas the Aprilaire 8870 on the wall in your house is a real device. A "RelayDevice" is virtual whereas your Elk M1's "Output 10" is real. Builder lets you constuct a house full of virtual objects, create logic to drive everything, and then test it all before connecting the real devices.

You can drag several devices into a "Watch window" and observe if they interact according to the logic you created. When you are confident the logic works as expected, you "bind" each virtual device to its real counterpart. This is where the Device Driver converts the "CeilingLight ON" command into the appropriate Lutron RadioRa, Insteon, X10, etc signal. The beauty of this concept is that the logic remains independent of the technology.

If you experience problems communicating with the real devices, you can open the "Port Spy" and observe what is being transmitted and received by the Device Driver.

You can build the logic using familiar concepts like Scenes and Schedules or with more sophisticated tools like Object Diagrams or Scripting. If you choose Scripting, everything is object-oriented, the language is VBScript, there's a full editor syntax highlighting and debugger, and fairly complete documentation with several examples. Everything you create in Builder can be exported in XML format (.XDO file extension) and shared with other users.
-----------------

A Driver can be "native", namely a DLL written in C++ using the SDK, or as a Module written in VBscript. I've chosen to write the Elk M1 driver as a Module because I'm more comfortable with VBscript than C++ and I believe it will be more accessible to others.

I'm willing to beta-test, too. Please shoot me the details

I'd be interested in trying this out as well. I am looking for a way of tying my Elk and iLine lighting system together to provide more flexible rules than either can provide on their own.

The Premise software looks like an interesting model and as a developer I can find my way around an ATL project if that would help.

politics123, RobWalker, welcome aboard gents!

RobWalker, I think you'll be in your element when you discover Premise's architecture.

Currently, my protoype driver is:

• receiving inbound M1 packets (via serial or Ethernet)
• verifying packet integrity
• parsing the packets
• calling the appropriate message-handler
• dumping the message-data to the Windows Debug Console

I'm still a newbie when it comes to Premise driver-development and the members of the Premise community are helping me a great deal. Today I learned how to create a shiny, new class without using the Class Wizard. I've identified the Premise objects I'll need to build in order to hold the received M1 data. I've also created a few "container" classes to house Areas, Zones, Outputs, etc.

I'd like to give it a try.


Scott

I have a little spare time, I will give it a try and report back to you.

Mike

To all prospective beta-testers,

While I'm busy creating the driver, now would be a good time to familiarize yourselves with Premise. I recommend you watch at least the first two tutorial videos and install the software (in the Setup Wizard, select the Large Home template).

Tutorials
Software

For the more ambitious, I suggest you use Premise's CADDX Device driver and bind several DoorContacts and MotionDetectors to their physical counterparts in the CADDX Device ... just to get comfortable with the whole concept of binding and how Premise handles a Security Panel (it also supports Ademco and HAI).

FYI

Progress is slower than I had anticipated but I'm pleased with the results. Transmitting, receiving, and interpreting the M1's messages is the easy part ... building the appropriate Device Driver objects to store all of that information is the tricky bit. I'm using Premise's existing Ademco/CADDX/HAI Device drivers to guide me in designing an Elk M1 driver.

Here's how the M1_Panel Device driver appears in Premise (see photo). It shows the Zones folder populated with 16 zones. The MaxZones property lets you modify the number of zones in increments of 16 up to maximum of 208 zones. Selecting "48" will increase the number of available zones from the default quantity (16) to 48 zones. The same principle applies for the maximum number of Areas and Outputs (and eventually all other categories). Outputs 4-6 are automatically omitted because they don't physically exist on the M1.

123,

Count me in. I install Elk M1Gs for a living. I've done over a dozen of them and am using PowerHome to control the automation features of the panel. I can throw a working ELK M1G into the lab for actual testing. PM me for my email address.

-=*Sharby*=-

P.S. UPB support "with Get Status command" is the next step for me for solid UPB automation.

sharby said:

Count me in. I install Elk M1Gs for a living.
...
I can throw a working ELK M1G into the lab for actual testing.

Click to expand...

Thanks and welcome aboard! Your lab environment is better suited to testing alarm conditions (burglar, fire, etc) that are inconvenient to exercise using my home's M1. In addition, I don't have thermostats, discrete temperature sensors, and insteon/zwave/upb interfaces so I can't test all aspects of the driver. The participation of interested volunteers, like yourself, will help me build a better mousetrap.

May I suggest you have a look at Premise's first two tutorial videos to get a better understanding of how it works. Premise and Powerhome are very different in technology, execution, and deployment.


Status Update
I'm streamlining my code to handle the driver's user-interface (i.e. the folders containing Areas, Zones, Outputs, Lights, Thermostats, Temperature Sensors, Tasks, etc). Each M1 function presents its own challenge. Unlike Zones, where each one is basically on/off and its type is determined by the M1's programming (Burglar/Fire/Water/Gas/etc), Lights are different because each Light must offer a user-selectable choice between Appliance (ON/OFF) or Dimmer (ON/OFF/BRIGHTNESS). I've discovered how to do this and copied the technique used in Premise's HAI OmniPro II driver. Once I have the driver's UI nailed down, I'll connect it to the M1 message-handling logic. For the first release, the driver will probably be limited to "read-only" handling of areas, zones, and outputs.