Elk and Lighting

Spanky said:
I agree with Toymaster that all lighting devices should be individually addressable.
I think you miss read my post. I was making a statement on what I felt was on the programmers mind when they designed the database structure for the lighting control of the M1. That might of been acceptable when they designed the M1 but with today's changing technology the database needs to change with it.

Today alone I have been fighting that database structure trying to get X10 motion sensors from a W800, INSTEON and native X10 devices all to be happy together in the database. I also had to explain to a prospective client that even though the M1 can work with multiple Lighting technologies it is difficult to get multiple working on the same M1 because they can conflict with each other. Pretty soon I will have to make a spread sheet of all the do's and don'ts and plot out my lighting placement and addressing just to make the database happy.

I am not sure if I am the only one that thinks this way but the way the Lighting database is done, needs to be changed as soon as possible. I know this would create a MAJOR undertaking but if it is not done it may be the downfall of the M1. Users are going to be wanting to mix technologies together to give them the best options for their needs.

I have over 60 INSTEON switches and it was not fun going around the house putting every one in link mode twice. I had to due it twice because when I got done I found that I forgot a light that should have been grouped with others. Then to get 2-way status I need to go back and link each one to the PowerLinc again (Which I have not done due to time). On top of this When my wife goes into the Web interface she has no idea on which page of lighting is the light she wants to control. She finds it easier to use the switch directly rather then use the M1 which defeats the purpose of the web interface.

Please do not get me wrong, I love the M1 but I am starting to hate the lighting portion. I started using the M1 because of the reliability but it is starting to be a pain in the butt. I am not looking forward to installing the M1 with INSTEON in a customers home, it will end up costing more in setup then it would just to use UPB. I am also not looking forward to the time you release a new firmware update or if a switch fails and I have to do this all over in the same order.We all know Elk can do a better job at implementing INSTEON because of the quality products they have and we see the features we want in competing products.

Wife factor: If my wife can turn on a light from a web page with out an index, then its good. ;)
 
rcharris said:
2) I assume that if multiple Insteon devices (example: switches) are linked to each other, and if one or more of them are linked to the M1XSP, then M1G can control the linked device ensemble by controlling one of the individual linked devices. True?
NOT TRUE! You cannot control a group of Insteon devices by controlling a single member of the group.

If you have three switches (A, B, and C) that are all double linked to each other so they all act in sync, you still cannot not treat them as a single entity or ensemble.

Each device only knows about the devices they are directly linked to and those links are closely held secrets. A knows that it is linked to B and to C But A has know way of knowing that B is linked to C. An Insteon device has no way of knowing about links between 2 devices unless it is one of those devices.

To control this group of switches from an M1, you would individually link A, B, and C to the M1's interface module. If you just sent a signal to A then only A would activate. There is no way for B and C to automatically operate in sync based on a command sent only to A.
 
upstatemike,

You just beat me to the post. I was about to refer him to your post in the Elk Marketplace section regarding this.

There might be a way to have A, B and C to stay in Sync with the M1. how about Link all the switches to the M1, hide the slaves from Web view and create a bunch of rules and end up turning on or off the light 3 times along with a crap of traffic.

Sounds Fun!
 
Thanks Mike for the clarification.

As far as Insteon, this was the first attempt in getting something to work. Insteon has been the hardest lighting system for ELK to interface to. I am sure there will be improvements in the future.
 
All:

Thanks again, again. I've included your latest comments in the comparison table and attached it to this reply.

I had originally hoped that by doing this comparison the choice between Technologies would become clearer. Now I am in data overload. Executive summary?

UPB: Most complete feature set; reputation for reliability; most expensive.

Z-Wave: Good feature set, if one doesn't want manual switch operations to kick off other automation tasks; Mid-cost; Must use separate controller for configuring.

Insteon: Most painful to configure system / setup for M1 control, reasonable feature set, low-medium cost. There does seem to be alot energy around Insteon right now, is that because it is the newest, with new hardware / Software support emerging, (primordial soup so to speak?)

I think I'm leaning towards either Insteon or UPB, depending on how my job search goes. ($$) And I will have to check out Powerhome

Regards, All,
Rod
 

Attachments

  • Elk_Lighting_Comparison_2006_02_13.htm
    14.4 KB · Views: 91
While at EHX last week, I heard from Leviton representatives that the soon-to-be-released Vizia-RF (Zwave) product will have a patent-workaround feature which will allow the switch to report back to the M1 without the M1 having to poll. However, as I understand, the M1 will require a firmware update to support this.

June 1 is the promised release date for the entire planned Vizia-RF product line.

Has anyone else heard any more details?
 
To revisit this 1 year old thread...

1. Are there any plans for ELK to support the status notifications of the newly released Vizia RF switches?

2. Does ELK support more than one insteon group/scene yet? The docs seem to indicate not. And if not, is it on the drawing board?

Johnny
 
I use many groups with my Elk M1. You just need some software, such as Powerhome to set the groups up and then you can reference them by group number with the M1.
 
mtwalsh367 said:
I use many groups with my Elk M1. You just need some software, such as Powerhome to set the groups up and then you can reference them by group number with the M1.
That's good to know thanks.

Anyone know about ELK and Vizia RF's 2 way communication?
 
mtwalsh367 said:
I use many groups with my Elk M1. You just need some software, such as Powerhome to set the groups up and then you can reference them by group number with the M1.
Please tell us a few more details concerning Elk and Insteon groups...

I have groups set up easily enough with PowerHome, but how do you handle these with the Elk? Does your device number have to start above 192?

Please help us out on this topic, I have found very little info on setting up groups (using PowerHome) with Elk.
 
Smarty said:
I have groups set up easily enough with PowerHome, but how do you handle these with the Elk? Does your device number have to start above 192?
Within the Elk, lights 1-192 are "regular" and 193-253 (254?) are "groups". Those numbers are what you put into PH's elkinsteon.exe
 
You don't need to define any insteon device addresses for the groups within your M1 so all that you have to do is as follows:

- Use powerhome (or other Insteon software) to define the devices that will belong to your M1 groups. For your M1 groups your serial PLC connected to your M1 will be the controlling device and the group number should start with 1 for the first group, 2 for the second, and so on. All you are doing with this step is defining your groups and establishing the proper Insteon links between the Insteon PLC and the devices within each group. This is purely Insteon configuration at this point.

- Now all you have to do is go into your M1 lighting devices and name the groups. I don't have my M1 handy right now but I think the group addresses for Insteon start with device 193 (check you M1/Insteon documentation to make sure this is the correct number). Give the device a name (I use G1-Outside, G2-Security, G3-xxxx, etc for my naming standard. Then set the device type for Insteon (I can't remember the M1 device type for Insteon).

Now all you do is reference the lighting device in a rule and "let there by light". I have had great luck with groups on the M1 ever since powerhome started supporting Insteon. I have about 10 groups defined.

Keep in mind that you don't want to execute a series of groups back to back from the M1 just as you don't with individual lights. You need to build in enough of a delay for the Insteon network to completely process a group along with any retries or you will end up with some lights not responding properly. I use a 2 second delay between individual lighting commands and a 5 second delay between group lighting commands. This typically isn't an issue because if you have the right groups defined for what you are doing you only have to execute one group at any given time.

Feel free to follow up with any additional questions or email me directly at [email protected].
 
mtwalsh367 said:
Keep in mind that you don't want to execute a series of groups back to back from the M1 just as you don't with individual lights.
This may still be true for groups, but I think Elk adjusted the delay with individual lights that this usually isn't an issue anymore. At sunset and bedtime I have a number of lights controlled with no delay in the rules and it works 99.9%. Maybe adding a delay would get me the extra .1% for the occasional issue? Or maybe we can ask Elk to bump their internal delay just a tiny bit more?
 
Back
Top