Went back to smarthings [But came back]


Looking at it, it would seem that the time to turn illumination after motion may be too short because what happens is when arming it, the lights go out for the keys but the actual arming/disarming indicator stays on until the arming/disarming process is complete. There doesn't seem to be a way to turn the lights off other than the time out after motion.


After pairing the keypad. Press configure, wait a couple of minutes. Remove both batteries for a couple of minutes and insert batteries. Not sure why but that's how I get the lights to function normal on my Xfinity keypads. Possible it's the same as the Iris.


So I tried your ported Zigbee Dimmer Driver On one of my Sengled Element Color Plus bulbs. As you mentioned, it works exactly as @toyanucci described and showed in his video.

I believe it has something to do with the device configuration parameters that the ST code sends to these bulbs.

Since Hubitat does not automatically run the Configure command when changing a driver, I restored the driver to the Generic Zigbee RGBW Light driver. And what do you know...the physical on and off reporting still works!

@mike.maxwell - can you please add a feature request to implement the same Zigbee configuration settings that ST uses with these bulbs to the stock Hubitat Drivers for Sengled Element Classic and Sengled Element Color Plus bulbs?

The magic must be in these few lines of code, right?

def configure() {
	log.debug "Configuring Reporting and Bindings."
	// Device-Watch allows 2 check-in misses from device + ping (plus 1 min lag time)
	// enrolls with default periodic reporting until newer 5 min interval is confirmed
	sendEvent(name: "checkInterval", value: 2 * 10 * 60 + 1 * 60, displayed: false, data: [protocol: "zigbee", hubHardwareId: device.hub.hardwareID])

	// OnOff minReportTime 0 seconds, maxReportTime 5 min. Reporting interval if no activity
	refresh() + zigbee.onOffConfig(0, 300) + zigbee.levelConfig()

Most likely it is the “zigbee.onOffConfig(0, 300)” command, I think...

GE link bulbs stop responding

I noticed that too but I had a mess with the settings so I ended clicking configure with the generic driver. Anyway we got a great feature discovered, too bad the guy returned the hub.


I never knew that !! Nice find Dan.


Regarding the OP: While it would be nice to have the Sengled status issue sorted out, I am struggling with the notion that it has to be either or with the ST and HE hubs. Sure, it's ideal to get everything working locally on the HE hub, but if something isn't quite right on HE, keep what's not right on ST.

I just setup my HE today and have migrated all but a few things over, but what I have not migrated continues to work just fine! And what I have transferred over is simply working faster and more reliably already. No way I'm ditching the HE if something hangs up getting completely off of ST. That is just silly.

Dry the baby off. The bathwater can be disposed of separately.


@kipa the OP didn’t buy a SmartThings. He bought a Hubitat and then returned it in order to buy the ST. I don’t believe he ever had both at once


As I mentioned several posts above, the bulb reporting is due for some changes, at that time I'll have a look at power on state reporting.


Sure seems like he was on ST, tried HE, and went back to ST...thus the title of this thread... :wink:

Here’s his original post’s first paragraph...


Thanks Mike. I just thought I’d point out what our further testing had uncovered. I am still amazed that these Sengled bulbs send out a last gasp Zigbee message as power is removed from them, in addition to their power on Zigbee message. Pretty cool bulbs, IMHO. :sunglasses:


Thanks for that! I didn't pick that up first read. :frowning:


Agree, the one thing, and the only thing to date that I don't like about them is their on transition time, which is like 0...
That I'll be looking into as well.


I'm not one to be described as impulsive but in this case I may have been. I really should have given the community a chance to rally as they have in the past 24 hrs.

For the person that asked, I already had ST but wanted to try out HE. I will likely try HE again as these developments have me very curious if I can get it to work (especially the keypad fix described above). But please let the app be a priority, or if possible a stylish redesign of the dashboard.


Hubitat has accidentally leaked a pre-release copy of their mobile app that a handful of people downloaded. Hubitat has made pretty descriptive posts about their intent for the next Dashboard.

In other words, we already know these are priority. Naturally the only release date they ever quote is "when it's ready."

We know the goals of the Mobile app: A user (not admin) tool that has a dashboard, notifications and presence.

We also know the goals of the new Dashboard: almost all feature requests from this forum.

You can also make the existing web Dashboard into a pseudo mobile app:

Notification today is via Pushover.net. You get an acct and create a virtual device in Hubitat, select the pushover driver and then enter your Pushover tokens. 7500 notifications per month is included. Because it's just a device, it's able to be used throughout Hubitat automations.

I have an Apple infested home. Therefore I have a homebridge integration, which is identical to the one on ST. Same developer, common code. Thus I have superb presence detection via HomeKit. In other words, I already have everything the Mobile App is going to offer.

Hubitat also has Hub Link and a community developed app called Other Hub that 'merges ST and Hubitat' to greatly simplify the migration. (You can leave sensors and automations on ST while you migrate physical switches, outlets and bulbs. Virtual devices magically appear in ST allowing you to replace the physical device with it's virtual in automations and have ST turn devices on and off via Hubitat.)


And, honestly, right now, I use the 'Other Hub Event Pusher' as the primary means to give my partner Nicole the 'app' experience via the SmartThings Classic app. Note that even with the 'real-time integration' enabled, it can sometimes get a little wedged as far as light statuses go, but, honestly, it's functional enough to pass the WAF test here. :slight_smile:


:smiley: :smiley: You're using ST app as "dashboard" and I use HomeKit :smiley: viva la choices


There are a ton of different dashboards to try/use in the meantime too. Josh from SharpTools.io reached out to me about it, gonna give it a whirl at some point just for fun.

I can tell you the HE and feature/bug fix/capability requests is the complete opposite of let’s say Ubiquiti products where they seem to fall into a black hole or get accepted but never implemented. :rofl:


I got the app, honestly I uninstalled it, nothing there that I or my wife can't do already.


I love SharpTools (although it still needs a few enhancements, like on dual custom icons for states.... :slight_smile:).

If Josh could figure out how to make a local version run on a RPi or VM I would cough up a large chunk of change for that! I think it is the best best dashboard available right now.

But in any case, I use the cloud version extensively and it works VERY well. Oh, and even has a thermostat tile that works. :wink:


That’s an interesting idea! I told him that I hadn’t tried it mostly because I want to stay as local as possible and use limited outside apps. But I am going to personally try it out cause it looks cool.

I understand why they won’t do it, but if HE released a locked down SBC (not just Pi, I’m more of an Odroid fan) or Virtual appliance version I would be all over it and give them tons of $.