All my buttons show 0% battery from last night. They all are working and changing the battery makes no difference.
What DTH are you using?
Stock ZigBee Button.
I Believe they have made backend changes which is causing math calculations to be wrong or bad code has now become errors. My smartapp is now full of errors
There was a change yesterday which is causing this for devices using the zigbee-button, nyce-motion-sensor, or nyce-open-closed-sensor device handler. It may also be impacted custom devices which use this:
result.value = Math.min(100, (int) pct * 100)
The above can be changed to
result.value = Math.min(100, (int) (pct * 100))
result.value = Math.min(100, Math.round(pct * 100))
We’re looking at a hotfix and I’ll keep this thread updated.
We upgraded major versions of Groovy yesterday for executing SmartApps and DeviceTypeHandlers, which included some rather major changes to the language.
If you want to DM me I’d be happy to help you dig into the issues that you are experiencing
This…seems like something that may have been good to commmunicate.
Don’t you know that Samsung’s slogan is to “always be proactive, after the fact”?
wouldn’t it be more useful to start a topic with whats been deprecated/added/updated
There appears to be quite a few apps & dh that are now getting errors
currently my error is
What’s the full error?
thats all i get in the ide logs
Support has been fantastic and it looks like a fix is in the works.
A hotfix was deployed. If your device is still reporting 0%, try tapping the “Refresh” tile in the Classic app or remove/re-add the batteries.
Can confirm all is good now. THANK YOU!!
Hmm, I took a look but nothing is standing out.
If anyone is seeing strange behavior since about 2018-09-06 12pm EDT yesterday, please flag it. We’re working to address other issues such as this but may miss the obscure errors.
What version of groovy is it using now?
Anything devs need to watch out or change for a smooth transition ?
Thanks. Looking at the release notes I came across this:
- The extension methods for the
java.util.Dateclass are now in a separate
groovy-dateutilmodule which isn’t included by default when using the
groovy-allpom dependency. Add the additional module as a dependency if you need it or consider migrating to the java.time JSR-310 classes (similar Groovy extension methods exist for those classes and they are included by default when using the
Any changes required to SA/DTH using
Date class methods or is that compatibility inclusion/naming handled internally by the platform?
C’mon guys. Why can’t you communicate this stuff - or better yet, not make changes that destroy basic functionality??
i would hope they keep the code base update. but communication is nice. Did SmartThings ever update to Grails or whatever they were thinking about back in the day?