Has anyone managed to get one of these working?
https://www.quirky.com/shop/706
I was trying to look at the IDE but honestly had no idea how to even start =(
It’s zigbee and it’s been reported that it can be connected but nothing further.
@wackware just posted this: Pre-Release of Quirky (Connect) Service Manager and 7 Devices
Sounds like SmartThings will work with any device that does not require the Wink hub.
I know this may be a bit confusing (my bad), but Quirky says that the Wink Hub or a Wink Relay is required for all of their new devices, Tapt, Norm, Tripper, etc… The only ones that don’t are the older devices that are the 7 that I listed. They work by using your home’s WiFi.
The new Wink devices should be able to used without a hub because they are ZigBee. Someone will have to develop a device type for them to speak the specific ZigBee commands that is needed to control them. I have ordered a tripper, should be here next week. I’ll see what I can do to get it going.
I hope I made some sense.
3 Likes
I just received mine and I’ve made some good progress on a device handler for it. It’s based on the SmartThings Open/Close code and a brief glance at the ZCL docs. I have some checks in there for the tamper alarm, but don’t have it wired to anything. Comments and contributions are welcome.
5 Likes
Awesome. They’ve gone from door stops to door sensors. Well, you get the idea. Thank you! Battery level is not reported, but otherwise I can’t complain.
Works great! Thank you so much.
Not reporting battery level but I can live with that.
Battery level will report, but it’s being finicky right now and only seems to send the report if the door opened and closed after requesting it (hitting refresh). It does also send a battery status (low or OK, no voltage) with it’s open/closed status report, but that one is just being logged currently. I could probably have the sensor send a periodic update with the voltage, but don’t want to drain the battery constantly updating that. What’s a good reporting interval for that? Hourly?
I’m going to play around with that aspect a bit more when I have more time this week.
Edit: found some time at work 
but can’t test it until I’m home. I believe that it should now request a battery update upon open/close.
It will periodically report automatically on battery level change. You don’t need to call for it.
Add the cmd + refresh() like the smartsense open/close sensor and you’ll get the initial battery report on pair.
I had that in there initially (and I’ve added it back now), however it never sent an attribute report for the battery level. Not even an initial report on pair. If I hit refresh and then immediately trigger the sensor, it sends the report. It doesn’t seem to respond to anything unless it’s in pairing mode or the command comes in around the same time as a physical state change. I’m hoping I’ve just made some kind of silly error in the report configuration. Otherwise the low/OK battery status that comes in with the IAS zone status report may have to suffice.
I’ll play around with it when I can dedicate some time to it later.
Is there a good source for understanding the zcl global send me a report commands in the configure for zigbee devices? That’s the one area of zigbee device types that I haven’t been able to fully understand, and ST doesn’t address it at all in their documentation. Is it just sending a configure reporting command? Would you or @mitchp mind breaking down the examples in this Tripper code?
Thanks!
My understanding is that it’s based on section 2.4.7 of the ZCL spec.
the first parameter being the target cluster, then the attribute identifier, data type, minimum reporting interval, max interval, then reportable change. If I’m wrong here then hopefully @wackware can correct me (and that might explain why I’m not getting the reports I’m expecting…)
You’re right. The docs don’t really spell this stuff out and the tools have a lot of room for improvement. The spec says that there are supposed to be responses to these commands, but I feel like the hub isn’t reporting all of the back-and-forth between it and the devices. I’m certainly not seeing the Configure Reporting Response packets if they’re coming in at all.
Thanks! That makes it easier to follow. So are you receiving messages where the command comes through as “0a”? I think that’s what the reports should come in as. When I’ve seen that as part of the GE Link bulbs, it had a “read attr” beginning. But like you, I was only getting those messages when I sent a read command out. Otherwise I was receiving a very similar message, but with “08” or Read Reporting Configuration notation.
I had no issues messing around with Hues and Links and getting the expected responses. With the Tripper, it doesn’t seem to respond to rattr commands unless I send them within about a second of tripping either the contact sensor or the tamper button. When I do that: success. I get my battery voltage attribute. I have yet to receive a periodic battery status report.
It just seems to me that the sensor wakes up on a physical change, then goes idle again and doesn’t respond to commands. I’m sure this behavior saves a ton of battery life, but makes it hard to communicate with it outside of the initial pairing. It doesn’t seem to behave exactly the same way the SmartSense Open/Close does (from looking at the code. I don’t have one to play with)
This sort of makes sense since it’s not measuring temperature, luminance or anything else that you’d really need to poll at random times.
Maybe there are some Zigbee geniuses here that could shed more light on this.
I don’t think of it as a Zigbee thing, I think of it as a battery powered device thing. Most battery devices sleep until, 1. They report a change, or 2. They awake on a schedule and notify associated points they’re awake and wait for commands a few seconds before sleeping again.
That’s what I figured. Didn’t mean that the sleep behavior was a Zigbee thing, I was referring more to the syntax of my commands, right clusters, attributes, etc. being correct. If those are correct and the device is just ignoring me to save power, then I don’t need to waste my time running in circles trying to get it to send periodic battery voltage reports. I’ll try a couple more things before I just change the level reporting to use the OK/Low response.
It’s fun coding against a black box when you don’t completely know how it’s supposed to behave 
Apologies for a newbie question (even after going through the SmartApp tutorial), but when I try to add the code to a new SmartApp code window, I get the following error code:
groovy.lang.MissingMethodException: No signature of method: script14208269655752099199587.metadata() is applicable for argument types: (script14208269655752099199587$_run_closure1) values: [script14208269655752099199587$_run_closure1@236f8af8]
Possible solutions: getMetadata(), getState(), setState(java.lang.Object), metaClass(groovy.lang.Closure)
Again, I’m sure it’s something obvious that I’m doing wrong, but can anyone help a newbie out?
This is a Device Type, not a Smart App. Create a new Device Type and paste it in and it should work!
That makes so much more sense.
Thanks very much! Works perfectly!
@mitchp is your battery reporting only values divisible by 11? 77, 88, 66?
The math in the ST device code is the cause.