Home Depot/Hampton Bay Zigbee Fan Controller in SmartThings

Feature Requests
1

Currently SmartThings has a customer device handler for the Zigbee Fan Controller by Hampton Bay that can be purchased alone, or included with some fans. When SmartThings integrates with HomeAssistant it only sees the device as a single switch that turns the fan on/off, but can’t control the light or fan speed due to the way the child devices are handled in HomeAssistant. Other platforms like Google Assistant identify all the child devices separately.

2

As a workaround you might be able to setup virtual switches in SmartThings cloud that could be accessed by Home Assistant.
Until I got my HA Alexa integration working for Alexa Routines I used a SmartThings virtual switch/sensor combo (some call it an “Alexa Switch”) to trigger Alexa events from HA.

3

can the zigbee fan controller not be paired directly to HA bypassing the SmartThings app altogether?

Also, do you have a link to the fan controller?

4

Here is the link for the fan controller
https://www.homedepot.com/b/Lighting-Ceiling-Fan-Parts-Ceiling-Fan-Remotes/ZigBee/N-5yc1vZbvmuZ1z0kb2j
I am running Homeassistant in Docker on a Linux VM. The hypervisor I use doesn’t easily pass through devices from the host hardware to the guest vms so I can’t just use a Zigbee/Zwave stick, and I already had the SmartThings. I may upgrade to a better server and use VM Ware which will have better passthrough, but until then I am stuck using peripheral hubs. I thought about getting a wink which the fan controller was designed around, but they have been showing signs of failing as a company and I don’t want to waste the money.
This is the handler for SmartThings that allows the fan controller to work with my SmartThings hub.
https://community.smartthings.com/t/beta-v0515-hampton-bay-zigbee-ceiling-fan-light-controller/85084

I was told by @andrewsayre in the issues forum https://github.com/home-assistant/home-assistant/issues/23485 that:

Child devices that are created with isComponent: true are not exposed in Home Assistant because they are internal to the implementation of the DTH. That is not something we’ll change anytime soon. If they show up as discrete devices in SmartThings, they will work in this integration. The reason you only see a switch is because that’s all that the parent DTH is exposing capability-wise.

He then recommended to post this as a feature request and hopefully something can be done in a later update.

Edit: fixed link to fan controller

5

uummm…

I think you need to check that link again…

6

that was very weird, that was something I searched days previous and I had literally just pulled up the home depot site for the controller and copied the link. Anyway, I have fixed the link and it should work now.

2 Likes
7

Thanks!

It sucks that you don’t have a way to test it natively thru a zigbee controller.

If you have a spare RPi laying around that you could temporarily install HA on to test it it might be worth a try.

I would do it but I don’t think I want to spend another $50 on something that won’t work without Wink.

8

It looks like HA works with the Wink API if you setup a developer account.

9

I saw that but I don’t think that helps in this situation.

the issue is that I don’t have (and i don’t want) a wink hub. And we don’t know if the fan controller will pair to a non-wink zigbee controller directly and then work with zha in HA.

10

I see now it is implied you need the hub. :frowning:

This quote is deceiving, IMO.

Home Assistant integrates with the Wink API and automatically sets up any switches, lights, locks, fans, climate devices (thermostats, air conditioners, and water heaters), covers, sensors, alarms, and sirens.

11

It does integrate with the Wink API which is cloud based and needs the hub. Then when you set up the integration it goes to the Wink Cloud and pulls down all of the devices that is associated with your hub. I think…

I wouldn’t call it "deceiving’, just not explicit enough.

12

I understand that sentiment too, especially since Wink’s future is a little questionable if you are up to date on tech news.

But we do know that it will pair to a non-Wink zigbee controller because it paired very easily to my SmartThings. It just takes a custom device handler for it to recognize the “child devices”. When I first paired it to my SmartThings hub it showed up as a single switch, just like it does in HA. Once I added the custom device handlers and pointed the device to them it all worked. So I believe you should be able to add the device to your existing zigbee controller, the only question is how much of the device you could control (you may end up only with a single on/off switch for the fan and no light control). If it doesn’t work you could always return the Fan Controller to Home Depot and get your money back. Simply tell them the truth, that it didn’t work with your system.
In regards to my system, I might try to modify the device handler code to change the “isComponent: true” to “isComponent: false” and see if it will split all the child devices out in my SmartThings app which will then allow them to all be seen by HA. When I use the SmartThings app I only use the newer version which shows them all separated anyway. The isComponent is what groups them to a single device and only in the “Classic” app. Maybe that is the answer for you as well, maybe using a zigbee stick and the built-in zigbee management will keep the devices separate.

13

good point.

Yeah, that’s true.

Maybe if I get some time I’ll give it a try.

14

If you get one at home depot and it works, check out ebay, I just got 3 of them for $39 each vs the $50 at home depot.

1 Like
15

So I changed the isComponent=true to isComponent=false in the child device handlers, and waited a little time for the changes to take affect. I don’t know if the hub needs to be rebooted, haven’t tried that yet. I went to my HomeAssistant SmartApp in my SmartThings Classic app and saved it again to update, then restarted Hassio a couple times. I checked my integrations and still only see the single switch that correlates to the parent device and it doesn’t see any of the child devices. I enabled debugging for the SmartThings integration and in my log it shows the following when I turn the fan from MED speed to OFF

DEBUG (MainThread) [homeassistant.components.smartthings] Push update received: {'location_id': '5d8d8499-85ba-4131-8d86-940d5c3645ca', 'device_id': '3836b3ff-3a27-498d-abe1-e6900539d2bd', 'component_id': 'fanMode2', 'capability': 'switch', 'attribute': 'switch', 'value': 'off', 'data': None}
DEBUG (MainThread) [homeassistant.components.smartthings] Push update received: {'location_id': '5d8d8499-85ba-4131-8d86-940d5c3645ca', 'device_id': '3836b3ff-3a27-498d-abe1-e6900539d2bd', 'component_id': 'Main', 'capability': 'switch', 'attribute': 'switch', 'value': 'off', 'data': None}

Specifically it is referencing the component_id “fanMode2” when I set the fan to Med. It changes to “fanMode1” if I choose Low, and “fanMode3” if I choose Hi. So the integration is definitely sending updates for the fan state and speed, but HomeAssistant isn’t processing them properly. The above log entry that references component_id “Main” always comes in tandem with the fan state when it is switching the fan state from OFF to ON or vice versa. When switching from one speed to another, it sends just the “fanMode-” alone. This makes me believe that the “Main” component_id is the only thing being identified by HomeAssistant.

Turning on/off the light doesn’t reflect anything in the log at all.

16

Can you set up a template sensor to extract the state from the json string that is sent?

17

I assumed since the state was being transmitted I might be able to do such, but not very good with the templates. Last time I tried I broke my front end pretty good. Maybe if someone with some familiarity could use the above data to format a template I could try.
Edit: Since the most recent update (0.93.2) none of the states show up in the log for SmartThings, but the single entity for the fan switch still updates based on if the fan is running or not.
Also, I tried looking into using templates, but I can only see how to reference data that shows up as part of an entity in my entities list, not how to reference information that is broadcast to HA but not processed as an entity.

18

@dragonsoul84 Unfortunately, it’s probably not that easy to change. Given the logs you provided I can conclude 2 things:

  1. The changes (isComponent to false) are not being reflected. If it was, you would have unique device_ids for each component. You might have to remove/re-add the device in ST to trigger the change and it may take a few hours to reflect in the API if you use the same name.
  2. The DTH is not using components they way there were designed to. It makes no sense that changing the fan mode for a results in a different component_id. Think of component_id as the device_id as of a child. It’s clearly being used to facilitate something else.

There’s no issue with how HA processes the events. The DTH is sending data that make no sense. Often custom DTHs are hacked together to work via the ST Mobile App – but don’t implement the concepts correctly to work in 3rd party/API integrations.

19

Thanks @andrewsayre for the input. I may try removing the device and re-adding it. I did initially detach the device from the DTH in the ST backend, made my changes, and then re-attached it hoping that would be similar to removing the device, but apparently not. I don’t know why the creator implemented the component_ids the way they did, but how you explained it makes it clear to me why the speeds show up in my ST --> Google Assistant integration as individual devices/switches and not a single switch with speed options. If your first suggestion doesn’t help it looks like I may be waiting until the ST integration works better with components, or hopefully someone will improve the DTH to work better with integrations.

20

Looking at things a little more, if the integration can take the main device (device_id) and spawn its child devices (component_ids) for other items, shouldn’t home assistant just do like google is doing for this device and show the child devices that act as single switches, and when one switch turns on to change the speed, the DTH on the backend turns off any other speed switches? I’m thinking it was done this way because the device supports non-standard fan functions (such as “Comfort Breeze” that alternates the speed using a special algorithm to simulate a breeze blowing through the home rather than a constant blowing of air), and has 4 speeds (low, med, med-high, and high) instead of just 3. If it only used the standard programming for fan devices it would loose the med-high speed and “Comfort Breeze”. If I had to lose those for my HA integration it wouldn’t kill me, I’d just use the ST app for the times I need them. But I would hope that HA would have a way to grab all the child devices just like it does with other devices.