Compatible Devices List


Aaaaand another one, this one also for “Generic ZigBee RGBW Light”. With a little heads up (same for the Osram Flex RGBW lightstrip a few posts up). The driver/device throws an error if the field for fade time at setLevel is used (even with a 0). With that one blank everything works.

No signature of method: is applicable for argument types: (java.math.BigDecimal, java.math.BigDecimal) values: [100, 1] Possible solutions: wait(), any(), trim(), size(), collect(), dump() on line null

Zigbee/Osram/Smart+ Classic E27 Multicolor

Pairing info

endpoints.03.model:CLA60 RGBW OSRAM


I looked around and could not find these few devices listed. i have a very simple setup with smartthings but always wanted the local stuff that smarthings barley offers. Seems like most of my devices are compatible but i dont see these:
-Aeotec Water Sensor
-Radio Thermostat CT50 (i had this working with smartthings with wifi and over zwave at different times. Right now wifi since the zwave module died and using this from github (on github /statusbits/smartthings/blob/master/


just realized the aeotec water sensor is aeon labs so that is on the list!


When the pearl driver is complete, will I see it in the device dropdown? I am slowly transferring devices from my Vera hub to Hubitat, and don’t want to disconnect the pearl from Vera until I know that Hubitat will support it.

I asked a similar question on a thermostat dashboard topic, but will the device driver support hold? My husband likes to set the hold at the thermostat, but currently the Vera hub doesn’t know anything about it so the hold is not really a hold in some cases. I noticed that the current Smartthings Centralite Thermostat device driver doesn’t have any logic for hold, but I did track down an older one that does. I had contacted Centralite support several months ago and they say the thermostat does report hold status but I don’t currently know how to verify that.


yes, and it will likely be noted in the release notes.

Good question, if centralite says the device reports “hold”, then we should be able to include that in the driver, though it’s not clear to me how it’s supposed to work, presumably when the thermostat is set to “hold”, the driver would ignore any setpoint requests sent to it?


I have never been able to get a good answer to the hold question! But to me what you say is what should happen, if the thermostat has been set to hold then don’t do setpoint changes. According to the pearl manual:

HOLD button will enable Hold function which locks out all scheduled system changes. This includes internal schedules and external schedules from a controller only if the controller supports this.

I don’t see how the thermostat supports internal schedules…but seems like just ignoring setpoint changes would be good enough, for me anyway :grinning:.


If the Hubitat succeeds in seeing the device Hold status, even if that’s all it is - a status report with no real Hold functionality - we could still use that in RM to build whatever effective Hold behavior we wanted … I would hope.


the perl does not report hold status, it also doesn’t prevent command setpoint changes, looking at the manual, hold is supposed to prevent internal and external schedule changes, which would imply that it supports command scheduling. I’m not going to attempt to implement or investigate scheduling for this version of the driver.


For some reason mine keeps losing connection. It works and then after the first event I need to push the button on the side of it to wake it up or something. :frowning:


I would love to support for

WiFI/iRobot/Roomba Vaccum


Hm, I have noticed strange behaviour with the Osram Smart+ Indoor Flex RGBW. Maybe it isn’t fully compatible after all.

I can set a dimmer level to 20, 50 etc and it works great, the light turns on and everything is fine. However, I noticed while trying to iron out som bugs in my rules that the switch state never changes to “on” and “on” is not detected via refresh. Also, there doesn’t seems to be a variable for “level” in the device info - I guess those two are connected.

If I send the “on” command, the switch chages to “on” just as it should. But it’s rather limiting and clumsy to have to send both “on” and dimmer level for every action. To that, some toggle variants will not work correcly.

So TL;DR. Setting dimmer level directly turns on the light as it should, but doesn’t change switch to “on”. Also, level doesn’t seems to be a level variable in the driver when combined with this light.

(It’s on here. As you can('t) see.)


Yes, there is a bug in the driver, an update is currently being tested.


I assume that LED strip lights aren’t incandescent either?


Well, no. But I thought that was just the label for the color?


aha! That does make sense.


OK, that’s a pity … Do you think an external heat/cool set-point change (ie, from RM) would clear the local hold, as opposed to just changing the set-point of the hold? Wondering if it still my have value as a temporary hold, just until the next (RM scheduled) event.


The hold function only applies to scheduling that has been implemented via the thermost cluster on the device itself, so as it stands, the hold button on the thermostat does nothing, I have not had the time, nor am I likely to investigate the zigbee thermostat scheduling api, additionally the device claiming to support this and it actually working are separate matters. Despite relevent certifications, I’ve already run across mandatory commands and reports that have not been implemented in various devices.
So the hold button will not interfere with nor prevent any set point changes physically or digitally.


Are there any updates on plans for integration with Ring and/or Arlo?

I think that they are going to be the last bits I cannot migrate, and really dont want to keep ST around for those orphans.

IFTTT is way too slow for my needs (turn on X when doorbell has motion, etc.)


Yes, I was disappointed in the response time of this as well, the delay here is on the ring side BTW…


ST as an orphan…

I was thinking the same thing. I had everything OFF ST (except my phones as presence sensors) and so was about to shut it down and was wondering who I’d give it to, etc.

Then I had a thought.

ZWave has a 232 device limit and I can predict that one day I’ll reach that.

Keeping ST as a “slave to Hubitat” via Hub Link, Other Hub, etc. would double my device count. I’d have to be selective to put cloud insensitive devices there but ST is (glacially) working towards Local too. I’m saying to myself… I can add new devices (device types, vs additional devices I already have on Hubitat) and get confidence in them before migrating them to HE.

just my thought…

But if you’re going to sell your ST hub at a discount… I have friends and family I’d love to get infected with this craze. :smiley: :smiley: