ZigBee scenes?

🛎️ Get Help
1

Hi guys,

Before buying a Hubitat, I asked their support on Facebook about functionality of using ZigBee bulbs(in this case Hue) directly with Hubitat.

Unfortunately, I cannot achieve the functionality that I was informed was possible. When I add a Hue ambiance bulbs, they are added as generic RGB ZigBee bulbs. I can then change them to generic CT bulb, for the temperature part of ambiance bulbs to become adjustable by Kelvin temperature. I can then create scenes with the wanted color temperature and brightness. However if I turn of the bulb, and activate a scene, the bulb only turns on to its previous setting. If I hit “on” for the scene once again while the bulb is now on, it changes to the specified parameters. This is far from the behavior I was informed about.

With deCONZ I am able to save scenes, say, Scene 1: 5% brightness - warm, scene 2: 100% brightness: cold. If I activate either scene, the bulb turns on straight into these configured settings. With Athom Homey, this was seemingly not currently possible. I asked deCONZ developers about this functionality, and they say it has to do with using the persistent storage on the bulbs to save scenes, that can then be called directly with a single command. This is supposed to be the one and only way to make these kinds of bulbs work properly, as ZigBee can only accept a single command at a time.

Apparently, no one else has implemented ZigBee integration in this way yet, which I really do not understand. Especially given the fact that the deCONZ code is right there to be inspired from.

Is the Hubitat going into the ever growing pile of incapable home automation systems I regret having bought, or is there any good solutions?

3

So, the other night I actually just tried adding Hue bulbs directly to Hubitat as part of an experiment I was trying using a second (OK, fourth...) Hubitat hub as a Hue Bridge replacement. I ran into the similar issues. I was wondering if there were bugs or if it was just me. Specifically:

I assume this is just mismatched fingerprint information in the Generic RGB Zigbee Bulb driver. So far, I've discovered that Hue White and Color bulbs and the LightStrip Plus get added as RGB (should be RBGW) and the Hue White Ambiance gets added also as RGB (should be CT). I think these are all third-gen, though I have some older (and maybe newer/3.5-gen?) ones I'll probably try at some point too. @mike.maxwell usually writes these drivers, so if he doesn't have any bulbs to test with, I'd be happy to re-pair mine and get the fingerprint so they can correct this (unless there's some reason I don't see why RGB is actually the desirable outcome).

I noticed this too (and yes, I clicked "Configure" after changing the driver). If I have a scene that, say, sets the bulbs to 4000k then pick a scene that sets them to 2700k, activating the scene for 2700k actually keeps them at 4000k unless I activate the 2700k scene twice in a row. (I think the brightness might be correct, but the CT definitely isn't.) I haven't done enough playing around to figure out exactly what causes this because it does appear to work OK sometimes, but something definitely seems to be wrong. Glad I'm not the only one.

And while we're on the topic of possible bugs, a totally-off Sengled A19 Color Element Plus also seems to turn on when startLevelChange(up) is used (but eventually off again, maybe if I reach 100%, but not if I stop before they turn off). The Hue bulbs don't do this, directly paried or via the Bridge. Guessing the Sengled behavior is wrong, but they're the only non-Hue ones I have, so I don't know.

As for saving scenes on the bulbs themselves, I'm not sure how that works on ZHA. I'm not even sure how it works on ZLL, other than that the Hue Bridge lets you (via the Hue app) configure scenes and assign them to buttons on a remote/dimmer, which then do immediately activate as you describe when that button is pressed (with or without the Bridge, which isn't super special on a ZLL network). Hubitat has a fantastic Hue Bridge integration; unfortunately, it does not provide access to Hue scenes. If it did, I'd go back to the Hue Bridge (that would be fantastic and the best of both worlds). I still might, depending on how my experiment works out. :slight_smile:

4

No, HE doesn't support Zigbee Scenes Cluster (0x0005) - at least not yet. There is a built-in app that more or less emulates its behavior, but the standard-defined Zigbee cluster is not supported.

The app-based solution has the advantage that you can include different kind of devices into your scenes (Zigbee-ZWave-WiFi-Whatever), but has the disadvantage that there's a small popcorn effect when activating it. Otherwise the bulbs' behavior is still consistent, it's just... different. :slight_smile:

5

This is not true, so I'm unsure what you mean by support, there are no helper methods currently (zigbee.on(), zigbee.off() ect...), however raw commands are fully supported for this and any other Zigbee ZHA or ZLL cluster.

Unlike Z-Wave where the overloaded commands need to be implemented prior to being available for use within a driver, Zigbee doesn't work this way.

There is nothing platform side preventing the use of the scenes cluster.

6

Well that is a major disappointment to say the least. I don’t understand why this functionality is not like the very first thing to do before even releasing any hardware or software at all. Am I missing something? It seems, without it, ZigBee automation is borderline useless.

7

I’m sorry I didn’t fully catch the details there, but you’re saying it’s fully possible? Shouldn’t that mean it should long be implemented by now? As I see it, it is one of the absolute necessities to have something you can call a working driver/handler.

8

Clearly not everyone else sees it that way, or it would be available in the drivers and platform today. :smile:

Saying zigbee automation is useless without that capability is laughable, though. I get it doesn't meet your needs/requirements, but let's not get too far into hyperbole.

2 Likes
9

It's certainly usable without this. I mean, lots of people (myself included, to some extent still) use the Hue Bridge integration over the LAN, where you're either using Hue Groups or (like me) individually addressing Hue bulbs. If you have Hubitat scenes or groups set up, there's no hope of group messaging there. That is why I hope they add support for Hue scenes, though--it would make this much easier (I don't need to configure things in both Hue and Hubitat) and faster (the least of my concerns but still something).

That being said, I do wonder what it would be like with a driver that supported these natively on the Hubitat side, which I wasn't sure was possible before. :slight_smile:

In any case, I'm pretty sure the bug above remains when using Hubitat scenes. Surely more than just the original poster and I are experiencing this problem?

10

No honestly I mean it. To me, automating is basically two things, creating scenes and creating triggers/conditions/controls for them. This basic functionality needs to function completely stable and smooth, or else I don’t think it is ready for release. Here it seems like scenes is not implemented, but rather software emulations, that doesn’t work smoothly.

If I can’t make something work completely smooth, I rather not use it, and wait till something better comes along. I don’t have a tolerance for quirkiness or workarounds.

I am completely sure that there must be a bunch of people out there disappointed by this missing feature, that just does not know the alternative or how to explain it.

Any way, I do understand it still pretty much a beta, and a feature like this could be coming. For now, I think I’m getting rid of the Hubitat though.

11

Probably a good idea in my opinion if you need that functionality immediately.

12

Hmmm... You're right, zigbee scenes CAN be implemented using raw commands, but the way HE currently implements scenes does not involve Zigbee Scenes Clusters. IMHO this is what @bendixs misses... maybe once I'll try to make an app/driver for that :slight_smile:

13

that is correct, the scenes component of our groups and scenes app does not have Zigbee scene commands implemented.

This isn't driver related as all the zigbee group commands are sent from the group app and don't involve the drivers in any way.

Of course Zigbee scenes can be implemented in our scenes app, however we have many competing agendas, and are currently focusing on platform stability and bug fixes, feature enhancements while super important do take a back seat to the above.

2 Likes
14

I just tested this and cannot reproduce this behavior. My Sengled Element Color Plus A19 bulbs respond as I would expect. With the bulb off, issuing a startLevelChange(up) call turns on the bulb at its previous dim level and ramps it up to 100% brightness. However, the dimming level attribute does not seem to update if you only issue a startLevelChange command. The level attribute does update after the stopLevelChange() command is issued. Those two commands should really always be issued as a pair, usually tied to a button pushed and released pair of corresponding events.

15

Actually, that sounds exactly like my problem. :slight_smile: None of my other bulbs turn on if they are off. With my Hue bulbs (used either via the Bridge or directly paired), this command only affects bulbs that are already on. With the Sengled, it turns on and changes level regardless. Maybe Sengled is doing it "right" and Hue is "wrong," but it's certainly different and I think consistent behavior would be best, unless this is something at the bulb level that Hubitat can't control.

(I also didn't mean to conflate the "turning on then off again if it wasn't already on" behavior with my main issue of it just "turning on even if it was off" for a startLevelChange(up). That being said, even if you have a release event triggering the stop command, it will still happen if you hold the button down "too long.")

16

This is a known issue with ZLL EU lamps, if you ask @mike.maxwell nicly he may give you a temp work around driver until the full driver is fully implemented.

17

Interesting... I cannot reproduce that behavior... I wonder if there is a difference in Sengled firmware versions, perhaps? How long does it take, in your case, to have the bulb automatically turn off? I have just tested with a few other Sengled Element Color Plus A19 bulbs, and they always simply go to 100% and stay there...:thinking: I am running running these bulbs in CT mode, at 2700K, if that makes a difference.

Update: I also tried in RGB mode and again the bulbs go from off to on and ramp to 100% and stay on the whole time using the startLevelChange(up) command.

18

Understandable that platform stability and bug fixes comes before features, I respect that. But any kind of idea how far away a functionality like this could be? It will pretty much determine whether my Hubitat is being listed for sale now, or will be sitting patiently for a second try soon.

An alternative option though, has deCONZ been integrated in Hubitat yet? I got a deCONZ server with all my ZigBee devices running great already. If I could just import that into Hubitat, I honestly would prefer that anyway.

Last question; How does the startLevelChange function work? Does it continously send a bunch of commands to the ZigBee bulb, or does it send 1 command telling it to, say, dim to 1% in 0,xx seconds per %? That functionality of Hubitat actually seems useful for creating automations with smart wall switches/remotes etc.

19

I cant answer that, it won't be in the 2.1.1 release.

neither, startLevelChange tells the device to start changing its level from the current level using the default transition time, it is one command issued once, unless followed by a stopLevelChange the device will either turn off when it's level gets to 0, or stay at 100 percent.

These two commands when used with a button controller are designed to mimic the smooth dimming that you get with a physical dimmer interface.

20

Ok, that actually sounds pretty cool for the transition command. Is this a ZigBee standard command of some sort? I haven't seen that functionality on Homey, Home Assistant, deCONZ or anything before.

21

These are available commands for both Zigbee and Z-Wave, I'm not aware of any other platform that formally exposes it the way that we do.

3 Likes