ISY User Manual for Motion Sensor II (2844-222)

[lilyoyo1]

If you're needing multiple programs to ensure things are off, I would look at your communication and work towards fixing the issue. While that can work (and an easier fix) you could be creating a bigger headache since any communication that is happening will prevent other communication from happening at that moment. 

[JacktheRipper]

Quote

I was wondering if anyone would like to collaborate on a real manual for this thing?

idkayaker... Precisely my original intent when I started the thread, so I would be glad to help. There's a lot of insights sprinkled in the exchanges above, and boiling all that down to a coherent document would be great. Please feel free to make a draft and circulate it for community comment.

Quote

If you're needing multiple programs to ensure things are off, I would look at your communication and work towards fixing the issue.

lilyoyo1... I wish it were simple to first understand, and then correct, communications issues that interfere with Insteon operation, but it is not. While Insteon and ISY were a vast improvement over X10 when I first got into using them (circa 2004 or so), I have found them to be far from perfect. Modems seem to gradually lose robustness (I'm on my third one, just for my own house), Motion sensor sensitivity seems to degrade over time too, for both MS 1 and MS 2 sensors. Switch reliability has been a problem for me as well. I have two at the moment that occasionally report back that they have toggled state, but in fact they have not done so. That is not a communications issue, it's a device reliability issue. Sending repeated commands has helped. Some lessons I've learned over the years include...

(1) Get rid of 100% of your fluorescent devices, particularly the bulbs with built-in mini-ballasts. They simple put too much junk out on your wiring, which kills that avenue of Insteon robustness. I discovered this (duh) when I had some porch lights that could be turned on by an Insteon switch, but could not be turned off.

(2) Lamplincs don't operate very well with smaller led loads, such as small Christmas light strings. When the load is very small, it confuses the Lamplinc sense feature. Use on/off (relay-based) devices instead.

(3) Don't use LAN devices that transmit their traffic over your power lines. When I had solar put in a few years ago, the installer snuck of those systems in on me, and it killed my Insteon operation.

(3) Don't use (non-Insteon) three-way switches that communicate over your power lines.

Begs for a list that might be titled "The Top Ten Things You Can Do to Improve Insteon Reliability"...

 

[idkayaker]

Jack great advice from many hours of trouble shooting over many years. good list. so compact florescence are a no no

[larryllix]

3 hours ago, idkayaker said:

Jack great advice from many hours of trouble shooting over many years. good list. so compact florescence are a no no

The dimmable CFLs had better power supplies inside, same as the better LED bulbs. They can both cause problems, and with age, I suspect most of them, regardless of technology, will.

[idkayaker]

Id be curious to see what an O scope shows on a voltage wave form as CFL and LEDS are added.

[larryllix]

4 hours ago, idkayaker said:

Id be curious to see what an O scope shows on a voltage wave form as CFL and LEDS are added.

Others have tried it but without specialised filters and level controllers they don't show much as the magnitude of noise is small compared to AC waveform magnitudes. If any 2nd or 3rd order harmonics are introduced they can be really hard to discern with the human eye.  These harmonics can distort the relative time of the zero crossing which Insteon depends on for timing. Small amounts of noise on the "front-porch" of the zero crossings can confuse the small Insteon signal.

IIRC X10 used the AC waveform time just after zero crossing but electronic dimmers can switch on at those times, making a mess of X10 signals. Along comes Insteon using the other side of the zero crossing by timing from the previous crossing. Now LED, HID, and CFL ballasts can interfere with that area of the signal. 

Who ya' gonna' call?

[Brian H]

Though X10 related some can be applied to Insteon also. Jeff has a great set of troubleshooting tutorials. A few of them show noise from things like a cheap cell phone charger and some CFL bulbs. You may find some information that is helpful.

http://jvde.us/x10_troubleshooting.htm

I tried an o scope and as pointed out not much could be seen.  I have tried the circuit ELA posted. Using an ACT CP000 Isolating Phase Coupler. I used an X10 XPCP as ACT is out of business. The Insteon power line signal frequency is not that far away from X10. Both are tuned for. It worked fairly well with my low end scope. Have not tried the new one I now have.

Edited December 16, 2019 by Brian H
Add information

[idkayaker]

6 hours ago, Brian H said:

Though X10 related some can be applied to Insteon also. Jeff has a great set of troubleshooting tutorials. A few of them show noise from things like a cheap cell phone charger and some CFL bulbs. You may find some information that is helpful.

http://jvde.us/x10_troubleshooting.htm

I tried an o scope and as pointed out not much could be seen.  I have tried the circuit ELA posted. Using an ACT CP000 Isolating Phase Coupler. I used an X10 XPCP as ACT is out of business. The Insteon power line signal frequency is not that far away from X10. Both are tuned for. It worked fairly well with my low end scope. Have not tried the new one I now have.

Waoo!! Brian nice, are u a EE or is this strictly an avocation. I can tell you from experience trouble shooting communication issues like this can be a trying time. I do have professional horror stories. I see you are from east CT. I still have family in Shelton. I also as I write this have I hope that I found my problem. Its the switch. I set up some counters on the program execution and the sensor was communicating motion but the light switch is not turning on. So what i thought was a faulty sensor can be a faulty Switch.

[Brian H]

I am a retired Electronic Technician and a electronic hardware experimenter.

Keep us in the loop on the new switches changes to the problem.

[greazer]

(Per suggestion from @larryllix below, adding tags for info that is specific to MSII's. There's only a couple things actually. I did a lot of this with MS I's)

Wanted to provide some information about things that I've learned over the years of using Insteon motion sensors with the ISY. These are in no particular order, but you all may find them useful.

• From what I've gathered ISY by Universal Devices is not Insteon. Therefore, all of the options that are available for the motion sensors are the result of reverse engineering or really bad communication between the two companies. This means just about anything goes with these options. The most basic ones will most likely definitely work, but some of the other ones are probably the result of reverse engineering and therefore wind up poorly documented, or may not even work.  
• The motion sensor will send one on event when they are triggered. They will not send another ON event until after they go off. BUT they continue to sense motion while on and each detection will reset the timeout to turn off. Therefore, if you have a 3 minute timeout the OFF event will never be sent until motion ceases for 3 minutes. 
• MSII-only: Pretty sure that that default 495 seconds of "Off Button Timeout" likely controls how long the motion sensor stops sending events after you press the *motion* button on the device. I haven't tested that but I do know that when I've turned off motion for a sensor, it does magically eventually turn itself back on... probably after 495 seconds.
• I used to use programs to better control when things happen when motion is detected. BUT that method can tend to be very laggy. In other words, if you have a program to turn on a light when you walk into a room, by using a program the amount of time it takes for the event to occur, be detected, and turn on the light is slower, often much slower, than if you just set up a controller/responder scene (whereby communication between the motion sensor and the responding light is basically a direct line of communication). So pretty much all of my "walk-into-a-room-and-turn-on-the-light" behaviors are now no longer programs. It's a bit more of a pain to setup and maintain (say when you want to change the timeout, as you have to physically put the MS into write-mode), but I just have found it worth the effort.
• I do have some motion sensors that I set to send ON-only events, and have a program that detects the light coming on but then turning it off. One case of this is for my garage, where I have two motion sensors. One of them is the "main" sensor and turns the garage light on and off after a default timeout, like normal. The 2nd motion sensor is there to just basically "support" the main one to ensure that the garage light stays on if I happen to be in a place where the main sensor can't see me for its timeout period. This second MS keeps the lights on and ONLY keeps the lights on. Eventually the main sensor will see me again and thus it will eventually be able to turn off the lights.
• MSII-only: I've played around with sensitivity and day/night thresholds, but I cannot make rhyme or reason about them. I could be wrong, but I've just chalked this up to bullet #1.
• To do something like preventing a light from coming on during the day or having it come on dim between certain hours of the evening, I DO use a program. But the program is only designed to set the light level of the scene in question. So in other words, if say you don't want a motion sensor that is directly connected to a light via a scene during the day, then here's what the program looks like:

• THEN you also have a program that sets the light levels for *scenes* given whatever criteria, like this: Note that this capability requires 5.x version of the ISY firmware but it does work with the original Insteon Motion sensors.

• This program, is called "Set Scenes" and is called by other programs (like the one above) depending on the criteria I'm using to set the light levels. Note that scenes can be adjusted in devices WITHOUT having to put them into write mode (waking them up, or whatever you want to call it).
• I've found that using programs to enable and disable other programs to be very problematic and difficult to deal with. So I try to avoid doing that.
• I DO use disabling of programs to make sure that they are never called for me by the ISY AND to remind me that they are helper functions only (as you can call disabled programs from other programs and the disabled program executes). In fact I have a whole set of helper functions that I organized into a folder:

Hope this helps somebody out there. 

Edited August 16, 2020 by greazer
Nevermind, this IS the right thread. :)

[larryllix]

@greazer Nice! You should mention your information is about the MS II. Most of it does not apply to the original Insteon MS.

The off time duration is not mentioned. I found that aspect makes the MS II mostly useless for lighting, but great, and seemingly more reliable, for logic applications in ISY.

Edited August 16, 2020 by larryllix

[greazer]

Thanks @larryllix. By "logic applications" you mean using notifications from them in programs?  And by "off time duration" you mean a time to specify that the motion sensor will stay off and not send ON notifications?

 

 I'll edit the post to mention those things that I found to be MSII specific. I have actually really liked MSII especially compared to the original MS's. In fact, I've replaced almost all of my MS I's with MS II's and have been quite satisfied with them. At one point, I had tried to use a Z-wave motion sensor (Dome) which worked well, but they seem to be sooo picky and difficult to configure (hold down a button for half a sec to wake it up, and you're not sure if you did it right) and then you have to look up parameter numbers and datatype sizes. Such a pain.

[larryllix]

1 hour ago, greazer said:

Thanks @larryllix. By "logic applications" you mean using notifications from them in programs?  And by "off time duration" you mean a time to specify that the motion sensor will stay off and not send ON notifications?

 

 I'll edit the post to mention those things that I found to be MSII specific. I have actually really liked MSII especially compared to the original MS's. In fact, I've replaced almost all of my MS I's with MS II's and have been quite satisfied with them. At one point, I had tried to use a Z-wave motion sensor (Dome) which worked well, but they seem to be sooo picky and difficult to configure (hold down a button for half a sec to wake it up, and you're not sure if you did it right) and then you have to look up parameter numbers and datatype sizes. Such a pain.

Yes, and yes. 

The Off time is what nullifies most of my appkications. As long as motion for the timer setting it will never reset and send a new On. I have one in my laundry room on USB power and it makes no difference. If the light goes out until you stand still for X minutes delay the lights will never come back on.

I was using them in high usage places due to the USB power but now have removed them and only use for security alerts where duration are not a factor.

I wish Insteon would correct this bad design but it seems it was done to support their dumber system and thwart ISY users. The next product logic change will confirm or deny this hypothesis IMHO.

Hopefully UDI will discover some new logically corrections to stop these things from hanging the Insteon comm channel in the near future. I don't query them (MS II) anymore. It can cause a disaster in ISY / Insteon systems and the alternate field information is random garbage at times.

[greazer]

16 hours ago, larryllix said:

Yes, and yes. 

The Off time is what nullifies most of my appkications. As long as motion for the timer setting it will never reset and send a new On. I have one in my laundry room on USB power and it makes no difference. If the light goes out until you stand still for X minutes delay the lights will never come back on.

I'm not sure I'm following. I use one in my laudry room in the way I think you're describing. I have my router, server, amp and other things in my laundry room up on a shelf and yesterday I was up there cleaning and organizing. After walking into the laundry room, the lights came on as expected. While I was dorking around up on a ladder, the MS II couldn't see me, so the lights eventually went out. All I needed to do is wave my foot in front of it to get it to turn back on. 

But maybe I'm misunderstanding what you're describing... ?

[larryllix]

44 minutes ago, greazer said:

I'm not sure I'm following. I use one in my laudry room in the way I think you're describing. I have my router, server, amp and other things in my laundry room up on a shelf and yesterday I was up there cleaning and organizing. After walking into the laundry room, the lights came on as expected. While I was dorking around up on a ladder, the MS II couldn't see me, so the lights eventually went out. All I needed to do is wave my foot in front of it to get it to turn back on. 

But maybe I'm misunderstanding what you're describing... ?

I think you understood correctly by your comments.
Perhaps there were different releases and I got a different one than you.
If I set my timeout short the lights turn off quickly with lack of movement (of course)
If I set my timeout long (3-5 minutes) and the lights time off, I have to not move for those 3-5 minutes before the lights can be triggered on again.

These are my options as set for this room. If you can find something obvious I would appreciate any hints to make these more useful.


 

 

Edited August 17, 2020 by larryllix

[greazer]

15 hours ago, larryllix said:

If I set my timeout long (3-5 minutes) and the lights time off, I have to not move for those 3-5 minutes before the lights can be triggered on again.
 

I'm definitely not seeing this behavior, and I have several MSII's with long (3-5 minute) timeouts. In fact, here's my laundry room settings. The firmware version looks the same, so I'm not sure what might be happening. I believe most of the values here except for Timeout is set to the default. As I mentioned above, it's possible that some of these settings aren't what they say they are in the ISY. You might try a simple experiment by resetting your MSII to factory and then just changing the Timeout value. I know with 100% confidence that the behavior you're desiring is exactly what I'm experiencing. I have several other MSII's setup the same way. FWIW, I just did another a test with my Kitchen MSII instead of the Laundry. It has a 5 minute timeout. I walked into the kitchen and triggered it on. I waited 5 minutes back in my office till I saw the sensor go off. Walked right back in the kitchen (takes about 5 seconds) and the sensor tripped on again thus turning on the kitchen lights.

[larryllix]

@greazer I think I have found the problem!

MY laundry room is the only place I have left using a MS II. The other two are moved to places where they do not directly control lights and are only used for occupancy logic in ISY, so this problem has not applied to those units.

In my laundry room program I was trying to treat the algorithm like the old MSes and use a retriggerable Wait X minutes in ISY software. I had a dual time out based on time of day so some times were worse.

Now suppose the MS II is retriggering with motion in the room but the software timer, not getting any retrigger signals, timed out and turns off the lights.
The MS II internal timer has been retriggered and will never send another On until it times off, and is set to send On in a new cycle.
This would appear with the effect I was describing. No lights on would ever occur until the MS II see no motion for it's timer duration, and it can send another On.

Looks like my synopsis of this was dead wrong and it always seemed to prove out as true in situ. I have now changed my ISY timer to an all-else-fails timer at 15 minutes, longer than should ever be needed in the laundry room, and always (hopefully)  exceeding the internal MS II timer.

CONCLUSION:  Never use an ISY program timer to beat the MS II's  internal timer, when using a direct Scene link between the MS II and a light, to turn off the light.

I will be testing this new idea (for me) to prove whether this was the case. I have lowered the MS II timer down to 90 seconds, but I may also need to physically lower the MS II to catch motion underneath it more dependably.

 

@greazerThank you for your efforts and your persistence! This was a hard lesson for me.

[greazer]

Your welcome, @larryllix! Lord knows I know you have helped me countless times in the past!

What you describe is happening makes total sense now and I certainly agree with your new ISY Axiom. However, I do wonder why you would even need to have the ISY timer fallback to turn off a light that is hard-linked to a MS or MSII? As long as there's motion in the room, the light will stay on. When you leave, the MS or MSII times out, turns off and thus turns off the light.

I suppose you might have a situation where a person can turn on the light in the room for some reason without ever triggering the MS. OR perhaps you have it hooked up to Alexa or have some other programmatic way to turn on the lights without requiring anybody to walk into that room. Is this why you have this fallback?

For me, I don't have this situation occur much, but even if I did, it doesn't bother me as the appropriate MS is likely to be tripped eventually. On a related note though, I do have a program that runs when all MS's in the house turn off. That program waits for a 30 minutes before turning off all the lights in the house if no further motion is sensed anywhere. (Actually if the lack of activity is discovered during the day, I lengthen the timeout to 3 hours since during the day, 30 minutes could conceivably pass if somebody's sitting on the couch watching TV, not moving much. In that case, turning off all the lights in the house is undesirable. If you're not moving for 3 hours, then you must be asleep.  ) This should usually ensure that any light that doesn't need to be on is turned off after 3 hours, no matter what.

 

 

[larryllix]

3 hours ago, greazer said:

Your welcome, @larryllix! Lord knows I know you have helped me countless times in the past!

What you describe is happening makes total sense now and I certainly agree with your new ISY Axiom. However, I do wonder why you would even need to have the ISY timer fallback to turn off a light that is hard-linked to a MS or MSII? As long as there's motion in the room, the light will stay on. When you leave, the MS or MSII times out, turns off and thus turns off the light.

I suppose you might have a situation where a person can turn on the light in the room for some reason without ever triggering the MS. OR perhaps you have it hooked up to Alexa or have some other programmatic way to turn on the lights without requiring anybody to walk into that room. Is this why you have this fallback?

For me, I don't have this situation occur much, but even if I did, it doesn't bother me as the appropriate MS is likely to be tripped eventually. On a related note though, I do have a program that runs when all MS's in the house turn off. That program waits for a 30 minutes before turning off all the lights in the house if no further motion is sensed anywhere. (Actually if the lack of activity is discovered during the day, I lengthen the timeout to 3 hours since during the day, 30 minutes could conceivably pass if somebody's sitting on the couch watching TV, not moving much. In that case, turning off all the lights in the house is undesirable. If you're not moving for 3 hours, then you must be asleep.  ) This should usually ensure that any light that doesn't need to be on is turned off after 3 hours, no matter what.

 

 

It is all about having lights on bright and for extended retriggerable times during the day light hours, and very dim and for very short retriggerable times during the night time hours. This doesn't seem to be possible using the MS II with a direct Insteon Scene, whereas using the old MS it was, using a combination of Insteon scene and ISY programs.

For occupancy I mostly use MSes that set a programmable timer. Each room sets the timer at different times. In the TV watching room I use 180 minutes due to little motion at times, while the typically exit room, I use only 20 minutes, assuming the person may exit. Is the house security is turn on the timer is set to 1 minute and times out quickly. From 11:00 PM to 8 AM the timer is stopped from counting down.
 

BTW: To use the '@' notification system you must choose the name from the dropdown menu or it just becomes normal text.
    @greazer vs. @greazer

[tjkintz]

I have 2 MS II's, one controlling a scene and one triggers a program. The one controlling the scene works more or less as expected. The purpose of the program is to turn on a bathroom light scene when my wife steps out of bed at night and leave those lights on until she returns to bed. It is normally a bathroom trip but could be an insomnia trip lasting much longer. The program sends an email message for each on and off signal. I have discovered that the MS II sends multiple ON signals while it is sensing motion. This is true before the timeout set in the options expires. The email messages are a few seconds apart and stop once the motion is no longer being sensed. This is true when the MS II is set to send ON only or both ON and OFF. I programmatically turn on the scene at the first ON and ignore all the extra ON signals for 30 seconds. After the 30 seconds, I assume the next ON was caused by her return to the bed so I ignore all extraneous signals for another 10 seconds and then turn off the lights. I had expected the MS II to send one ON and no others until the timeout option setting expired but that isn't how it works.

Edited August 20, 2020 by tjkintz

[larryllix]

9 hours ago, tjkintz said:

I have 2 MS II's, one controlling a scene and one triggers a program. The one controlling the scene works more or less as expected. The purpose of the program is to turn on a bathroom light scene when my wife steps out of bed at night and leave those lights on until she returns to bed. It is normally a bathroom trip but could be an insomnia trip lasting much longer. The program sends an email message for each on and off signal. I have discovered that the MS II sends multiple ON signals while it is sensing motion. This is true before the timeout set in the options expires. The email messages are a few seconds apart and stop once the motion is no longer being sensed. This is true when the MS II is set to send ON only or both ON and OFF. I programmatically turn on the scene at the first ON and ignore all the extra ON signals for 30 seconds. After the 30 seconds, I assume the next ON was caused by her return to the bed so I ignore all extraneous signals for another 10 seconds and then turn off the lights. I had expected the MS II to send one ON and no others until the timeout option setting expired but that isn't how it works.

Interesting. I have not seen any other poster reporting this about any  MS II. Can you post a screenshot of your option settings?

Edited August 21, 2020 by larryllix

[greazer]

On 8/20/2020 at 12:00 PM, tjkintz said:

I have discovered that the MS II sends multiple ON signals while it is sensing motion. This is true before the timeout set in the options expires. 

@tjkintz, I didn't think I was experiencing what you indicate with my MSII. I don't get an ON notification until after the MSII times out. I created a quick program to beep my office light switch when an ON is received (or just open the event viewer to see what events are occurring, I usually find beeping easier). It looks like this: 

The Office Desk MS is an MSII v.46 (not v.47, like my others) and sits pretty much right by my keyboard so it's constantly seeing me move as I type. The LED blinks as expected when I move, and the scene-linked lights stay on while I'm in here, but I do not hear a beep from my light switch. If I let the timeout expire and the MSII goes off, when I trip it back on I do hear a beep from my light switch. This is true regardless of whether I have On/Off or On Only set for the MSII.  Here are the settings for my Office Desk MS II:

Note: I actually get multiple beeps when the MSII senses movement. This can be verified in the event viewer. I don't know why this is. But in any event, I don't get continual beeps as I see the LED light up. Only after the timeout occurs.

[greazer]

On 8/19/2020 at 4:24 AM, larryllix said:

It is all about having lights on bright and for extended retriggerable times during the day light hours, and very dim and for very short retriggerable times during the night time hours. This doesn't seem to be possible using the MS II with a direct Insteon Scene, whereas using the old MS it was, using a combination of Insteon scene and ISY programs.

@larryllix, I am definitely changing the brightness of triggered lights based on the time of day using the technique I described above. That leaves a way to change the OFF time after a light is triggered on. I don't know how that can be done other than by changing the MSII to be ON Only, then creating a program that starts a timer when the MSII is triggered on and turns the light off after it times out. You could then use a variable time limit in the program itself based on time of day.  If you did that, then you could set the applicable MSII's to timeout after 30 seconds since you want motion to be sensed as quickly as possible each time. This way, you can still take advantage of having scene-link performance to turn a light on. Lag is probably not much of an issue when turning a light off.

I used to do something like this, but I really didn't like the fact that when setting up a new MS, I'd HAVE to remember to change the hardware options (particularly make it On Only as well as setting the timeout) AND make sure I have a program for it to ensure the lights are turned off. By making use of the defaults for MSII, there have been cases where I just made a scene to link the light and the MS and that's pretty much it.

[larryllix]

7 hours ago, greazer said:

@larryllix, I am definitely changing the brightness of triggered lights based on the time of day using the technique I described above. That leaves a way to change the OFF time after a light is triggered on. I don't know how that can be done other than by changing the MSII to be ON Only, then creating a program that starts a timer when the MSII is triggered on and turns the light off after it times out. You could then use a variable time limit in the program itself based on time of day.  If you did that, then you could set the applicable MSII's to timeout after 30 seconds since you want motion to be sensed as quickly as possible each time. This way, you can still take advantage of having scene-link performance to turn a light on. Lag is probably not much of an issue when turning a light off.

I used to do something like this, but I really didn't like the fact that when setting up a new MS, I'd HAVE to remember to change the hardware options (particularly make it On Only as well as setting the timeout) AND make sure I have a program for it to ensure the lights are turned off. By making use of the defaults for MSII, there have been cases where I just made a scene to link the light and the MS and that's pretty much it.

When using the MS II, the retriggerable possibilities in ISY programs is not possible. When you disable the Off command from the MS II, you lose the retriggerable timer possibilities, from the MS II, also.

Now that I am aware the Off cycle in the MS II is NOT doing what I thought it was, I can see some possibilities for a very short timer duration inside the MS II and make it run like the original MSes. More experimentation needed here but sounds more promising now.

[tjkintz]

Above are my settings and program. This is not the first iteration of the settings or program but it is what it evolved to when I discovered I was getting multiple ON triggers, and therefore multiple email notices,  before the 30 second timeout. I used to have ON/OFF set and just ignored the OFF. I wanted maximum sensitivity and took a chance the higher the sensitivity number, the greater the sensitivity.  I still don't know if that is true. I have the hardware jumper set to limit the range because I don't want the lights to turn on when I get out of bed. The program is in a folder with a condition that it only runs from sunset to sunrise. I didn't want to rely on the sensor figuring out if it is night or day. There is a separate program to monitor the status of the night light scene. If any of the lights are on then the status is 1, else the status is 0.