Ugh… it’s always some randomly weird issue with this platform though.
Same here completely out of the blue… I’ve had the master bedroom lamp connected to this device for YEARS now, and all of the sudden it starts acting up today.
Switched the DTH to the one in the other thread and it started working automagically.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
27
Well talk about kismet!
After assisting @Manarama quite a bit earlier today, I just discovered now that my garden lights had not turned on at sunset!
And, indeed, of all my various switches (ZigBee and Z-Wave) around my home, only 2 of my outlets are Aeotec Z-Wave Metering appliance rated plugs (the garden lights and a heater).
Hub V1 here, so I’m pretty sure that rules out firmware issues, since I don’t think Hub V1 has had a firmware update in many months.
Now I’m really curious as to what has changed in the standard Z-Wave DTH. Looking at the SmartThings public source code repo on GitHub now…
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
28
Indeed: There was a major “reversion” of the DTH code committed to Production 7 days ago (and likely deployed today … “rollout Tuesday”).
Just for the sake of random cross-reference, the Live Logging error also occurs if I manually claim the device is a Z-Wave Metering Dimmer, except it’s DTH has matching code at Line 300.
@Brad_ST: Please note this for your Support team? Per @Manarama, removing and re-adding the device may fix the issue; I have not tried this, yet, as my 2 affected outlets are not easily accessible.
The quickest solution to get the Outlet Switch working? Just manually change the Device Type in the IDE to “Z-Wave Switch Generic” (or possibly a few other usable choices).
@workmonk: Tagging you, since the Commit Blame is associated with your GitHub handle. I’m not finger-pointing; but the diagnostic trail has to start somewhere, of course. I certainly could be completely wrong with this analysis. I have not attempted any debugging, nor or trying to use an earlier production commit of the DTH code.
just looked at mine and all the 3 devices using Z-Wave Metering Switch have the same debug message, they all seam to be responding to commands in the app though
I suspect this bug only affects Aeotec Switches (and perhaps only certain specific models of Aeotec (certainly only those with Metering). It may also affect those using a very similar underlying protocol quirk; i.e., this could be the fault of Aeotec – I guess SmartThings can’t test every model of every device?
I’ve tagged the devs and we should have an update in the morning. Looks like a simple NPE catch, but want the z-wave experts to take a look at this before we hotfix this.
Just noticed all my Aeotec Smart Switch 6’s have all stopped working - all using the “Local” DTH ‘Z-Wave Metering Switch’ makes me wonder what is the point of local processing when a change in the cloud can make them become unusable anyway.
Glad I found this thread before getting the Zigbee plugs out
I’m in the same boat here. So it seems that there are two “solutions” currently. 1) Remove and re-add the devices or 2) Change the device handler
Neither of these are ideal from a user standpoint. Especially for things that have been working fine for years, but all of a sudden no longer work because of a server side change.
Even after the hot fix had been applied I still was having issues with some of my Aeotec Switch 6’s - in the end I found changing the DTH from Z-Wave Metering Switch to Aeon Outlet seems to have made them all work.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
41
That’s because the “hotfix” did not revert the broken code … Apparently only a bandaid was applied (IMHO)… i.e., protection against fatal NPE, not a fix of the underlying assumptions and non-NPE consequences.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
43
Null Pointer Exception… generally results in a fatal error.
The Device Handler was aborting due to the conditional statement expecting a value or object that doesn’t exist (i.e., the referenced variable is pointing to nothing … null), in some circumstance. Perhaps only for Aeotec devices…
Groovy makes avoiding NPE’s easy by using the ? indicator in the object reference, it will simply return “false” instead of an error.
While that adds some degree of safety, it is not necessarily good programming practise. If a section of code is expecting a value in an object, then there ought to be a reason that the value is expected, and if no value is found, that could be symptom of a serious problem elsewhere in the code. In other words, covering NPE with a bandaid “?” indicator, might really be hiding a festering wound underneath. That’s why strict languages do not provide such shortcuts. Groovy allows sloppy coding. … and yes… this can become a nasty “religious” discussion really quickly.