FGMS-001 Motion Sensor - Huge battery drain started

[extreme79 0]

Hi guys.

I'm on Zipabox, latest fw.

After the latest zipabox fw update, my fibaro motion sensors was "ghostly" associated with a wall switch (TKB wall switch turn on when motion detected, then off). I never manually associated the two devices. Zipato checked and nothing seems happened with zipabox & firmware. No device association results from controller interface.

Since that happened (is possibile that devices become associated without user actions? or this must caused by controller?), my fibaro motion started to dramatically drain the battery without any changes to the configuration (june-october 30% of drain.. two weeks drained more of 40% of battery).

Why?

Next I removed fibaro from zwave network, removed it from zipabox device list.. then rejoined it.

Ghost association disappered.. but battery drain not stopped.. and device turned off after two days (20% OF DRAIN!).

Please login or register to see this image.

/emoticons/default_sad.png" alt=":(" srcset="https://forum.fibaro.com/uploads/emoticons/[email protected] 2x" width="20" height="20" />

How this can be explained? Could be an hw issue (device worked great, except for battery drain)?

After device rejoined I also incremented the wakeup timing.. but nothing changed.

[j.nowacki 5]

extreme79, is it possible your MS is installed in a place with drafts or rapid temperature change? Maybe when a colder days came, this location started to cause problems. Increase interval of other reports, for light and temperature, not only for the wake up.

[extreme79 0]

extreme79, is it possible your MS is installed in a place with drafts or rapid temperature change? Maybe when a colder days came, this location started to cause problems. Increase interval of other reports, for light and temperature, not only for the wake up.

no. The sensor is placed in the living room, so exactly the same temperature/light variation during the day/night of previous months.

I have already increased wakeup timing, temp checks interval, temp/light reports timings. So the issue could not be related to timings (upper than fibaro standards). Attached my config parameters.

It's possibile that fibaro is trying to reach a not existent device (so huge requests > battery drain)? This could be caused only by controller or it's possibile that device started to do it autonomously?

Is there some other explanation?

Zipato support also asked me to "contact their support and ask them if they noticed any issue with battery drain or if device itself has some mode in case it can't reach it's controller".

They refers to a sort of "panic mode" like happen, example, with the danfoss valves that sometimes (if not able to reach controller) drain battery due to this.

Please login or register to see this attachment.

[j.nowacki 5]

extreme79, it should not be the case, Motion Sensor does not go into any sort of panic mode, like Danfoss does. Please reset the device by going into its menu and add it again.

[extreme79 0]

extreme79, it should not be the case, Motion Sensor does not go into any sort of panic mode, like Danfoss does. Please reset the device by going into its menu and add it again.

I already removed and rejoined it.

Before rejoining, I erased the fibaro motion eeprom following the manual.

I noticed that battery drain started with the "ghost" association that I initially described.

If the controller initiate a direct connection (for an error or something else) of the fibaro to a not existent device (or offline device), what happen?

I can assume then that there's a problem on the controller side?

[m.roszak 763]

extreme79,

in this case FGMS will try to send command frames to this "ghost" device and will resend this command few times before time-out.

So if (for example) there is a disabled device added to first association group of motion sensor there will be major battery drain (every detected motion will trigger sending command frames to this device).

[extreme79 0]

extreme79,

in this case FGMS will try to send command frames to this "ghost" device and will resend this command few times before time-out.

So if (for example) there is a disabled device added to first association group of motion sensor there will be major battery drain (every detected motion will trigger sending command frames to this device).

Ok. Clear.

So the "association" between two devices (in this case FGMS and TKB) can be started only by controller, and not by FGMS itself, right?

This is important.. because if a "auto association" is impossibile (without touching the device), it's absolutely a controller fault-bug that need to be checked by zipato.

thanks

[m.roszak 763]

It is impossible to set association from the device (FGMS), only way to set associations in our device is by using a controller.

No problem.