That has been my experience. If a zigbee device is reset, without removing it from the hub, when re-paired it picks up right where it left off, with automations remaining intact, etc.
If you haven't removed it from the hub, then you're not really repairing it, are you. It's already paired.
Correct, youāre really just re-connecting it. In your case, I would recommend removing the HBFC from the Hub, and the re-pairing it. This will make sure that the device is reset and re-configured when it joins. Make sure the parent device is working correctly before turning on the switch to create the two child devices. Also, the Device Network IDās of the child devices should be based on the parent deviceās Device Network ID. I had an issue where the parentās DNI changed after a multiple power outage event (I.e. Hurricane Florence), which caused the child devices to be messed up.
Perhaps you could turn off the switch to create child devices, the manually delete the two child devices if they arenāt removed automagically, then turn on the create child devices switch again to recreate them. Be sure to click SAVE between each change of the parent.
I suppose, but I have gotten several zigbee devices that were acting up to behave after a reset and re-pair process. By that I mean, the device is reset and put back into pairing mode, and the hub is in discovery mode.
Some kind of configuration info must be exchanged again by doing that, but I donāt claim to be an expert in this stuff.
I also donāt know if that will help with the specific problem youāre experiecing, but it wonāt affect the automations youāve already created, so might be worth a try.
If the issue has more to do with something wonky in the parent-child devices for this thing, then @ogiewonās probably right. And heās a smarter guy than me anyway 
.
1 Like
With zigbee devices the only thing joining again does is give the device a chance to find and or use a different parent (repeater) and re run the configure and installed methods.
A battery pull, or power toggle usually forces the device to hunt for a new repeater, configure can be run at any time.
For zigbee devices all the reporting settings are contained within the configuration method. Almost all zigbee devices require some level of reporting configuration to work properly, unlike zwave where many attributes are reported straight out of the box.
1 Like
So, are you saying that removing and repairing would help or wouldn't help?
If the only thing not working is device updates not hapening when the fan is operated from its own rf remote, but the unit can be controlled from HE, then pairing it again isn't going to fix that.
No, the problem is that device updates aren't happening when the device is controlled from Hubitat or the RF remote. And only the fan component. The light component updates correctly from both the RF control and HE control.
Is this the separate add on controller?, or the one that ships as part of the entire fan...
The add-on Hampton Bay zigbee controller that comes with RF remote. And now it seems that the light component isn't updating either. But only for one of the two devices I have paired to HE. I have two of the same device and one appears to be working correctly. Strangely enough, that is the one that is further away from the hub and the one that I had more trouble getting to work in the first place.
There may be some things on the driver that in can look at, been meaning to have a look at them for the past few months.
I have three of the Hampton Bay Fans in my house, a few things I have noticed.
The radios in these seem weak, weaker in fact than every battery zigbee device i own.
They do like having a repeater near by.
Every so often they are slow to respond to commands (this I may be able to fix in the driver)
I'm not using the composite device implementation, this may or not be part of the issue, and I will have a look at that as well.
Okay, so I unpaired and reset the device. I even powered down the ZLL bulbs that I have (Cree) since someone said they might be interfering. They were powered off the whole time I was running this test. I am now getting updates for the light device but only the light device. Here are the logs:
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.231 pm [info](http://192.168.1.12/device/edit/702)Office Fan fan was turned off
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.230 pm [debug](http://192.168.1.12/device/edit/702)evt- rawValue:0, value: off, descT: Office Fan fan was turned off
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.229 pm [debug](http://192.168.1.12/device/edit/702)Parse: read attr - raw: 3C670102020A00003000, dni: 3C67, endpoint: 01, cluster: 0202, size: 0A, attrId: 0000, encoding: 30, value: 00
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.146 pm [info](http://192.168.1.12/device/edit/702)Office Fan light was set to 100%
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.145 pm [debug](http://192.168.1.12/device/edit/702)evt- rawValue:255, value: 100, descT: Office Fan light was set to 100%
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.143 pm [debug](http://192.168.1.12/device/edit/702)Parse: read attr - raw: 3C670100080A000020FF, dni: 3C67, endpoint: 01, cluster: 0008, size: 0A, attrId: 0000, encoding: 20, value: FF
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.047 pm [info](http://192.168.1.12/device/edit/702)Office Fan light was turned off
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.045 pm [debug](http://192.168.1.12/device/edit/702)evt- rawValue:0, value: off, descT: Office Fan light was turned off
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:33.037 pm [debug](http://192.168.1.12/device/edit/702)Parse: read attr - raw: 3C670100060A00001000, dni: 3C67, endpoint: 01, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, value: 00
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:32.904 pm [debug](http://192.168.1.12/device/edit/702)refresh
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:22.338 pm [debug](http://192.168.1.12/device/edit/702)Parse: catchall: 0104 0202 01 01 0040 00 3C67 00 00 0000 04 01 00
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:47:22.203 pm [debug](http://192.168.1.12/device/edit/702)setSpeed: str:0
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.777 pm [info](http://192.168.1.12/device/edit/702)Office Fan fan speed was set to medium
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.776 pm [debug](http://192.168.1.12/device/edit/702)evt- rawValue:3, value: medium, descT: Office Fan fan speed was set to medium
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.770 pm [debug](http://192.168.1.12/device/edit/702)Parse: read attr - raw: 3C670102020A00003003, dni: 3C67, endpoint: 01, cluster: 0202, size: 0A, attrId: 0000, encoding: 30, value: 03
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.646 pm [info](http://192.168.1.12/device/edit/702)Office Fan light was set to 100%
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.645 pm [debug](http://192.168.1.12/device/edit/702)evt- rawValue:255, value: 100, descT: Office Fan light was set to 100%
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.644 pm [debug](http://192.168.1.12/device/edit/702)Parse: read attr - raw: 3C670100080A000020FF, dni: 3C67, endpoint: 01, cluster: 0008, size: 0A, attrId: 0000, encoding: 20, value: FF
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.560 pm [info](http://192.168.1.12/device/edit/702)Office Fan light was turned off
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.559 pm [debug](http://192.168.1.12/device/edit/702)evt- rawValue:0, value: off, descT: Office Fan light was turned off
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.558 pm [debug](http://192.168.1.12/device/edit/702)Parse: read attr - raw: 3C670100060A00001000, dni: 3C67, endpoint: 01, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, value: 00
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:30.432 pm [debug](http://192.168.1.12/device/edit/702)refresh
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:29.384 pm [info](http://192.168.1.12/device/edit/702)Office Fan light was set to 100%
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:29.375 pm [debug](http://192.168.1.12/device/edit/702)evt- rawValue:255, value: 100, descT: Office Fan light was set to 100%
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:29.373 pm [debug](http://192.168.1.12/device/edit/702)Parse: read attr - raw: 3C6701000808000020FF, dni: 3C67, endpoint: 01, cluster: 0008, size: 08, attrId: 0000, encoding: 20, value: FF
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:21.538 pm [debug](http://192.168.1.12/device/edit/702)Parse: catchall: 0104 0202 01 01 0040 00 3C67 00 00 0000 04 01 00
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:21.422 pm [debug](http://192.168.1.12/device/edit/702)setSpeed: str:3
[dev:702](http://192.168.1.12/logs#dev702)2018-11-17 02:46:18.052 pm [info](http://192.168.1.12/device/edit/702)Office Fan fan was turned off
Now, the other device I have of the same type is working correctly. Here's the logs for that one.
[dev:325](http://192.168.1.12/logs#dev325)2018-11-17 02:50:09.276 pm [info](http://192.168.1.12/device/edit/325)Kitchen Fan fan was turned off
[dev:325](http://192.168.1.12/logs#dev325)2018-11-17 02:50:09.275 pm [debug](http://192.168.1.12/device/edit/325)evt- rawValue:0, value: off, descT: Kitchen Fan fan was turned off
[dev:325](http://192.168.1.12/logs#dev325)2018-11-17 02:50:09.273 pm [debug](http://192.168.1.12/device/edit/325)Parse: read attr - raw: EE980102020800003000, dni: EE98, endpoint: 01, cluster: 0202, size: 08, attrId: 0000, encoding: 30, value: 00
[dev:325](http://192.168.1.12/logs#dev325)2018-11-17 02:50:09.245 pm [debug](http://192.168.1.12/device/edit/325)Parse: catchall: 0104 0202 01 01 0040 00 EE98 00 00 0000 04 01 00
[dev:325](http://192.168.1.12/logs#dev325)2018-11-17 02:50:09.125 pm [debug](http://192.168.1.12/device/edit/325)setSpeed: str:0
Why is the second device able to parse the response without a refresh
Also, for some reason, even though they are the same model, the working one is showing up as
- model: HDC52EastwindFan
The nonworking one is showing up as: - model: HBUniversalCFRemote
I never noticed this difference until just now. I'm not familiar enough with the logging to know why these events aren't happening for the non-working one. Is something not being sent by the fan or is something now being parsed by HE? But it definitely appears that it is these three events that are not happening in the non-working one.
[dev:325](http://192.168.1.12/logs#dev325)2018-11-17 02:50:09.276 pm [info](http://192.168.1.12/device/edit/325)Kitchen Fan fan was turned off
[dev:325](http://192.168.1.12/logs#dev325)2018-11-17 02:50:09.275 pm [debug](http://192.168.1.12/device/edit/325)evt- rawValue:0, value: off, descT: Kitchen Fan fan was turned off
[dev:325](http://192.168.1.12/logs#dev325)2018-11-17 02:50:09.273 pm [debug](http://192.168.1.12/device/edit/325)Parse: read attr - raw: EE980102020800003000, dni: EE98, endpoint: 01, cluster: 0202, size: 08, attrId: 0000, encoding: 30, value: 00My one, working HBFC is model HDC52EastwindFan
Yeah, I'm thinking there is something odd about that unit. Maybe I just never noticed it in ST. But I think it's going to have to go back to KOF. Luckily I only got it in May so it's still under warranty.
2 Likes
I just migrated one of my fan controllers over from ST where I used @stephack device handlers. I didn't realize that I needed to enable a setting to create the child devices in this HE driver. I am glad I was reading this. I didn't expect to need to do this. In my ST experience child devices always were created automatically. Not an issue but I just didn't know. @mike.maxwell Is there some kind of documentation for this driver or for that matter any of the other drivers that I should be reading up on and not just blindly adding devices the way I am prone to. 
After some further investigation, I found a resolution to my issue with this fan controller. If anyone else is having some wonkey behavior, this might be useful to you too. So, I had a power outage that lasted about 8 seconds today. The only devices that were affected were my two HB Fan controllers. They just completely were uncontrollable from HE. So, I left the devices in HE, went into pairing mode on the hub and reset the fan module by the 2 seconds-1 second switching routine. The unit reset but and did it's little flashing lights routine but Hubitat recognized that the device was already configured. So, it just went back into the same slot that was there. The child devices would not control anything, so I had to toggle those off in the edit device page, save, and then re-enable them. It seems that did assign them new device numbers so i have to rebuild all automations with them. But the devices are all now updating correctly in HE. Don't have to return the one unit after all. 
1 Like
Glad to hear that you have them all working as desired!
This definitely seems like an unhandled scenario in the Hubitat Composite Driver when reconnecting this device into an existing Hubitat device. Perhaps @mike.maxwell could investigate? The issue is the mapping between the parent and the child is based on the parent's device network id. Usually this is fine, but with this device the parent's device network id changes when the device reconnects to the hub and reuses the original Parent Device. From this point on, the parent cannot find its child devices until they are removed and recreated. @mike.maxwell, perhaps the mapping between the Parent and the Child could be based upon the parent's numeric device ID, instead of it's deviceNetworkID?
1 Like
That would be wonderful!!! It's a real pain to go through and replace the device in so many different apps.
1 Like
Have you ever tried updating the child network ID to match the new parent ID? Curious if this would solve this issue.
I am pretty sure I tried that. It did not help.
