You are absolutely correct about that! I know the Hubitat team is very receptive to updating the platform to include support for new devices, especially when it is as simple as adding the device specific 'fingerprint' to one of their existing 'Generic' drivers. Users who discover such situations will often simply tag @mike.maxwell, showing him a screenshot of the device fingerprint that is available during the pairing process by clicking the small "more" link. He usually gets the new fingerprint added to the appropriate driver within a release or two of the firmware, depending on where the team is in the development cycle.
If Hubitat has to write a device specific driver from scratch, that will usually take more time and require that Mike Maxwell have access to one of the devices.
Are you turning on with a level of 1 or are you issuing a command of setLevel(1) while the device is off? Because there is a difference in behavior between those two.
EXACTLY! That's because the bulb is trying to go directly to that level but the LEDs have a minimum on level of like 15 or 20. So, when it receives an on command and the level is below that, it brightens to the min level then dims back down to the level it wants. A setLevel command should be handled by the bulb the same way...but it isn't. That's not Hubitat's fault. If Ecosmart is going to use cheap LEDs in their bulb (that's why they act that way) then they should have taken the time to consider how to implement them. They did it for the on command, they should have for the setLevel as well. But that's what you get for $4.88.
I son't mean to beat a dead horse so to speak but again we are comparing the drivers in Hubitat. I will not argue that the bulbs don't compare to Philips Hue or other similar bulbs, but the experience is completely different when using the native ecosmart drivers used by Smartthings. I argue that if the same driver was in Hubitat the experience would be what I am experiencing now using Smartthings. as @flotsam1 noted and I experienced as well, when lowering the dimmer level at or belwo 10@ the on time dramatically increased and in my case I could never get the light to come on below a dimmer level of around 8%. Now I can dim the light to 1% with a colortemp of 2700k and it comes only almost instantly. The reason I asked my original question is that IMO this is not a "bulb: issue but a driver issue else I would not get two different results with the only variable be the hub and more specifically the drivers. I would like to know were you can get these bulbs for $2.88 or $4.88 as for my use these are acceptable bulbs and even more so at these prices
Home Depot was selling that light bulb with remote and that package had evidently been discontinued so it went on clearance... 1st to $8.88 then $4.88 and some have seen less than that. I bought about 12 at the $4.88 mark but don't see them in any HDs around me anymore. It's same bulb that they are selling 2 for $20.
I acknowledge that. But you have to realize, there is really only 1 guy at Hubitat who writes drives. I won't even guess at the size of Samsung's staff that works on drivers. So, things have to be prioritized. And a cheap bulb that you can't even buy a couple of months after it came out isn't going to rank very high on their priority list. I'm sorry if that isn't acceptable to you but it is just the reality of the landscape.
I would argue that the bulb is what's at fault here, not the driver. The fact that Samsung decided to develop a driver for a crappy bulb is their choice. The fact is, the bulb does not respond correctly when a standard command is sent to it. Who's fault is that? Is Hubitat supposed to write a driver for every model of every device on the market? Of course not...that's why there are standards. But this bulb doesn't follow them. But the bulb is barely worth $2.88. I would never use this in anything except an outside fixture that I didn't really care about. You can get a bulb 1000x better made by Sengled off Amazon for only $7. It doesn't do color temp, but neither does this one really.
Also, the 2 pack of bulbs is $18, which is more expensive than a better bulb. So, I would not recommend buying any more of these bulbs.
The bulb is not compliant with standard commands. Therefore the bulb is at fault. Why does it not behave correctly when a setLevel command is sent to it like every other bulb? That's Hubitat's fault? How do you figure?
I've really tried to be nice and try to help you with this issue. For you now to turn around and do this, well, it's really rather rude. Good luck to you.
Thanks, the 2 pack is the only ones sold in my location. I thought it interesting in the post you reference was suggesting what I did here and I thought I was being original @flotsam1 "Now if one of our Hubitat experts can find a ST driver for us that might work, would be helpful!" I have pm'd the person that @ogiewon mentioned, at least this will give him a chance to decide based on Hubitats road map if this fits in and is worth the time perusing.
Note that the quote you referenced relates to the remote that was shipped in a "kit". I couldn't care less about a driver for the bulbs - they work and meet my needs as-is using the generic Zigbee driver.
Now on that remote it doesn't seem as if that will ever work in HE due to how it was designed.
Thanks for correcting me. Last night I just quickly read (only partially) the thread and I was in the process of reading the entire thread when I got your pm and realized I was mistaken in the context of my post.
You mentioned you are using the generic Zigbee driver. I am going to try that one and see if I get the same results I get from the out of the box driver in ST. When I originally paired with Hubitat it gave me a Generic Zigbee RGBW driver out of the box. When I asked for help on the forum I was directed to the Generic Zigbee CT (dev) driver but that didn't make things much better (wouldn't dim below 10% and at the 10% level took twice as long to turn on. Now thru ST I can dim to 1% and it turns on much faster (but still a little time delay) than it did on Hubitat
I pulled out my Smartthings and paired the bulb to it. From what I can tell the bulb works the same as it does on Hubitat. I can set it to 1% dim and it takes about 8 seconds to turn on. Send an On command and it comes on about 30 then dims to a lower level.
For me either the RGBW or CT driver work. As far as routing goes I have two that are each routing an Irish V2 motion. No missed events. I still maintain that the Zigbee bulbs that are an issue are those with a Marvell SOC. I have some of the original OSRAM bulbs and they did cause problems. When I replaced those my Zigbee network got more reliable.
Thanks for sharing your experience, I am not sure what I might have done incorrectly, when every I tried to lower the dimmer level below 10% the light would not come on (Motion lighting rule). In support of you conclusion that the bulbs work the same way (ST and Hubitat) I found that I could import the driver code from ST into Hubitat and use that untouched in Hubitat and I could turn on, off set colortemp and dimmer level, however I could not test this driver in motion lighting as I have my only ST motion sensor in use by ST. I have a new ST motion sensory on the way then I can setup a motion rule and see what the transition time is when the ST driver gets triggered in Hubitat.
Thanks for the suggestion, again showing my newbiesm I have not idea how to do that
Not wanting to take any more of your time, can you direct me somewhere were I read up on how to do that?
It’s pretty simple. Go to your Devices page, click Add Virtual Device at the top, then pick the Virtual Motion Sensor from the drop down for type. Give it a name and then click Save or Done (can’t recall off the top of my head.)
You can then click Active or Inactive buttons on that device’s page to simulate a motion sensor. Use this motion sensor in your automations to test things out. Later, you can replace this virtual sensor with a physical one once it arrives.
