List of Incompatible Devices

Ok to save people some time and possible headache, I want to start a list of devices that won’t work with Hubitat at this time. As I migrate stuffs over th Hubitat, I am hoping I won’t have to add to the list :slight_smile:

If you find something not working, please add to the list.

  1. ST Presence Sensor (will pair but not working with Hubitat. Might need some Hubitat work to keep track of sensor coming and going?)

I have a few Xiaomi buttons ("smart switches"), bouth the round (original?) and square-ish (Aqara? or is it the other way around) versions, and I've tried them both with a couple different ST DTHs I ported. Both pair, but neither really works in terms of registering the button press as an event beyond a checkin.

I also have a few Xiaomi motion sensors and door sensors. Both have paired and worked correctly for me for a while, but within a day or so, they "fall off"--- a problem some ST users are probably familiar with. I'm trying a different DTH now and some ST tricks (leaving them near the hub with the hub in pairing mode for a while), but I'm not sure if that will work on Hubitat. I'm not sure how Hubitat implements ZHA, but maybe it's related to the problem discovered by some users of the Bellows library that Home Assistant uses:

These aren't standard ZHA, so I'd have no reason to expect them to work, except they're close enough that many ZHA hubs can apparently be tricked into using them, and I have a few, so I'm hoping it can work. But for now, I'd put these---and really probably most Xiaomi ZigBee devices---on a "not really but kind of maybe" compatibility list. :slight_smile:

EDIT: In case you are reading this thread much later than my original post, Hubitat works pretty well with these now, probably similar to ST, after an early hub firmware update. But there are problems with repeaters, so using ones know to work well with Xiaomi devices (or none and keeping them all in good range of your hub) would be my recommendation, Other threads have more information on this,

1 Like

So I figured this would be a good place to start with the stuff that may (or may not) work as of this date. In no particular order, this would be the stuff I have that I would not expect to be able to migrate over from ST… comments are more than welcome:

  1. Eight sleep mattress;
  2. Netatmo (all devices);
  3. IFTTT;
  4. Homekit (through HA RPI server);
  5. Hue Bulbs;
  6. Z-Wave Multichannel device (for Intermatic PE653 Pool Pump);
  7. Logitech Harmony;
  8. Synology Surveillance Station/Foscam Cameras;
  9. Nest Thermostats and Smoke Detectors;
  10. Roomba Vacuum;
  11. Neato Vacuum;
  12. Sonos;
  13. Google Calendar (this is a really cool ST app);

That seems to be all for now.

Looks like most of these are integrations with mainly cloud APIs.

I’m curious about #5, are you referring to the hue bulbs them selves, as they pair up just fine directly? Hue bridge integration is coming soon.

Appreciate the feedback and information!

1 Like

I’m also interested in hearing more about some of these… what is this one in particular? do you have a link?:


Something I need before I can go cold turkey with ST.

  1. Keen Vents
  2. DSC Alarm Server
  3. Ecobee
  4. Spruce Sprinkler
1 Like

for #1, we have a built in driver for Keen vents.

DSC is an interesting one. Most implementations use EnvisaLink EVL-4 which I assume you have connected to your DSC panel? I’d rather see a direct integration with the EnvisaLink EVL-4 then working with another middleware alarm server… Thoughts?

As for spruce, do you have the zigbee or wifi version?

1 Like

Cool, didn’t realize #1 is done. As for DSC, you’re right, direct integration would be awesome. Few linux machines running at home the better.

I have the zigbee version of spruce.

1 Like

Well bummer…

  1. ZOOZ Z-WAVE PLUS MOTION SENSOR ZSE02 (Generic Z-Wave motion sensor worked with ST but not with Hubitat)

  2. Zooz mini sensor ZSE09 (ST device handler not working and neither does generic)

  3. Stelpro Ki Z-Wave Thermostat. No driver will do anything with it not even Generic Driver.

  4. GE Fan Controller works fine. I’m not just happy with the default driver :sunglasses:

  5. Dual in-wall relay’s. I have vision (monoprice) DH works with enerwave as well. They work for on/off but show as a single device and have to use RM to create virtual switches and a lot of effort for a simple device. NOTE: physical interaction is NOT reported back through virtual switch. So if the device is turned off at the switch that doesn’t get reported back to the Virtual Device.

I haven’t even gotten around to the other devices. The others should be fine as standard switches that I’ve installed have worked.

I have GE fan controller working. Are you trying to do anything fancy with it? I think I’m just using a generic dimmer driver with it.

It is working. I just had to use an external driver to have the low/med/high preset buttons to work.

Included it in my list as it should be there by default so others don’t have to scratch their heads trying to figure out that a dimmer works with the fan at certain “dim” levels and having to know or figure out those presents. It’s pretty generic so I just think a “Fan Control Switch” driver should be included with sane presets already defined. That’s why I said it was a Kludge… it works, but would be a lot better if it was “standard”.

1 Like

I went back and looked and there’s a “GE Smart Fan Control” driver… I switched to it and, well… it’s anything but smart. No presets just a standard Dimmer.

We had an internal debate on this subject. One issue is that this sort of fan has been used with dimmer capability for a long time by some. So, we were reluctant to take that away. But, we did work up the alternative along the lines you are suggesting. We would need to introduce a new capability to distinguish the two ways of controlling it.

I wouldn’t say it takes much guess work to figure out the dimmer levels. 0…33 low, 34…66 medium, 67…99 high (more or less). Or 25, 50, 75 work. Since you’re going to use these in some app, it makes little difference. Rule Machine has an action that adjusts one of these using dimmer level, stepping from off to low, to medium, to high, to off. Button Controller has the same action.

The driver I’m using just has some preset boxes in the parameters for the level with a click box for low/med/high and below that is the parameter for the level.

Simple driver, but obvious that it’s for fan control of low/med/high settings. It works for a normal dimmer purpose, but for fan control it makes it really obvious. I had this same question/issue when I first installed the switch and installed the “regular” ST fan controller… I was like “what the hell this is just a normal dimmer”. I then started second guessing if I installed the wrong switch as I was doing several that day. Then I did the forum searches and low and behold… no… it is just a regular normal dimmer switch, but with a higher watt rating to handle the motor and you have to set the level for the motor to kick in. But it would have saved me time and worry if the so called “GE Smart Fan Control” device handler and corresponding configuration looked like it was for a “FAN” and not just like every other dimmer I was installing.

I understand all of that. But, it’s not an incompatible device. It doesn’t belong on this list.

Yeah… true… it does work… I’ll edit :slight_smile:

Zooz Z-Wave Plus Motion Sensor (ZSE02)

Hubitat Information after pairing:

deviceType: 1280
inClusters: 0x5E,0x85,0x59,0x71,0x80,0x5A,0x73,0x84,0x72,0x86
deviceId: 3
manufacturer: 338

SmartThings after pairing:

Raw Description zw:S type:0701 mfr:0152 prod:0500 model:0003 ver:0.01 zwv:3.95 lib:06 cc:5E,85,59,71,80,5A,73,84,72,86 role:06 ff:8C07 ui:8C07

The Hue Bridge. ST integration with this is pretty eh. I liked an app in ST called Hue B Fast (sp) but it tried to add devices for each scene which became unwieldy.

It would be great to have the bridge and have a better organized way to add scenes and (date I say) their labs which are kinda cool.

Here is the link:

I do recall it being a time consuming setup but the gist of the app was that the app searched your calendar each day and if the app found the trigger word the contact sensor DTH (created by the app) would trigger as open.

This allowed all sorts of rule making customization. For instance, I have a morning routing which changes the Mode to morning UNLESS the calendar says no school.

This is the device type for the PE653 Pool Controller from ST. BTW... how far off are these device types in ST from the device types in Hubitat.

Is there some documentation on what would need to be changed in order to obtain a level of compatibility?


Download the Hubitat app