Jump to content

Any luck with 2420M low battery indication?


IndyMike

Recommended Posts

Hello forum members,

 

I'm wondering if anyone has had success getting low battery events from their 2420M motion sensors?

 

I currently have 4 Rev 1.1 sensors (ISY lists them as V.00) installed in "high activity" areas. As a result, I've gone through multiple batteries on each unit over the past 4 months. I've never seen a low battery trigger from any of the units.

 

Typically, the sensors will become intermittent and begin generating communication faults. Soon afterward they go off line.

 

I'm a bit tired of watching the logfile in an effort to predict when the next battery will fail (hate coming home and seeing 12 - 75 watt cans burning away).

 

If someone out there has had success, I'd sure appreciate a firmware rev/model rev.

 

On a positive note, when the batteries are "up" the motion sensing and day/night detection on these units has been flawless. I've been using the day/night status to qualify programs and I haven't seen it miss yet.

 

Thanks,

IM

Link to comment

Hi IndyMike

 

I cant be of any help as my one an only sensor has been installed for a few months on it's first battery. Having moved form X10 I second your comments on reliability. However, My X10 Hawkeyes' would last years (at least two), so now you have me concerned with your "multiple batteries in 4 months". Even being in a high traffic area (mine is not) this seems very excessive.

 

Joe

Link to comment

Hi Indy!

 

I was a beta tester for the motion sensor. My beta unit did generate a low-battery command. But, those betas would go through batteries very quickly... turns out they were not timing out, but were drawing full power continuously.

 

My replacement unit (1.0) hasn't yet had the battery die, so can't answer your question directly. But, it is in about the most active location in the house. It sounds to me like your batteries are dying too quickly, though perhaps not as fast as the beta units!

Link to comment

Hello Joe,

 

Sorry to have raised concern. I should have provided some more detail on the "high activity". On and average the weekday (3 kids at home), my kitchen sensor trips an average of 120 times (on/off) a day. If it's a rainy day I've seen as many as 250 trips.

 

After my first battery died I realized that the ISY folks gave us the ability to decrease the LED drive. I changed the LED brightness on one unit to "0". It's on it's second battery whereas the other units are on their third. To early to tell, but I hoping for a significant battery improvement on my "test unit".

 

I replaced two Hawkeyes with the 2420M's. The Hawkeyes would last roughly 6 months in the same location.

Link to comment

Hello Darrell,

 

It's encouraging that the beta units provided low-battery triggers. I can't imagine Smarthome back-peddling on an advertised feature. I guess it's time to find my old variable DC supply and run some tests.

 

Thanks for the reply,

IM

 

Hi Indy!

 

I was a beta tester for the motion sensor. My beta unit did generate a low-battery command. But, those betas would go through batteries very quickly... turns out they were not timing out, but were drawing full power continuously.

 

My replacement unit (1.0) hasn't yet had the battery die, so can't answer your question directly. But, it is in about the most active location in the house. It sounds to me like your batteries are dying too quickly, though perhaps not as fast as the beta units!

Link to comment
  • 2 weeks later...

Update (6/27/09): the following tests were conducted using a linear power supply input to the 2420m. I have found that they do not represent operation with a 9V battery source. Refer to the following post for 9V source information.

Manged to dig out my power supply and find some time to play.

 

Setup:

Two 2420M motion sensors, V1.1

Timeout: 0.5 Minutes

Led Brightness: 100

Darkness Sensitivity: 35

 

Notes:

1)The motion sensors have a fair amount of storage capacity. When changing voltages, it's necessary to wait around a minute for the internal voltages to settle out.

2)Per the manual, the sensors will "double flash" then led when the battery is low.

 

The good news - Both of my units worked flawlessly over a voltage range of 4.5 to 9V. This include linking and setting options.

 

The results:

1) At around 4.25 volts, both units would begin to indicate a low voltage condition with a double flash. This double flash repeats at intervals equivalent to the timeout period. What I did not expect, was that the sensor also sends out on/off communications during this period. With my units programmed for a 0.5 minute timeout, the sensor would indicate on for 30 seconds, cycle off for ~ 1 second and then back on. For anyone who has had their lights cycle on/off repeatedly when linked to a 2420m, this is the culprit - the low battery indication. Really not good.

 

Neither of my units communicated the "low battery indication" at this point.

 

2) Between 4 Volts and 3.25 volts we have somewhat of a race condition. Communication with the Accesspoint is beginning to degrade (comm errors popping up). Below 3.25 volts communication was off line. Out of 10 trials, I received one low battery communication during this section.

 

3) Reducing the supply voltage to 3 volts will latch the low battery communication flag in the sensor (not the ISY). Unfortunately, the sensor can't communicate this fact back to the ISY since the communication went off line at 3.25 volts.

 

4) Increasing the Voltage back to 5 Volts allows the sensor to communicate the "low battery indication" back to the ISY. This works 100% of the time.

 

5) Increasing the Voltage back to 9 Volts does not reset the low voltage indication. The unit will continue to double flash until the supply is cycled. The supply must be off for around a minute to allow the unit to discharge completely.

 

6) After power cycling to clear the low battery fault, the sensor does not communicate a "healthy battery" indication to the ISY. The only way that I have found to clear the "low battery ON" indication in the ISY is to delete the sensor and add it back in. We really could use a query or at least a manual override here.

 

Well, that's it in a nutshell. For right now, I'm trying to figure a way to program around the potential "cycling light phenomena". If this were to happen in my better half's kitchen, I'm not sure I would survive the aftermath.

 

IM

Link to comment

Sorry folks, but the above appears to have been a waste of time.

 

I had intended to put an older battery in one of the 2420's to monitor the decay and note when the low battery/looping kicked in. The battery I chose measured 6.8V in circuit.

 

This produced a number of differences from the power supply test posted above.

1) The 2420m diagnosed the 6.8V battery as "low" by indicating two led flashes during activity. It did this with two of my detectors.

2) The sensor did not enter the "looping mode" as it did when I operated from the power supply.

3) The sensor did not communicate the low battery status to the ISY.

 

In contrast, when operating from the power supply the 2420 would run down to ~ 4.25V before flagging a low battery.

 

I imagine there is a significant difference in the source impedance of my power supply VS the 9V battery. Since the battery impedance will increase as the cells discharge, it's not an easy thing to simulate. The 2420 is apparently keying off this and flagging the battery as low.

 

Back to the drawing board...

Link to comment

Hello Mike,

 

Thank you for the extensive testing. You know all readers appreciate it.

 

I have two motion sensors since mid-Jan (6 months). I am pretty sure the high-use one is experiencing battery fatigue. I still haven't seen a Low-Battery message but reporting motion is becoming sporadic. I'll dig out the VOM and see what the voltage reads.

 

Rand

Link to comment

Two of my Insteon motion sensors run the batteries dead every 2-4 weeks, and I've never had a low battery indicator from either of them. I only have 1 other, and in (significant) contrast, the battery has never gone bad in that one.

Link to comment

Thanks - I think I'll have to. I only got 5 days this last round, operating in "Night only mode" and using a new Duracell battery. The LED appeared nice & bright so I moved the access point right below the unit, but still nothing. A few days later the LED quit lighting as well. Still no low battery warning from any of them.

Link to comment

I have 7 motion sensors. I have never had a successful low battery indication. Also, I wish I could disable the dusk/dawn transmit feature. All of my motion sensors point at the very areas lit by the lights tied to the sensors. I do not use dusk/dawn sensing in any programs and this is just a huge waste of battery energy in my situation.... at least 10 unnecessary transmissions per detector per day. So not only battery draining, but at least 70 unnecessary radio traffic transmissions per day, usually many more.

Link to comment

I know it would be a pain, and may void warranty, but you could wrap the sensor in black electrical tape, although the ISY console would show the Dusk/Dawn as On. But it would eliminate the unneeded transmissions. Or perhaps you could figure out the resistance needed to switch to dawn and install that value resistor in place of the sensor. Then the ISY would show it as Off.

 

I have 7 motion sensors. I have never had a successful low battery indication. Also, I wish I could disable the dusk/dawn transmit feature. All of my motion sensors point at the very areas lit by the lights tied to the sensors. I do not use dusk/dawn sensing in any programs and this is just a huge waste of battery energy in my situation.... at least 10 unnecessary transmissions per detector per day. So not only battery draining, but at least 70 unnecessary radio traffic transmissions per day, usually many more.
Link to comment

A very interesting idea. Unfortunately in my case I would also like the majority of the sensors to only function at night, again to save battery energy and network transmissions. So I would like the sensor to still be able to tell dusk/dawn. I would like to have a jumper where it does not transmit this condition, very much like the On only jumper. The unit still has a time-out value, it just does not transmit the Off command.

Link to comment

Illusion,

 

The ISY gives you the ability to set the darkness sensitivity (options tab at the bottom of the device window). This is typically set at 35%. Presumably, adjusting to 0 would reduce the number of reports the 2420 gives (don't know if it would actually disable the feature).

Link to comment

IndyMike....but again, that also changes the functionality of the devices itself. The motion detectors brightness setting for dusk/dawn also affect the night only operation of the detector. Further, the detectors are still pointing at the very areas lit by their operation, so any setting that is set for the proper darkness sensitivity with change the dusk/dawn sensor with a motion trigger after dark. I am not looking for a solution from the forum on this one, as I believe it is a design issue with the motion sensor product. I am just venting....

Link to comment

Sorry Illusion,

 

I hadn't seen your last post indicating you were using night only operation.

 

I am a bit curious about the excessive number of dusk/dawn indications you're getting. I just looked at my log for the motion sensors - 4 sensors are averaging 10 reports a day (1 on/1 off per sensor) over the past month.

 

I looked at the dusk reporting on the sensors some time ago. It turns out the dusk reporting period varies with the sensor motion timeout. Said differently, if your sensor is programmed to send an off command 2 minutes after motion has ceased, the dusk/dawn period will be 2 minutes + 3 minutes 30 seconds. By setting the dusk/dawn sense period wider than the motion timeout the sensor avoids being fooled by local lighting that may have turned on when the motion was sensed.

 

From your description, your sensors are behaving very differently than mine.

 

IM

Link to comment
Sorry Illusion,

 

I looked at the dusk reporting on the sensors some time ago. It turns out the dusk reporting period varies with the sensor motion timeout. Said differently, if your sensor is programmed to send an off command 2 minutes after motion has ceased, the dusk/dawn period will be 2 minutes + 3 minutes 30 seconds. By setting the dusk/dawn sense period wider than the motion timeout the sensor avoids being fooled by local lighting that may have turned on when the motion was sensed.

 

From your description, your sensors are behaving very differently than mine.

 

IM

 

IndyMike,

 

Very interesting. I had not realized that the dusk/dawn period is in relationship to the timeout. I do not think that my sensors are behaving very differently than yours. I do not use the off command on any of my sensors. I have a short time-out and the off command is timed and handled by the ISY, usually for a much longer period of time than the time-out. I think there is only one or two programs that have a shorter timer section than the detector time-out plus 3.30m. This is why the sensors are seeing the local lighting. I will have think about this new understanding. I was planning on shorting the time-out to 1m on all but one sensor, but now will have to reconsider this from a network traffic perspective as that will mean not only the additional On commands but additional dusk/dawn triggers for the 2 sensors with shorter ISY timers.

Link to comment

IndyMike,

 

Now that I have thought about it, I think I will go the other way with my time-outs to reduce the dusk/dawn triggering.

 

When you looked at the dusk reporting, did you find that the dusk/dawn period would be +3:30 regardless of time-out period selected? IE: Is it plus 3:30 for very short time-out periods as well as very long ones?

 

Also, did you find this through documentation or experimentation? Just curious.

Link to comment

Hi Illusion,

 

The timeout period for the Dusk/Dawn was arrived at through experimentation. I was using my "drawer test" to activate motion and plunge the sensor into light/darkness. Most of these tests were performed with a 0.5 minute motion timeout and a 35% darkness sensitivity.

 

I went back though my notes and found that the timeout period that I had documented was actually 3min 40sec (not the 3:30 that I had posted).

 

Last night I played a bit more with the darkness sensitivity and the motion timeout period. Here's a summary of what I've seen:

 

1) NO Motion: If the light level changes state (no motion present) the sensor will delay around 3min 30 sec prior to changing the output state. This appears to be independent of the dusk sensitivity setting. This measurement was made by switching a 4 bulb T-40 fluorescent fixture on/off over the sensor. I did see a fair amount of variability in this time (3:05 to 3:50 with the same settings). I attribute this to the implementation of the photo cell/light calculation of the sensor.

 

2) Motion: The sensor will not change the state of the dusk/dawn output within the motion timeout. If motion is sensed and the light level is changed, the sensor will only change the dusk setting 3:40 after the motion off is issued. This timing was very consistent and was not affected by the dusk sensitivity.

 

3) Motion re-trigger (within timeout): If motion is sensed within the motion timeout period, the timeout is simply extended (i.e. motion off command is issued at the specified timeout period after the last motion). Since the dusk/dawn is only issued 3:40 after the motion off command is sent, this will be delayed as well.

 

4) Motion re-trigger (outside motion timeout, before dusk timeout): Since the sensor will not issue the dusk/dawn output while the motion output is active, re triggering motion again delays the dusk/dawn output.

 

5) Light re-trigger (light cycling within the 3:30 second timeout): Still playing with this one. I initially saw a lot of variability which may again be due to my light source and the photocell.

 

The jumpers in all of the above were in their default position. I believe you mentioned that you were using the "dusk only" mode. I have not tested that configuration.

 

IM

Link to comment
  • 5 weeks later...

Indy, thanks so much for all your testing as reported in this thread. I can now confirm the lack of a low-battery warning transmission.

 

My first motion sensor low battery (Rev. 1.1--same as you reported) occurred last week. The battery lasted about six months. The sensor just stopped transmitting. There was no low-battery ON command issued.

 

The beta units did send the low-battery ON command, but didn't go to sleep (drained battery within a week). It appears the production models go into too deep a sleep, and forget to send the low-battery warning :shock: .

 

BTW, please do let us know the results, when available, of your experiment with reduced LED brightness level--does it extend the battery life?

 

CJVann and Illusion, could you let us know the revision of your motion sensors (on the label in the battery compartment)? Thanks so much.

 

Has anyone actually received a low-battery warning from a production motion sensor, and if so what version/revision?

Link to comment

Darrell,

 

Thank you for confirming. It's good to know that my experiences aren't due to that little black cloud that continually hangs overhead.

 

When I spoke to Smarthome about this, they indicated that the "documented" battery low indication was the "double flash" of the led. Sure enough, my units double flash when the battery is getting low. The battery low communication to the ISY is apparently issued sometime much later (and typically after the communications have broken down).

 

I'm currently running a comparison test between two of my sensors. One is programmed for full led brightness with the other programmed to 0%. Both are located in the same high traffic area (kitchen). I'll try to report back when they begin to develop problems.

 

Thanks again,

IM

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...