Sengled Element Plus State Not Updating

🛎️ Get Help
1

I just got a set of these Sengled Element Plus bulbs and paired them up. The driver was detected correctly as a Zigbee White Color Temperature Bulb.

The issue is when using setLevel the switch state is not updated. Even after clicking refresh or ping the status is never updated so it's not working well with automations. Seems similar to this thread, but these are the Element Plus and I'm not sure if there was a resolution to @bangali problem.

Any ideas? Anyone else have success with these bulbs?

2

That driver needs some love, which is on the very short side of a rather long list.

3

Thanks Mike. Do you think some fixes related to this will make it into the next firmware release?

These bulbs seem decent so I’ll probably keep them in the box until a fix is ready. Back to the flickery but reliable Z-Wave bulbs for now!

A sort of unrelated question: Do you know if the Hue White Ambiance bulbs support on/off/level/temp when paired directly without a hub?

4

there hasnt been any resolution.

5

Same here. Not updating level status.

6

The Zigbee White Color Temperature Bulb driver was deprecated (disabled for new pairing) and replaced with Generic Zigbee CT Bulb (dev)
If you're still using Zigbee White Color Temperature Bulb, please change the driver to the new one, hit configure after replacing the driver.
Let me know the results.

7

Mine paired off the bat with the Generic Zigbee CT Bulb (dev).

The only difference I see is the setlevel does not update with 0%. Meaning it will update when sent everything between 1%-100%. Those of us attempting to achieve a "sunrise" ramping effect by using setlevel instead of on/off are out of luck.

However, the plain white (non-CT) Sengled bulbs DO allow 0%, so there must be some small difference between "Generic Zigbee Bulb" and this one.

8

I have no idea what this means.

9

I have these bulbs. That’s the right driver, but they don’t respond to 0%. Start at 1%. Dimming smoothly is difficult with them. It’s the bulb.
Not totally impossible, but don’t expect too much from them.

10

Dude seriously?

11

Now why would I ask such a question if I knew explicitly what this translated to...

12

WELL, since you asked, you asked me to describe the results. The fact that you blew me off tells me you're not interested in dealing with people like me who aren't developers. I can only describe what I observed, and I think I did that pretty well. If there's anything else I can do to help you figure out how to fix this driver, please let me know.

*edited for civility

13

@kilowatts there are developers here too? and here i thought we were all part time code hackers here :wink:

@mike.maxwell was probably just trying to understand the use case.

here is some code for sunrise ramp i had lying around. is this what you were looking to do?

definition	(
    name: "rooms test app",
    namespace: "bangali",
    author: "bangali",
    description: "rooms test app",
    category: "My Apps",
    iconUrl: "https://cdn.rawgit.com/adey/bangali/master/resources/icons/roomOccupancy.png",
    iconX2Url: "https://cdn.rawgit.com/adey/bangali/master/resources/icons/roomOccupancy@2x.png",
    iconX3Url: "https://cdn.rawgit.com/adey/bangali/master/resources/icons/roomOccupancy@3x.png"
)

preferences {
	page(name: "roomsTest", title: "Rooms Test")
}

def roomsTest()     {
	dynamicPage(name: "roomsTest", title: "Rooms Test", install: true, uninstall: true)      {
        section("")      {
            input "roomLight", "capability.switch", title: "Light?", required: true, multiple: false
            input "roomMinutes", "number", title: "How many minutes?", required: true, multiple: false
            input "roomMinKelvin", "number", title: "Minimum Kelvin?", required: true, multiple: false
            input "roomMaxKelvin", "number", title: "Maximum Kelvin?", required: true, multiple: false
        }
    }
}

def installed()     { initialize() }

def updated()       {
    initialize()
    state.inSeconds = ((roomMinutes * 60) / 100f).round(0).toInteger()
    state.kelvinIncrease = ((roomMaxKelvin - roomMinKelvin) / 100f).round(0).toInteger()
    if (state.inSeconds > 0 && state.kelvinIncrease > 0)        {
        state.level = 0
        state.kelvin = roomMinKelvin - state.kelvinIncrease
        runIn(1, rampUpLight)
    }
    else
        log.debug 'number of minutes or difference between max and min kelvin too small.'
}

def	initialize()    {
    unsubscribe()
    unschedule()
}

def rampUpLight()       {
    if (state.level != 99)     runIn(state.inSeconds, rampUpLight);
    state.level = state.level + 1
    roomLight.setLevel(state.level)
    state.kelvin = state.kelvin + state.kelvinIncrease
    roomLight.setColorTemperature(state.kelvin)
}
3 Likes
14

Thanks @bangali. So this looks like a verbatim "sunrise" effect, replete with Kelvin changes and all. Awesome. However, I was only referring to a smooth level change, so this only proves Mike's point on the need to use clear terminology. Sooo let's start over.

If @SmartHomePrimer is right about the bulbs themselves not responding to 0% then we're SOL. However the other Sengled bulb models do respond to 0%, so it might be worth having a look at the driver.

I'm having trouble finding where the hub drivers are located. Someone linked to Mike's git in another thread but I only see 4 drivers in there. (Understood if end users are discouraged from tampering)

15

I checked the setLevel sections of the ct and standard bulb drivers, in both cases we pass whatever value is sent straight to the device, ie both drivers use the same code for level adjustments.

In my limited testing with 0 on bulbs, there is no common standard in the way they respond.

Neither is there a standard on what they do when 0 is accepted, and you turn the bulb on with on, most seem to come up with some default level, but again, non-standard here.

1 Like
16

So there's a bit of history behind the operation of these bulbs and the driver development that you didn't see. I really encourage you and others that are new to the platform to use search in the forum so you can get a bit of background before posting. I'm guilty of not always doing it myself, but there's no call for a lack of civility.

The Sengled Element Plus bulbs are very unique, due to their ability to be dimmed by a conventional dimmer and via Zigbee. No other bulb that I'm aware of has that capability, and would otherwise sustain damage or act erratically if you tried it. As a result, they don't act like typical Zigbee bulbs and @mike.maxwell worked to create a driver that would control them as smoothly as possible and still encompass other Zigbee bulbs. I think he did a great job. And yes, @mike.maxwell is very much associated with Hubitat. He's one of the founders working tirelessly to create drivers and other software that we're all benefitting from. Much respect is earned and deserved.

Here are some rule machine rules I have been using for quite a long time to fade the Sengled Element Plus bulbs to off and another to allow them to fade on. It works relatively smoothly (most of the time) with these bulbs. They misbehave and sometimes fade on or fade off very unevenly. Occasionally just jumping to full ON or straight to OFF, with no fade. This particular behavior seems to be related to whether or not they were previously controlled conventionally via the dimmer, vs being controlled digitally via the Zigbee radio. It typically takes a cycle on and off again via Zigbee to get them to at least exhibit their normal behavior via Zigbee. They did the exact same thing on SmartThings and Wink, both of which have custom drivers written in cooperation with Sengled for these bulbs. They're just not going to behave like your typical Zigbee bulb. They'll fade to 1%, but it looks the same as 4%, and then they just suddenly turn off. It's just not smooth with these bulbs, but the results I'm able to achieve with separate rules controlling these bulbs is the best I've been able to achieve with any of the three hubs I tried them on to date. I have given up trying to make a silk robe from a sow's ear, The bulb are not standard, don't behave standard, and the evidence would suggest they're never going to. I have a rule for ON in the way I prefer with these bulbs and a rule for OFF. I have resigned myself to the fact that these bulbs are different and must be treated as such.

59%20AM
Screen Shot 2018-08-19 at 11.20.59 AM.png550×569 31.4 KB
!
14%20AM
Screen Shot 2018-08-19 at 11.40.14 AM.png552×576 30.7 KB

3 Likes
17

[quote="kilowatts, post:14, topic:1211"]
Thanks @bangali. So this looks like a verbatim "sunrise" effect, replete with Kelvin changes and all. Awesome.
/quote]

sure thing. right. you could remove the kelvin set off course.

there is one other potential here. there is a startLevelChange command for these drivers. this currently only accept an enum … 'up' or 'down'. if you can convince @mike.maxwell to add another parameter duration and handle the level change up or down over that duration … then this command would do exactly what you want.

HE driver code is not publicly shared.

1 Like
18

there is another way to do this for level only. but dont know if it will run in to issues with a recent guardrail that was put in place.

@mike.maxwell | @bravenel recently there was a 120 second limit put in for long running processes. if the following commands are issued from an app … that will not timeout - yes?

light.setLevel(1)
light.setLevel(100, 180)

thank you.

19

light.setlevel(100,180) is implemented in the device itself. Software implementations of things similar that use runIn() will not hit the limit either, as the instance runs, calls runIn(), and then finishes in much less than 120 seconds.

20

cool. think rooms needs a fade down to off over 30 secs setting. :slight_smile:

@kilowatts another way if you wanted to give that a try.