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

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.

Since it’s working for now, I can’t give you actual Live Logging. But I did look this morning when it wasn’t and I recall there not being much. Something like three lines that pretty much stated that commands were sent but no acknowledgement as to response or rejection.

Let it run for a over an hour and watch the activity…

The next time this happens, please post the log output. You should see at least 2 things with every change request.

  1. Along the lines of “adjusting to speed” low, med,etc
  2. a report from the controller saying that the change successfully occurred - “status report received from controller…”

OK, then we’re back to the “fans can be problematic.”

In particular if you have one fan trying to use another fan as a repeater the fact that you have two sets of blades spinning around can definitely make it challenging to get signal through.

If you can go up one floor above The fan and then go about 3 m horizontally towards the other fan and put a zigbee repeater right around there, you may be able to bounce signal up and over and get more consistent results. Sometimes it’s just trial and error. And remember you should do a zigbee heal each time you physically change location of devices.

2 Likes

While I haven’t been able to test it myself…you “should” be able to to access the setFanSpeed command from CORE. You can then pass the STRING parameter to the command and I believe it would work. You would also probably need to pass 01 02 03 or 04.
1,2,3,4 might work but it would probably give you a null error in the logs. Give it a shot and let me know.

Can’t test myself because we had a power outage at my house and I think it fried my controller. These devices seem to be very delicate :frowning:

1 Like

Yes! YES! It works!! I can’t tell you how much grief this saves me. Thank you for everything!

P.S. Single digits (“2”) work as well.

2 Likes

Awesome! I was in the process of loading up WebCoRE for a test on this. :wink:

An update and a question:

I have my webCoRE piston running beautifully. If anyone wants to look at it or import it, I’ll create an import code. However, it is needlessly complicated if you don’t have two fans and use means other than Minimotes to control them.[quote=“stephack, post:89, topic:85084, full:true”]
The next time this happens, please post the log output. You should see at least 2 things with every change request.

  1. Along the lines of “adjusting to speed” low, med,etc
  2. a report from the controller saying that the change successfully occurred - “status report received from controller…”
    [/quote]

My zigbee dropout problem went most of the day Sunday without appearing. Around 7-8pm, the one problem controller disappeared (the first controller has never failed). When I noticed it, I started Live Logging, but it returned very quickly. I’m leaving Logging on to see if I can capture the next event. At that point I did a Zigbee reset per @JDRoberts suggestion. As of Monday morning, it’s still good. Hopeful, but not optimistic, that might be enough.

[quote=“JDRoberts, post:90, topic:85084, full:true”]
In particular if you have one fan trying to use another fan as a repeater the fact that you have two sets of blades spinning around can definitely make it challenging to get signal through.

If you can go up one floor above The fan and then go about 3 m horizontally towards the other fan and put a zigbee repeater right around there, you may be able to bounce signal up and over and get more consistent results. Sometimes it’s just trial and error. And remember you should do a zigbee heal each time you physically change location of devices.
[/quote]And, the blades are metal!

I can get above the fans, but it’s attic crawl space so I’d prefer not to, at least until December, and I’d need to run power and deal with Florida summer attic temperatures. That can’t be good for the repeater, though it might be a sacrificial mission worth taking on. An alternative is to mount the Zigbee controllers in the attic space above the fans, but they seem both warm already and delicate so I’m avoiding that. Thoughts?

My question about the DTH: Since I have no lights, can I remove the light child app and delete the light devices? (Just to clean up.)

@stephack has noticed this on his and I have experienced it once. We are watching it but haven’t been able to figure out why some of the devices are behaving this way… is it any changes in the device handler or is it a ST platform zigbee related issue? It is very difficult troubleshooting because issues are random and not consistent across devices.

I doubt it’s related… but I have noticed that quite a few people are having strange issues with the Device Health functionality. Just to minimize potential problems I have disabled my Device Health on the ST hub to see if things become more stable. @CAL7, if this happens again please try this and let us know if it has any effect. You may be the best person to troubleshoot this because it appears to happen to you most often.

1 Like