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.
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.
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.
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
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 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 ) 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:
- Is the black or white antenna the Zigbee?
- Any chance (I think not) the DIP switches need to be different to avoid Zigbee conflict?
- Would the distance difference of 25’ vs 30’ likely be a problem?
- 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?
- Any hints to diagnose?
-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.)
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:
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…
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.
- Along the lines of “adjusting to speed” low, med,etc
- 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.