ISY/ELK Integration Review and Usability

[bTwix]

I'm new to the forum and have an Elk + ISY/PLM setup that's working great. I had been using both HouseLinc and PowerHome and found the ISY an order of magnitude easier to use: scenes are a snap, standalone module, easier to update/modify from my PC (vs. M1XSP + Powerhome), and very reliable and fast. After getting fed up wtih DOA PLC controllers, the buggy SDM software required to control them, worthless support for lighting scenes (HouseLinc), the ISY+PLM combo has rescued my investment in Insteon lighting and made it a total snap to integrate with my Elk system.

 

What makes the ISY a truely fantastic product is how it really "gets" how the user wants to interact with lighting (vs. HouseLink or PowerHome). The usability of ISY is an order of magnitude better than the others. Seting up lighting scenes, programming switches, and integrating with Elk is so much easier using ISY it's not even funny. With the ISY+PLM my Elk/Insteon integration has gone from a *royal* PITA to something I set up in an evening and now simply take for granted. I don't normally give "glowing" reviews, but - after suffering through multiple DOA PLCs and device centric programming software- I can say that if you value your time and sanity at all, getting an ISY+PLM is a no-brainer.

 

The UD Admin Console is used to manage all devices, links, and scenes. Consistent with the scene centric design of the ISY, all your lighting scenes are displayed in the left nav tree of an explorer style window. There is one special scene called "My Lighting" used to keep all devices (switches, lamplincs, etc.). All linked devices are added to the "My Lighting" scene. Additional scenes (e.g. 3-way links, ambiance scenes, etc.) are listed alphabetically after the special "My Lighting" scene. If you have existing 3-ways links, scenes, etc. they are all discovered as scenes and added after "My Lighting".

 

Discovering my existing configuration (originally created with HouseLinc) was easy using the "Start Linking" command in the ISY/UD Console. Once in "linking mode" you do the normal press and hold on each switch to add them to the ISY.

 

REQUEST: I expected to be able to rename the switches as I linked them (ala HouseLinc) and not being able to do so required me to identify each switch manually after the long running discovery process completed by turning each light on/off and renaming them from the tree view. Please provide some way of renaming devices as I link them.

 

After you're done with the press and hold on each switch you select the appropriate option (add devices - keep links) and click "Cancel" on the linking dialog to initiate the long running discovery process.

 

REQUEST: I had double-check with the manual to figure out if the first two options would delete my existing configuration (BTW, Acrobat 8 / XP hung on the user guide - acrobat 7 worked fine). The "Cancel" button that stop linking and started discovery was a bit counter intuitive. I would have expected "Stop Linking" and "Stop Linking and Discover" buttons instead of "Cancel".

 

After I selected the right option (add devices - keep links) and clicked "Cancel" the long-running discovery process worked flawlessly and finished discovering my 20+ devices, N-way switches, and other scenes by the time I woke up the next day.

 

The linking and discovery process added all devices to the special "My Lighting" scene. I have an appliancelinc controlling a fan I renamed "My Lighting" to "My Devices". All other 3-way/N-way switches and KPL ambiance scenes I had originally created in HouseLinc were discovered as Scene1 - SceneN. The next thing to do was rename my devices and scenes to something more meaningful.

 

For devices I used the following naming convention:

" [- ]" (e.g. Bed Cans N - 1st, Bed Can SE - SE, Bed Floor Lamp). Using first allows easy sorting of switch/load by room. I use before to accomodate consistent naming across switches and applicancelincs/lamplincs. Keep in mind that Elk truncates names to 15 charachters on import to try and keep them short.

 

For scenes I used the following naming convention:

"" (e.g. 3 Attic Lights, 3 Kitchen Under Cabinet, SA All Int Lights, SA All Lights, SR Bed, SR Kitchen, etc.).

 

For WAF I have a main toggle switch in each room that controls the default scene for that room. For more fine-grained control I use KPLs to control individual lights (e.g. porch, entry, hall, cabinet, floor lights, etc.) in addition to some normal 3-way/N-way switches so I have many 3-way/N-way switches. Finally I have scenes defined for ambiance (movie, party, romance, etc.).

 

To make sense of the 20+ scenes I categorized them as follows:

- 3-way/N-way switch scene - prefix scene name with "3" (3-way scene)

- Default room scene - prefix scene name with "SR" (room scene)

- Ambiance scene - prefix scene name with "SA" (ambiance scene)

 

Note: ISY scenes are exported/imported into Elk as an Elk lighting device so the 15 character name limit also applies to scenes.

 

After I renamed all my scenes I found a couple duplicates that I didn't even realize were there (when using HouseLinc) since it's hard to see the forest for the trees when using device centric software like HouseLink or PowerHome. Conversely ISY does a great job of abstracting all the Insteon link configuration into logical scenes and is one of the main reasons ISY is so much easier to use than other Insteon lighting controller products. The ISY/UD Console also automatically adds all discovered scenes to the ISY controller so you don't have to create duplicate scenes (e.g. one for the KPL, one for the PLC).

 

The UD Admin Console provides a virtual dimmer switch panel for each scene in your setup making it easy enough for my wife to adjust scene lighting levels. Each controller (e.g. switch, KPL button, etc.) of a scene can have different onlevels and ramp rates for all loads in the scene and there's even a "Copy Scene Attributed From " button that makes it easy to copy scene onlevels and ramp rates to each controller in the scene.

 

REQUEST: When discovering KPL scenes configured created outside of ISY (e.g. originally created in HouseLinc) the default ISY scene leves/rates are all set to 100%/0.1s. There is no converse "Copy Controller Attributes to " which would allow discovered KPL scenes to be copied back to the ISY scene. One has to manually copy the settings from the KPL scene to the ISY scene by setting the slider positions. When Elk controls a scene it uses the scene attributes of the default ISY scene, not those of one of the scene controllers (e.g. KPL button). While having to manually copy the scene settings is somewhat inconvenient the virtual dimmer switch panel makes it pretty easy. I found that taking a screen shot and using it for reference made things go pretty quick.

 

After everything is configured in ISY/UD Console importing into Elk is a snap. Simply go into the UD Console/Configuration/ELKM1EP tab and click the "Generate ELK Export File" button. This creates an XML file you can import into ELK using ELKRM. In ELKRM right click the ELKRM/Automation/Lighting tree node and selecting the import lighting data option. After you import the ELK-Export.xml all the ISY Insteon devices and scenes are added as Elk lighting devices. If you don't need X10 check the "Future" checkbox for faster lighting response times (removes built in X10 delay).

 

REQUEST: It would be nice to have an option to set "Future" to true like there is for "Show" so I don't have to check "Future" in each Elk lighting device manually.

 

Next you need to configure the ISY to talk to Elk via the M1XEP over the nonsecure port (e.g. 2101). Enable the nonsecure port in the ELKRM M1XEP setup and enter the M1XEP IP/nonsecure port in the UD Console/Configuration/ELKM1XP and you're good to go. If the ISY doesn't pickup the change right away just reboot the ISY from the shell interface (e.g. telnet to the ISY on port 126 or hookup directly to serial port B on the ISY) and it should come up right away. If you get a flashing security panel you're probably using the secure port (e.g. 2601) by accident.

 

To test the setup goto the ElkRM applet console interface, login, and select the lighting section. After you've verified that the Elk can control the lights via the ISY create a couple tasks to turn a scene on/off and verify it from a keypad. After that the sky's the limit.

 

I find that I mainly use scenes to control lighting in Elk rules actions and individual devices for testing if the device is already on in Elk rule qualifiers (i.e. AND statements).

 

ISY has made creating scenes and controlling them from Elk so easy, all my Elk rules control lights through scenes. Even if I'm turning a single light on/off (e.g. front porch) this is usually part of a N-way switch and if I turned the light on by directly controlling the load switch the linked KPL buttons (part of the N-way switch) wouldn't correctly reflect status. Since all rooms have a default scene controlled by the wife-friendly main toggle switch Elk rules also use the default room scene. So I haven't hit a case yet (in my particular setup) where I'm not using a scene to control lights from Elk rules.

 

When adding an Elk rule qualifier to decide if a light should be turned (e.g. if front motion and front light not already on then turn on front porch for 5-min), I'll use the specific device to test if the light is on. I suppose I could test if the scene is on as well but I wasn't sure if that would always work reliably.

 

As a general rule though I'm controlling lights much more than testing if a light is already on. So ideally scenes would show up in the list of Elk lighting devices first and individual Insteon devices later in the list.

 

REQUEST: Elk lighting devices are randomly order during the export/import process. All the device and scene naming conventions used in the ISY/UD Console to group and sort devices and scenes don't provide any benefit in Elk due to the random ordering of scenes and devices.

 

Looking at the ELK-Export.xml it seems like this could be fixed either in ISY/UD Console or ElkRM. ISY/UD Console could order the suggested ELK-ID elements (grouped by scene and device and sorted alphabetically). Alternative ElkRM could do the same when importing given the distinct and elements in the ELK-Export.xml.

 

In addition to grouping and sorting (scenes first, then devices) the addition of new scenes/devices needs to be considered. The first thing you're likely to do after the initial ISY/Elk export/import is add new scenes/devices in ISY/UD Console. If the original import of scenes/devices is packed then the only freespace for new scenes/devices is at the end of the list which would break the scene/device grouping. Alternatively all the lighting devices could be overwritten but then Elk rules referencing a given Elk lighting device could break (e.g. point to a different device that overwrote the one orignally imported).

 

From a user perspective the best solution to this would be to fix up the rules when new lighting devices are imported based on the lighting node or scene address. This way the Elk lighting devices could still be grouped by scene and device, ordered alphabetically, and packed into a single contiguous list.

 

Alternatively, using a stack/heap grow towards the middle approach could be used to keep scenes and devices separate in the Elk lighting device list, keeping scenes at the top of the list and devices at at the bottom. However this still wouldn't allow preserving the alpha sort across imports as new scenes/devices are added/removed - so the rule fixup above would be my preference.

 

ISY is a great Insteon lighting controller and provides excellent integration with Elk. If you have Insteon and Elk ISY does the best job of getting everything working together. The GUI is more friendly than HouseLinc, Elk integration smoother than PowerHome, it's a standalone module, you can configure it via brower, telnet, or serial, and it uses a great scene based approach that makes it intuitive to configure.

 

ISY discovery could be a little easier to understand ("Cancel" button), device renaming at linking time, user guide pdf that doesn't hang Acrobat 8 would be nice (acrobat 7 works - so probably my acrobat 8 install), copy controller scene attributes to scene, ISY docs should describe Elk integration using the non-secure port 2101, and the Elk export/import could have better grouping/sorting and reimport capabilities that preserves grouping/sorting.

 

But the ISY is one of the few products I've used that really "gets it". And that's exactly what you should do if you have more than a few Insteon devices. The ISY controller makes Insteon work like it should and live up to the promise. UD tech support is top notch too.

 

Good job guys!

[Algorithm]

Super review, bTwix! I don't have an Elk (would like to have), but the ISY review was spot on. Great job!

[Michel Kohanim]

bTwix,

 

Thanks so very much for an excellent review/recommendations and apologies for a tardy reply.

 

Please find my comments below.

 

With kind regards,

Michel

 

 

REQUEST: I expected to be able to rename the switches as I linked them (ala HouseLinc) and not being able to do so required me to identify each switch manually after the long running discovery process completed by turning each light on/off and renaming them from the tree view. Please provide some way of renaming devices as I link them.

I've added this request to our list of enhancements.

 

REQUEST: I had double-check with the manual to figure out if the first two options would delete my existing configuration (BTW, Acrobat 8 / XP hung on the user guide - acrobat 7 worked fine). The "Cancel" button that stop linking and started discovery was a bit counter intuitive. I would have expected "Stop Linking" and "Stop Linking and Discover" buttons instead of "Cancel".

We shall take this into consideration ... we've renamed this same button so many times in the past that we finally resigned to keeping it Cancel. But, then again, the label for this button does cause confusion.

 

REQUEST: When discovering KPL scenes configured created outside of ISY (e.g. originally created in HouseLinc) the default ISY scene leves/rates are all set to 100%/0.1s. There is no converse "Copy Controller Attributes to " which would allow discovered KPL scenes to be copied back to the ISY scene. One has to manually copy the settings from the KPL scene to the ISY scene by setting the slider positions. When Elk controls a scene it uses the scene attributes of the default ISY scene, not those of one of the scene controllers (e.g. KPL button). While having to manually copy the scene settings is somewhat inconvenient the virtual dimmer switch panel makes it pretty easy. I found that taking a screen shot and using it for reference made things go pretty quick.

Excellent idea!

 

REQUEST: It would be nice to have an option to set "Future" to true like there is for "Show" so I don't have to check "Future" in each Elk lighting device manually.

Excellent idea but this is purely an ELK development effort. I shall notify our representative at ELK.

 

REQUEST: Elk lighting devices are randomly order during the export/import process. All the device and scene naming conventions used in the ISY/UD Console to group and sort devices and scenes don't provide any benefit in Elk due to the random ordering of scenes and devices.

 

Looking at the ELK-Export.xml it seems like this could be fixed either in ISY/UD Console or ElkRM. ISY/UD Console could order the suggested ELK-ID elements (grouped by scene and device and sorted alphabetically). Alternative ElkRM could do the same when importing given the distinct and elements in the ELK-Export.xml.

Agreed.

 

In addition to grouping and sorting (scenes first, then devices) the addition of new scenes/devices needs to be considered. The first thing you're likely to do after the initial ISY/Elk export/import is add new scenes/devices in ISY/UD Console. If the original import of scenes/devices is packed then the only freespace for new scenes/devices is at the end of the list which would break the scene/device grouping. Alternatively all the lighting devices could be overwritten but then Elk rules referencing a given Elk lighting device could break (e.g. point to a different device that overwrote the one orignally imported).

 

From a user perspective the best solution to this would be to fix up the rules when new lighting devices are imported based on the lighting node or scene address. This way the Elk lighting devices could still be grouped by scene and device, ordered alphabetically, and packed into a single contiguous list.

 

Alternatively, using a stack/heap grow towards the middle approach could be used to keep scenes and devices separate in the Elk lighting device list, keeping scenes at the top of the list and devices at at the bottom. However this still wouldn't allow preserving the alpha sort across imports as new scenes/devices are added/removed - so the rule fixup above would be my preference.

 

Yes, absolutely. Please do bear in mind that this is our initial release, a test if you will, upon which we'll be addind more functionality as time permits.

 

 

ISY discovery could be a little easier to understand ("Cancel" button), device renaming at linking time, user guide pdf that doesn't hang Acrobat 8 would be nice (acrobat 7 works - so probably my acrobat 8 install), copy controller scene attributes to scene, ISY docs should describe Elk integration using the non-secure port 2101, and the Elk export/import could have better grouping/sorting and reimport capabilities that preserves grouping/sorting.

Thanks so very much for your invaluable feedbak.

 

 

Good job guys!