Oops, my bad. I just noticed the Err 113 and didn’t even read the description 
For the button that generates read attribute reports on the normal “on / off” cluster 0006, I have never seen a read attr - raw: message come through SmartThings parse(description). The description always been presented as an on/off:
I don’t think the 25.x beta is parsing the message in the same way. However, I have no idea what is going on here, sorry.
Honestly, I am not a fan of how we are currently letting the users know what has gone wrong with the device, hopefully in the future we can refactor that to avoid scenarios where the user would have to dig deep.
1 Like
No it still does not work. On this DTH you can push the main tile and it will simulate pressing the button on the device. I used that a couple of times, so thats probably what you are seeing. But pushing the button on the device itself has no effect
Oh, interesting. So, what is happening is that the button is reporting the same attribute twice in the same message (cluster 0x0006 attr 0x0000) with both the 0 value (off) and the 1 value (on). Previously we had what I would call a bug in that we were stripping that second attribute value out and instead just sending it as an on/off message. Now that we have expanded the capabilities of our messaging to handle more messages properly, when I go to convert it to existing messages for backwards compatibility, it’s not matching what an “on/off” message would be because it has 2 attribute values included. I’ll have to think about to handle this as the previous behavior was a bug, but it was a bug that people developed against. In the mean time if you use
zigbee.parseDescriptionAsMap(description)
you should get back something that looks like
[raw:48A4010006100000100000001001, dni:48A4, endpoint:01, cluster:0006, size:16, attrId:0000, result:success, encoding:10, value:00, additionalAttrs:[[attrId:0000, attrInt:0, encoding:10, value:01, isValidForDataType:true, consumedBytes:8]], isValidForDataType:true, clusterInt:6, attrInt:0]
which includes both values for the attribute (one in “value” and one in “additionalAttrs”). Also use of zigbee.getEvent should generate an switch event based on the first attribute listed.
1 Like
EDIT: Ah, well things seem to be reporting fine now…
2 Likes
Not much to add here except to say that the level of involvement and transparency from the SmartThings staff on this beta has been very refreshing!
7 Likes
@veeceeoh Anything we can do to get the Xiaomi Aqara button working on this new FW?
Yes, but I am heading out of town and won’t be able to look at it until Sunday at the soonest. I am joining the beta testing to make sure any code changes will work correctly.
1 Like
I added a Zen Thermostat back to SmartThings that I had moved to another platform in order to test this firmware update. Unfortunately, that was before I read this post. But I see it’s in yesterday’s update still. Is it still a problem? If it’s not believed to be a problem, I definitely have some: most of the “smart” functionality on my thermostat no longer works after upgrading, including changing the setpoint, and changing the mode to/from off/heat/cool, or properly reading the idle/heating/etc. states (“idle” actually does seem to be read correctly, but I’m not sure about the rest). Functions that do seem to work include the reporting of the current temperature, changing the fan state (auto vs. on, though I’m not sure the tile properly updates), and battery reporting.
If this is supposed to be working now, I guess this is my report that it’s not. Otherwise, hopefully we’ll have a new update that will restore this functionality or the ability to downgrade to a working version.
It looks like you’re running the new Zen firmware. So we would have expected your thermostat to be working fine. Please log a bug in Centercode, and we’ll seek a resolution as quickly as possible.
1 Like
We’re about to release 0.25.16 to the remaining beta testers who haven’t received it yet. Please let me know if you don’t receive the update today.
1 Like
Note that we’re still not releasing the beta firmware to Zen thermostat users in light of the issues reported by @BertABCD1234. We’re investigating that issue now and will let you know when we have a path forward.
3 Likes
@Kianoosh_Karami at this point should we be able to successfully pair devices using S2? Or is everthing falling back to S0 until the app update?
Yeah Jimmy, I will keep you in the loop but for now let’s just say we are targeting April-May timeframe to release S2 functionality in the App.
Sounds good. Just making sure we aren’t supposed to be seeing any successful networkSecurityLevel for S2 at this point.
Anyone seeing “this device is unavailable” on NYCE Open/Closed Sensors? I’m still getting it on 25.16 although opening and closing the door fixes it temporarily…
yes, but that isn’t a hub firmware issue. Something it up with that device handler and/or device health.
@Kianoosh_Karami, @cbaumler, @Zach_Varberg
Check out BUG-0031 please.
Firmware : 25.17
Title : Manually using any zwave device does not update the mobile app or the IDE
I’ve tested with almost ALL of my zwave switches, and the results are the same. Here are just a few so far:
Nook Ceiling Lights
Downstairs Lights
Guest Room Fan
Screened Porch Fan (Leviton)
Screened Porch Fan Lights (Leviton)
Master Bedroom Reading Lights
Master Bathroom Mirror Lights (and every other zwave switch in the Master Bathroom Group)
etc, etc, etc
This is happening on any kind of GE zwave device I have (brand new or old: zwave, zwave plus, dimmers, fan controllers), as well as my Leviton device. I believe my Aeon micros too, but I can’t verify.
I honestly don’t know when this started but I just noticed this morning. Using the device manually works fine, but it does not update in the IDE or mobile app (Classic).
But:
If I tap on the refresh tile in the mobile app, the IDE will update and so will the mobile app. Seems like the Refresh tile must be used to properly reflect the device’s state.
This is easily repeatable. Going to need some help on this one guys because I’ve never seen this behavior before.
EDIT : Looks like my Linear garage door controller is doing this too.
EDIT : Looks like my August Pro Lock is doing this too (Front Door Lock)
Without knowing proper device states, ALL my automations and SmartApps are currently unreliable and not useful.
1 Like
Did you try to reboot your phone? Sometimes I’ve noticed it’s an issue with the sync with the ST mobile server.
To verify you can open the IDE and check the latest device state for your device. If it’s showing the correct value there then it’s a ST mobile server sync issue. If it’s showing the wrong value in the IDE it’s most likely to do with the hub.