[BETA v0515] Hampton Bay Zigbee Ceiling Fan/Light Controller

It’s not syncing every time I hit the master. So is there nothing that can be done from a code perspective? It looks like there there is polling going on every ~5 minutes, but that only seems to be happening for the light and not the fan. Can you confirm? It would be preferable to know the status of the fan without any manual intervention.

LIke I first responded a week ago, it is desirable but remember it is beta. :slight_smile: The polling does other things you can read about in First Impressions thread. As time permits we can look at outstanding issues to see what can be done but this is not high priority at the moment.

I completely get this is in beta. I just want to make sure that I don’t have any faulty hardware and that others are experiencing the same behavior. Thanks for all your efforts thus far.

1 Like

There are a couple of issues with the Android version that I thought I would mention.

  1. Fan Light - when the light is off, you are on the Fan selection screen (where you can set the fan speed, turn the light off and on and set the dimmer) and you change the dimming %, the light comes on to the dimming amount selected, but the light icon still shows it as off. It also shows as off on the Fan Light selection item on the Smartthings list.

  2. This one is no biggie, but on the Fan selection screen, when you scroll down to the bottom, it shows only dashes in the first two fields on the right that are supposed to show the fan child and light child versions. The parent version is shown.

  1. Are you saying that when you adjust the dimmer the light comes on but the light icon displays as off? If so, this is probably related to the recent ST app update that is not updating device statuses correctly. They are working on a fix for that.

  2. Hit the refresh button, then back out of the thing details view and go back it. It should display the versions now

I copied this over from another thread because it belongs here.

If you are using incandescent bulbs and you desire to go lower that is a con. However I believe the reason the factory firmware limits it to 20% is because this device is a repair part for the Gardinier fan which uses LED’s and it would make sense that below 20% the LED’s might start working inconsistently or when going from off to on 20% was the amount needed to get them to illuminate.

@dalec Continuing our discussion from the GE thread to here…

I’ve taken a better look at what is exposed by your DTH and I can see some real benefit from having discrete device names for each fan speed mode and I expect to be able to put them to good use. However, would you please consider implementing a set level to X command in the main device? This would be compatible with the GE 3-speed fan controller and most lighting dimmer methodologies in ST. . Thanks for considering!

I am not aware of previous dicussions you’ve had with @dalec or the exact benefit of adding this feature but I’ll do my best to address your request.

This controller has the ability to control BOTH the light and fan. Adding a setLevel for both the fan and the light will not only make coding this DTH unnecessarily complex but it will also make it confusing to use for a lot of users. I think it would make more sense to use another smartApp or modify the existing smartApp to utilize the newly exposed modes. smartApps are designed to scale in complexity as necessary. Device handlers should be as simple as possible to allow all use case scenarios.

With that said, I’m very open to adding/improving features if they are practical, so please let me know if I’m missing something obvious fromyour previous discussions.

PM me a link to your smartApp and I’ll take a quick look when I can.

I hear you BUT the multi speed fan device isn’t a dimmer application. Think of it like a replacement for the the pull chains on a typical ceiling fan. It simple discrete commands. Using dimmer logic is MUCH more confusing to the end user and is evidenced by the loads of posts here in the forum that continually refer to their misunderstanding of that logic that the GE can’t really control 0-100% but three speeds based on a random thresholds to trigger multiple speeds. Simple discrete commands are logically easier to understand, implement and troubleshoot. The K.I.S.S. method is the way I think. :blush:

Now the benefit I would see is if and when the device is actually able to control the full range from 0-100 and not do it in stages but that isn’t the way the manufacturer designed this device and firmware.

Hi, Stephan. Thanks to you @stephack @ranga @dalec for creating this. It’s the solution to my fan problems. My previous, short, discussion with Dale about fan speeds was here:

I appreciate the complexities of handling both a fan and light control in one DTH for the general use case. (In my installation, I don’t have a light, so I’m only using the fan.)

My control is through a webCoRE piston that needs to control two fans independently. I can certainly put enough lines of programming in to deal with eight different devices (2 fans x Lo/Med/MedHi/HI), but the coding is so much easier if I can loop through two devices and dynamically set the speed. Here is a brief summary of how it looks:

(Index is a variable 1-4 for the speed) For each of Fan1, Fan2 Do setLevel to Index * 25 END For

I have a just-barely working knowledge of how SmartApps and DTH’s are coded and work. Are you suggesting that if the DTH doesn’t have the setLevel capability, then a SmartApp could translate my setLevel command to one that is compatible with your DTH’s?

Keep in mind that I am a real novice, but I do see in the parent DTH that there is a setFanSpeed command, but it doesn’t seem to accept a parameter. I’m curious as to its purpose and wonder if there is some way to use that to achieve my objective.

Thanks, Dale. I understand your point about mapping percentages into specific limited speeds. I don’t mean to push my luck because I am truly grateful for what you have created, but would your objections be mollified if the setFanSpeed accepted a simple 1/2/3/4 input? I’ll quit bugging you now :).

You are not bugging or pushing your luck :smile: It is GREAT to always give feedback to evaluate and determine future possible updates. My intent was to only give my thoughts both pro or con at this time with the current device handler revision and it certainly isn’t intended to mean things won’t change or won’t be done in the future.

As far as setFanSpeed it is a custom command that was added in so that the handler could keep track of the commanded fan speed Lo/Med/Med-Hi/Hi for the purpose of returning to the last stored speed. It isn’t helping what you wanted to do with WebCoRE (edit: WebCoRE can directly accesses the custom command setFanSpeed :slight_smile: ) Let us know when you get everything installed and how it works for you.

Thanks for your patience with me. [quote=“dalec, post:78, topic:85084”]
Let us know when you get everything installed and how it works for you.
[/quote]Very timely! I did install everything Friday afternoon. Absolutely no problems with one device and your DTH. Can’t say the same for the second controller.

Fan1 is mounted about 25’ from the ST Hub with a plate glass window the only thing in the line-of-sight. Fan2 is another 5’ farther away.

Fan1 has been solid since the first moment. Fan2 was a little slow to pair but made it in a few minutes. Control worked across all functions. So far, I’m golden. Then, I notice an hour later, that it’s not spinning at the last speed I set; and no commands are being acknowledged. I can’t power-cycle it without the switch killing both, so I have to climb up and disconnect the module. In, brought next to the Hub, I do a Zigbee reset (several times) and just when I’m ready to give up, ST sees it. Back to good, so re-install. A couple hours later, repeat, but comes back on its own. An hour later, repeat; half a day later, still no response.

So, a few questions:

  1. Is the black or white antenna the Zigbee?
  2. Any chance (I think not) the DIP switches need to be different to avoid Zigbee conflict?
  3. Would the distance difference of 25’ vs 30’ likely be a problem?
  4. I’ve set a webCoRE piston to send a refresh command every few minutes, but it doesn’t help. Is there a better approach to prod it?
  5. Any hints to diagnose?

Thanks again!

-the white is zigbee
-are you using one remote with two controllers? The dip switches are only for communicating with remotes
-I don’t know distance issues or max with ST zigbee
-the device is setup with a refresh poll now

here are helps to diagnose. You didn’t mention how the remote works while having issues with ST. Just confirm. Open up the IDE Live Logging and then isolate on the good fan and watch how the logging is registering when you operate it. Then clik on and isolate the “bad” device to see how the logs differ. theoretically they should mirror each other real closely. This might give you a sense on what the issue is.

So how is the speed controller working on the fan RPM compared to the GE controller for you?

I expected the DIP switch configuration was just for remotes, so that question was a longshot. I have no remotes because I’m exclusively using variables based upon motion, presence and temperature with MiniMote button overrides. So, the only manual control I have is through the DTH interface.

Right now, connection has been re-established. AFAIK, the only thing I did was re-position the module and antennas. Or, it’s just random. Now that you’ve confirmed the Zigbee antenna, I can focus on getting that in the best position.

Speed control is everything I wanted. Previously, I was getting 30rpm, 62rpm and the max which is spec’d at 292rpm. Now, I get 61rpm, 140rpm, 200rpm and the max. (200 is a guess because it’s too fast to gauge.)

1 Like

Sounds like the speed control is solved now to figure out why your one controller is going weirdo.

FYI: @JDRoberts has an excellent post on ZigBee range here:

1 Like

Thanks for the link. Good read.

I’m within the shortest limits JD cites, so it’s not the first place I’d look. Do you know if the Zigbee module used by KOF repeats? It’s not battery, so I expect it would but I don’t know if that’s a ZHA requirement or if there’s a way to know. If it repeats, then the semi-failing device is mere feet away from a solid repeater.

It should repeat. As I’ve mentioned before, fans can be problematic, if I understand you correctly are you saying that the fan is operating, say at medium speed, and then a couple of hours later the motor has stopped and the fan has stopped spinning even though no commands were sent?

Or are you saying that the fan is operating at medium speed and you send an instruction to change it to low-speed and it doesn’t change to low?

If it’s the first case, then it’s something wrong with the fan itself.

If it’s the second case, do you have a remote and if so does it respond correctly to the remote?

and monitor the IDE Live Logging to see what is happening when the fan misbehaves…

1 Like

Hi, JD. It’s the second case. The fan just continues doing what it was and never gets or acknowledges a command from the ST.

I don’t have a remote. I can only 1) turn off everything [both fans, both Zigbee controllers] by a simple wall switch which I normally never touch, or 2) via the DTH which is nonfunctional when it goes incommunicado.