Battery reports 100% all of the time

  • 527 Views
  • Last Post 08 February 2017
treeVt6 posted this 19 June 2016

All of the battery powered devices I have in Axial report 100% battery all of the time. This includes Aeotec Multisensor 6, Ecolink Z-Wave PIR Motion Detector and Aeotec Minimotes.  Autoconfigure has been successful and they are associated with the z-stick.  I am running 4.1.5994 of Axial (although I've never had this work correctly, even with past versions).  This wasn't a real big deal and I have ignored it until now, but as I add more battery powered devices it would be nice to be able to monitor the battery level.

Does battery level work correctly for anyone else?

Thanks

Order By: Standard | Newest | Votes
weidnerj posted this 19 June 2016

I don't know about level all being at 100% battery all of the time, mine has the actual power levels on this version. 

There was an issue about an year ago where every device device (battery and non battery) would show a battery and the only way to resolve was to run a newer particular version, and to either do a clean install or remove and re-add the devices.  Not sure if this might have something to do what you are experiencing...

treeVt6 posted this 26 June 2016

Thanks for the response.  Yeah I wondered about re-adding the devices too but I had actually just replaced one of them so it was new.  I did get the newer device to start working after updating firmware and changing some paramters on it.  I'm not sure which fixed it.  If the the other devices aren't working simply because they need to be removed and re-added I might try that now that Axial has the ability to replace a device.  I'm not sure if the procedure will work if I'm replacing a device with itself but it can be a lot of work to setup all of the scenes again so I hope it will!

rscott posted this 27 June 2016

@treevt6 Are you saying that once you updated firmware/parameters, it started to report the proper battery level? 

In general, it'll stay at 100% until a reading is sent from the device. If the device never sends a reading, the battery will never change. Most devices will send battery reports to the associated devices, so make sure your USB stick is one of those associated devices. Also, you could try it to poll but make sure you have it set to "queue until wakeup" if you enable the polling option on a battery operated device that sleeps.

gallwapa posted this 10 July 2016

 @rscott Should kwikset locks be set to queue as well then?  I've noticed a similar issue - 100% battery yet the LED light on the door indicates low battery.  Kwikset claims the batteries should last a year, realistically I've seen ~4 weeks.

rscott posted this 21 July 2016

@gallwapa - You don't want to queue locks, otherwise no commands will be sent. However, you definately don't want to poll the lock very often. I have mine set to poll once every 24 hours.

f0ggy987 posted this 26 July 2016

Add me to the list of people getting strange battery level reports.

Rgarding my lock:

  • Yale YRD220-NR-619

The battery level shown in InControl does decrease, but does not match what Yale says the lock is reporting. I first noticed an issue when the lock itself started indicating a low battery, but the battery level reported in InControl was still showing 60% . I reached out to Yale to find out at what level a 'low battery' condition is triggered and they told me it is at 30%

No matter what I do I can't get the battery level on the following three devices to show anything other than 100% :

  • Nortek PIR sensor (WAPIRZ-1)
  • Nortek door sensor (WADWAZ-1)
  • Everspring smoke detector (EVS-SF813)

I am using v4.1.5994

Thanks

 

f0ggy987 posted this 28 September 2016

Bump...any more information I can provide that would be helpful in troubleshooting this?

rscott posted this 29 September 2016

@f0ggy - You might give version 4.1.6103 a try. You'll need to find your battery op devices and set them to poll every few hours but make sure you queue until wake up.

This will make a difference if your battery operated device sends a "wake up" to Axial Server AND if the device responds to battery poll requests. You can determine if it wakes up by searching your logs - you'll see a message saying "Device 106 woke up" - the 106 in this case refers to your device's node id, which is visible in the lower right hand portion of the screen when you click a device.

If you need to configure your device to wake up, you can use the zen tools to configure the device to wake up. The clock in the screen shot shown in the link has a text box next to it, which is where this configuration happens (it's in seconds). Note that if it's a sleeping device, you'll need to toggle the blue square so it doesn't try to queue commands you send; you'll also need to manually wake your device so it'll hear the commands coming to it.

f0ggy987 posted this 03 October 2016

Thanks for the response.

I upgraded to version 4.1.6103 but the problem persists.

I believe polling and waking up are concerned with updating or refreshing the battery level, no?

I can manually trigger my devices and see a status update in Axial. I also see the 'last communication' date/time update in the devices properties...but the battery level will never change from 100%

So the devices and Axial are definately talking...either the device isn't sending its battery level or Axial is ignoring it/mis-interepting it.

 

Is there anyway to tell from the log or from the packets screen in ZenTools if the battery level is being sent? I quite often see 'unknown alarm type recieved' (or something to that affect) listed in my log.

 

Thanks

 

rscott posted this 04 October 2016

You could go to the device and enable the audit logs. After you restart the service, it will log anything coming from the device. After that, look in your logfile.txt to see if it sends a battery report.

f0ggy987 posted this 24 January 2017

Hi Ryan,

Sorry for the (long) delay. Below is the logfile contents with auditing enabled:

Nortek PIR sensor (WAPIRZ-1):
10/5/2016 5:07:31 PM: Unprocessed parameter Zensor_Net_Source_Node_ID, value=0 from node 30 alarm_report
10/5/2016 5:07:31 PM: parameter ZWave_Alarm_Type, value=7 from node 30 alarm_report
10/5/2016 5:07:31 PM: zwave_alarm_type set with value of 7 from value 7
10/5/2016 5:07:31 PM: parameter ZWave_Alarm_Event, value=2 from node 30 alarm_report
10/5/2016 5:07:31 PM: Unprocessed parameter Number_of_Event_Parameters, value=0 from node 30 alarm_report


Yale lock (YRD220-NR-619):
10/5/2016 5:37:24 PM: Alarm_level 1 received from node 5
10/5/2016 5:37:24 PM: Found zwaveAlarmType of `0` with event of `0`
10/5/2016 5:37:24 PM: Unrecognized alarmType 0 with event 0
10/5/2016 5:37:24 PM: Alarm_level 1 received from node 5
10/5/2016 5:37:24 PM: Found zwaveAlarmType of `0` with event of `0`
10/5/2016 5:37:24 PM: Unrecognized alarmType 0 with event 0

Nortek door sensor (WADWAZ-1):
10/5/2016 5:37:24 PM: Unprocessed parameter Zensor_Net_Source_Node_ID, value=0 from node 20 alarm_report
10/5/2016 5:37:24 PM: parameter ZWave_Alarm_Type, value=7 from node 20 alarm_report
10/5/2016 5:37:24 PM: zwave_alarm_type set with value of 7 from value 7
10/5/2016 5:37:24 PM: parameter ZWave_Alarm_Event, value=2 from node 20 alarm_report
10/5/2016 5:37:24 PM: Unprocessed parameter Number_of_Event_Parameters, value=0 from node 20 alarm_report

 

All three devices report successful association with the controller. Those log entries were from when I was using an Aeotec Z-Stick Gen2 controller. I just migrated to a Gen5 controller and am seeing the same behavior (what prompted me to return to this thread), with one exception: The Everspring smoke detector (EVS-SF813) now doesn't list a battery level at all. Again it is succesfully associating with the controller.

I'm now running Axial Control version 4.1.6192.32946

Thanks again!

rscott posted this 05 February 2017

Hi Ryan,

Sorry for the (long) delay. Below is the logfile contents with auditing enabled:

Nortek PIR sensor (WAPIRZ-1):
10/5/2016 5:07:31 PM: Unprocessed parameter Zensor_Net_Source_Node_ID, value=0 from node 30 alarm_report
10/5/2016 5:07:31 PM: parameter ZWave_Alarm_Type, value=7 from node 30 alarm_report
10/5/2016 5:07:31 PM: zwave_alarm_type set with value of 7 from value 7
10/5/2016 5:07:31 PM: parameter ZWave_Alarm_Event, value=2 from node 30 alarm_report
10/5/2016 5:07:31 PM: Unprocessed parameter Number_of_Event_Parameters, value=0 from node 30 alarm_report


Yale lock (YRD220-NR-619):
10/5/2016 5:37:24 PM: Alarm_level 1 received from node 5
10/5/2016 5:37:24 PM: Found zwaveAlarmType of `0` with event of `0`
10/5/2016 5:37:24 PM: Unrecognized alarmType 0 with event 0
10/5/2016 5:37:24 PM: Alarm_level 1 received from node 5
10/5/2016 5:37:24 PM: Found zwaveAlarmType of `0` with event of `0`
10/5/2016 5:37:24 PM: Unrecognized alarmType 0 with event 0

Nortek door sensor (WADWAZ-1):
10/5/2016 5:37:24 PM: Unprocessed parameter Zensor_Net_Source_Node_ID, value=0 from node 20 alarm_report
10/5/2016 5:37:24 PM: parameter ZWave_Alarm_Type, value=7 from node 20 alarm_report
10/5/2016 5:37:24 PM: zwave_alarm_type set with value of 7 from value 7
10/5/2016 5:37:24 PM: parameter ZWave_Alarm_Event, value=2 from node 20 alarm_report
10/5/2016 5:37:24 PM: Unprocessed parameter Number_of_Event_Parameters, value=0 from node 20 alarm_report

None of those logs actually contains a BATTERY_REPORT. If you search through your logfile, do you ever see one?

f0ggy987 posted this 07 February 2017

I just checked - I don't have any BATTERY_REPORT entries in the log file (or anything else with 'battery' in it).

These devices reported successful associating with the controller and all are supposed to support battery level reporting.

Thanks

rscott posted this 08 February 2017

You might download the zentools and use it to "set the wake up interval" time for your battery devices.  It's the final icon at the top of the toolbar. The value it needs is in seconds. In order to set that value you'll need to 1) Wake the battery device up and 2) make sure zentools doesn't queue the command by putting a "check" in the box to the right of the device in the list.

Close