Motion Sensor II question

[JSchumann]

I installed my Motion Sensor II when I had older v4 firmware installed.  Since then I moved to V5.0.15.  Now my Motion Sensor II shows up as Insteon Motion Sensor v.00, Is there a way to update it to Motion Sensor II or do I have to uninstall it and reinstall?

Note, my older motion sensors show up as v.41

Thanks,

John

[HABit]

I had to remove MSII's from ISY and relink to use all of the features (many which do not work as you'd expect due to the haphazard design/documentation/something?? of SmartLabs).

I actually had to do a device reset on the MSII's because they had problems such as poor sensitivity, or other errata.

ASFAIK the Low Battery node, never notifies the ISY (sends command code). You can write a program that detects the Motion On command and then perform a brief wait (I use from 2 to 5 seconds depending on where the MSII is installed), and then Query the MSII. You can store the MDII "Battery Level %" in a variable and use it to detect low battery status. However, this too is not always accurate, so I do a wait 49 hours in the Low Battery detection program, before sending a push alert. The Luminance value seems the least reliable (my results), so I don't use.

Here's a sample program I use:

[larryllix]

28 minutes ago, SeeGreen said:

I had to remove MSII's from ISY and relink to use all of the features (many which do not work as you'd expect due to the haphazard design/documentation/something?? of SmartLabs).

I actually had to do a device reset on the MSII's because they had problems such as poor sensitivity, or other errata.

ASFAIK the Low Battery node, never notifies the ISY (sends command code). You can write a program that detects the Motion On command and then perform a brief wait (I use from 2 to 5 seconds depending on where the MSII is installed), and then Query the MSII. You can store the MDII "Battery Level %" in a variable and use it to detect low battery status. However, this too is not always accurate, so I do a wait 49 hours in the Low Battery detection program, before sending a push alert. The Luminance value seems the least reliable (my results), so I don't use.

Here's a sample program I use:

The MS II interface was a hack by UDI, as Insteon would not come forth and supply one after years of requesting, and Insteon users had no other source of MSes.

Meanwhile, UDI has become frustrated and wanted to remove all support for the messy unit. They didn't after users not having anything else.
We were also advised not to rely on any of the side parameters due to lack of accuracy that fluctuates with different usages. My temperatures jump all over the scale with different operations.

Do not be surprised if querying the MS II causes your ISY to hang. It does mine at times. Known problem with the ISY/MS II hack.

I am thinking of just sending money to China instead of a MIA company.  Maybe they will have all the new Insteox products in waiting.

 

 

Edited June 27, 2020 by larryllix

[simplextech]

10 minutes ago, larryllix said:

I am thinking of just sending money to China instead of a MIA company.  Maybe they will have all the new products in waiting.

Aren't we all already... except the MIA company part...  You send money to SmartHome who's products are made in China... so... same thing.  Except if you bought it directly from the manufacturer you'd probably get support.

Only good thing I have to say about the MSII is the ability to use the "On-Only" feature and linked to a switch.  That's it.  Wrap that in program to make logic decisions on when to turn off and call it a day.  Nothing else about the MSII worked correctly for me.  Glad I got rid of them!

 

[HABit]

10 minutes ago, larryllix said:

The MS II interface was a hack by UDI, as Insteon would not come forth and supply one after years of requesting, and Insteon users had no other source of MSes.

Meanwhile, UDI has become frustrated and wanted to remove all support for the messy unit. They didn't after users not having anything else.

I know UDI has pulled out their hair trying to resolve the problems with the MSII's. Unfortunately, unless one uses Zwave devices (I gave up trying since living in a cinder block house is a killer for all RF), there are few viable alternatives.

14 minutes ago, larryllix said:

Do not be surprised if querying the MS II causes your ISY to hang. It does mine at times. Known problem with the ISY/MS II hack.

This has never happened to my MSII's so far (anything possible I guess). Do you have a link to this issue, or point me to it's been discussed.

[larryllix]

2 hours ago, simplextech said:

Aren't we all already... except the MIA company part...  You send money to SmartHome who's products are made in China... so... same thing.  Except if you bought it directly from the manufacturer you'd probably get support.

Only good thing I have to say about the MSII is the ability to use the "On-Only" feature and linked to a switch.  That's it.  Wrap that in program to make logic decisions on when to turn off and call it a day.  Nothing else about the MSII worked correctly for me.  Glad I got rid of them!

 

I have three of them and after testing in key locations, am slowly moving them to non-lighting locations. They seem to work well for just occupancy, and security applications.

IMHO they are more reliable for those applications, more compact, and work without batteries.

Getting real tired of hearing Insteon is going to launch "we-can't tell-you magic things, please stand-by, because we have a new CEO" every year since 2014, every year when the only thing we have seen is the MS II flop.

Edited June 27, 2020 by larryllix

[larryllix]

7 minutes ago, SeeGreen said:

I know UDI has pulled out their hair trying to resolve the problems with the MSII's. Unfortunately, unless one uses Zwave devices (I gave up trying since living in a cinder block house is a killer for all RF), there are few viable alternatives.

This has never happened to my MSII's so far (anything possible I guess). Do you have a link to this issue, or point me to it's been discussed.

You would have to search the forum, just like I would. Look for a Michel Kohanim or my post about the MS II about 6 months ago. Maybe "remove", "discontinue", or "mistake" words.

Edited June 27, 2020 by larryllix

[HABit]

Yeah, my 2nd career: Searching ISY Forum. Yes have seen all of the aforementioned issues regarding awful MSII implementation and the flakey values received from it (do spend a lot of time looking back years at posts), but have never seen the ISY locking up issue you mention (wouldn't be surprised, but would like to know the mechanism of how the ISY "locks up").

You do make a good point about Insteon - I'm frustrated by an aging/old product set where known problems are not addressed, but only receive periodic "visions of grandeur" statements about how exciting/great our lives will be when the glory of the NEW Insteon is revealed. The problem I grapple with is: Will I care, or even still be alive when/if the shimmering light event occurs.

[larryllix]

2 hours ago, SeeGreen said:

Yeah, my 2nd career: Searching ISY Forum. Yes have seen all of the aforementioned issues regarding awful MSII implementation and the flakey values received from it (do spend a lot of time looking back years at posts), but have never seen the ISY locking up issue you mention (wouldn't be surprised, but would like to know the mechanism of how the ISY "locks up").

You do make a good point about Insteon - I'm frustrated by an aging/old product set where known problems are not addressed, but only receive periodic "visions of grandeur" statements about how exciting/great our lives will be when the glory of the NEW Insteon is revealed. The problem I grapple with is: Will I care, or even still be alive when/if the shimmering light event occurs.

IIRC I think the MS II goes into rapid Insteon packet flooding after a query. I am not sure I have experienced that but found ISY acting very strangely after MS II query. Can't rember the symptoms now. The parameters received were always garbage anyway.

[JSchumann]

4 hours ago, SeeGreen said:

I had to remove MSII's from ISY and relink to use all of the features (many which do not work as you'd expect due to the haphazard design/documentation/something?? of SmartLabs).

I actually had to do a device reset on the MSII's because they had problems such as poor sensitivity, or other errata.

ASFAIK the Low Battery node, never notifies the ISY (sends command code). You can write a program that detects the Motion On command and then perform a brief wait (I use from 2 to 5 seconds depending on where the MSII is installed), and then Query the MSII. You can store the MDII "Battery Level %" in a variable and use it to detect low battery status. However, this too is not always accurate, so I do a wait 49 hours in the Low Battery detection program, before sending a push alert. The Luminance value seems the least reliable (my results), so I don't use.

Here's a sample program I use:

Thanks SeeGreen, looks like I have a new mission!

 

John

[larryllix]

5 hours ago, SeeGreen said:

I know UDI has pulled out their hair trying to resolve the problems with the MSII's. Unfortunately, unless one uses Zwave devices (I gave up trying since living in a cinder block house is a killer for all RF), there are few viable alternatives.

This has never happened to my MSII's so far (anything possible I guess). Do you have a link to this issue, or point me to it's been discussed.

 

[kclenden]

6 hours ago, larryllix said:

We were also advised not to rely on any of the side parameters due to lack of accuracy that fluctuates with different usages.

 

6 hours ago, SeeGreen said:

The Luminance value seems the least reliable (my results), so I don't use.

My experience with Luminance has been good, but I'm probably using it differently than you.  I have my MSII setup to only signal motion at night.  That has worked perfectly for me.  In the MSII options you can set the Luminance Level that represents Night.  To figure out what level should represent Night, when I first install a MSII in a location, I have a program that queries Luminance every time motion is detected.  If the MSII signals motion and I don't think it's dark enough to be Night, I adjust the MSII Night Level option.  Once I have the Night Level set where it only signals Night when I think it's night, I quit querying the MSII for Luminance.  So in my experience, the MSII internal use of Luminance Level seems to be very reliable, even if the Luminance Level it reports when queried by the ISY isn't reliable.  But I'm just one data point.

[larryllix]

3 hours ago, kclenden said:

 

My experience with Luminance has been good, but I'm probably using it differently than you.  I have my MSII setup to only signal motion at night.  That has worked perfectly for me.  In the MSII options you can set the Luminance Level that represents Night.  To figure out what level should represent Night, when I first install a MSII in a location, I have a program that queries Luminance every time motion is detected.  If the MSII signals motion and I don't think it's dark enough to be Night, I adjust the MSII Night Level option.  Once I have the Night Level set where it only signals Night when I think it's night, I quit querying the MSII for Luminance.  So in my experience, the MSII internal use of Luminance Level seems to be very reliable, even if the Luminance Level it reports when queried by the ISY isn't reliable.  But I'm just one data point.

I don't use the luminance but I just may use it on one unit now. I am thinking of an algorithm to keep the lighting in my Gathering Room constant. We have some overcast days where the luminance varies greatly in the room and I was going to use outside Tags for that. I have an MS II in that room that is only used for occupancy detection, and not lighting, so it may work well. Now I must try it.
Thanks.

Edited June 28, 2020 by larryllix

[HABit]

On my sample program above, if you notice values that are are inconsistent, you may want to inset a wait n seconds (1 or more), after the Query MSII command, to allow the MSII to respond and the ISY to update its Node values for the MSII, before saving to vars.

@kclenden Thanks for your input. I really have wanted to get an ambient light detection node in some of the areas where I have the MSII’s installed, but have found that the actual values “wander” around inconsistently, so Luminance has been so far, unusable for me. Typically, I use ambient light levels to determine when it’s appropriate to augment lighting in an area. So when the Luminance value falls below some threshold, the HA system either initiates, or allows (from motion, etc), area lighting. After reading Michel’s trials with the MSII, and declaration that its operation was haphazard (not motion, only peripheral sensors), I determined that I would have to qualify all readings from the MSII to see if useable. I think next I’ll try some sort of smoothing of data values, rejecting outlier data within some period.

Would you mind telling what version your sensors are? I have found varying quality of the MSII’s with some requiring repeated factory resets before they become functional. Perhaps that’s what is being observed with these little troublemakers.

@larryllix Thanks for that link. Oddly, I’ve never had that failure with the MSII’s yet. I have seen it with one of my older MS1’s. Looking at the error log I see an entry with 0’s running off the edge of the log (assuming here the device has gone into “insane” mode and is repeatedly transmitting garbage). Unfortunately, it has reliable Dark detection, so have been reluctant to replace it.

[larryllix]

8 minutes ago, SeeGreen said:

On my sample program above, if you notice values that are are inconsistent, you may want to inset a wait n seconds (1 or more), after the Query MSII command, to allow the MSII to respond and the ISY to update its Node values for the MSII, before saving to vars.

@kclenden Thanks for your input. I really have wanted to get an ambient light detection node in some of the areas where I have the MSII’s installed, but have found that the actual values “wander” around inconsistently, so Luminance has been so far, unusable for me. Typically, I use ambient light levels to determine when it’s appropriate to augment lighting in an area. So when the Luminance value falls below some threshold, the HA system either initiates, or allows (from motion, etc), area lighting. After reading Michel’s trials with the MSII, and declaration that its operation was haphazard (not motion, only peripheral sensors), I determined that I would have to qualify all readings from the MSII to see if useable. I think next I’ll try some sort of smoothing of data values, rejecting outlier data within some period.

Would you mind telling what version your sensors are? I have found varying quality of the MSII’s with some requiring repeated factory resets before they become functional. Perhaps that’s what is being observed with these little troublemakers.

@larryllix Thanks for that link. Oddly, I’ve never had that failure with the MSII’s yet. I have seen it with one of my older MS1’s. Looking at the error log I see an entry with 0’s running off the edge of the log (assuming here the device has gone into “insane” mode and is repeatedly transmitting garbage). Unfortunately, it has reliable Dark detection, so have been reluctant to replace it.

I have not experienced that "insane mode" that I know of but I have seen random garbage come out of one MSII for temperature. The scary part is they are inconsistent between different units and even from one time to the next.

Hopefully, MSIIs work with Insteon Hubs, giving hope that UDI will get it figured out one day and we can have at least one Insteon MS we can trust.

[HABit]

I have an Insteon Hub I got a while back when the MSII’s were first released, just so I could use it to setup the MSII’s. After I initially updated the ISY to v5.x and tried to re-link the MSII’s as the 2844, many failed and then stopped working. I used the Hub to attempt resetting the MSII’s to operable states (unfortunately did not work). Ultimately I determined (with hints from the many sojourner’s here on the Forum), I needed to do factory resets on the MSII’s, sometimes several times, to be able to link to the ISY. I think there is much unknown about the MSII, what the Hub does when it “installs” one into the Hub, etc. I have also come to suspect that some of these things are hacks to “fix” the design flaws in the MSII’s.

My experience is that the MSII’s work pretty well for motion detection. I have seen problems with sensitivity issues (ie MSII turning on after delay even though targets in close/direct proximity to the MSII). The MSII’s that have this issue don’t seem to be redeemable even with multiple factory resets and repeated re-links to ISY (the ISY has nothing to do with the issue other than it is enrolling the device). 

I have become convinced that Insteon used a PIR processing chip (tiny micro) with multiple sensors, and have actually found a couple of candidates that might have been used in the design. These chips perform certain processing tasks such as digital integration for ambient light, PIR temperature compensation, etc. but have to be understood before hacking out a solution using same. The result is I believe, what we have now. Unfortunately, if implemented properly, the MSII could have been a really great addition to the Insteon device line. So perhaps Insteon will give us the “Glorious Shining Moment” we are all hoping for, and re-establish itself as a viable HA device vendor. Time will tell (but not too much time...).

[larryllix]

MSIIs are not good for light operations due to not supporting retriggerable signals.

They appear to support a retriggerable timer internally, but they do not inform external devices of the retrigger.  This doesn;t work for ISY994 and other HA central control systems. Insteon appears to have created this to support the Insteon system devices and defy HA systems.

MSIIs have another problem. The internal reset timer is the same internal timer used for the time-on timer (mentioned above). What this means is that once the internal timer expires from lack of motion detected, the MSII cannot send another On signal as long as it detects motion. Whether you require the external retriggered MS signal for HA, or not, you are going to have a period of dark time (no lights on) as long as the same lights on timer is set to. If you continue to move around the room, the lights will never come back on until you stop all motion for the timer time.

Complete design fail. ISY is not the only system that will not work nicely with these units. I suspect Insteon doesn't want UDI to survive, and this is just one more clue.

[gzahar]

On 6/28/2020 at 11:41 AM, larryllix said:

MSIIs are not good for light operations due to not supporting retriggerable signals.

They appear to support a retriggerable timer internally, but they do not inform external devices of the retrigger.  This doesn;t work for ISY994 and other HA central control systems. Insteon appears to have created this to support the Insteon system devices and defy HA systems.

MSIIs have another problem. The internal reset timer is the same internal timer used for the time-on timer (mentioned above). What this means is that once the internal timer expires from lack of motion detected, the MSII cannot send another On signal as long as it detects motion. Whether you require the external retriggered MS signal for HA, or not, you are going to have a period of dark time (no lights on) as long as the same lights on timer is set to. If you continue to move around the room, the lights will never come back on until you stop all motion for the timer time.

Complete design fail. ISY is not the only system that will not work nicely with these units. I suspect Insteon doesn't want UDI to survive, and this is just one more clue.

I won't say that I understand the intricacies of the MSII and it's timers enough to completely grasp what you are trying to convey (mainly I don't want to think that hard!), BUT I will say that I am using the MSII (under USB power) to trigger and keep a light on and it is working fine for me.  If I stand still long enough (or hide) the lights will go off and they turn back on after I move around again.  Also I do use 2 of them in the area to cover spots that can't be seen by the other and they are USB powered as I mentioned; so maybe that makes a difference.  Happy to share any settings or programs (that I stole/modeled from examples on the forum) if that helps.

Edited June 29, 2020 by gzahar

[lilyoyo1]

57 minutes ago, larryllix said:

Complete design fail. ISY is not the only system that will not work nicely with these units. I suspect Insteon doesn't want UDI to survive, and this is just one more clue.

I highly doubt this is a conspiracy of insteon to see to UDI's demise. In fact it hurts them more since UDI is a large part of their consumer base. Having those users unhappy doesn't serve them well in any capacity. All that would do is make them use devices from a competitor. Being that one would need a strong mesh, that means additional devices from zwave instead of insteon.

Their issue is short-sightedness. They make insteon only for themselves vs involving other companies in the process to ensure products work in full with other controllers.

[larryllix]

41 minutes ago, lilyoyo1 said:

I highly doubt this is a conspiracy of insteon to see to UDI's demise. In fact it hurts them more since UDI is a large part of their consumer base. Having those users unhappy doesn't serve them well in any capacity. All that would do is make them use devices from a competitor. Being that one would need a strong mesh, that means additional devices from zwave instead of insteon.

Their issue is short-sightedness. They make insteon only for themselves vs involving other companies in the process to ensure products work in full with other controllers.

Especially since a current  Insteon company officer, formerly posting here, worked for the UDI that Insteon isn't aware of.

...and Insteon pulled the rug out from under UDI with their own PLM development. After years of interactions they just didn't remember they made any arrangements with UDI, and co-incidentally just as Insteon  thought Apple was going to get into bed with them and make them industry giants?

"You can fool some of the people....

Edited June 28, 2020 by larryllix

[redridge]

This is a good read.  I have to say I have one down in our shared condo garage that works flawlessly ....... on it's own, sitting on a storage cabinet.  The neighbors love it as our building has a flawed lighting scheme where the common garage interior's are off all day.  When I go into the garage to work for any time at all I take it off the storage cabinet and dis-able it with the on-board button, otherwise I have to move to keep the lights on!   Since my buttons in our main entry hall (3 floors up) and master bedroom are responders from the load it controls they follow and control the load which is fine, but I too could not get anywhere with this thing, AND/OR the door transmitter.   I plan to add some 5800 series wireless sensors down there that will better integrate with the ISY via the Vista 128 alarm panel and my precious AHC X10 IR receiver.(lol)

Edited June 28, 2020 by redridge

[HABit]

Larry, you make a good point about the retriggerable nature of the MSII. As long as the MSII keeps detecting motion within its timeout period, it will reset its counter/timer for re-arming. This effectively suppresses initiating any additional On messages being issued. Typically I try to set the re-arm (time out) time as short as possible And only have the MSII sent On commands, using an ISY program/timer to provide a light (or device) turn-off. If additional On commands are received from the MSII, the ISY timer value is reset, so the on-time is extended. However, as you point out, the problem with that is if the  MSII is internally retriggered by motion, the subsequent On commands never come to reset the ISY timer. Fortunately, after having studied the problem, typically the opposite action occurs, which is people are doing some stationary thing and no detection occurs by the MSII. This is as bad since then the lights/etc. will turn off. Then it becomes a game of adjusting the timeout value of the MSII to optimize the detection in a particular zone.

I can’t comment on corporate cultures or motives, but I can offer an experienced guess (having run development programs in my dim, dark past), regarding why the MSII has this unfortunate characteristic. I believe it was a failure on the part of the Project Manager/Team/ Leader/whomever to recognize who the core customers of  Insteon are. They determined (or were told to do this), that what customers desired was a Popeil-like motion switch that would turn a light on, keep it on for as long as motion was detected, and then shut off. Great, but unfortunately serious integrators are then challenged with utilizing the MSII in a more sophisticated HA implementation. If they had given control over whether the MSII automatically retriggered, or just timed out and sent additional On commands, then this problem would be reduced. Unfortunately I have participated in development projects where Marketing is breathing down the Engineering team’s necks, told to do things that we did not want to do, and then later taken heat for it working that way, after product release.

If you are using the MSII in the context of how it was designed then it is a great device for stand alone operation. I have one in the laundry room. The ISY knows it’s Responder is on/off, but the MSII’s main function is just to turn on the lights (Using a Scene), and keep them on as long as someone is present (longer timeout and retriggerable time periods = excellent performance). However, note the absence of any ISY interaction. 

[lilyoyo1]

1 hour ago, larryllix said:

Especially since a current  Insteon company officer, formerly posting here, worked for the UDI that Insteon isn't aware of.

...and Insteon pulled the rug out from under UDI with their own PLM development. After years of interactions they just didn't remember they made any arrangements with UDI, and co-incidentally just as Insteon  thought Apple was going to get into bed with them and make them industry giants?

"You can fool some of the people....

Insteon was always aware that he worked for udi. When insteon asked him to come back, his being able to continue to work on his own projects and udi was part of his terms and in his contract. With that said, he's no longer with insteon at this time.

The plm fiasco had nothing to do with that person. As I said before, short sighted decision making. It's this decision making that made them jump in bed with apple in the first place and almost bought the company down. That single decision is the main reason why JD ended up needing to sell the company.

[larryllix]

2 hours ago, SeeGreen said:

Larry, you make a good point about the retriggerable nature of the MSII. As long as the MSII keeps detecting motion within its timeout period, it will reset its counter/timer for re-arming. This effectively suppresses initiating any additional On messages being issued. Typically I try to set the re-arm (time out) time as short as possible And only have the MSII sent On commands, using an ISY program/timer to provide a light (or device) turn-off. If additional On commands are received from the MSII, the ISY timer value is reset, so the on-time is extended. However, as you point out, the problem with that is if the  MSII is internally retriggered by motion, the subsequent On commands never come to reset the ISY timer. Fortunately, after having studied the problem, typically the opposite action occurs, which is people are doing some stationary thing and no detection occurs by the MSII. This is as bad since then the lights/etc. will turn off. Then it becomes a game of adjusting the timeout value of the MSII to optimize the detection in a particular zone.

<snipped>

If you are using the MSII in the context of how it was designed then it is a great device for stand alone operation. I have one in the laundry room. The ISY knows it’s Responder is on/off, but the MSII’s main function is just to turn on the lights (Using a Scene), and keep them on as long as someone is present (longer timeout and retriggerable time periods = excellent performance). However, note the absence of any ISY interaction. 

You missed the other part of the retriggerable timer. That same timer is used to time the off cycle of the MSII also. That means until you stop all motion the timer will never expire and the MSII will  never send another On signal to turn on the lights. IOW: It's algorithm is just plain defective.  I have walked around in the dark, middle of the night too many times with this MSII, now. I didn't want to stay with a SH Hub, or be a slave to Insteon's simple timer HA logic. Now that ISY has features to interfere with Insteon scenes, there may be more avenues yet.
This may have something to do with the "block sending off commands" and I forget my results, when I tested that aspect. I may not even have tested that aspect.  

I like ISY to control as much as I can and avoid scenes whenever possible. Getting the speed of light response from a MS is one place I cannot avoid scenes though and one of the best parts of Insteon devices. If Zwave were not so slow, I may have switched to that system when the MS1 first died. I have a stock of MS1s now, though.

I have one in my laundry room also due to USB power and saving a battery there. Again there are times when you stand in the dark until you manually override the MSII. Usually it is good if you only enter every 5-10 minutes or longer, each time.

[lilyoyo1]

2 minutes ago, larryllix said:

You missed the other part of the retriggerable timer. That same timer is used to time the off cycle of the MSII also. That means until you stop all motion the timer will never expire and the MSII will  never send another On signal to turn on the lights. IOW: It's algorithm is just plain defective.  I have walked around in the dark, middle of the night too many times with this MSII, now. I didn't want to stay with a SH Hub, or be a slave to Insteon's simple timer HA logic. Now that ISY has features to interfere with Insteon scenes, there may be more avenues yet.
This may have something to do with the "block sending off commands" and I forget my results, when I tested that aspect. I may not even have tested that aspect.  

I like ISY to control as much as I can and avoid scenes whenever possible. Getting the speed of light response from a MS is one place I cannot avoid scenes though and one of the best parts of Insteon devices. If Zwave were not so slow, I may have switched to that system when the MS1 first died. I have a stock of MS1s now, though.

I have one in my laundry room also due to USB power and saving a battery there. Again there are times when you stand in the dark until you manually override the MSII. Usually it is good if you only enter every 5-10 minutes or longer, each time.

I have a couple of their motion sensors and not once have I had an issue with them timing out or re-triggering. Granted I use programs vs direct linking which may have something to do with things. From my personal experience with them, they work well for being a motion sensor but not for anything else.