Closed NickWaterton closed 4 years ago
Why does the battery state get reported for each of the sensors? it's the same battery for all three.
Because we copied this setup from the Hue API and aren't yet exposing the battery as a separate ZHABattery /sensors
resource (as we do for e.g. the IKEA FYRTUR).
Please don't confuse the web socket notification for the Zigbee attribute report: it's one report from the sensor to deCONZ, which translates it into three web socket notifications.
I don't mind the contact state being reported every 5 minutes (its actually useful to me), but is there a way to change the reporting interval of the other sensors?
Change the reporting configuration in the deCONZ GUI. See the user manual (under Help) on how to do that.
disabling some of the sensors (temperature or orientation/vibration)?
Not sure if that's possible, but you could disable the corresponding attribute reporting (set the intervals to 65535).
As you can see the reports are every 5 minutes, but a different 5 minute interval for each sensor.
That's the device firmware, but not uncommon. I see the same for the Hue motion sensor. Typically different clusters report independently.
The main issue is the battery life dropping at a rate of 1% a day, any suggestion on how to reduce the drain?
Reduce the reporting rate, so the device powers its radio less frequently.
Note the nature of these button cell batteries: they report 100% for up to a year, and then fall quite quickly. Did you install a fresh battery, or is this the battery shipped with the device?
Thanks for the quick response.
Please don't confuse the web socket notification for the Zigbee attribute report: it's one report from the sensor to deCONZ, which translates it into three web socket notifications.
Ok, so this is a non-issue then.
Change the reporting configuration in the deCONZ GUI. See the user manual (under Help) on how to do that.
i will try to find out how to do this, and see if it makes a difference.
Did you install a fresh battery, or is this the battery shipped with the device?
This is the battery shipped with the device. I understand about battery life, I'm used to seeing them sit at 100%, then months/years later drop off a cliff. This is why I was surprised to see it dropping 1% a day for 2 weeks. I was thinking it would stabilize at 90% or so, but no, it just keeps dropping.
Thanks for the pointers, I'll see what i can do to change the reporting interval, and keep an eye on the battery level. I have some fresh batteries, so if it keeps dropping, I'll swap it out.
I have successfully changed the reporting interval for the open/close sensor and temperature.
The battery level has not dropped since I extended these duration's - which is promising.
i do have a problem with some other reporting intervals, for example the battery level. This is set to 45 minutes (2700 seconds). I can change this period (tried changing it to 6 hours - 21600 seconds), which reads back correctly, but after a few minutes, this period reverts back to 45 minutes.
Any idea why these changes do not "take" - ie why would they revert back to the default after a period of time?
Thanks.
Probably because the REST API plugin is re-applying its default settings, after it hasn't received a report for what it considers to be a reasonable amount of time. You should be able to see that in the log, with enough debugging options enabled. I'd try 2 hours.
You mean with --dbg-info=2 --dbg-aps=1
? I'll try that. I just changed battery reporting to 3600 (1 hour) and that seemed to work. I increased the temperature and contact reporting to 20 minutes (up from 5 minutes), and that also worked.
Any idea what a 'reasonable amount of time' is? I've just switched to 2 hours, so we'll see what happens.
This seems to be a bit of an issue, as I really don't need battery reporting that frequently, 6 hours is the SmartThings default, so 45 minutes is a bit too often.
I wasn't expecting the rest plugin to override what I'm trying to do - is there any way to turn that off? (command line option?).
Thanks again.
Any idea what a 'reasonable amount of time' is?
Not by heart.
is there any way to turn that off? (command line option?).
It's hard-coded, unfortunately, and not the most transparent code. I think the plugin might use different thresholds for different types of devices.
Looks like 1 hour is the max for battery reporting. I'll take a look at the code (if I can find it).
Ok, it's in binding.cpp
. Unusual piece of code, all the values are hard coded. Might be an idea to use an .xml
file or a SQlite3
db file to store values for devices, would make it easier to change stuff.
Anyway, the problem is that the values for VENDOR_SAMJIN
are not quite right. The code says that the values are from https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/smartsense-multi-sensor.src/smartsense-multi-sensor.groovy
and while most of them are, some were missed and are instead set to default. one of these is battery reporting interval, which should be:
zigbee.configureReporting(zigbee.POWER_CONFIGURATION_CLUSTER, 0x0021, DataType.UINT8, 30, 21600, 0x10)
According to the Samsung file, ie 21600 seconds (6 hours), but is instead set to default (60 * 45) = 45 minutes. I don't know why 45 minutes would be a good idea for battery reporting interval, but there it is. the minimum change is also set to 1 (ie 0.5%), which should be 16 (8%).
If you increase the value by more than 1.5 times the original value, then it gets reset back to the default value. I think this does it at line 1199:
NodeValue &val = bt.restNode->getZclValue(POWER_CONFIGURATION_CLUSTER_ID, rq.attributeId, bt.binding.srcEndpoint);
if (val.timestampLastReport.isValid() && (val.timestampLastReport.secsTo(now) < val.maxInterval * 1.5))
{
return false;
}
return sendConfigureReportingRequest(bt, {rq});
as rq
contains the default values, and this is part of the POWER_CONFIGURATION_CLUSTER_ID
section, which gets called a lot.
The ultimate fix is to add a section like this:
else if (sensor && sensor->manufacturer() == QLatin1String("Samjin") && (sensor->modelId() == QLatin1String("motion") ||
sensor->modelId().startsWith(QLatin1String("multi")) ||
sensor->modelId() == QLatin1String("water"))) // Samsung Sensors
{
rq.minInterval = 30; // value used by ST config file
rq.maxInterval = 21600; // value used by ST config file
rq.reportableChange8bit = 16; // value used by ST config file
}
After line 1150 (or somewhere similar).
Thanks for the help in tracking this down.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Good catch!
With new JSON based device description files (DDF) these values can be defined in them per device in future.
Till DDF are available I'll update the bindings.cpp
to align with the groovy file values.
I'm currently testing the topic with a Samjin button, I don't think attribute reporting is the main problem here.
The reason why the battery is trained so fast is that the Samjin devices on lowest MAC level poll the parent node rather quickly if new messages are available. Roughly every 5–10 seconds.
But they do have a Poll Control cluster to configure this behavior, now I'm checking why it isn't used properly (there was some code for this if I remember correctly).
No kidding! This is my Samjin multi
sensor:
The 0 Check-in Interval is valid though, according to the spec it means disabled.
A value of 0 indicates that the Poll Control Server is turned off and the poll control server will not check-in with the poll control client.
The default Long Poll Interval of 28 is quite intense though and only useful during setup.
I am running the latest FW (conbee II) and deconz server (2.5.77).
My SmartThings Multipurpose sensors (2018) are working, but I have noticed some odd things.
At this rate, the sensor will be out of battery in about 3 months (I was hoping for longer battery life). I am using the sensors as door open/close sensors.
I don't mind the contact state being reported every 5 minutes (its actually useful to me), but is there a way to change the reporting interval of the other sensors? This may not be an issue if it's not the cause of the battery drain.
I have the websocket set to
websocketnotifyall
so I can see all the device updates (whether they change or not).Why does the battery state get reported for each of the sensors? it's the same battery for all three.
Is there a way to extend the battery life? say by increasing the reporting interval? or disabling some of the sensors (temperature or orientation/vibration)?
I have changed the orientation threshold to 90, to prevent very frequent reports from the orientation sensor (due to door vibrations).
This is my high level log (with nothing happening to the door - ie idle state):
Here is an example of the output from my websocket listener:
As you can see the reports are every 5 minutes, but a different 5 minute interval for each sensor. Here is a battery report:
Which seems to be a battery report for each sensor (sensor id 8, 9 and 10). Which makes no sense as it's the same battery for all three sensors in one device.
The main issue is the battery life dropping at a rate of 1% a day, any suggestion on how to reduce the drain?
Thanks.