Yep, you are exactly right about the dimming below 7. I noticed that in the logs earlier today. Another easy fix, we just use the existing hex function.
def setLevel(value) {
def cmds = []
sendEvent(name: "level", value: value)
def level = hex(value);
cmds << "st cmd 0x${device.deviceNetworkId} 1 8 4 {${level} 1500}"
log.debug cmds
cmds
}Adding the following to configure seems to make it dim on/off (~.5 second transition)
`
// Transition Time
"st wattr 0x${device.deviceNetworkId} 1 8 0x10 0x21 {0005}"
`
Where might one add this code?
@urman Is there a way to reconfigure devices that have already been added? Basically force the configure method to fire? Without removing and readding things?
Today is my first foray into Zigbee stuff and I have almost no idea what Iām doing.
I made a copy of the GE Link Bulb device type in the ide (itās in the example code). Then added my command at the bottom of the configure function. I also added in setLevel from @kelchm
The bulb seems to lose the setting if it loses power. Not sure what to do about that (if anything)
Very good. Thanks very much for the explanation, @Dianoga. Worked perfectly.
@Dianoga: There IS a way to reconfigure previously configured bulbs. Edit each bulb in the ide, and change the device type to your modified device type, and change āPublishedā to āSelf-Published.ā Works like a charm.
You could surface the configure tile in the app. Tapping it runs the configure() method. Using the simulator is the most convenient though.
I applaud your ZigBee efforts and am willing to answer anything you got! Itās probably what Iām best at when it comes to device handlers.
@urman I assume I need to create the configure tile first. Unless itās a magic tileā¦ is it a magic tile?
I tried adding a preference for transition time in seconds, so that updating that fired off the write attribute command. I modeled it after the multisensor interval preference, but I couldnāt get the transformation from a simple integer to the payload format to work properly.
def updated() {
log.debug "Will set transition time to (${(settings.transitionTime ?: 5).toInteger()} seconds)"
state.config = true
}
"st wattr 0x${device.deviceNetworkId} 1 8 0x10 0x21 {${"00" + (10 * (settings.transitionTime ?: 5).toInteger())}}"
This groovy language is strange to me. Not much of a programmer, but a good bit of VBA at work to automate stuff. Is there a good primer somewhere? The documentation is helpful, but a good online tutorial to get used to the syntax and flow would be helpful.
Create the tile, like in the Aeon Multisensor
So after some testing with some of the code from above (code from @kelchm in particular), I found that the device had a hard time manually transitioning - it would almost ābounceā around when I tried to manually adjust to 100%.
Iāve noticed that as well, I havenāt had a chance to determine why yet.
Not the original purpose of the thread, but we seem to be updating the GE Link device typeā¦I noticed that the refresh() command was only updating level and not the on/off status. For instance, when the bulb showed off in ST, then was manually turned on; a refresh wasnāt updating the status to āonā. I updated the parse() using the below to pick up the two ācatchallā strings that the refresh() command generated for the on/off cluster to correct this. I also increased the delay between the two read attributes in refresh() to 1000 as sometimes the level read wasnāt showing up. Not sure if itās the best approach, but it seems to work. (sorry if the formatting copied in weird)
// Parse incoming device messages to generate events
def parse(String description) {
log.trace description
if (description?.startsWith("catchall:")) {
def msg = zigbee.parse(description)
log.trace msg
log.trace "data: $msg.data"
def x = description[-4..-1]
log.debug x
switch (x)
{
case "0000":
def result = createEvent(name: "switch", value: "off")
log.debug "Parse returned ${result?.descriptionText}"
return result
break
case "1000":
def result = createEvent(name: "switch", value: "off")
log.debug "Parse returned ${result?.descriptionText}"
return result
break
case "0100":
def result = createEvent(name: "switch", value: "on")
log.debug "Parse returned ${result?.descriptionText}"
return result
break
case "1001":
def result = createEvent(name: "switch", value: "on")
log.debug "Parse returned ${result?.descriptionText}"
return result
break
}
}
if (description?.startsWith("read attr")) {
log.debug description[-2..-1]
def i = Math.round(convertHexToInt(description[-2..-1]) / 256 * 100 )
sendEvent( name: "level", value: i )
}
}The value youāre passing to the hex() function is the level as a percentage (0-99), so you need to use the transformation (level * 255 / 100) to change it into a value between 0-255 to send to the hex() function.
I got this working with my Sengled Classic bulbs but cannot get to them to smooth dim when turning on/off. Does anyone know if this is possible?
Any luck? Iām just running into this same thing.
What a joke smartthings is, I just got a Hub v3, coming from a 1st gen Wink: no fading between dimming levels, no native handling of Schlage locks user codes/options.
Need to use third (paid) party DH/SmartAppsā¦
Custom DH loose local processing, new ST apps lacks functionality compared to the classic appā¦
Powerful it may be but steep learning curve and not user friendly AT ALL.
This thread was first created in 2014, 4+ years later and the default zigbee DH still doesnāt properly support transitionā¦
And yet SmartThings is thriving under Samsung ownership.
And Winkā¦ is unlikely to even survive as a business or product.
Why?
Becauseā¦Samsung? Theyāve got plenty money to throw at ST.
Wink sole distributor is HomeDepot in Canada and yes itās not doing so well because smart homes is a pretty niche market with smart speakers having the largest market penetration. But one canāt deny the fact that is it much more use friendly and for its limited capabilities and it does it rather well if you donāt run into some of its bugs.
Anyway, if ST is the future of smart homes then it is it will remain an even nicher product gathered for the thinkerers and geeks and not your average users IMHO.
My out of the box experience have been pretty lack luster, I was expecting more with all the hype surrounding ST, it is only thriving because of the community, its āhackabilityā and compatibility with a broad range of products and cheaper sensors.
Iām a web programmer but I donāt necessary want to fiddle with the Groovy IDE and muck with the inner workings, I want things to just work.
If I wanted that experience, I would have went with a DIY/OpenSource RPi solution or somethingā¦
Now, what is Samsung/STās position on fixing such thing? Create a thread under Features and feedback? Or is it because its something they wonāt fix? (Because thereās a workaround and they are leaving it to the userās mercy)