Elk Lighting Status incorrect

[Morris Hansen]

I have integrated my Elk with the ISY 99. For the most part, I can control the lights using both rules and through the web interface. I have had a couple situations where the Elk ended up not turning on or off the lights correctly.

 

I then noticed that the Elk web interface does not update when the lights are controlled outside of Elk. ie. controlling the lights by physically using them or even if ISY controls the lights. Either way, the Elk does not reflect the proper status.

 

Is there something else I need to configure either on the Elk or in the ISY so that everything is properly sync'd? All I have done is exported the XML file and imported it into the Elk. I then set everything to SHOW and FUTURE.

 

Thanks for any ideas. Morris

[Morris Hansen]

I have continued to try and figure out what triggers work and what doesn't. I had configured the Elk to only show the scenes for the 3-way switches so that it would be easier to know when the lights were on and to control the scene.

 

If the light is turned on via the ISY or by pressing either device, the scene in the Elk is not properly reflected. I can control the light by using Elk to turn on the device controlling the load but then the slave device is out of sync. This acts the same when I control the load directly from ISY instead of using the scene.

 

I added a Elk rule to turn on/ff the scene whenever the load is turned on/off but it then always go to full brightness even when I try to dim using any method. This keeps everything in sync but removes the ability to dim the load.

 

The Elk does not update the status of scenes which kind of makes sense now. Is there anyway that anyone has found to keep all the devices in sync no matter how the scene/devices are controlled.

 

I am still learning all the details with the ISY and the Elk integration and appreciate any feedback or ideas.

 

Thanks, Morris

[Michel Kohanim]

Hello Morris,

 

Everything has to be in synch regardless of how/whom/where a device/scene was truned on/off. If they are not, then we have to troubleshoot why:

 

1. If you have ELK rules with timeouts ISY will be out of synch with your ELK. This is currently being addressed by the next ELK release

2. Since ISY does not have values/states for scenes [yet], thus turning on/off a scene in ISY (or a physical controller for that scene) do not update the scene in ELK

3. Except for the above two cases, everything else should work as long as ELK is working based on the latest export file

 

With kind regards,

Michel

 

I have continued to try and figure out what triggers work and what doesn't. I had configured the Elk to only show the scenes for the 3-way switches so that it would be easier to know when the lights were on and to control the scene.

 

If the light is turned on via the ISY or by pressing either device, the scene in the Elk is not properly reflected. I can control the light by using Elk to turn on the device controlling the load but then the slave device is out of sync. This acts the same when I control the load directly from ISY instead of using the scene.

 

I added a Elk rule to turn on/ff the scene whenever the load is turned on/off but it then always go to full brightness even when I try to dim using any method. This keeps everything in sync but removes the ability to dim the load.

 

The Elk does not update the status of scenes which kind of makes sense now. Is there anyway that anyone has found to keep all the devices in sync no matter how the scene/devices are controlled.

 

I am still learning all the details with the ISY and the Elk integration and appreciate any feedback or ideas.

 

Thanks, Morris

[Morris Hansen]

Michel,

 

I do have rules in Elk to turn off lights after a certain amount of time. For example: When someone comes down my driveway, the Elk is triggered and then turns on the driveway lights for 2 minutes. The other night, I noticed that the lights were triggered around midnight and they were still on at 7am. Is this what you mean by timeouts?

 

I could see that maybe something would be out of sync from a device status standpoint but would have still expected the Elk to turn off the light after 2 minutes.

 

I am looking forward to being able to utilize scenes more effectively. Hopefully what you are working on will allow scenes to also be dimmed as well and not just on/off.

 

Any idea when Elk will be releasing an update?

 

Thanks, Morris

[Michel Kohanim]

Morris,

 

Please see my comments below.

 

With kind regards,

Michel

 

Michel,

 

I do have rules in Elk to turn off lights after a certain amount of time. For example: When someone comes down my driveway, the Elk is triggered and then turns on the driveway lights for 2 minutes. The other night, I noticed that the lights were triggered around midnight and they were still on at 7am. Is this what you mean by timeouts?

 

I could see that maybe something would be out of sync from a device status standpoint but would have still expected the Elk to turn off the light after 2 minutes.

Yes, this indeed is what I am talking about. The response to ELK request wipes out the timeout period since ISY does not know anything about timeouts. ELK should be releasing an update very soon. In the meantime, and as a workaround, you could bring those rules into ISY.

 

I am looking forward to being able to utilize scenes more effectively. Hopefully what you are working on will allow scenes to also be dimmed as well and not just on/off.

Please take a look at this post ( http://forum.universal-devices.com/viewtopic.php?p=5307 ) which is where this topic is being discussed and the output of which (in some form) is most probably how we'll implement status for scenes. I am not sure how we can ascertain the on level for a scene but please do be kind enough to give us your input/views in that post.

[Morris Hansen]

I will review the other thread and see if I can add anything to the discussion.

 

As for moving the rule over to the ISY, I don't know how I would be able to only do these timers based on contact closures on the Elk and let the device act normally when these contact closures are not active.

 

I did figure out a way to do this in the Elk. Instead of having the Elk rule turn on a light for 2 minutes, the rule turns on the light and then turns on a output for 2 minutes. The Elk allows you to use outputs as a variable to keep track of something.

 

I then created a separate rule that is triggered when the output turns off and then turns the light off. This gives the same functionality as the single rule and keeps everything in the Elk.

[Michel Kohanim]

mohansen,

 

Thanks so very much for the update. I do understand the crux of the issue now. As I mentioned before, we are going to work much closer with ELK to have better integration so that you wouldn't have to go through what you are going through now.

 

With kind regards,

Michel

 

I will review the other thread and see if I can add anything to the discussion.

 

As for moving the rule over to the ISY, I don't know how I would be able to only do these timers based on contact closures on the Elk and let the device act normally when these contact closures are not active.

 

I did figure out a way to do this in the Elk. Instead of having the Elk rule turn on a light for 2 minutes, the rule turns on the light and then turns on a output for 2 minutes. The Elk allows you to use outputs as a variable to keep track of something.

 

I then created a separate rule that is triggered when the output turns off and then turns the light off. This gives the same functionality as the single rule and keeps everything in the Elk.

[Morris Hansen]

I would be interested and willing to test any Elk or ISY code to resolve this.

 

I am still seeing some unreliability with Elk controlling Insteon through the ISY. It does not seem to be 100%.

 

Thanks, Morris

[Michel Kohanim]

Hello Morris,

 

Does the reliability issue happen regardless of the input: i.e. keypad, triggers, timed rules, etc?

 

With kind regards,

Michel

 

 

I would be interested and willing to test any Elk or ISY code to resolve this.

 

I am still seeing some unreliability with Elk controlling Insteon through the ISY. It does not seem to be 100%.

 

Thanks, Morris

[Morris Hansen]

I have seen it with both triggers and timed rules. My driveway sensor triggers the Elk. Based on a rule that is executed on the driveway sensor trigger, I have 2 Insteon devices turn on and then set an output on for 2 minutes. After 2 minutes the output turns off and this in turn triggers another rule that turns off the 2 Insteon devices. Just tonight, only one of the 2 devices turned off. Sometimes neither device turns on.

 

Is it possible that the Elk could be sending commands to quickly for the ISY?

 

I can't tell in the ISY if the commands are getting to it from the Elk or it is something in the Elk. It would be nice for the ISY log export to depict when something is sent from the Elk. Is this functionality on your roadmap?

 

Thanks for your help.

[Michel Kohanim]

Hello Morris,

 

I can tell you with 99% certainty that what you are witnessing is due to how we ELK/ISY process commands. ISY does not return the extra parameters needed by ELK to execute triggers/timed event and, as such, ELK rules/triggers will not be functioning properly till they release the fix for this issue (basically, not expecting ISY to send back time/extra information on the status updates). As per my conversation with our ELK friends, they feel this should be released very soon.

 

As far as logging ELK events, no it has not been in our roadmap but it is now!

 

Thanks so very much for the feedback,

With kind regards,

Michel

 

 

I have seen it with both triggers and timed rules. My driveway sensor triggers the Elk. Based on a rule that is executed on the driveway sensor trigger, I have 2 Insteon devices turn on and then set an output on for 2 minutes. After 2 minutes the output turns off and this in turn triggers another rule that turns off the 2 Insteon devices. Just tonight, only one of the 2 devices turned off. Sometimes neither device turns on.

 

Is it possible that the Elk could be sending commands to quickly for the ISY?

 

I can't tell in the ISY if the commands are getting to it from the Elk or it is something in the Elk. It would be nice for the ISY log export to depict when something is sent from the Elk. Is this functionality on your roadmap?

 

Thanks for your help.

[Morris Hansen]

Great. I look forward to the Elk release.

 

As for the logging enhancement, it would be nice to have detailed logging so that anything that triggers Insteon activity would have unique logging variables.

 

Thanks for your prompt responses.

[snhroc]

Is the Elk still not aware of scene updates? I'm trying to use a KPL button to reflect Garage door state, and to close or open the garage door.. basically the KPL button is a scene controller/responder for Scene "Garage Bay 1"

 

21 WHENEVER Garage Bay 1 (Zn 9) BECOMES NOT SECURE

THEN TURN Garage Bay 1 [120 (H8)] ON,

23 WHENEVER Garage Bay 1 (Zn 9) BECOMES SECURE

THEN TURN Garage Bay 1 [120 (H8)] OFF,

 

The above rules work fine to indicate on the KPL button whether the garage door is open or closed

 

25 WHENEVER Garage Bay 1 [120 (H8)] IS TURNED OFF BY SOME EXTERNAL DEVICE

THEN TURN Output 193 ON FOR 2 SECS

 

However, the above rule doesn't work (because the Elk doesn't recognize scene status changes?) Output 193 triggers the relay to activate the garage door, and it works in other rules. Can anyone think of a creative workaround? I thought of turning on and off a dummy load device, but I don't have any available open loads.

[Michel Kohanim]

Hello snhroc,

 

Scene statuses are also sent to ELK. What version of ELK do you have?

 

With kind regards,

Michel

Is the Elk still not aware of scene updates? I'm trying to use a KPL button to reflect Garage door state, and to close or open the garage door.. basically the KPL button is a scene controller/responder for Scene "Garage Bay 1"

 

21 WHENEVER Garage Bay 1 (Zn 9) BECOMES NOT SECURE

THEN TURN Garage Bay 1 [120 (H8)] ON,

23 WHENEVER Garage Bay 1 (Zn 9) BECOMES SECURE

THEN TURN Garage Bay 1 [120 (H8)] OFF,

 

The above rules work fine to indicate on the KPL button whether the garage door is open or closed

 

25 WHENEVER Garage Bay 1 [120 (H8)] IS TURNED OFF BY SOME EXTERNAL DEVICE

THEN TURN Output 193 ON FOR 2 SECS

 

However, the above rule doesn't work (because the Elk doesn't recognize scene status changes?) Output 193 triggers the relay to activate the garage door, and it works in other rules. Can anyone think of a creative workaround? I thought of turning on and off a dummy load device, but I don't have any available open loads.

[snhroc]

5.1.8

 

Hello snhroc,

 

Scene statuses are also sent to ELK. What version of ELK do you have?

 

With kind regards,

Michel

Is the Elk still not aware of scene updates? I'm trying to use a KPL button to reflect Garage door state, and to close or open the garage door.. basically the KPL button is a scene controller/responder for Scene "Garage Bay 1"

 

21 WHENEVER Garage Bay 1 (Zn 9) BECOMES NOT SECURE

THEN TURN Garage Bay 1 [120 (H8)] ON,

23 WHENEVER Garage Bay 1 (Zn 9) BECOMES SECURE

THEN TURN Garage Bay 1 [120 (H8)] OFF,

 

The above rules work fine to indicate on the KPL button whether the garage door is open or closed

 

25 WHENEVER Garage Bay 1 [120 (H8)] IS TURNED OFF BY SOME EXTERNAL DEVICE

THEN TURN Output 193 ON FOR 2 SECS

 

However, the above rule doesn't work (because the Elk doesn't recognize scene status changes?) Output 193 triggers the relay to activate the garage door, and it works in other rules. Can anyone think of a creative workaround? I thought of turning on and off a dummy load device, but I don't have any available open loads.

[Michel Kohanim]

Hi again,

 

I know for a fact that 5.1.8 has a bug where your lights might turn on/off by themselves but I am not aware of any other issues. May I humbly suggest contact ELK. They are excellent in finding issues and resolving them.

 

With kind regards,

Michel

5.1.8

 

Hello snhroc,

 

Scene statuses are also sent to ELK. What version of ELK do you have?

 

With kind regards,

Michel

Is the Elk still not aware of scene updates? I'm trying to use a KPL button to reflect Garage door state, and to close or open the garage door.. basically the KPL button is a scene controller/responder for Scene "Garage Bay 1"

 

21 WHENEVER Garage Bay 1 (Zn 9) BECOMES NOT SECURE

THEN TURN Garage Bay 1 [120 (H8)] ON,

23 WHENEVER Garage Bay 1 (Zn 9) BECOMES SECURE

THEN TURN Garage Bay 1 [120 (H8)] OFF,

 

The above rules work fine to indicate on the KPL button whether the garage door is open or closed

 

25 WHENEVER Garage Bay 1 [120 (H8)] IS TURNED OFF BY SOME EXTERNAL DEVICE

THEN TURN Output 193 ON FOR 2 SECS

 

However, the above rule doesn't work (because the Elk doesn't recognize scene status changes?) Output 193 triggers the relay to activate the garage door, and it works in other rules. Can anyone think of a creative workaround? I thought of turning on and off a dummy load device, but I don't have any available open loads.