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
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.
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.
@dragonsoul84 Unfortunately, it’s probably not that easy to change. Given the logs you provided I can conclude 2 things:
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.
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 differentcomponent_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.
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.
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.
So I too have these controllers and I am using them with HA and SmartThings. However due to the fact that they do not display properly in HA as noted. This is what I did instead. Since I’ve been using HA with SmartThings since before the wonderful integration piece was completed I have the SmartThings MQTT bridge stuff working. So in my case I just added all of the controls for the fan controller to the MQTT bridge app. Yes this is not ideal but it works. I also plug the light in through the MQTT as well. I haven’t attempted to add them directly to HA yet because the zigbee side of my Nortek stick is weird. I might give this a whirl though here soon and see what my findings are.
Yeah, I was on the fence to swap back to using the MQTT bridge myself. I had that working well, but changed to the integration which also worked well until I threw in the fan controllers. I was hoping that some updates would have been done with the integration to address this shortcoming, but nothing so far. I started tinkering with the handlers to try and remove the child devices and make it all into a single handler, but I could only get it to where the devices would show up individually but not actually operate. Don’t even know if it’s possible to do that, probably why they made them child devices in the first place. If I can’t figure it out in the next month or so I’ll probably just go back to MQTT
Yeah I run hybrid lol. Local Zwave with HA, MQTT bridge and the integration lol. But hey it works. I’ve almost finished migrating all of my zwave devices from ST over to HA but I still have a few outliers that I just haven’t got around to yet. I figure for now ST will end up being my zigbee controller because the zigbee side of my USB isn’t 100%
So I have been still looking for a solution to this issue and I think I have finally found what I’m looking for, I will probably attempt this at some point in the near future, but I wanted to share my discovery for those that may want to make the move to a fully local solution. I found this website that details the setup of the fan controller in Homeassistant.
I hope this proves helpful to anyone who has come across this thread looking for answers.
I wish I would’ve seen this post months and months ago ugh. But so happy to see that I can now control my HamptonBay ceiling fans natively in HomeAssistant. No more need for me for the MQTT Bridge. YES!!!
Honestly, I dismantled my smartthings hub and switched it all over the the native zwave component. Unless something has changed and someone made some improvements to the handler, I don’t even know if it can be used anymore. My memory tells me that it relied completely on the old SmartThings app to configure and that app has been deprecated (not even sure if it functions, I remember seeing an email about them shutting it down). The MQTT bridge did work ok with my locks but did almost nothing for the fan controller. Best bet is to get a zigbee controller (I used the GoControl one here: https://www.amazon.com/GoControl-CECOMINOD016164-HUSBZB-1-USB-Hub/dp/B01GJ826F8)
and then set it up natively in homeassistant. I haven’t had a single issue since doing it that way.
The listed model also supports wave so you can migrate all your zwave off the SmartThings too. The only thing I feel I’m missing is an easy to use management interface for my lock user codes.
Probably gonna have to migrate to the new OZW (Open ZWave) soon also because it looks like the standard zwave component is going to be replaced by it soon, so if you do go this route I’d look into going straight to OZW but I don’t know how well this fan controller works with it.
Well crap. I was hoping for a way to make it work, as my HA install is currently in Docker, in a Hyper-V Ubuntu VM. I have very little hope that I would actually be able to send a USB stick down to it. LOL
Doi. Yes you are right. I even specified the usb stick to be zigbee with zwave as a bonus, but then went on about zwave. Thank your for correcting that information.
I’m sure there is a way to pass the device through. maybe something like this.
It passes through a com port to the guest vm vs passing the USB port itself, but maybe it will work or get you on track. I think the stick just shows as a com port anyway, but I don’t know if that is how Windows would read it before passing it on. I have the same installation type, but using ESXI VMWare instead of Hyper-V which I know almost nothing about. VMWare is super easy to passthru.
Thanks. It very well may work, but the thought of passing a device from host to vm and then from vm to Docker seems fragile. I have another project that I really need to complete to move my Windows server over to Unraid, then things would be a bit cleaner.
Just want to say I just added 3 of these with no issue doing the zha.permit method that the article above mentions. HA picked them up seamlessly.
Cannot comment on a lightkit function as I don’t have one on my fans. But do note, HA registered a light even though I don’t have one, so I suspect it will work fine.