Time delay in between THEN instructions

[fleetz]

I have a number of rules that have multiple THEN lighting instructions. When the rule is fired typically 4 out of 5 lights are switched on sometimes only 3. The same thing happens when I switch them off however if I stagger the of times by a few seconds they will switch of reliably. What need to be able to do is put a time delay in between the THEN instructions, is this possible??

It appears that flooding the C-BUS data BUS with the salvo of on commands sees some missed and therefore staggering the on commands should see a reliable outcome. Is it possible within rules to do this??

Regards,

Fleetz

 

[Photon]

I have the same problem with my X10 switches. I ultimately redid my rules so the M1G addresses only one device at a time. I separate the rules' trigger times by at least one minute to keep it simple. Since additional THENs following a single trigger event count as additional rules, this apparently wastes no memory space.

I've seen no reliability issues with multiple OFF commands following a single trigger.

Regards. . . . John

 

[electron]

This is a crazy untested idea, but can you do something like "Then Turn LIGHT_A off for 1 seconds", "Then Turn LIGHT_B off for 2 seconds"? It all depends on if that rule triggers at all, as I do remember some stuff not executing if it is in that state already.

If that doesn't work, the only other way I can think of is to use a virtual output for each light, and do the same thing as in my previous example. Every time the light changes status, you would have to update the virtual output for that light, so the "Turn VIRTUAL_OUTPUT_A off for 1 seconds" would trigger. Once you control the outputs with timers, you would have to create another set of rules that would turn the light on whenever the virtual output is turned on (or off). This is pretty messy, but I think it could work.

 

[Spanky]

Lighting commands have an automatic 2 second delay when using X10 or the M1XSP Serial Expander. If OPT option flag in the lighting setup is checked then there is no delay.

In the case of C-bus, all the lighting commands are passed to the C-bus interface on Port 0 via RS-232.

If you want to add light delays, you will have to turn on a light and start an output timer. When the output timer runs out, turn on the next light and start a timer and so forth.

 

[LaurentR]

I had the same issue with my Zwave lights. If you send 4 commands back to back, the RZC0P dies, so I had to stagger them. I used Spanky's trick.
See picture attached of my first few rules:



Laurent

 

[fleetz]

Thanks Guys,

I have implimented the output timers and it has improved the reliablity a lot. Unfortunately it is still not 100% reliable even with 4 or 5 seconds on the output off timer which should be plenty of time to execute the lighting commands before the next one is timed to release it's command envairably these is always 1 that does't fire off (random) and as these lights time off which I have deliberately staggered there off times by 10 seconds or so from eachother intermtently one won't switch off as is the case to switch on.

I spent the best part of 4 hours just on experimenting with timing. Can't get repeatable results. Ness have it logged as number of folks here are experiencing the same thing as I said Ness and are working on it and I know will get to the bottom of it, thought I would spend the time with a work around in the interim but that doesn't look a happening thing.

I am just going to have to wait until Ness provide their C-Bus interface fix and go through the exercise again. It is not useable as is

Cheers,

Fleetz

 

[Spanky]

The problem we have seen on some lighting systems like Zwave is when multiple lighting commands are sent and one fails, retries are made and the next lighting command stomps on the command that is retrying. Adding more delay between the lighting commands allows for any retries to complete before the next lighting command is issued. If you have a marginal installation that requires a lot of retries, you will see missing lighting commands.

C-Bus has not taken off in the US so we do not have much experience yet. Ness Security in Australia designed the C-Bus interface to the M1 therefore they are the current C-Bus to M1 experts.

 

[Madcodger]

The problem we have seen on some lighting systems like Zwave is when multiple lighting commands are sent and one fails, retries are made and the next lighting command stomps on the command that is retrying. Adding more delay between the lighting commands allows for any retries to complete before the next lighting command is issued. If you have a marginal installation that requires a lot of retries, you will see missing lighting commands.

C-Bus has not taken off in the US so we do not have much experience yet. Ness Security in Australia designed the C-Bus interface to the M1 therefore they are the current C-Bus to M1 experts.

Spanky,

I understand the output timer solution, but in a new release it really would be handy to just create a simple "wait" function that pauses the sequence for the specified period of time, then allows it to continue. Would make Rules programming MUCH simpler.

 

[Spanky]

A THEN lighting command WAIT for X seconds would be possible. That would delay the next lighting command going out. Other rules would continue to operate.

 

[Madcodger]

A THEN lighting command WAIT for X seconds would be possible. That would delay the next lighting command going out. Other rules would continue to operate.

That would be helpful, and a nice addition to the next release. If you could do the same for outputs it would also be great, as I and others often turn on more than just lights (or multiple lights) by turning on an output.

For example:

Turn on Output 30
Wait 10 seconds
Turn on Output 31

etc...

Thanks,

Joe

 

[LaurentR]

The problem we have seen on some lighting systems like Zwave is when multiple lighting commands are sent and one fails, retries are made and the next lighting command stomps on the command that is retrying. Adding more delay between the lighting commands allows for any retries to complete before the next lighting command is issued. If you have a marginal installation that requires a lot of retries, you will see missing lighting commands.

Spanky, the thing I don't understand about the Zwave issue is that the RZC0P seems to have all the hook to make sure commands are properly flow-controlled and acknowledged, removing any possibility for collision and hanging in the case of commands that take too long. So why is the Elk having issues with these commands?

Laurent

 

[Spanky]

I believe the problem we have seen is that the flow control is not getting all the way back to the M1 from the RZCOP. We are looking into the issue.