RBoy
(www.rboyapps.com - Making SmartThings Easy!)
1
Apparently there was some sort of a platform patch or upgrade yesterday which is causing all SmartApps and device handlers to throw a number format exception when they try to read any attribute which has a value of null:
log.trace "${device.currentValue("tamper")}" is throwing java.lang.NumberFormatException if tamper value is null
if (device.currentValue("someAttribute")) , if the someAttribute value is null, it’s throwing an exception java.lang.NumberFormatException
Hmm, interesting. Lots of weirdness going on today. One thread has a user lose devices in Classic while they’re still there in the new app, while another user is experiencing scheduling issues, and I just noticed this in the last hour: (note the unit format change)
I know it’s off topic, I apologize, but I find all this pretty coincidental… There is planned maintenance going on, so maybe related?
More weirdness going on. Before and after screen shots from my water meter. Where some states had nothing, they now have “null”, and there are new states that have showed up? Love the back end changes we never hear about until something breaks…
Those are the attributes of the Health Check capability that you haven’t given a value. You’ve just used checkInterval. Normally they don’t get displayed if they haven’t been used. So that would probably tie in with the original post.
To be fair, this one was announced in advance, just without any details, and updates are currently in progress, so no telling exactly where they’ll end up.
Event pipeline planned maintenance
.
Maintenance in progress
.
Scheduled maintenance is currently in progress. We will provide updates as necessary.
.
.### Time posted
.
May 19, 10:00 EDT
I had some of my custom SmartApps, like BitBar, get and set a currentBattery level to ‘null’ which caused all the parent and child devices to go MISSING from a room. I had to quickly diagnose and then update the BitBar’s AppToucher’s routine to manually check for a null battery value and reset the battery to 100% just to resolve this! Users were thinking I had changed the application and sending me problem reports.
I never thought that a capability like battery = null could take down the whole device display! This has also been a problem with RGB bulbs not reporting current color. Ugh!
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
8
Not rectified yet, unfortunately even accessing an attribute with a null value is throwing the exception. In many cases it’s valid to have a null value since they represent uninitialized or unsupported attributes.
A simple example, if the tamper attribute is not initialized it should be initialized otherwise the new ST app won’t show the state on the device page. On the flip side if it’s initialized you don’t want to reset it otherwise you lose a valid state. Thus the only solution is to check if it’s set to null and the moment you do that the platform throws an exception.
Infact for devices which are disappearing or not show up after pairing, this is also an issue. If there’s an exception during the update or installed methods the app doesn’t show the device (even though the IDE does).
I’m completely unable to load my hub or device list in the IDE (just get an error 500: server error) and my app will not load my devices either - it just says “Something’s Wrong - We can’t load your screen right now.” Could this be related?
Looks like it may be broken again. Anyone else having issues?
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
14
Yes, something else happened in the ST database which is breaking virtual devices attributes. Deleting the devices and recreating them seems to fix it (sigh…)
Unfortunately any SmartApps using these devices also start throwing errors until the delete the devices.
Something else is going on with smartthings in general. Most of my devices don’t work or aren’t working properly. I’m seeing a lot of errors. Just trying to turn off or on a light, I get the following
Do we know that we have to delete and re-create the devices? Doing so will require setting up all automations and smart apps that touch those devices, so I guess knowing if there will be an alternate fix would be helpful.
1 Like
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
17
Correction, not just virtual but I’m seeing that attributes from many devices (virtual and physical) have been wiped clean which is making the smartapps read the attribute as null when they query it.
Both of these were enabled and hour ago. Now many of my devices using these attributes are showing them a empty (i.e. null). Tagging @tpmanley
The temporary solution is to reinitialize the devices depending on how the DTH is written, excluding/deleting and pairing them again/recreating them does solve the issue (because this re initializes the attribtes) but it doesn’t get to the root why the platform wiped them clean as it may end up happening again.
I had some of my custom SmartApps, like BitBar, get and set a currentBattery level to ‘null’ which caused all the parent and child devices to go MISSING from a room. I had to quickly diagnose and then update the BitBar’s AppToucher’s routine to manually check for a null battery value and reset the battery to 100% just to resolve this! Users were thinking I had changed the application and sending me problem reports.
