Thanks, I think I did get one submitted. I could have used those instructions al little earlier 
. Just chalked up a little more knowledge figuring it out.
My 3 Multi Sensor are still reporting 100% battery. I have taken the battery out and back.
Still the same. I have asked ST support UK(by email) nothing back as yet.
I woke up to verification that the modified DTH worked for my CentraLite 3321-S multi sensors. The offender that started the original post has dropped from 100% to 80%. The battery raw value is 29 which is 2.9 volts, which is the 80% step in the 3.0-2.5 volt range. This took 28 days to change since the battery was replaced. The other steps should go quicker as new batteries are usually around 3.2 volts. Now to watch verificatiion of the change to the minimum voltage for open/close reporting.
1 Like
Hey ST.
Arenāt you working?
Why canāt you fix it?
Iām really angry about this issue.
This issue have been appeared lots of months ago.
Donāt think about your salary anymore.
I think you guys donāt work.
Check this line in the device handler code.
if (descMap?.clusterInt == 0x0001 && descMap.commandInt != 0x07 && descMap?.value)
clusterInt is 0x0001 -->> this signal canāt be generated anymore!
Iāve been watching the log again and again, but this signal doesnāt turn up!!
I think that you guys fix that 0x0001 signal to appear normally, then this issue will be done, ok?
@posborne - This is still an issue and support just says weāre aware of the problem and weāre working on a fix. It seems you guys broke it, why is it taking so long to fix it?
If you canāt fix it, please just roll back. Why are you so obsessed on this version?
Is it gonna be reflected in your performance assessment this year?
I captured the log which contains the battery value
read attr - raw: 290401000108********, dni: 2904, endpoint: 01, cluster: 0001, size: 08, attrId: 0020, encoding: 20, value: 1e
But why this value is always ā1eā(30 in integer)
ā1eā will be calculated to 3.0V, so we always watch the battery 100%
Iāve used this battery few weeks, so it cannot be 3.0V correctly, maybe lower I think.
You guys solve the problem from the basis of zigbee function like āgetEvent()ā and " configureReporting()" and so on.
Your calculating function in handler code has no problem but maybe between zigbee function and ST function.
Please find out ASAP.
I have a project, uses ST contact sensor(I BOUGHT YOUR DEVICES ALREADY), in my company.
Because of this issue, I canāt open this system.
additionā¦
You use ādevice.currentState(ābatteryā)ā in calculating.
(I think this function needs volt value first, but volt calculation uses this functionā¦
Donāt you think this is kinda contradiction or makeshift?)
If this function is corrupted, all those calculation is gonna fail.
I recommend you check this ācurrentState(ābatteryā)ā function first.
Getting fed up of the bad support. When will we get the fix?
Send support a email, do a chat, rate the app in the app store and put it in your review. If youāve already contacted support contact them again and ask what the status is or when it will be fixed.
I did send 3 emails and got a answer.
āweāve been working hard to fix this blah blah blahā "change your batteries often"
about as useful as a chocolate tea pot.
1 Like
I got the same response
Itās a bit of a joke.
Any fix yet?
Almost two months now and this is still not fixed. Any update @posborne @Zach_Varberg @tpmanley ?
I donāt think they are going to from the tone of the support. If the response is make sure to change your battery often then that pretty much says you Sā out of luck pal.
Yeah, this is getting ridiculous.
Iām going to give support another email and if I donāt get decent resolution in a week Iāll file a better business bureau complaint requesting a full refund for each sensor this is affecting and buy sensors that work. I canāt have leak sensors show 100% battery and then magically go dead. Since support and the engineers that broke the sensors apparently canāt fix the issue maybe the group that handles those complaints can do something.
Also followed up on the GitHub issue: https://github.com/SmartThingsCommunity/SmartThingsPublic/issues/2428 since its being ignored here.
1 Like
I have 3 ST Multipurpose sensors that I purchased back in December of 2016. I have not replaced the battery in any of them almost a year later, they are all still working.
Albiet, one of the ST updates that created the whole issue with the battery always reporting 100% constantly is annoying so I am not sure how much life is left in them.
But, the one I use for the garage door / MyQ gets triggered at least 2 or 3 times day (6x open/closed) and I have not replaced the battery in almost a year. So from a longevity and reliability standpoint I havenāt had any issues other than the recent battery reporting % which is just silly for the fact that itās their own product.
They finally responded on GitHub and said they have been testing a fix for the last couple weeks. Not sure why they or support canāt just say that instead of leaving everyone in the dark and telling them to change their batteries often but at least itās something.
The issue is also frustrating because of how SmartThings sells their sensors. I have 5 leak sensors that list the manufacture as āSmartThingsā that all report 100% battery and 1 that lists as āCentraLiteā that reports 78% right now. So even though they look the same and were in the exact same packaging one works correctly and the other five do not.
I havenāt heard a thing on my pull request for the multiās from October 10th. I have 3 @ 80% and 2 @60%. Waiting on the next voltage drop to continue verification on the modifications. Change any of them back to the stock multi sensor and readings go back to 100%.