Elk Command Delay for Insteon

[Smarty]

Folks,
I have read the thread that spoke of how when turning on a series of Insteon lights, that by adding a 1-2 second delay you increase the reliability of turning the lights on.

My question is: how is this accomplished through the Elk programming? Something about using "Phantom Outputs", but how EXACTLY?

Thanks

 

[Mike]

Something like this?

(there may be a better way to do this but you mentioned phantom outputs, which was recommended by Spanky in another case, which is what I am showing):

WHENEVER THE TIME IS 8:00 PM THEN
THEN TURN Outside, Front [1 (A1)] OFF, FADE RATE = 0
THEN TURN Output 100 ON FOR 1 MIN


WHENEVER Output 100 STATE IS TURNED OFF
THEN TURN Outside, Back [1 (A2)] OFF, FADE RATE = 0

Obviously the time delay would be changed, but that is the concept being referenced.

 

[WayneW]

WHENEVER THE TIME IS 8:00 PM THEN
THEN TURN Outside, Front [1 (A1)] OFF, FADE RATE = 0

You are aware that "Fade Rate" isn't supported for Insteon yet, correct? Does it work for you?

 

[Smarty]

Thanks Mike.

Wayne....I have fooled with fade rate at all. I had read that it was NOT suported.

Thanks

 

[Smarty]

Hold on.....Multiple Whenever's CANNOT be used within one rule. What am I missing?

 

[Mike]

The rule puts it in. I have not tried, nor expected fade to work.

Sorry it was not intended to be one rule, I'll edit it to make that clearer.

 

[Spanky]

I talked with the Insteon Guru about the transmission timing on the M1. Currently it is set to 1/2 second between transmissions of multiple devices. The M1XSP buffers two light commands.

The problem is that if the first command does not go through and get an ACK back to the M1XSP, the command is repeated 5 times. Repeating the command causes light command 3 to not have buffer space to be stored and may be lost. Adding delay between light commands allows for any one light command to fail and be retried without affecting subsequent light commands.

Things that help:
Send light commands in groups of 2.
Send a Group Light command followed by individual on/off/dim commands.
Add delay with unused outputs for delay between light commands.
Make sure you do not have any dead switches that cause multiple retries.


Need your opinion:
Would you rather see more delay added between light commands, say 2 seconds, to guarantee any failure retries have completed or stay with 1/2 second between light commands.


Other fixes are in the works, but will take time to implement.

 

[Mike]

What about a pause command? Then the number could be tweaked based on individual circumstances. I'm thinking some will be happy and others not on changing the delay. There is probably a good reason why this doesn't already exist however.

Personally, if it makes it reliable it seems reasonable. I'm only using mine for some basic situations currently though.

 

[Smarty]

I think Mike has a good notion.

A "tuneable" pause delay would add flexability. The default for it could be set for like 2.0 seconds (a longer time) to insure maximum reliability. Then, you could "tune" to shorten the pause (as you watched for reliability issues).

 

[Digger]

Spanky......

Your post of today explained away some of the problems I am having. My 3rd, 4th commands are the ones that are lost when I tell a group of lights to go on or off. I never realized why until you gave that explanation.

Thanks for the info!!

 

[elcano]

Spanky......

Your post of today explained away some of the problems I am having. My 3rd, 4th commands are the ones that are lost when I tell a group of lights to go on or off. I never realized why until you gave that explanation.

Thanks for the info!!

Digger/Spanky

May I assume that commands 1st and 2nd are received properly by the dimmers/switches, but the acknowledgement is not received back by the controller? This is the only explanation for it to continue resending the command, right?

My point is that the communication is working one way, but not the other. There is something fishy here, dont you think? I mean, in addition to the buffering issue.

 

[Digger]

Elcano,

I have rules written to turn off individual lights when I arm way and its daylight out to save energy. I also have rules written that if there is a Fire Alarm to turn on lights so its easier to find the way out and help wake up kids etc.

So what happens is that I arm away and a couple lights go out but not all. Disarm and try again and the same thing. Disarm yet again and maybe the next light in the rule sequence will go out. Even if all of the lights are out except the last it still has to go through the sequence and get acknowledgements. I didnt realize why this was happening until Spanky's post.

Now why is this happening. It seems to be "Noise" from what I can tell. When I removed some CFL's it got much better. I still miss commands but not nearly as much.

Now if I stagger the off commands then it should send one and acknowledge, send the next and acknowledge etc etc. If necessary it might buffer one ocasionally. I would not care if it took 10 seconds to turn off 5 lights in the situation I described above since it is for energy savings.

 

[rcharris]

Spanky:

I think a lot of us would like to see a "Pause" command for rules for this as well as other automation purposes. A programmable pause would be ideal.

Regards,
Rod

 

[pkoslow]

My M1 and serial port expander have been servicing UPB lighting for the last few months and yeterday I reflashed it for Insteon. I tried M1/Insteon within a couple days of the firmware becoming available and then converted to UPB testing the very next day.

It's been about 3 months and I haven't seen any updates on the problem with sending multiple lighting commands in a single rule. How many of you are using Insteon reliably with your ELK and are you using the phantom output timers to overcome this issue?

If I understand correctly, to use this workaround will require creating a phantom output device for EACH light to work properly? If so, this seems like it will quickly get cumbersome and difficult to use when creating complex rules that control lots of lights!

Am I mis-interpreting how to implement the workaround, or is it really not that big of a deal? I'd much prefer to have slower lighting changes with a couple seconds between commands than have to monkey with all the phantom outputs and timers.


Any progress or feedback on this from the ELk camp?

Thanks,
Paul

 

[WayneW]

My workaround has been to use groups, Elk lighting IDs above 192. So I have 193 for what comes on at sunset regardless of occupancy, 194 for what comes on 1 minute after sunset if we are home or when we come home, 195 for some other scene, etc. I use PowerHome to configure this.