Documentation error for Valve or platform bug

General Discussion
1

According to the docs, Valve is supposed to use the attribute valve and not contact

http://docs.smartthings.com/en/latest/capabilities-reference.html#valve

Couple of things I’ve seen so far:

  1. The ST stock DH (GitHub) for Z-Wave and Zigbee still use the attribute ‘contact’ instead of ‘valve’ - is this by design or something that needs to be updated - @Jim
  2. The platform still seems to be returning the value (open or closed) for the attribute ‘valve’ (given point 1 above I’m assuming that the platform is internally converting contact to valve and reporting to the SmartApps), however the Zigbee devices are behaving differently from Z-Wave devices, there appears to be a lag or inconsistency in reporting the value for valve for a ZigBee valve vs a Z-Wave valve.

If the platform is internally converting contact to valve there’s a bug somewhere which is causing the values to go out of sync

@bflorian @slagle - any thoughts on 2 above?

What should one use in SmartApps, valve or contact ? @Jim

1 Like
2

ActionTiles has been using the Attribute “contact” for Valves.

(FYI: The SmartThings docs are on a public GitHub, so you can check the change history yourself.)

1 Like
3

Yes I know, wanted clarification from ST on why valve works but is delayed / not in sync with contact if the docs says that one should use contact. Also shouldn’t the DH’s be updated to use valve instead of contact?

1 Like
4

  1. The only way Attribute “valve” could possibly work is if it is explicitly added to the DTH. In which case, the delay is in the DTH code.

  2. SmartThings has no organized process to ensure DTHs and SmartApps are updated when there is a Capability specification change. It’s a rather serious situation that Platform companies solved eons ago with notification and deprecation procedures.

1 Like
5

According to the SmartThings Documentation Repo, Valve changed it’s Attribute from “contact” to “valve” about 6 months ago. I presume that is plenty of time for SmartThings to update their pubished DTHs; and plenty of time for the Community Developers to be notified – if this Community had an “Announcements Category” … oh wait; it does! :confused:

https://github.com/SmartThingsCommunity/Documentation/blame/28e3c3c53511816ce4d4f8f24223b712f3ded823/_static/capabilities/valve.src/valve.properties

1117×378 35.5 KB

904×432 30.1 KB

6

Well its still leaves the question open, @Jim do you want me to submit a Git request and change the ZigBee and Z-Wave attributes to valves for the DH’s or should the documentation be changed back to continue using contact?

7

Not sure if you’ve seen this @RBoy. Appears they are changing the DTHs.

https://github.com/SmartThingsCommunity/SmartThingsPublic/pull/2026

2 Likes
8

Awesome thank you, looks like was it committed an hour ago so I guess it answered my question, ST is going to move from contact to valve. @tgauchat ActionTiles may also need an update (unless you’ve coded it to be dynamic).

@workingmonk will it go into production this Friday?

1 Like
9

Ideally, for a planned deprecation process, the DTHs should offer both Attributes “valve” and “contact” to ensure a smooth transition for the possibly dozens of affected SmartApps out there.

But … oh well. Luckily this is a just a front-end change for ActionTiles. Not sure when to implement our side of the change though, since no official announcement of the cut-over time. And not sure what we are going to do for users running suddenly “non-compliant” DTHs.

(Yes… I’m acting more annoyed about this than necessary :rolling_eyes: … but one can dream that the process will improve when this happens with the next affected Capability, right? :smiley:).

1 Like
10

Changes go to prod on Tuesdays for Device Handler and SmartApp changes. The change for events is going out tomorrow and the changes for tiles are going out next Tuesday.

2 Likes
11

We are sending both the values for compatibility with existing smartapps that would be relying on the contact events for these devices.

2 Likes
12

Is there an end date for the contact event in the stock DH? i.e a migration roadmap by when SmartApps would need to update themselves otherwise it’ll create confusion, new DH’s being developed with valve where as new SmartApps now don’t know what to use, contact to support old DH’s or valve to support new DH’s?

1 Like
13

Thanks, bud!

I know one reason I’m obsessed with this thread, though…

Glance at my post from February 2015:

Y’all know I’m not a SmartThings employee; but this isn’t the first time that I was prescient! :smiling_imp:.

14

@workingmonk just wanted to check in if the patches are in production/firmware (both SmartApp and platform changes)

15

Yeah, the platform changes for those device types went out. If you see any issues, let me know.

1 Like
16

@RBoy since we didn’t have a firmware update to change the DTH running locally, we need to revert the tiles back to contact :cry:
The revert should go out next Tuesday

We’ll fix the tiles back to valve with the f/w changes scheduled for next month.

17

?? correct me if I’m wrong, with 17.x firmware series ST can push a patch instead of a whole firmware. Not possible to send a patch for the local DTH?

So from a SmartApp perspective it would need to go back to subscribing to contact AND valve (to make it future ready). I’m wonder how that would play out, it would lead to 2 notifications in that case right?

1 Like
18

Two identical Events seems likely to me; … I guess the SmartApp could filter one or the other, but that’s a pain.

This is a great reminder of how difficult it is for Capability (API) specifications to be changed. How do platforms with millions of developers and users do it?

1 Like
19

God royal yes, we’re working on a double/triple tap SmartApp and it’s a royal pain to filter out extraneous events, looking at timestamps etc.

@workingmonk any suggestions on best to handle this in the SmartApp to make it future ready? or any change of a mini firmware patch

20

Yes. The bug that we fixed was that the DTH was only generating ‘contact’ events. The new change generates both ‘contact’ and ‘valve’ events. With 18.x, we get the change so that locally executing DTHs do the same.