dimming an insteon group??

bdee1

Member
i have an insteon keypadlinc in 6 button config and a insteon switchlinc, both in a virtual 3 way controlling a light. the switchlinc is the master directly connected to the load.

i added the 2 insteon devices to homeseer with the tap add method. then i created an insteon group containing the keypad On button and the Switchlinc. and the group works for on/off. if i turn the group on in homeseer, the load turns on and the status is updated on both the kaypad and the switch.

the problem is that in homeseers device list (status page) there is no dimming control for the group. this is a problem because without having dim control on the group, my only way to dim is to dim either the keypad or the switchlinc and then the other device in the circuit doe not get its status updated.

can anyone help me out with this please?
 
Insteon links have the onlevel built into the link. It is like a scene not a group. So you have to set the on level when you build the insteon group.
 
ok but what if i just want a simple way to go into homeseer and select an arbitrary dim level (one time i might want to set the light to 60%, and the next time to 80% and so on), and have the light dim accordingly and the two switches inclolved set to the correct status.

isn't there a simple way to do that without having to setup a different insteon group for each dim level?
 
I think you'd have to send each switch the command separately if you don't want to create a group.
 
boy that seems really hokey - they should make it so that if you create a group without setting a on level it will let you set an arbitrary level when controllign the group. hopefully somethign like this will be added before it comes out of beta.
 
Is a homeseer group actually a group in the PLC?? If so there are dim up/down commands in the insteon sdm that should work when applied to the group. Maybe this is a limitation in the Homeseer Beta software for Insteon.
 
Why do you need a group to do this? There is only one load being controlled, just dim the circuit thats the master (keypadlinc) :D
 
because if there are slaves controlling the load their status wont be updated unless they are also sent a command or they respond to a group command.

Really what should happen is when a device remotely receives a command it should know to update its linked devices to its status.
 
az1324 said:
because if there are slaves controlling the load their status wont be updated unless they are also sent a command or they respond to a group command.

Really what should happen is when a device remotely receives a command it should know to update its linked devices to its status.
exactly!
 
bdee1 said:
az1324 said:
because if there are slaves controlling the load their status wont be updated unless they are also sent a command or they respond to a group command.

Really what should happen is when a device remotely receives a command it should know to update its linked devices to its status.
exactly!
I still say switches should not have to keep track of who they are linked to... that's the job of a controller. For simple switch to switch interaction, a group broadcast should keep everybody in sync. A5 DIM 50% should dim everybody in the A5 group without the individual group members needing to know who else is actually in the group.

Groups should not be tied to a piece of hardware such as a controller button or a computer interfaces memory slot, but should be a logical entity that is addressable within the communications protocol.

Switches Should not need to know the hardware addresses of other switches or maintaint complex link tables. They should only track their membership in the logical groups and respond to group commands from other switches. If they need to be controlled directly by a controller, the hardware address can be used but direct control should not be used in situations where you need a group of switches to operate in sync with each other.
 
I still say switches should not have to keep track of who they are linked to... that's the job of a controller
I believe Insteon's intent was to be "controllerless".
 
TonyNo said:
I still say switches should not have to keep track of who they are linked to... that's the job of a controller
I believe Insteon's intent was to be "controllerless".
Actually, I believe SH's answer to this is that it is their version of security.

Somewhere there is a thread here on how quickly someone could enumerate the Insteon address space, made even quicker by the fact that they group addresses by model. So the entire space is not in use. They should just give up on this farse.

There is only one answer to security and that is encryption, which is in their spec but has never been implemented. Unfortunately I doubt they have room to implement encryption in their limited firmware space.
 
TonyNo said:
I still say switches should not have to keep track of who they are linked to... that's the job of a controller
I believe Insteon's intent was to be "controllerless".
Even in a contollerless environment, like X-10, the switches only need to transmit and respond to to group addresses (A1-P16). They don't need to know who else is in the group.

Controllers need to know who is in the group and need to be able to modify group membership remotely. If Insteon did not intend to use any controllers then there was no reason to use the hardware addresses and link tables. A simple X-10 style address scheme using the more reliable Insteon transmission system would have been sufficient.
 
wuench said:
Actually, I believe SH's answer to this is that it is their version of security.

Somewhere there is a thread here on how quickly someone could enumerate the Insteon address space, made even quicker by the fact that they group addresses by model. So the entire space is not in use. They should just give up on this farse.

There is only one answer to security and that is encryption, which is in their spec but has never been implemented. Unfortunately I doubt they have room to implement encryption in their limited firmware space.
Enough with the security concerns! I'm still waiting to hear of even one case of somebody having their lighting system hacked... It just isn't an issue!
 
Back
Top