ST Multi-Sensor battery reporting issues

Thanks, I think I did get one submitted. I could have used those instructions al little earlier :wink: . 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.


You use “device.currentState(“battery”)” in calculating.
(I think this function needs volt value first, but volt calculation uses this function…:frowning:
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: 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%.