Announcement

Collapse
No announcement yet.

Battery status updates

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Battery status updates

    Hi Wim,

    I'm using Aqara temp/humidity sensors, they are fantastic and inexpensive workhorses. Like many Zigbee devices, they pre-programmed to only report data when an internal sensor changes value.

    As you can see below, I've got one that is operating fine, but the battery value has not been updated since inclusion. I know that the lithium coin cells have long operating life and will tend to report 100% until they fall off dramatically one day.

    Click image for larger version

Name:	Capture1.PNG
Views:	135
Size:	37.4 KB
ID:	1447744

    My question is this: I've check the device definition in HS4 and made sure that "Last Change Time Updates on Status Change Only" is unchecked on both the parent and battery child device, yet as you can see the time doesn't change. Is there something that can be done in deConz to program a cluster to make sure that battery updates are sent along with the other data reports?

    #2
    Originally posted by TC1 View Post
    Hi Wim,

    I'm using Aqara temp/humidity sensors, they are fantastic and inexpensive workhorses. Like many Zigbee devices, they pre-programmed to only report data when an internal sensor changes value.

    As you can see below, I've got one that is operating fine, but the battery value has not been updated since inclusion. I know that the lithium coin cells have long operating life and will tend to report 100% until they fall off dramatically one day.

    Click image for larger version

Name:	Capture1.PNG
Views:	135
Size:	37.4 KB
ID:	1447744

    My question is this: I've check the device definition in HS4 and made sure that "Last Change Time Updates on Status Change Only" is unchecked on both the parent and battery child device, yet as you can see the time doesn't change. Is there something that can be done in deConz to program a cluster to make sure that battery updates are sent along with the other data reports?
    Same problem here.
    tenholde

    Comment


      #3
      Tony,

      deCONZ does send the report on battery devices. But the plugin checks if the value of the battery changes. If it does, it will update the device, but only if it does.

      To compensate for that, in HS3 the plugin would update the time on the parent device if the plugin received proof the device was still reporting. It would not update the battery device time as the value did not change. This was working fine, created for SDJHealth from SteveMSJ for battery devices. And the HS4 plugin still does this, but it shows up for converted devices only.

      You always can double check on the properties tab/JowiHue in the JSON to see this.

      For very unclear reasons the device time in HS4 does not show last update time anymore on newly created (parent) devices. So this effectively removed the possibility to show the device is alive. I do not like how this develops, but see no other way then to move the update from device level to battery level. But my bones say nay

      Wim

      -- Wim

      Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData

      1210 devices/features ---- 392 events ----- 40 scripts

      Comment


        #4
        This is a big problem.

        Use case: Aqara Door/Window sensors. I've got some on Windows that in theory will never be open for months (central AC and heat) and it's critical to know if these devices are still alive/working for both auto-HVAC events (turn off HVAC if someone opens window) and security events (check all windows and doors).

        So what you are telling me is that these devices will look "dead" if they are untouched for any length of time?

        Comment


          #5
          They do not in HS3, but due to HS4 not updating the device holder (parent) anymore, yes they would, unless the battery goes to another level. Or the device becomes unreachable in deCONZ, this would also change the device to unreachable. At the end nothing to worry as the status is accurate still, but I understand your issue here, which again was correct in HS3, by showing the time the device reported itself earlier. Will update this in the next version
          -- Wim

          Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData

          1210 devices/features ---- 392 events ----- 40 scripts

          Comment


            #6
            Just so I'm understanding correctly, zigbee battery devices (in HS4) that go unused for some time will have updated timestamps for the battery child device as the physical device reports battery levels?

            Comment


              #7
              but see no other way then to move the update from device level to battery level.
              That is what I said.
              -- Wim

              Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData

              1210 devices/features ---- 392 events ----- 40 scripts

              Comment


                #8
                Ok, thanks. I was about to place a big order for z-wave window sensors and throw out all my zigbee ones.
                I love the Aqara window sensors because they are smaller than any Z-wave ones currently being sold. But as a security/risk management professional, it's essential there's an process and audit trail to prove the device is still alive/working.

                Appreciate your efforts and understanding on this.

                Comment

                Working...
                X