Errors generated by Hampton Fan Controller

I'm getting this error on one of my Hampton Bay Fan Controllers. I can control the fan fine but this error is generated every time the device is refreshed (manually or via scheduled reporting).

I have another one that's working fine.

I have tried cycling every attribute (light on/level/setFan Level) and tried configure(). Issue perists.
Anythoughts @mike.maxwell

java.lang.NullPointerException: Cannot invoke method sendEvent() on null object (parse)

Edit: I have 3 of these devices. After a recent extended power outage at my home only the bedroom fan stayed online. My den and family room fans both stop communicating with the hub (this is "normal" for me after power outages.

Bedroom fan: regained connection to hub after power was restored...and currently generates no errors.

Den Fan: Lost connectivity...I had to do my usual trick to reconnect...I flip the power switch on the fan...start a device discovery on the hub web interface, flip the power back on and wait...within 1 minute the fan lights blink and everything works again. I have dome this numerous times. This time, I receive the above error.

Family Room Fan: Lost connectivity...I left this fan disconnected because it requires a breaker flip to power down and is rarely used. I just did my usual trick to get it reconnected...it too is generating the above error.

1 Like

Check to see if the deviceNetworkID of the Child devices matches with the Parent Device. During my power outages recently, my HBFC started acting weird. Somehow the DNI of the parent had changed, which shouldn’t happen for a Zigbee device, right? I ended up turning off the switch for creating the two child devices, saved, then turned it back on, and saved again. The two children were created again and afterwards everything worked error free. Unfortunately, this means you have to go through every automation that uses the children and change them to use the two new ones.

This is precisely what I was hoping wouldn't be necessary. :disappointed:

It did in fact change. I dont have the controller in any apps..only the children. Any downsides of changing the controller dni back?

I didn’t try that. I assume the DNI of a hardware Zigbee device is supposed to be constant. Not sure how it can change. @mike.maxwell, any ideas?

Changed it....didn't work and had to change it back. This controller continues to be a real PITA!

The 16 bit address can change, the 64 bit one doesn't

Thanks Mike. Can you think of a way to avoid this issue of the parent losing its linkage to the children? What if the DNI of the parent was not used as the basis for th child DNI? Perhaps have the parent use some other unique DNI for each child that wouldn’t be bothered by the parent‘s DNI changing?

Is this our driver doing this?

Yes. It seems to be caused by power outage events. When the HBFC rejoins the Zigbee mesh, somehow the DNI has changed. Other Zigbee devices that fall off the network usually rejoin with the same DNI.

What’s weird is that when the HBFC reconnects, it uses the same Parent Device, not a new one. But since the DNI has changed, it has a hard time trying to find its own child devices to update them.

1 Like

Thank you for posting this, I just experienced this as Hurricane Michael blew through Charlotte yesterday. I didn’t lose power other than a few flickers. My one and only HB fan controller stopped working and was throwing the errors mentioned in the OP. I ended up resetting and pairing again which was a pain. Using stock driver.

@mike.maxwell, any update on this?
I recreated the child devices on one of my fans to fix this error. I left the other in case you needed to test anything. Let me know

What would happen if you tweaked the “broken child devices” to use the newer DNI based on the parent’s new DNI? I wonder if they would start working again? I think you tried the opposite, changing the parent’s DNI to match the old children... Just an idea.

I had the same idea....unfortunately the child devices are installed with "isComponent:true" so they cant be edited or deleted individually. Only via the parent.

1 Like

This bug got me. I struggled with this for days. Sometimes things would work, sometimes Alexa would turn things on/off, sometimes button controllers would work...

I initially paired the fan controller out of the fan, moved it to the fan, and apparently this is when the ID changed. I thought it was just a flaky device or poor Zigbee mesh like everyone complains about with this controller.

I turned off the option switch in the parent device labeled "This will create two additional devices, a fan and light that can be used in addition to the controller" and saved, and turned the option back on and saved again. I had to go through and fix all my rules as mentioned above. So far, it is working better than it has since I installed it.

I wouldn't have found this thread except this came up in another topic. Composite Child Devices and Dashboards

1 Like

I just had this happen last night. Like the rest, we had a power outage and the parent 8 bit DIN changed. This is a real pain to have to update all the rules, since I have 8 HBFs. Any update on a fix?

It was mentioned to @mike.maxwell a while back but I don't know if this is being actively worked on. A workaround that many have used is to create virual devices as placeholders in your apps. These virtual devices sync with your actual fan devices and this way, when the actual child devices get changed it would only need to be updated in the "sync" app.

@Ryan780 created an app for this I believe. I'm just too lazy to search for it at the moment.

I have been using @Ryan780 app to sync multiple fans (Awesome app). The challenge I'm facing is that I using SharpTools for my dashboards and the virtual fan driver isn't visible to the application. According to @josh, the driver doesn't expose one of the capabilities that are used as part of the authentication process.

@mike.maxwell , if this parent-child relationship isn't scheduled to be fixed in the near future, could you expose the sensor or actuator capabilities to the virtual fan driver so it can be used with Sharptools?

In the meantime, could you use the following Simulated Fan driver I put together instead of the built-in Virtual Fan driver? It exposes the Fan Control capability along with an Actuator and Sensor capability as a fallback.

This driver should effectively do the same thing as the built-in Virtual Fan driver... and it also exposes Actuator as a generic capability so it can be used in SharpTools.io

1 Like

Thanks Josh.