KPL secondary buttons, scenes and ELK status

[dss]

I have a KPL secondary button "B" crosslinked with a Switchlinc "A" carrying the load by creating the scene "C" which contains both A and B. I display this scene "C" in the ELK. I can control the scene from the ELK and A & B turn on and off appropriately. However when I turn on the scene by pushing button "B" the scene status is not correctly updated in the ELK. tried to create a rule where secondary button "B" would trigger the scene to go on or off in the ELK but it doesn't do anything. The scene is correctly displayed in the ISY however. Is there a way to make KPL secondary buttons update the scene they are a part of within the ELK?

[gregoryx]

seems like I saw it posted that that will not work the way you're asking.

 

If I understand why, this is it: the "scene" triggered by A is technically a different scene (within the Insteon devices, anyway) than the one the ISY triggers (and so is the one triggered by B - technically every "controller" is a different scene). I think the way to make it work as you ask is to have none of them control the scene, but use a program in the ISY to trigger the scene upon control of the buttons of the devices. That has the down side of a delay, so it's probably not ideal. You may want to consider a different thing to monitor in the Elk (that's what I had to do).

[dss]

I figured out a solution by changing my thinking 180 degrees. Instead of displaying the group in the ELK I'd display the load device "A" then I made rule that whenever A is turned on scene C is turned on and when A is turned off scene C is turned off. Now A, B and C stay synchronized whether the scene is activated locally or at the ELK panel and the status is correct in the ELK panel.

[dss]

Okay now having more problems with this. If I display the load device in the ELK and make an event rule to update the group/scene I can no longer dim the light. It takes it as an "on" and then make the group go full on. I must be missing something here.

[Michel Kohanim]

Hello dss,

 

Unfortunately, INSTEON does not allow to send brightness level to a scene. The responders in a scene respond with their programmed on level/ramp rate regardless of what you send them.

 

With kind regards,

Michel

 

Okay now having more problems with this. If I display the load device in the ELK and make an event rule to update the group/scene I can no longer dim the light. It takes it as an "on" and then make the group go full on. I must be missing something here.

[dss]

Okay, so what I finally did which seems to work is make a second group with all the responders and doesn't include the load device and made programs that turn this second group on when detects the load device going on and off when it detects the load device going off. This seems to work at keeping all the devices in sync whether controlled locally or the ELK web interface.

[Michel Kohanim]

Hi dss, thanks so very much for the feedback. Yes, it makes sense and a good workaround (for now).

 

With kind regards,

Michel

Okay, so what I finally did which seems to work is make a second group with all the responders and doesn't include the load device and made programs that turn this second group on when detects the load device going on and off when it detects the load device going off. This seems to work at keeping all the devices in sync whether controlled locally or the ELK web interface.

[gregoryx]

Down side to the pure program-based is that it has a delay.

 

If I'm understanding what you're doing, might you get the same effect by having ISY program simlpy fire the scene again? I think this would work. IOW, if any device in the scene activates the scene, the ISY re-activates the scene, thus making the Elk see the ISY version of the scene as ON.

 

The advantage to that model is that it would be as fast as direct and the program delay would only affect the Elk.

 

Down side is more PLC traffic.

[dss]

Down side to the pure program-based is that it has a delay.

 

If I'm understanding what you're doing, might you get the same effect by having ISY program simlpy fire the scene again? I think this would work. IOW, if any device in the scene activates the scene, the ISY re-activates the scene, thus making the Elk see the ISY version of the scene as ON.

 

The advantage to that model is that it would be as fast as direct and the program delay would only affect the Elk.

 

Down side is more PLC traffic.

 

I am having ISY program fire the scene again. The problem is if you fire the scene that includes the load device when you try to locally dim either up or down the program will then fire and turn it full on or full off. So you have to make another ISY scene just like the original but removing the load device. That way when the program fires it just updates the responder linked devices. Not really much delay and since the delay is just updating the LED on the linked devices and not the actual light being controlled it isn't a big deal and local control will work normally. Even if the ISY were removed, because the devices don't depend on the program, the scene will work normally as a group.

[gregoryx]

I've been playing with this a bit... I'd like to revive this question and see if Michel will kick in on this: Michel, is there any way for ISY to notify the Elk of what it considers "scene status"?

 

The Elk thinks the scene is a single device / light anyway... so couldn't you give the Elk the same "status" that you report in the ISY UI?

[Michel Kohanim]

Hi gregoryx,

 

To be hones, this is one of those questions that I am not very fond of reviving!

 

The main issue is that ISY does NOT have a status for a scene for the reasons outlined below:

 

The easiest thing to do would've been to consider the scene either as on or off (binary). So, no matter who/what/how the scene was turned on, then it would either be considered on or off. But, even this scenario will not work if a scene, or a controller therein, is dimmed or brightened. Then, we'll get to the arguments of whether or not the member statuses should be ANDed or ORed and ad infinitum. Resolution: scenes should not have any status!

 

With kind regards,

Michel

 

I've been playing with this a bit... I'd like to revive this question and see if Michel will kick in on this: Michel, is there any way for ISY to notify the Elk of what it considers "scene status"?

 

The Elk thinks the scene is a single device / light anyway... so couldn't you give the Elk the same "status" that you report in the ISY UI?

[dss]

I've been playing with this a bit... I'd like to revive this question and see if Michel will kick in on this: Michel, is there any way for ISY to notify the Elk of what it considers "scene status"?

 

The Elk thinks the scene is a single device / light anyway... so couldn't you give the Elk the same "status" that you report in the ISY UI?

 

Seems like what you really need is a virtual device which would be a member of a group that would be displayed in the ELK. If the device is controlled from the elk the other members of the group would respond as if it where just another member device. If one of the local devices are controlled this virtual device would respond too as would other devices in the group.

[Michel Kohanim]

Hi dss,

 

I don't think that works either because the main question is: what is the status of that "virtual device" when there are other controllers in the same scene? If you can answer this question, then we can simply apply the same logic to the scene itself.

 

With kind regards,

Michel

 

I've been playing with this a bit... I'd like to revive this question and see if Michel will kick in on this: Michel, is there any way for ISY to notify the Elk of what it considers "scene status"?

 

The Elk thinks the scene is a single device / light anyway... so couldn't you give the Elk the same "status" that you report in the ISY UI?

 

Seems like what you really need is a virtual device which would be a member of a group that would be displayed in the ELK. If the device is controlled from the elk the other members of the group would respond as if it where just another member device. If one of the local devices are controlled this virtual device would respond too as would other devices in the group.

[dss]

I think it just depends on which scene you put the virtual device in. There are some scenes like a virtual multi-way that the virtual devices is always in sync with the load device in which it would be a controller/responder. Then there are others where it would only be a responder in which you would not use in this situation. All you're really trying to do is keep the devices in the multi-way in sync with the Elk interface.

[Michel Kohanim]

Hi dss,

 

The main question for me is the status of a virtual device/scene when something dims/brightens it. Currently, for KPL secondary buttons, we calculate the status but it's really not to be used except for NOT OFF.

 

With kind regards,

Michel

I think it just depends on which scene you put the virtual device in. There are some scenes like a virtual multi-way that the virtual devices is always in sync with the load device in which it would be a controller/responder. Then there are others where it would only be a responder in which you would not use in this situation. All you're really trying to do is keep the devices in the multi-way in sync with the Elk interface.

[dss]

Hi dss,

 

The main question for me is the status of a virtual device/scene when something dims/brightens it. Currently, for KPL secondary buttons, we calculate the status but it's really not to be used except for NOT OFF.

 

With kind regards,

Michel

I think it just depends on which scene you put the virtual device in. There are some scenes like a virtual multi-way that the virtual devices is always in sync with the load device in which it would be a controller/responder. Then there are others where it would only be a responder in which you would not use in this situation. All you're really trying to do is keep the devices in the multi-way in sync with the Elk interface.

 

I guess what I'd want is more limited in scope. I just want a device/indicator in the ELK interface that acts like a switchlinc in a multi-way group. Just like a non-load switchlinc in a multi-way group if you dim it, it will indicate the dim level of the non-load device locally and the load device will display a matching load device. If you turn it off the load device turns off. If you turn it on the load device turns on. The problem with just displaying and using the load device in the ELK is that if you control it from the ELK the other physical multi-way switchlincs don't reflect this status change. If it acted more like a virtual member device it would update the other multi-way swithclincs. Displaying the group in the ELK and controling it from the ELK would change all the multi-way switchlincs but then it wouldn't reflect any local changes to one of the multi-way switchlincs. If it acted like a virtual switchlinc it would respond to local controls.

[dss]

Hi dss,

 

The main question for me is the status of a virtual device/scene when something dims/brightens it. Currently, for KPL secondary buttons, we calculate the status but it's really not to be used except for NOT OFF.

 

With kind regards,

Michel

I think it just depends on which scene you put the virtual device in. There are some scenes like a virtual multi-way that the virtual devices is always in sync with the load device in which it would be a controller/responder. Then there are others where it would only be a responder in which you would not use in this situation. All you're really trying to do is keep the devices in the multi-way in sync with the Elk interface.

 

I guess what I'd want is more limited in scope. I just want a device/indicator in the ELK interface that acts like a switchlinc in a multi-way group. Just like a non-load switchlinc in a multi-way group if you dim it, it will indicate the dim level of the non-load device locally and the load device will display a matching dim level. If you turn it off the load device turns off. If you turn it on the load device turns on. The problem with just displaying and using the load device in the ELK is that if you control it from the ELK the other physical multi-way switchlincs don't reflect this status change. If it acted more like a virtual member device it would update the other multi-way swithclincs. Displaying the group in the ELK and controling it from the ELK would change all the multi-way switchlincs but then it wouldn't reflect any local changes to one of the multi-way switchlincs. If it acted like a virtual switchlinc it would respond to local controls.

[gregoryx]

To be hones, this is one of those questions that I am not very fond of reviving!

 

I got a good chuckle of that.

 

Michel, I think if ISY viewed it similarly to a one-way device it would be better than not at all. IOW, "last thing WE did with it was ON or OFF" - after that, it's your problem. I think this is true to the nature of groups in Insteon, even if it ignores all the issues you describe.

 

What I like very much about it is that ISY then only reports what status it saw LAST AFFECTED BY A CONTROLLER in the scene. If any controller in the scene sends anything other than OFF, the scene is OFF until someone sends an OFF to the scene.

 

The alternative is much worse, I think: right now, the best way to control things THROUGH the ISY (like with Elk or MainLobby or a web interface) is to activate a scene in the ISY (to keep all elements of the scene in sync); but the ONLY way to know the status of anything is NOT to use the scene - making complex programs the only solution and thus adding to delays and PLC noise. A mess.

 

I see it this way: today, you don't want to have any status reflected by the scene because you don't want an argument over whether you implemented it right; if you implement it as "binary, last controller-based" you can explain why it can't be better, but at least it becomes useful in web, Elk, ML, and anything else that uses the ISY to control Insteon in a complex environment.

[Michel Kohanim]

gregoryx,

 

I see your point ... we already have this in our list of requirements. Since we are going to hopefully release official 2.7 this weekend, I am scared of touching the code. But, you have my word that we'll play with.

 

Thanks so very much,

With kind regards,

Michel

 

To be hones, this is one of those questions that I am not very fond of reviving!

 

I got a good chuckle of that.

 

Michel, I think if ISY viewed it similarly to a one-way device it would be better than not at all. IOW, "last thing WE did with it was ON or OFF" - after that, it's your problem. I think this is true to the nature of groups in Insteon, even if it ignores all the issues you describe.

 

What I like very much about it is that ISY then only reports what status it saw LAST AFFECTED BY A CONTROLLER in the scene. If any controller in the scene sends anything other than OFF, the scene is OFF until someone sends an OFF to the scene.

 

The alternative is much worse, I think: right now, the best way to control things THROUGH the ISY (like with Elk or MainLobby or a web interface) is to activate a scene in the ISY (to keep all elements of the scene in sync); but the ONLY way to know the status of anything is NOT to use the scene - making complex programs the only solution and thus adding to delays and PLC noise. A mess.

 

I see it this way: today, you don't want to have any status reflected by the scene because you don't want an argument over whether you implemented it right; if you implement it as "binary, last controller-based" you can explain why it can't be better, but at least it becomes useful in web, Elk, ML, and anything else that uses the ISY to control Insteon in a complex environment.

[gregoryx]

Thank you for listening, Michel - as you do so well.