This is my first Device Handler - I’m still learning Groovy, SmartThings and Zigbee - so be gentle!
I picked up an Osram Lightify Switch Mini the other day, after reading another thread showing off a Lightify Switch that fit over an existing switch plate. This one is designed to be separately wall mounted, and provides a dim up, down and reset button, with short and long press functions.
The Handler simply sends events, and so will require a SmartApp like Dim With Me or Synchronized Dimming to connect it to a light or group of lights for dimming.
I’ve not managed to get my head around the difference between ZLL and ZHA. Are the clusters and commands different for the same functions?
One thing I did notice - the documentation asks you to hold two buttons to do “Touchlink” - is that a ZLL thing? Doing that with the ST hub in pairing mode didn’t work, however, holding the up and middle buttons (which wasn’t documented) resulted in the device pairing with the ST hub just fine. So yes, I got the device paired to ST without a Lightify Hub.
Could you point me to any resources that explain how the configureReporting method works? Also, is there a convention for the right state variable to store the battery level in?
I’m probably the last person to ask! I’m just learning about how to modify / write DTHs myself, using the learn-by-example method, and have mainly been focusing on helping out with improving community-created DTHs for ZigBee-based sensors sold by Xioami.
I skimmed through NXP’s ZigBee Light Link User Guide, and the ZLL profile uses a reduced set of ZigBee clusters (0x0000, 0x0003, 0x0004, 0x0005, 0x0006, 0x0008, 0x0300) and also has a special ZLL commissioning cluster (0x1000).
I did not read whether a ZLL device may also use other clusters. Battery level is attribute 0x0020 in cluster 0x0001, and I notice in the fingerprint line of your DTH, in cluster 0x0001 is listed, so perhaps ZLL devices can use clusters / attributes outside the set for the ZLL profile?
Touchlink is a Light Link only feature that allows direct pairing of a ZLL device to other ZLL devices without a coordinator (hub.) It makes use of the special ZLL commissioning cluster. I don’t think it’s of much use in a ST environment because presumably you’d be pairing other ZigBee devices with a ST hub, and just using this switch as a controller.
Regarding configureReporting, I started with ST’s ZigBee reference here. For an example ZigBee device DTH that includes battery level reporting, the SmartThingsPublic ZigBee Button DTH is probably a good place to start. You may have to play with the min/maxVolts values, and check if the raw reported value is actually the Voltage * 10.
I’ve got hold of one of these myself, and to start with everything seemed fine - it took a few tries to get it paired and I’m not sure exactly what button pushes worked, but eventually I was sorted.
Except…
It appears to also be switching two of my SmartThings power outlets. Every time. Instantly. This is only on physical button pushes. Changing the values from within SmartThings doesn’t do anything.
So, it appears I’ve managed to pair this directly with my zigbee sockets. Any ideas how to unpair it again?
I disconnected the switch (same button combo seemed to do this), left it a couple of days, did a Zigbee heal (powered off, batteries out of ST hub, wait ~30 mins) and the problem appears to have gone away. I’ve held pretty much every combination of buttons at some point, so I’m not sure what the actual solution was, but this may help someone else down the line!
Yeah, not entirely sure how the protocol works here. There are two ways to pair the switch, only one of them works with the SmartThings hub.
When initially paired, there are two (or 3?) applications on the switch that bind to a broadcast address, which the hub then passes on to all connected ZigBee devices. The DTH I wrote does attempt to reset that binding to make it direct to the hub, which should allow a SmartApp to use the events directly.
If you get problems like this again, could you post your hub logs during the pairing process?
I have the same problem. I suspect it’s an issue with the way I’ve written the Device Handler. Unfortunately I don’t have time right now to get to the bottom of it.
So I managed to get this working without doing anything to the DH. I had to the delete the device, do a zigbee mesh rebuild (15 min power off on the hub - remember to remove batteries) then add the switch again. Then it works as expected.
But the issue that other zigbee devices in home are also effected when a button is pushed is still there. I suspect that this is more difficult to solve.
Yup, I’ve got the same experience.
I installed the DH from Github, and used Smart Lighting to just tie the switch into my stairs light (just a random light I picked in the house to try it out). The button operates the stairs light as it should, and “Recently” on that bulb shows it turning on and off.
However it also operates my living room light at the same time - which is an Innr lamp that I’ve had installed for a couple of weeks, paired directly to my ST hub. In that case, the Living Room “Recently” does NOT show that it turned on or off, so the Osram switch is talking to that bulb directly for whatever reason. It feels like it’s just jumped on the closest bulb it could find when it was pairing?
It does not affect any other bulbs in my house - but they’re all Hue, paired to the Hue bridge.
@chalford quite happy to unpair / repair and do some logging if you like?
@chalford - I’m using your DTH which works great, I have one question. I’ve noticed then when it is On, it doesn’t resend the ‘On’ command when you press the On button. Sounds redundant except when you think that the lights in controls can be switched on by other means in Smartthings / Webcore. Do you know of anyway to force it to send the On (or Off) command when the respective button is pressed, regardless of current state?
.