Zigbee reports not be received by parse (Zigbee filtering?)

While porting my Hampton Zigbee fan controller to HE I came across a difference with how hubitat receives updates from the controller. This issue is also present in the built in HE driver.

If the fan light is off and you send a light level command, the light comes on to the correct brightness, but does not update the level value. The controller should be sending 2 reports (on/off status and dim level) when it's off and receives a setValue command. In ST both theses reports are parsed and update correctly. In HE only the on/off status is received. If the light is already on, then the dim value is received and parsed correctly.

I have worked around this by adding a readAttribute command to the setLevel method, but this should not be necessary.....and as mentioned above, this issue is also seen with your official driver.

I cannot help on the Zigbee Parsing issue, however... I do have a quick question.

Is this the device you are referring to? I am interested in adding some smarts to my ceiling fan, as I currently only have one physical switch which controls power to both the light fixture and fan. I want to replace that one wall switch with a Lutron Pico remote, and this zigbee device seems like it would work well.


Yessir. A lot of details can be found here:

A couple things to keep in mind:

  • You will VERY likely need a zigbee repeater in every room that you use this controller (does not matter how close to the hub the fan is) .
  • It can be a pain to pair (requires flipping the power on/off 5 times and the timing is guesswork). This can be really painful if you dont have a physical switch because otherwise you will need to flip the breaker.
1 Like

This has nothing to do with the zigbee stack btw, it has everything to do with how the relevant clusters are configured for reporting in the driver.

not sure I agree with this, if the level value hasn't changed why send a report?, the current value properly represents the current level.

This is precisely the issue. It does not report even when the value is changed.

for example..
the light level is 75 and then the light is turned off.
We then send a setLevel command of 35.
The light will change to level 35 but the "level" attribute will remain unchanged because the parse emthod never receives an updated value from the controller. In ST this update is received.

See my report cofig below.
BTW, the fan speed and on/off report every 10 minutes as configured. The Light Level does not. This is less of an issue but thought I would mention it as well.

zigbee.configureReporting(0x0006, 0x0000, 0x10, 0, 600, null)+
zigbee.configureReporting(0x0008, 0x0000, 0x20, 0, 600, 0x01)+
zigbee.configureReporting(0x0202, 0x0000, 0x30, 0, 600, null)

this is what mine does when the following commands were issued to it.
on() --reports on
setLevel(25) --reports 25%
off() --reports off
setLevel(50) --reports on then 50%
setLevel(20) --reports 20%

when you switched to the HE driver did you hit configure to set the bindings and config params?

I was about to reply yes but then decided to verify. I did hit configure after changing the driver. However...what I now realize is that after hitting save...I need to refresh the web page and then hit configure. After doing this, it does work as you described.

So...do you see anything I need to change with my report config? Any suggestions since I can't view the code behind you driver.

I don't ever set the minimum reporting interval to 0, I always use 1 second.
The only other difference I see is that you have a change threshold set for the level cluster, we don't, and our max reporting for all clusters is set to 12960 seconds.

1 Like

That was it..I removed the change threshold and all is good.
It's always something simple that I miss.


@ogiewon you may or may not have come across this in-wall fan controller as well.


Itโ€™s compatible with the zigbee fan controller but uses the same ~400MHz RF signal as the handheld remote (i.e. not zigbee). I recently installed two of them rather than stick with picos to control my fans.

My reasoning was that theyโ€™d work even if my hubitat hub was down for some reason (less likely than with ST, I know, but still possible). Plus the images on each button make it easier for other family members to know what theyโ€™re pushing, including my kids.

Just throwing it out there as an alternative.

Thanks Mark. I did see that. I just wish the fan controller that came with it was Zigbee enabled. It does look like a nice wall switch design...

Yeah, I ended up with two wasted in-ceiling receivers when I bought the in-wall remotes. I still thought it was worth it though, the in-wall remotes work great with the zigbee in-ceiling receivers I already installed in my fan canopies.

1 Like