Power Draw Data from testing #2420 Motion Sensor

[Illusion]

Tests done on REV 1.1 motion detector. ISY99i/IR Pro v2.7.6:

 

The main purpose for this test was that I wanted to see how much more battery power it would take to have my motion detectors operating always and let the ISY always do the determination of what actions to take vs night only operation.

 

8.08mA on initial power up. No programing as this Motion Detector (MD) was already part of my system. This would be the same effect as a battery replacement. This was the condition created when I broke the circuit to put the amp meter in line. Now this is interesting. If I left the MD alone it would never go to sleep. I tested this for 30m. During this time the MD would not respond to Dusk/Dawn nor motion. It took several presses of the set button to knock it out of this mode and get the MD to flash its led and show up in the event viewer. Then it would drop into sleep mode. I tested this 4 times with the same results, but only once did I let it run for 30m. The other tests were just a few minutes long. This explains how I killed a nice lithium battery in one of my detectors when I replaced it. New rule: always make sure the detector shows its actions before you put it into service after a battery change. IE: press that set button till you see the led flash, it may take several attempts. For further confirmation make sure its commands show up in the event viewer. If not there is a good chance that the detector is not going into sleep mode and about a week from now you will have a dead batt. This also makes me wonder about the MD I sent back to Smarthome as defective because it would eat batteries. I wonder if I just did not get it to go to sleep after repeated battery changes.

33µA in sleep mode

 

14.34mA to Xmit a command

 

Energy cost of allowing the led to flash: (all values exist only for the duration of time for the led flash)

900µA LED at 255 (Very bright)

350µA LED at 100 (Not so bright)

Almost nothing at 1 (Very Very dim, but still visible in darkness)

nothing with LED jumper disable (no led flash at all)

900µA LED at 0 (0 makes the LED the same brightness as 255? bug?)

MD set in always detect mode, LED disabled via jumper, .5m timeout:

33µA sleep mode

486µA pulses about every 30s while in sleep mode

14.3mA to Xmit motion sense

MD set in night only mode, LED disabled via jumper .5m timeout:

33µA sleep mode

486µA pulses about every 30s while in sleep mode

2.35mA standby mode for 30s on motion detect without Xmiting

14.3mA to Xmit

 

For the MD to not Xmit, it still detects the motion. Even though the jumper is set for night only mode and it was bright for this portion of the test the MD still comes out of sleep. It does not use the high power of 14.3mA to xmit, but it goes into a sorta halfway sleep mode for 30s with a .5m timeout. With a 3m timeout the sorta halfway sleep mode was even longer at 57s.

 

Once darkness befalls the detector set for night only operation the power draw is identical to the always detect mode. It jumps out of sleep to Xmit and then goes right back to sleep.

 

Real world test:

Simulating a motion event during the day. I created motion intermittently over the course of 30s during the "day" with the detector set to night only mode and always detect. LED at brightness of 100 and a 3m timeout, on-only mode:

Night only mode:

Average power draw of 1.772mA over 1:30m

 

Always Xmit mode:

Average power draw of .345mA over 1:30m

 

It took over 5 times as much energy to not transmit the command. Even though the always on mode used 14.3mA to xmit, it did this for just an instant and then went right back to sleep. While the night only operation did not waste 14.3mA xmitting a command I do not care about, it sat at 2.35mA for so long in that halfway sleep mode that the average power draw was massively higher over this 1m30s test.

 

Conclusion: It is way better from a battery life perspective to just let the MD send commands during the day and use the ISY to determine whether to execute an action or not based on other data (Sunrise/Sunset, Dusk/Dawn sensors, Weather Bug light Data, Time of Day... Etc...).

[Michel Kohanim]

Hi Illusion,

 

This is great analysis; thanks so very much for providing this feedback. I am going to send this link to SmartHome engineering team .. I am sure they will find it quite useful.

 

With kind regards,

Michel

[SteveL]

Illusion,

 

This is a copy of the post I made on the smarthome forum.

 

Good stuff. There was a lot of thought put into when the motion wakes up and when power is used and conserved, but we are always interested in information like this. A second pair of eyes is always a good thing. I have passed your findings on to our CTO and our engineering team.

 

Thanks,

 

Steve L

Smartlabs

[CJVann]

I have a night-only MS that I've replaced repeatedly thru SmartHome because max. battery life is typically 1-2 weeks. In fact, I have yet another sitting here right now waiting to be returned. Thank you for sharing your findings; I'll stop using night mode!

[Illusion]

I have a night-only MS that I've replaced repeatedly thru SmartHome because max. battery life is typically 1-2 weeks. In fact, I have yet another sitting here right now waiting to be returned. Thank you for sharing your findings; I'll stop using night mode!

 

Is the culprit in a high traffic area during the day? What is the timeout on the offender?

[CJVann]

Timeout is the default value. The ISY Status graph is showing it tripped 31 times 6PM - midnight (dark) yesterday, so I'm guessing it sees something similar during the day. It tripped 9 times in 1 hour this morning (It's in the kitchen) before it came out of night-only mode.

[Illusion]

If you can live with longer timeouts that also will save power. I would also recommend writing programs in the ISY to handle the "off" function if you already have not done so. If you have the MD set to send the off command, just changing that via the jumper will lead to increased battery life. Changing to Day only mode will further help your cause.

 

I do wish there was a way to prevent the dusk/dawn wasted transmissions aside from opening the device up and modifying it.

[Illusion]

Using what I have learned from my tests I am going to begin testing long term battery life. I am attempting to maximize my battery life in these tests.

 

I have 7 Motion Detectors.

 

I have taken all the MDs apart and dripped black liquid electrical tape on the photo eyes thereby disabling the Dusk/Dawn feature. With 7 detectors that is 5110 radio transmissions and Insteon power line transmissions eliminated each year... minimum. As I use the ISY to determine time to keep devices on, and those waits are much longer than the internal timeouts in the MDs, the MDs would often see the area that was then lit up and would xmit a Dusk/Dawn command. Now those events will be eliminated as well so it is many more than 5000 radio transmissions and Insteon power line transmissions eliminated each year.

 

I am only using the "On" from the MDs, letting the ISY determine the off for devices that are reacting to the MDs. This will save 50% of the radio transmissions and Insteon power line transmissions that occur as a result of each motion event.

 

I have increased the default timeout from 1m to 3m on the detectors. This will reduce the number of retransmissions when motion is continuous in an area. This does have some potential negative results but I hope it is worth it on the battery saving front.

 

The detectors always detect motion and xmit and the ISY will determine what action to execute based on sunrise/sunset conditions. This is due to my finding that this actually takes less energy than night only mode.

 

The LED is set to a brightness of 100. Battery life could be improved if I disabled this via the jumper, but I really like seeing the LED for feedback.

 

I am using lithium batteries.

 

I will post back here when they die.

[unispeed]

anychance they are still working same batteries?

thx

Mark

[Sub-Routine]

Hello Mark,

 

I don't want to answer for everyone but I have found 9 months of battery works with our always busy kitchen motion sensor. The less used laundry room has been active for over 18 months.

 

Our outside sensors have been working for over 6 months but haven't been tested with below 0F yet,.

 

Rand

 

anychance they are still working same batteries?

thx

Mark

[Illusion]

Yeah, they are still going. Test has been contaminated a bit. I had to replace my PLM. As a result I had to put the MD into programming mode which takes a bunch more energy than just detecting motion. One of the MDs batteries did not have enough energy to power the programming mode even though it was detecting motion just fine. So it had to be replaced to complete the PLM replacement.

 

The one MD that underwent the battery change is in a heavily used area with at least 10 triggers per day every day for the past year.

 

Other test units are working fine still even after the heavy energy usage of re-programming.

 

All MDs are exterior and are in an operating environment that has ranged from 17˚F to 103˚F over the past year. I will report when the others start to die that are still in use with the original batteries.

[Illusion]

Test complete. The only battery to survive all the test contamination over the years gave up the ghost today. While it was still detecting motion, the liquid electrical tape I put over the light sensor apparently degraded to the point it had been allowing dusk dawn triggers of 10 per day for some time. I brought the unit in to add more liquid tape to the sensor and as a rule I require seeing the MD send an on and off in response to set button presses before I will put the cover back on. She gave me an on, but the battery could not muster up enough energy for the off. I am calling Time of death 7-19-11 for a battery that was put in service 9-27-09.

 

This is in a heavy use area with 15-40 triggers per day. This also had a PLM replace and restore in there which takes extra power. Further, for some time this MD has been sending Dusk/Dawn triggers many times per day. And it was still working when I pulled it down to try to stop the Dusk/Dawn commands. Almost two years. Not bad. Temperature range 8Ëš-109Ëš.

[Illusion]

Updated test results on new motion detector version.

 

Tests done on REV 2.3 motion detector with ISY994i/IR Pro v4.0.5:

 

60µA on initial power up. No programing as this Motion Detector (MD) was already part of my system. This would be the same effect as a battery replacement. This was the condition created when I broke the circuit to put the amp meter in line. This new version did not fail to drop back into sleep mode. So that is a good bug fix. But after programming options the MD did stick in a 6.55mA state until I pressed the set button and saw the commands show up in the event viewer. Indeed the MD would not respond to motion during this time, similar to the REV 1.1 used in the first tests. However, eventually it would drop into sleep and respond to motion. This occurred after about 3-4 minutes in several test attempts. So maybe still a good Idea to see the MD send commands in response to the set button press before returning them to service. Only takes a couple of extra seconds.

 

32µA in sleep mode

 

12.03mA to Xmit a command

 

Energy cost of allowing the led to flash: (all values exist only for the duration of time for the led flash)

500µA LED at 255 (Very bright)

170µA LED at 100 (Not so bright)

Almost nothing at 1 (Very Very dim, but still visible in darkness)

It appears that the LED is now off when set to 0. Another nice bug fix.

MD set in always detect mode, LED disabled via software set at 0 LED brightness, Occupancy sensing mode:

33µA sleep mode

66µA pulses about every 25s while in sleep mode

12.1mA to Xmit motion sense

6.55mA standby mode for 1s after xmit motion.

MD set in night only mode, LED disabled via software set at 0 LED brightness, Occupancy sensing mode:

32µA sleep mode

66µA pulses about every 25s while in sleep mode

50-150µA pulse on motion detect without Xmiting (day time)

12.1mA to Xmit

6.55mA standby mode for 1s after xmit motion.

 

Once darkness befalls the detector set for night only operation the power draw is identical to the always detect mode. It jumps out of sleep to Xmit and then goes right back to sleep with that 1s at 6.55mA

 

Real world test:

Simulating a motion event during the "day". I created motion intermittently over the course of 30s during the "day" with the detector set to night only mode and always detect. LED at brightness of 100, Occupancy sensing so the sensor would send commands upon sensing motion irrespective of timeout, on-only mode, timeout is not relevant with these settings:

Night only mode:

Average power draw of 42µA over 1:30m

 

Always Xmit mode:

Average power draw of 1mA over 1:30m - 5 on Xmit occurred during the 30s of simulated motion.

 

It took almost 24 times as much energy to send the unnecessary commands if you only wanted actions to occur after dark.

 

Conclusion: The conclusion with this newer MD is exactly the opposite from the conclusion drawn on the REV 1.1 MD. It is way better from a battery life perspective to let the MD determine dark if you want something to only occur after dark than to send commands during the day and use the ISY to determine whether to execute an action or not based on other data (Sunrise/Sunset, Dusk/Dawn sensors, Weather Bug light Data, Time of Day... Etc...). And the other conclusion is that the newer version is much much more power conservative all across the board.

[Xathros]

Very nice. Thanks for the data and your effort to gather it. After my recent round of battery replacements, I'm thinking it's time for some newer sensors. Most of mine are 4+ years old.

 

-Xathros

[Illusion]

Important update.

 

I was a bit distraught about my findings in my latest testing. I very much want to minimize my power consumption of the batteries, and I only need 'night' triggering. However, all my MDs sense motion in areas that are then illuminated by the 'on' action of motion sense.

 

Others may have discovered this, but here it is in any case: The timeout effect delays the switch to "day" but does not seem to delay the switch to "night" in the MD. This coupled with the always send occupancy option, which ignores timeout, solves all my issue. They really did a great thing on this version.

 

With a timeout of .5m dark will be executed in about 3m and day will be executed about 4m after exposure to bright.

 

But with a timeout of 5m set, dark will be executed about 3m after being in the dark, but day's execution will be after 25-30m.

 

So I set the MD to only send motion after dark, occupancy mode, with a 5m timeout and now for about 30m I can move around the area and keep the lights on, while still getting the huge energy savings I found in testing.