Why would you consider getting rid of the Hue Bridge? Such a useful addition.
1 Like
If a second (OK, fourth...) Hubitat can do everything for me, I could just use that and use non-ZLL bulbs like Osram and Sengled without having to mix LAN and Zigbee calls while theoretically being able to leverage Zigbee group messaging (which Hue will do itself if you expose groups, but I don't--I rarely want everything in a room on at the same time, and I'd consider sticking with Hue if Hubitat supported Hue scenes, but it doesn't, while also not supporting "real" Zigbee scenes so it's kind of a wash right now...but maybe some day 
).
1 Like
I try not to run custom code for lights (I have them running on a dedicated hub to ensure it's as fast and reliable as possible), but I did experiment with an early port of Hue B Smart on my test hub. Nothing disastrous, but I don't think it supports the startLevelChange and stopLevelChange commands (probably could add it--in guessing Hubitat's Hue integration fakes this with repeated dimming commands but I don't know), which I like to have for my Pico remotes, and once I noticed a light that should have been turned off staying on. I'll probably try it again sometime to see how it works now.
There are issues with delayed command response in my experience, another developer attempted to improve it but gave up.
1 Like
Decent news! I sort of got this working, but I don't know Zigbee well by any means and could only guess and what to do in the driver based on what messages I saw in the catchall the device was sending. This driver appears to work for most functions, which are turning left or right (it doesn't send an event for each--it just continually sends a number representing the current level, apparently stored on the device, and will bottom out at 0 and top off around 254 or 255, which I convert to 0-100). Pressing the button also sends an event.
It would make sense for this to be a button device, with one event sent for a left turn and another for a right turn, or ideally maybe even one event sent for a small turn and another for a large turn (or an event sent on the starting and stopping of a turn). Unfortunately, I don't see that happening. It stores a number that represents the level it thinks it's at, then repeatedly sends a new level as you turn the knob, based on how far you turn it. It seems like it would be possible for someone to write a driver that works with this data and fakes the ideal scenario I describe, but I don't know how well that would really work. So instead, I have this implemented as a Switch Level device, effectively acting as a dimmer (it might be possible to send a level to the device, effectively syncing it with a real bulb or dimmer--but I don't know enough Zigbee to see; but it would certainly be usable in at least the other direction as-is). Because I had to do that, I also mapped the button press to the Switch capability, with a press toggling it on or off. It would make sense to implement that as a Pushable Button, and you certainly could, but I did it the other way (I suppose it could also do both) since I had to use Switch Level to make the rest make any sense, and this way you could use it as some sort of dimmer device "bound" to a real bulb/group/dimmer/etc.
Here is what I've figured out so far:
/**
* Partly based on source originally copyright 2018-2019 SmartThings
*
* Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
* in compliance with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
* on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
* for the specific language governing permissions and limitations under the License.
*
*/
import com.hubitat.zigbee.DataType
metadata {
definition (name: "Lutron Aurora Dimmer", namespace: "RMoRobert", author: "Robert Morris") {
capability "Actuator"
capability "Switch"
//capability "Pushable Button"
capability "Switch Level"
capability "Configuration"
fingerprint profileId: "0104", inClusters: "0000,0001,0003,1000,FC00", outClusters: "0003,0004,0006,0008,0019,1000", manufacturer: "Lutron", model: "Z3-1BRL" }
}
// Parse incoming device messages to generate events
def parse(String description) {
logDebug "description = $description"
def event = zigbee.getEvent(description)
if (event) {
if (event.name=="level" && event.value==0) {
log.debug "level = 0"
}
else {
log.debug "sending ${event}"
sendEvent(event)
}
} else {
def descMap = zigbee.parseDescriptionAsMap(description)
if (descMap && descMap.clusterInt == 0x008) {
log.debug "8 data = ${descMap.data}"
logDebug("Button turned, setting level from device data")
def dataList = descMap.data
if (dataList.size() < 3) {
logDebug "Ignoring data ${dataList}"
} else {
int deviceLevel = Integer.parseInt(descMap.data[0], 16) * (100/254)
logDebug "Device level = ${deviceLevel}"
setLevel(deviceLevel)
}
} else if (descMap && descMap.clusterInt == 0x0006) {
logDebug("Button pressed, toggling switch")
sendEvent(name: "switch", value: device.currentValue("switch") == "on" ? "off" : "on")
} else {
log.warn "DID NOT PARSE MESSAGE for description : $description"
log.debug "${descMap}"
}
}
}
def off() {
sendEvent(name: "switch", value: "off", isStateChange: true)
}
def on() {
sendEvent(name: "switch", value: "on", isStateChange: true)
}
def setLevel(value, rate = null) {
if (value == 0) {
sendEvent(name: "switch", value: "off")
} else {
sendEvent(name: "switch", value: "on")
sendEvent(name: "level", value: value)
}
}
def installed() {
sendEvent(name: "switch", value: "on", displayed: false)
sendEvent(name: "level", value: 100, displayed: false)
//sendEvent(name: "pushed", value: "1", displayed: false)
//sendEvent(name: "numberOfButtons", value: 1, displayed: false)
}
def configure() {
zigbee.onOffConfig() +
zigbee.levelConfig() +
zigbee.enrollResponse() +
zigbee.readAttribute(zigbee.POWER_CONFIGURATION_CLUSTER, 0x20)
}
def logDebug(str) {
log.debug(str)
}
Again, I do not know much about Zigbee and had to figure this out based on what the device was sending according to logging events I made. I am likely missing functionality that could be better implemented if I understood better what all the clusters were. As-is, this does seem to work for me to report turns and pushes, though unfortunately not in the way I'd like the device to actually report them. Still, if you want to use this device on Hubitat, it's a promising beginning. If you're not in a hurry, I'm sure Mike will get his hands on one sooner or later (I'd even send mine to borrow if desired) and write something that works a lot better if he thinks the device is worth it.
Where did you get it?, amazon only has then for pre order, delivery mis next month...
I pre-ordered mine from the Hue online store (where Lutron also redirects to) when it was first announced. I think they've started arriving for early orders already, having seen at least someone on the ST forum with one too.
I just got my Amazon pre-order a few minutes ago.
When I paired mine it showed up as 'device.' I expected something like that, but I get no feedback in any logs at all. Even after I tried installing your device driver, I see nothing whatsoever. I know the dimmer is working when I previously paired it directly to my Hue bridge. Should't I see at least garbage output from the dimmer, regardless of proper driver?
This might be a silly question, but you said you installed the driver. Did you then go to the device and change the driver to the correct one? (I have to ask. 
) Assuming you did that, did you hit "Configure" after making the change? (You won't see this do anything. It sends configuration to the device.)
As you turn the knob, you should indeed see logs but also the "level" attribute changing. Presses should toggle the "switch" attribute on/off. (So the best way you can probably make this work on Hubitat, assuming this works for you, is mirroring it with one or more "real" bulbs or groups.)
Yes, I installed the driver just like I normally would in the ST developer console, and changed it on the device itself. I decided to delete, reset, and re-pair the dimmer, and it came up first-time as the new driver. Also, there's output in the logs.
I then created a simple dimmer rule in RM4.0 and told it to react on changed -- then for the action, control dimmer and FOLLOW event dimmer. Now it works exactly like you'd think.
Not so sure how to get it to follow the button press yet, but it's showing promise.
I have dimming and button-press working now, without modifying the driver code at all.
and for the button itself:
The only issue I'm seeing is that it's not super graceful when you get near the extremedies of the dimming range, and also it doesn't properly discard duplicate level-changes... it doesn't feel super natural. I think I can tune this on the RM side, but some changes will likely be needed on the driver. I'll see what I can do tonight -- maybe from Happy Hour.
Thanks for the code @bertabcd1234!
What I'd like to do is change the driver to use a button object instead, so maybe I can get long-press and double-tap out of it. Assuming it even sends that over Zigbee. I saw no indication of that in the Hue app earlier, so we might be SOL and have to work with RM on toggle-logic.
just ordered one...
Is the install on these as simple as it looks? What about the aesthetics of it? Look and feel nice?
Thinking about ordering me one or two as well.
As far as I can tell from what's coming from the device, it doesn't do this either. It would be fantastic if this worked as a button. Pressing it could certainly send "button 1 pushed" or similar since that event clearly happens, though I only have that toggling switch now. For turns, it might be possible to do a little math and fake it in the driver (e.g., send button 2 pushed if turned left, which you can tell if the level is decreasing, send button 3 pushed if turned right with similar logic, etc., but you'd need to be able to "wrap around" when it reaches 0 or 254; with a bit of a delay, you could probably also fake a "release," though I'm not sure that would be useful). However, I'm not sure how well any of that would actually work.
Mike will undoubtedly do much better work than this now that he's ordered one, though how well the limits of the device will constrain the possibilities are TBD.
2.1.4 will have a built in driver for this device.
2 Likes
Yes, this...
