When does Insteon motion sensor take the timeout setting?

I want to set the timeout "on the fly" to the Insteon motion sensor, using the plugin "set motion sensor timeout", but it does not seem to take it.
Under certain circumstances I'd send a very short timeout and others about 20 minutes.
When does the device take the command? I know that when you sync up originally to the device to add it to the list you have to manually press the set button but I did not think you would need to do it in this case since it was in an operating mode and not a setup mode.

So I guess I'm asking when does the Motion sensor acknowledge the "set motion sensor timeout"?
I have jumper 5 set.

Thanks,

Dave

[jay (support)]

The motion sensor has to be awake in order to receive any command.

The precise answer is "when it's not in sleep mode." The INSTEON motion sensors will accept configuration commands immediately (within about 0.2 to 0.3 seconds) after sending out any ON or OFF command to an INSTEON responder. After that 0.2 to 0.3 seconds, they go back in to sleep mode and do not respond to any commands. So, the only way to send configuration commands to an INSTEON motion sensor without pressing the SET button is to create a trigger that activates on any command from the target motion sensor then sends the configuration command to that sensor. This technique works, but is not highly reliable because often times there will be other INSTEON traffic that will delay your configuration command from getting to the motion sensor before it goes back into sleep mode, causing the configuration command to fail. In the testing I've done, it often takes numerous repeated attempts to send configuration commands (thus, multiple ON or OFF changes later) to a remote motion sensor before it receives it correctly. I'd say the reliability of this technique is not high enough to use for per-motion-detection events.

If you want the motion OFF actions to be conditionally delayed, set the motion sensor to the shortest timeout value you'll ever need (I set mine to 30 seconds) and use Indigo triggers to perform the actions needed after an OFF command is received, delaying the actions by the appropriate time based on your conditions. Be sure that your Indigo triggers for the motion ON command use the "Remove Delayed Actions" action for the motion OFF triggers so that if motion is detected sometime after the motion sensor sent an OFF command, the subsequent ON command cancels the delayed OFF actions. I use this technique for all of my motion activated lights in the house.

Thanks for the very useful information. I did not know about the short window of .2 to .3 seconds (should have been a little longer)
I really think they could have designed it better. I'm really quite disappointed in the Insteon Motion Sensor in general. I realize that they are trying to conserve battery power but they could have had some "keep alive" timing that would produce a window of time to set things instead of actually having the device trigger from something.
Also , if I'm not mistaken, it only sends out the low battery indication once until the battery is dead. That is just not good practice. They could of at least send the condition out when it was triggered when in a low battery condition.

I have 30 or so Insteon motion sensors and about 150 other Insteon devices. The reason I don't set the motion sensors to a short delay (30 seconds) is due to high traffic. This can cause missed events and too much delay to turn on a light if controlled by Indigo.

I might try the short window trick but like you said it would not be a 100% solution.

Hopefully someone comes up with a motion sensor that performs better, but until then I'll have to cope with the current model.

Thanks again.

Dave

Glad the info was helpful.

I have 30 or so Insteon motion sensors and about 150 other Insteon devices. The reason I don't set the motion sensors to a short delay (30 seconds) is due to high traffic. This can cause missed events and too much delay to turn on a light if controlled by Indigo.

Yes, with that many motion sensors and other devices, a 30 second timeout would cause quite a bit of traffic and I imagine cause any number of issues. With only 13 motion sensors and a total of 53 INSTEON products in my setup, it seems the INSTEON network is nearing its limits in terms of speed, especially if there are more than 2 people moving around in the house. It doesn't help that the motion sensors are "chatty" and send out more INSTEON traffic per message than most INSTEON devices (probably to ensure that each responder receives the message, but it's still congestive to the network).

Though I haven't done so myself yet (and I have no experience with Z-Wave), you might try switching over to Z-Wave motion sensors. It would be a costly migration, but you could do it one sensor at a time and it'd give you a good idea of how the Z-Wave motion sensors compare to the INSTEON ones. I suspect they're more reliable, and if I remember correctly, they do use regular "check-in" intervals to allow for attached devices (like your computer Z-Wave interface) to send configuration updates.

[jay (support)]

I don't believe Matt's gotten to command queueing for the Z-Wave motion sensors yet (they also sleep but wake up at a specified interval to receive commands) but it's something we do want to implement.

So far, the Z-Wave devices seem much more robust in terms of network communication. We have seen some slowdowns when messages have to be routed multiple times between the source and destination, but I think in general most residential implementations won't have that many hops. Direct source to destination communication is extremely fast - significantly faster than INSTEON. And we believe signal collisions (the problem you're seeing with so many INSTEON devices) is handled a lot better with Z-Wave.

Temper that with the fact that we don't have a whole lot of Z-Wave experience yet and certainly not with the number of devices that you have - so we really don't know how it's going to scale. Our feeling is that it will be better but we don't have the anecdotal evidence to prove it yet.

It might be worth a try though - you can get a Z-Stick and a motion sensor for about $120 so you'll have to decide for yourself if it would be worth it to do an experiment. You'd want to plan for them to be relatively close (~30-40 feet with just a few walls between) since they are your first two devices. Later you can add a routing slave (most hardwired devices route as well) to extend the reach of the network.

[matt (support)]

I don't believe Matt's gotten to command queueing for the Z-Wave motion sensors yet (they also sleep but wake up at a specified interval to receive commands) but it's something we do want to implement.

Z-Wave command queuing for sleeping modules does work currently with module configuration settings. So you can change the settings then the next time the module wakes up Indigo will push out the new changes. Note that with Z-Wave there is a special "I'm awake" message that is periodically sent, which is when Indigo writes the queued settings. You cannot just trip the motion sensor and have the queued commands sent at that time because the module goes back to sleep too fast and ignores incoming commands. But when it sends the "I'm awake" command it stays awake long enough for us to push the commanded that are queued up.

That's great. Nice to know about Zwave motion sensors. I will check them out shortly.


Dave