Motion Sensor II and Continuously Montoring Motion

[BoomerangThree]

Hi everyone,

I'm trying to work with the Sensor II and write a program that will continuously monitor the sensor so that as long as there is motion in the room, the lights stay on.

The issue is that the Sensor II will not continuously "report" it's status.  I have / or think of I have set the Sensor II to "Never" timeout, thinking that as long as it detects motion it will trigger my program and a counter variable will get reset so that the counter gets reset to the timeout value as long as there is motion.

What happens is that the Sensor II reports it's initial motion, the program kicks off, but the Sensor II will not report any additional motion.  Seems like it's still on a timeout because when it finishes what I think is it's timeout then it reports motion or no motion again.  So the counter gets updated, after a No Motion is reported and so the lights go back on because of the "delayed" motion detection.

Make sense?  Any ideas how to fix or work around this?

 

Jeff

[Teken]

16 minutes ago, BoomerangThree said:

Hi everyone,

I'm trying to work with the Sensor II and write a program that will continuously monitor the sensor so that as long as there is motion in the room, the lights stay on.

The issue is that the Sensor II will not continuously "report" it's status.  I have / or think of I have set the Sensor II to "Never" timeout, thinking that as long as it detects motion it will trigger my program and a counter variable will get reset so that the counter gets reset to the timeout value as long as there is motion.

What happens is that the Sensor II reports it's initial motion, the program kicks off, but the Sensor II will not report any additional motion.  Seems like it's still on a timeout because when it finishes what I think is it's timeout then it reports motion or no motion again.  So the counter gets updated, after a No Motion is reported and so the lights go back on because of the "delayed" motion detection.

Make sense?  Any ideas how to fix or work around this?

 

Jeff

Hi Jeff,

Yes, the MS II has a on board timer that needs to turn off before it allows it to cycle again. This behavior is completely different when compared to the legacy MS where if you set it to always ON. Anytime the MS saw movement it would let the ISY restart the countdown timer. A quick work around is to have another program where you tap on the light switch which will over ride the count down timer.

Some use a double tap vs others a single tap . . .

So the theory of operations is MS II sees *Human* and turns lights on. Human is tired of the light constantly turning off so *Human* needs only tap up on the switch and stop the countdown timer.

Now, *Human* must remember to turn off said light switch . . . ?

Or have a third program monitor the second program and turn it off after say 30, 60, 120 minutes.

[BoomerangThree]

9 minutes ago, Teken said:

Hi Jeff,

Yes, the MS II has a on board timer that needs to turn off before it allows it to cycle again. This behavior is completely different when compared to the legacy MS where if you set it to always ON. Anytime the MS saw movement it would let the ISY restart the countdown timer. A quick work around is to have another program where you tap on the light switch which will over ride the count down timer.

Some use a double tap vs others a single tap . . .

So the theory of operations is MS II sees *Human* and turns lights on. Human is tired of the light constantly turning off so *Human* needs only tap up on the switch and stop the countdown timer.

Now, *Human* must remember to turn off said light switch . . . ?

Or have a third program monitor the second program and turn it off after say 30, 60, 120 minutes.

Hi Teken,

Thanks for the reply, support, and experience.  So, here is where I'm at;

UPDATE:  Just for kicks I took the battery out of the Sensor II and back in to reboot it.  I don't think this really did the trick, I thought perhaps a reboot would allow ISY to update the timeout parm of the Sensor II. 

In addition, I increased my counter and now I seem to be getting updates every so many seconds that resets my timer to the timeout duration.  Still playing with it, will update again, but I may be close.

The MS II has a 15 second timer like you stated. 

I'm thinking about a similar function as the "tap up on the switch", but with a Alexa voice command that will disable the timer like you recommended.  I already have another program that executes every 15 mins to see if it can turn things off after a certain period of time when no motion is detected.

 

Edited July 4, 2020 by BoomerangThree

[Teken]

1 minute ago, BoomerangThree said:

Hi Teken,

Thanks for the reply, support, and experience.  So, here is where I'm at;

UPDATE:  Just for kicks I took the battery out of the Sensor II and back in to reboot it.  I don't think this really did the trick, I thought perhaps a reboot would allow ISY to update the timeout parm of the Sensor II. 

In addition, I increased my counter and now I seem to be getting updates every so many seconds that resets my timer to the timeout duration.  Still playing with it, will update again, but I may be close.

I'm thinking about a similar function as the "tap up on the switch", but with a Alexa voice command that will disable the timer like you recommended.  I already have another program that executes every 15 mins to see if it can turn things off after a certain period of time when no motion is detected.

 

One other thing is (IF) its possible when the unit is powered via USB it seems to operate a little differently. As some of the sensors can be queried for status and also seem to update more frequently which makes sense as power isn't an issue. Let us know how it turns out and what solution you decide upon as I am sure it will help the next person.

The MS II has so much potential but Smartlabs continues to drop the ball on a product that could make them millions?!?  

NOTE: Some have reported querying the sensor can lock up the controller so use this feature with caution . . . 

[BoomerangThree]

12 minutes ago, Teken said:

One other thing is (IF) its possible when the unit is powered via USB it seems to operate a little differently. As some of the sensors can be queried for status and also seem to update more frequently which makes sense as power isn't an issue. Let us know how it turns out and what solution you decide upon as I am sure it will help the next person.

The MS II has so much potential but Smartlabs continues to drop the ball on a product that could make them millions?!?  

NOTE: Some have reported querying the sensor can lock up the controller so use this feature with caution . . . 

So I know see the restriction, thanks to you.  When the MS II senses motion, it kicks off its own internal timer, like you said, so nothing is reported or sent to the ISY.  If no motion during this MS II internal timer, ISY get's notified of additional motion, but if it's within the MS II timer interval, nothing gets reported to ISY. 

So, I'm going to try and work with both on / off coming from the MS II and use it's internal timeout.  I will set for two nodes, one for on and one for off and work with that.

I have seen where this might not reliable, but I'll try anyway.  That way, the MS II will do what it's suppose to do and as long as there is motion, it won't report off to the ISY.  We shall see.

 

Edited July 4, 2020 by BoomerangThree

[jec6613]

I've had three solutions to this, depending on my response time:

1) Set the MSII to on only, with a short timeout, and add it to a scene with the light.  Then use a program to come along and turn off the lights after, say, 5 minutes.  With a 30 second MSII timeout and a 5 minute program timeout, the MSII will re-fire if any movement is seen after 30 seconds, and re-start the countdown timer.  Response to light on is instant, so I use it for bathrooms and similar.

2) Set the MSII to not be in a scene, firing off and on.  This then is handled by the ISY to turn on the lights, and the MSII stays active so long as it senses motion.  I use this for longer term occupancy sensing and when the instant response doesn't matter, such as when the lights are on dimly anyway and just brighten.

3) Have the MSII in a scene, firing on and off.  Its own internal timer resets if there's any motion, though I've found this less reliable, it works for a few outdoor lights.

[BoomerangThree]

17 minutes ago, jec6613 said:

I've had three solutions to this, depending on my response time:

1) Set the MSII to on only, with a short timeout, and add it to a scene with the light.  Then use a program to come along and turn off the lights after, say, 5 minutes.  With a 30 second MSII timeout and a 5 minute program timeout, the MSII will re-fire if any movement is seen after 30 seconds, and re-start the countdown timer.  Response to light on is instant, so I use it for bathrooms and similar.

2) Set the MSII to not be in a scene, firing off and on.  This then is handled by the ISY to turn on the lights, and the MSII stays active so long as it senses motion.  I use this for longer term occupancy sensing and when the instant response doesn't matter, such as when the lights are on dimly anyway and just brighten.

3) Have the MSII in a scene, firing on and off.  Its own internal timer resets if there's any motion, though I've found this less reliable, it works for a few outdoor lights.

KISS - Looking good for the following approach.

1. 1st, like others, I had the binary icon associated with my MS II for the longest time indicating that the ISY was having trouble communicating to the MS II.  I believe the MS II options were getting updated, but the icon associated with it was indicating that changes were still to be written to the MS II.  Well, when I added the 2nd node for both On / Off signals coming from the MS II, the icon changed from binary to communicating or written.  Hmmmmm.

2. Then I took a very simple approach, and have a separate program for On and another one for Off.  The MS II is configured for a 90 sec timeout and as long as the MS II is sensing motion, it doesn't send a Off signal and I believe the internal 90 sec timeout gets reset every time it senses motion.

3. I'm stress testing now, but so far so good.

[Teken]

12 minutes ago, BoomerangThree said:

KISS - Looking good for the following approach.

1. 1st, like others, I had the binary icon associated with my MS II for the longest time indicating that the ISY was having trouble communicating to the MS II.  I believe the MS II options were getting updated, but the icon associated with it was indicating that changes were still to be written to the MS II.  Well, when I added the 2nd node for both On / Off signals coming from the MS II, the icon changed from binary to communicating or written.  Hmmmmm.

2. Then I took a very simple approach, and have a separate program for On and another one for Off.  The MS II is configured for a 90 sec timeout and as long as the MS II is sensing motion, it doesn't send a Off signal and I believe the internal 90 sec timeout gets reset every time it senses motion.

3. I'm stress testing now, but so far so good.

The binary writes you see are one of the key issues others have reported to UDI. This is more of an issue where a person tries to make say a KPL change back lighting states for a given time period. In the past only the res-ponder would be updated and written to - no issues.

Now, using the MS II the *Controller* is for some odd reason being asked to make writes?!? This causes the system to queue these writes and at some critical point the ISY will slow down, lock up, or reboot.

So use caution in integrating the MS II into scenes where its asked to adjust scenes . . .

[jec6613]

2 hours ago, Teken said:

The binary writes you see are one of the key issues others have reported to UDI. This is more of an issue where a person tries to make say a KPL change back lighting states for a given time period. In the past only the res-ponder would be updated and written to - no issues.

Now, using the MS II the *Controller* is for some odd reason being asked to make writes?!? This causes the system to queue these writes and at some critical point the ISY will slow down, lock up, or reboot.

So use caution in integrating the MS II into scenes where its asked to adjust scenes . . .

I just turn off writes to battery powered devices, it doesn't seem to care that I'm not writing to the MSII most of the time.  For USB powered ones, after I make the changes I execute the pending writes via a program.

[BoomerangThree]

8 minutes ago, jec6613 said:

I just turn off writes to battery powered devices, it doesn't seem to care that I'm not writing to the MSII most of the time.  For USB powered ones, after I make the changes I execute the pending writes via a program.

Out of curiosity, how do you “turn off writes” and “execute the pending writes via a program”?  Always trying to learn.

[larryllix]

24 minutes ago, BoomerangThree said:

Out of curiosity, how do you “turn off writes” and “execute the pending writes via a program”?  Always trying to learn.

There are icon options at the top of the admin console software in Windows machine java screens with two different options concerning this.
Then you write programs that trigger on event from the battery devices, wait a few seconds to avoid signal collisions and the write the updates via an ISY program line.

Caution: If your battery devices do not support this option, you may flood ISY caches with data that can bog your ISY down to a very slow grind. Every time a trigger is detected, ISY will attempt to write the whole cache out and you will constantly see "Busy" on your admin console. This can become hard to find and hard to correct.

Edited July 5, 2020 by larryllix

[asbril]

4 minutes ago, larryllix said:

There are icon options at the top of the admin console software in Windows machine java screens with two different options concerning this.
Then you write programs that trigger on event from the battery devices, wait a few seconds to avoid signal collisions and the write the updates via an ISY program line.

Caution: If your battery devices do not support this option, you may flood ISY caches with data that can bog your ISY down to a very slow grind. Every time a trigger is detected, ISY will attempt to write the whole cache out and you will constantly see "Busy" on your admin console. This can become hard to find and hard to correct.

Why is it that with some devices, the write to device does not seem to work ?  I have a Zooz switch that constantly appears to have a pending update .

[larryllix]

1 hour ago, asbril said:

Why is it that with some devices, the write to device does not seem to work ?  I have a Zooz switch that constantly appears to have a pending update .

No idea. I don't use these features anymore. It locked up my ISY until I did a factory reset to clear the caches,  before I figured what was causing it.

[asbril]

34 minutes ago, larryllix said:

No idea. I don't use these features anymore. It locked up my ISY until I did a factory reset to clear the caches,  before I figured what was causing it.

Right now I have no delayed response issues, but I remember that 2 or 3 years ago I did a factory reset and it made a big difference in response timing.

[BoomerangThree]

Verification of the following?

Just wanted to verify based on others experiences.

1. A factory reset is safe with the backup and restore capability?

My ISY has experienced a couple slow downs / freezes and if it continues I may try a reset. This might also clear up my “empty slots” on my Polisy also, which UDI is looking into.


Sent from my iPad using Tapatalk

[larryllix]

1 hour ago, BoomerangThree said:

Verification of the following?

Just wanted to verify based on others experiences.

1. A factory reset is safe with the backup and restore capability?

My ISY has experienced a couple slow downs / freezes and if it continues I may try a reset. This might also clear up my “empty slots” on my Polisy also, which UDI is looking into.


Sent from my iPad using Tapatalk

IIRC  just factory reset, set your DHCP, time zone, and location lat/long, and restore a good backup. Done.

But if you loaded up your caches before, you need to disable those caching functions or it will just  happen again. I have many older MSes and apparently they don't support the "open linking window period" after sending events.

Edited July 5, 2020 by larryllix

[BoomerangThree]

1 minute ago, larryllix said:

IIRC  just factory reset, set your DHCP, time zone, and location lat/long, and restore a good backup. Done.

But if you loaded up your caches before, you need to disable those caching functions or it will just  happen again. I have many older MSes and apparently they don't support the "open linking window period" after sending events.

Thanks larryllix,

1. Can you point me in the right direction for how to “disable those caching functions”?

[larryllix]

Thanks larryllix,
1. Can you point me in the right direction for how to “disable those caching functions”?

Look back about 5 posts.

Sent using Tapatalk

[BoomerangThree]

On 7/4/2020 at 4:08 PM, Teken said:

One other thing is (IF) its possible when the unit is powered via USB it seems to operate a little differently. As some of the sensors can be queried for status and also seem to update more frequently which makes sense as power isn't an issue. Let us know how it turns out and what solution you decide upon as I am sure it will help the next person.

The MS II has so much potential but Smartlabs continues to drop the ball on a product that could make them millions?!?  

NOTE: Some have reported querying the sensor can lock up the controller so use this feature with caution . . . 

Teken,

Powering the MS II with USB definitely makes a difference.  As soon as I hooked up power to USB instead of battery, updates from ISY to the MS II were executed the "waiting to write changes icon" changed, I'm able to update even the temperature calibration.  Changes are almost immediate where before it would take a minute and appear not to take the changes.  The MS II even beeps now to indicate changes were made to it. 

Thanks everyone, especially Teken and larryllix.

Jeff...

Edited July 5, 2020 by BoomerangThree

[Teken]

Teken,
Powering the MS II with USB definitely makes a difference.  As soon as I hooked up power to USB instead of battery, updates from ISY to the MS II were executed the "waiting to write changes icon" changed, I'm able to update even the temperature calibration.  Changes are almost immediate where before it would take a minute and appear not to take the changes.  The MS II even beeps now to indicate changes were made to it. 
Thanks everyone, especially Teken and larryllix.
Jeff...

Rock On . . .


Sent from my iPhone using Tapatalk

[toddhutch]

On 7/4/2020 at 7:16 PM, larryllix said:

There are icon options at the top of the admin console software in Windows machine java screens with two different options concerning this.
Then you write programs that trigger on event from the battery devices, wait a few seconds to avoid signal collisions and the write the updates via an ISY program line.

Caution: If your battery devices do not support this option, you may flood ISY caches with data that can bog your ISY down to a very slow grind. Every time a trigger is detected, ISY will attempt to write the whole cache out and you will constantly see "Busy" on your admin console. This can become hard to find and hard to correct.

I'm looking where these options are... I'm using 5.x. I'm not finding the place to change this-

Is this a Pro version only option?

 

Edited July 6, 2020 by toddhutch

[Teken]

I'm looking where these options are... I'm using 5.x. I'm not finding the place to change this-
Is this a Pro version only option?
 

Pro only option but you can upgrade your controller to obtain the same.


Sent from my iPhone using Tapatalk