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.
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.
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 
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.
Awesome! I was in the process of loading up WebCoRE for a test on this. 
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.
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.
You got it. If and when it goes offline, I’ll turn off Device Health and see what happens next. I love an adventure.
EDIT: Sad to say, the other - previously reliable - speed controller dropped off. I powered it down for an hour and it returned upon power-up. The logs don’t say anything useful. But I have now turned off Device Health to see if anything magical happens.
I know this is useless, but it’s all I’ve got now. This is when the controller is being ignored by ST and I try to turn it on to “High”. The fan is the one closest to the ST hub and had been good until this afternoon. FWIW, the other fan is slightly farther and, at this moment, is working.
Parent device log:
Child device log:
Shortly after posting the above, the other fan left. The time was about 7:25pm. It was running at Med-Hi and I sent two OFF commands.
Thanks for the logs. Well we know that the smartApp is attempting to send the commands to the controller but for some reason the controller is not receiving it. My best guess at this point is either:
I think it’s time to disable the Device Health on your ST hub. Once you get them talking again, please continue to monitor the logs and cross your fingers.
PS the “adjusting to null” you see in the last pic is probably because you used “1,2,3,4” instead of “01,02,03,04” in CORE. This should have no impact on the function of the fan but does cause the logs to display null. Easy fix for a future update.
Thanks, Stephan. Same fan as above - came back in its own. Sometime between 8:00 and 8:05pm. After an hour+ of trying, you can see the fan mode value finally changed from 03 to 00.
glad its back. Dont forget to disable the Device Health.
Also, what version of the device handler are you running?
