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: https://github.com/rcloran/bellows/issues/43
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.
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,
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:
Eight sleep mattress;
Netatmo (all devices);
IFTTT;
Homekit (through HA RPI server);
Hue Bulbs;
Z-Wave Multichannel device (for Intermatic PE653 Pool Pump);
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?
ZOOZ Z-WAVE PLUS MOTION SENSOR ZSE02 (Generic Z-Wave motion sensor worked with ST but not with Hubitat)
Zooz mini sensor ZSE09 (ST device handler not working and neither does generic)
Stelpro Ki Z-Wave Thermostat. No driver will do anything with it not even Generic Driver.
GE Fan Controller works fine. I’m not just happy with the default driver
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.
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”.
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.
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.
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.
