Fan Module (Hampton Bay)

[mjruotolo]

I would like to use this module with the gateway. https://www.homedepot.com/p/Hampton-Bay-Universal-Wink-Enabled-White-Ceiling-Fan-Premier-Remote-Control-99432/206591100 This is a universal zigbee fan controller with fan and light controls. I have included a bunch of screeen shotes of the nodes as well as the device handler from smartthings. Not sure if this will help in any way. Please let me know what other info you will need.

Smartthings Device handler. https://github.com/dcoffing/KOF-CeilingFan/blob/master/devicetypes/dcoffing/kof-zigbee-fan-controller.src/kof-zigbee-fan-controller.groovy

[gmitch64]

I'd like to second this too please. Fan control is the one main area that I've not touched automation wise.

G

[jjlawren]

I have a couple of these that I’d love to integrate.

[manup]

So this is only the remote? Is there also some data available about the controller?

Can you please also provide the basic cluster attributes? They should be visible when joining the device while sensor search is running.

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Request-Device-Support

[jjlawren]

The fan/light controller which is wired to the ceiling fan has both an RF antenna and a zigbee controller. The remote it comes with is RF, but the controller can additionally be paired to a zigbee hub.

[ebaauw]

I stumbled across these looking for a solution for my ceiling fans. They are everything you'd want. Unfortunately, only for the North-American market (110V, different mechanism to attach the fan to the ceiling, where the controller fits neatly under the canopy).

[anacozero]

Any other info needed? Been sitting on these units for a while after switching off smartthings. Would love to help in anyway.

[ebaauw]

Receiver on when idle is true, cool. Looks like it would be exposed as a /lights resource if we just whitelist the device type, 0x000e. I wonder if the Level cluster actually links to the fan speed, or if its only used to accept Move to Lebel (with On/Off) commands to turn the fan on or off. Cluster 0x0202 is Fan Control, which defines an attribute for setting the fan speed to off/low/medium/high/auto. This needs to be added to general.xml. Then, we need to find out which of these are actually supported.

[anacozero]

This driver helped me figure some info out: https://github.com/stephack/Hubitat/blob/master/deprecated/drivers/KOF%20Fan%20Controller.groovy

It looks like x0202 is the fan control. There is no cluster info on x0202 in deCONZ on my device, so i can't provide any screenshots on what that looks like. Not sure how to get that info.

And x0008 is the light dimmer control. the id 0x0000 is the light dimmer level with values between 0 - 255

[anacozero]

added this to general.xml for testing and it seems to be working for all fan control except breeze. It will read the value, but won't write it.

<cluster id="0202" name="Fan Control">
<description>Attributes and commands for switching Fan Control.</description>
<server>
                <attribute-set id="0x000" description="Fan Level">
                    <attribute id="0000" name="FanLevel" type="enum8" access="rw" default="0" required="m">
                            <value name="Off" value="0"></value>
                            <value name="Low" value="1"></value>
                            <value name="Medium" value="2"></value>
                            <value name="Medium-High" value="3"></value>
                            <value name="High" value="4"></value>
                            <value name="Breeze" value="6"></value>
                    </attribute>
                </attribute-set>

    <command id="00" dir="recv" name="Fan Speed Select" required="m">
        <description>Control Fan Speed</description>
        <payload>
            <attribute id="0x0000" type="enum8" name="Fan Speed" required="m" default="0">
                <description>The effect identifier field specifies the fading effect to use.</description>
                            <value name="Off" value="0"></value>
                            <value name="Low" value="1"></value>
                            <value name="Medium" value="2"></value>
                            <value name="Medium-High" value="3"></value>
                            <value name="High" value="4"></value>
                            <value name="Breeze" value="6"></value>
            </attribute>
        </payload>
    </command>          
</server>
<client>
</client>

    <!-- TODO -->
</cluster>

[ebaauw]

Ah, so the REST API should expose two resources, one for controlling the light, and one for controlling the fan.

Where did you get the command from? I didn’t see any commands in the Fan Control cluster. I think there also a value 5 for Auto. Value 6 means on while occupancy is detected, which would need an Occupancy Sensing cluster.

Can you control the fan using the command from the deCONZ GUI?

[anacozero]

I just wrote the command based on my limited knowledge of how this works. Pretty new to this whole thing and just trying to be dig in as much as possible to be helpful.

I can't control the fan with the command in the GUI, but i can control the fan in the GUI through the attribute editor:

[ebaauw]

That’s how it’s supposed to work, according to the ZCL spec.

[ebaauw]

I updated general.xml with the ZCL spec for Fan Control.

As the Fan Control cluster is on the same ZigBee endpoint as the On/Off and Level Control cluster, we cannot create an additional /lights resource for the Fan. Also, exposing the fan part as a separate ZHAFan /sensors resource seems both unintuitive and too much work. Therefore, I think the best options is to add state.speed to the /lights resource.

With the above commit, you should see a single /lights resource, with state.on and state.bri reporting and controlling controlling the light, and state.speed reporting the fan speed. Updating the speed hasn't yet been implemented. Also, for now, I expose the raw enum value in state.speed.

Obviously, I cannot test this without the Fan Module. Could you please compile and test this PR? Re-pair the Fan Module, or search for new devices from Phoscon and read the Basic cluster to trigger the creation of the REST resource. Please list the REST resource, so I can check that it's working as intended.

[anacozero]

I was able to add the device to the REST interface and it shows up as a light device. Here are some screenshots of it in phoscon. I am not able to see the fan speed in the interface.

**************************** Object info *****************************
{
"type": "Fan",
"name": "Light 3",
"modelid": "HDC52EastwindFan",
"swversion": "0000000F",
"uniqueid": "00:22:a3:00:00:20:cc:2c-01",
"manufacturername": "King Of Fans, Inc.",
"state": {
"on": true,
"bri": 140,
"alert": "none",
"reachable": true
},
"etag": "a6495b828ba08cbcda6d94baa51b2e49",
"hascolor": false
}
************************* End Object info ***************************

[rtclauss]

I have two of these installed and ready at home. I can provide testing and debugging to get fan control working, too.

[ebaauw]

Phoscon won’t show the fan speed in the interface, but it should be included in the REST resource. Can you please GET /lights/id and list the output.

@anacozero where did you get the object info from? The REST API reports the object with the keys sorted; I’m afraid this comes from another system that might filter out state.speed.

[anacozero]

Here's the JSON direct from the API:

{
    "etag": "eb8436f6ba6f6fb71057b881e1253048",
    "hascolor": false,
    "manufacturername": "Heiman",
    "modelid": "HDC52EastwindFan",
    "name": "Light 1",
    "state": {
        "alert": "none",
        "bri": 255,
        "on": false,
        "reachable": true
    },
    "swversion": "0000000F",
    "type": "Fan",
    "uniqueid": "00:22:a3:00:00:20:cc:2c-01"
}

[ebaauw]

Damn, no state.speed. On the good side: the REST API plugin did accept the device type.

[ebaauw]

Looks like I didn't include it in the response of GETting the light state. Can you please check if it appears in websocket notifications, when you change the speed (from the remote or through the deCONZ GUI)?

[anacozero]

So interesting behavior. Only turning on and off the light sent notifications on the websocket. Changing the fan on the controller didn't.

{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":true,"reachable":true},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}
{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":false,"reachable":true},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}

Tried changing the fan speed in the GUI through the attributes editor, and still no notifications. But if I changed the speed on the remote (or GUI), THEN force read the value through the GUI, I'd get the notification. So it only showed when I pressed READ in the GUI.

I can change the fan speed all I want, but it doesn't update in the websocket notifications until I click READ.

{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":true,"reachable":true,"speed":4},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}
{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":false,"reachable":true,"speed":4},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}
{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":false,"reachable":true,"speed":0},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}
{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":true,"reachable":true,"speed":0},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}
{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":true,"reachable":true,"speed":3},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}
{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":true,"reachable":true,"speed":2},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}
{"e":"changed","id":"1","r":"lights","state":{"bri":254,"on":true,"reachable":true,"speed":1},"t":"event","uniqueid":"00:22:a3:00:00:20:cc:2c-01"}

EDIT: I just checked the REST resource and state.speed isn't listed.

[ebaauw]

I just checked the REST resource and state.speed isn't listed.

That should be fixed by my latest commit. If you're comfortable with it, you can compile it yourself (on a Raspberry Pi), otherwise, wait for 2.05.66.

Changing the fan on the controller didn't. So it only showed when I pressed READ in the GUI. I can change the fan speed all I want, but it doesn't update in the websocket notifications until I click READ.

Attribute reporting hasn't yet been set up for the fan speed. Polling hasn't been setup either, so the only way the REST API sees the new value is when reading the attributes in the deCONZ GUI.

As the controller uses the manufacturer code for Ember, it's already whitelisted to configure the attribute reporting for state.on and state.bri. By the looks of it, the controller supports attribute reporting for state.on. Could you change the light brightness and double-check that the change is reported over websocket notifications immediately?

Could you setup attribute reporting for state.speed manually in the deCONZ GUI, to check whether the module supports this? Open the Bind Dropbox panel in the GUI, drag the the 0x0202 cluster to Source, drag endpoint 01 of the RaspBee/ConBee to Destination and press Bind. Here's an example for the Level Control cluster:

Next, open the Cluster Info panel, and select the 0x0202 cluster. Then scroll down to the list of attributes and double-click on Fan Level. In the popup window, enter the reporting configuration and press Write Config. Here's an example for Current Level, the same values should work for Fan Speed:

When this succeeds, you should see notifications for state.speed.

[rtclauss]

Hi, I pulled the code from your branch, rebuilt the plugin, restarted deconz, and added my fan.

As the controller uses the manufacturer code for Ember, it's already whitelisted to configure the attribute reporting for state.on and state.bri. By the looks of it, the controller supports attribute reporting for state.on. Could you change the light brightness and double-check that the change is reported over websocket notifications immediately?

I do see the brightness immediately change in notification/websocket:

{"e":"changed","id":"14","r":"lights","state":{"bri":154,"on":true,"reachable":true,"speed":5},"t":"event","uniqueid":"00:22:a3:00:00:27:8b:81-01"}
{"e":"changed","id":"14","r":"lights","state":{"bri":254,"on":true,"reachable":true,"speed":5},"t":"event","uniqueid":"00:22:a3:00:00:27:8b:81-01"}

Could you setup attribute reporting for state.speed manually in the deCONZ GUI, to check whether the module supports this? Open the Bind Dropbox panel in the GUI, drag the the 0x0202 cluster to Source, drag endpoint 01 of the RaspBee/ConBee to Destination and press Bind. Here's an example for the Level Control cluster:

I went through these steps and when I write the new value (Off -> On, for example), I see the fan start spinning however I do not see any notification via websocket that the value has changed unless I repeat the steps @anacozero went through to manually read the attribute in the deCONZ GUI. Only then do I see the notification fired with the value of the new fan state.

[ebaauw]

Hi, I pulled the code from your branch, rebuilt the plugin, restarted deconz, and added my fan.

Does it show state.speed in the /lights resource?

I went through these steps and when I write the new value (Off -> On, for example), I see the fan start spinning however I do not see any notification via websocket that the value has changed unless I repeat the steps @anacozero went through to manually read the attribute in the deCONZ GUI. Only then do I see the notification fired with the value of the new fan state.

Hm, the the Smartthings Device handler sets up attribute reporting for 0x202/0x0000:

https://github.com/dcoffing/KOF-CeilingFan/blob/65c7ce03177fb955c149d10717399b442b480f9a/devicetypes/dcoffing/kof-zigbee-fan-controller.src/kof-zigbee-fan-controller.groovy#L299-L305

Its data type is enum8 (0x30), maybe the deCONZ GUI doesn't handle that correctly? @manup, could you please check that? @rtclauss, was the Reportable Change field greyed out (as for the On/Off attribute)? What does it show when you read back the reporting config?

[anacozero]

I followed your steps for setting up attributes reporting and can now immediately see notifications on the websocket for state.speed when the fan speed is changed.

The brightness change of the light is also shown in the websocket immediately.

I will have to wait till the next version is released. I recently moved deCONZ and Conbee off of my raspberry pi to a Windows VM. I'll try to spin up an Ubuntu VM of deCONZ this week and compile it and test it on there.

[ebaauw]

I followed your steps for setting up attributes reporting and can now immediately see notifications on the websocket for state.speed when the fan speed is changed.

Cool. I’ll see if I can make the REST API plugin setup the reporting. And then of course, change the fan speed thru the API.

[rtclauss]

Does it show state.speed in the /lights resource? Yep:

{
"etag": "432f3de28965052961a99e3c5494daf4",
"hascolor": false,
"manufacturername": "King Of Fans,  Inc.",
"modelid": "HDC52EastwindFan",
"name": "Light 14",
"state": {
"alert": "none",
"bri": 254,
"on": true,
"reachable": true,
"speed": 2
},
"swversion": "0000000F",
"type": "Fan",
"uniqueid": "00:22:a3:00:00:27:8b:81-01"
}

Its data type is enum8 (0x30), maybe the deCONZ GUI doesn't handle that correctly? @manup, could you please check that? @rtclauss, was the Reportable Change field greyed out (as for the On/Off attribute)? What does it show when you read back the reporting config?

My mistake, I forget to add the reporting change information as you had in your screenshot. Once I added the reporting information and wrote the changes I do see notifications in the websocket api.

[hgelpke]

If I read this thread correctly, there should be proper integration with version 66 release, correct? I just bought this controller in large part because of the quick support shown here in the thread but as of now, I only see the light component in the Home Assistant integration.

[ebaauw]

Still need to add support for changing the fan speed through the API. Not sure if we should keep the numeric value for state.speed (would be needed if you want to include it in a rule condition), or use a string value instead.

I don’t know about HA, but I’m waiting for these issues to be resolved before adding support in homebridge-hue.

[hgelpke]

There seems to be a lot of good info coming from Zigbee2Mqtt on this device right now and they may have solved a lot of the quirks of this fan:

https://github.com/Koenkk/zigbee2mqtt/issues/1357#issuecomment-503719831

[hgelpke]

Has there been any development on this recently?

[DAM21]

If I read this thread correctly, there should be proper integration with version 66 release, correct? I just bought this controller in large part because of the quick support shown here in the thread but as of now, I only see the light component in the Home Assistant integration.

Same here, I'm only seeing the light. I think ZHA has some support.

[hgelpke]

Anybody have luck with the fan component?

[ikrowni]

Anyone still working on getting the fan control going? Just finished installing this and I'm only getting light control as well.

[DAM21]

Same here, I ended up switching to ZHA and both work.

[anacozero]

I ended up switching to zigbee2mqtt. Can access all of the fan functions now

[bwoodworth]

Any update on this?

[gmitch64]

I'm still interested too. I'm probably going to be installing mine in the next couple of weeks - if nothing else, it still works as a fan with a handheld remote.

If there's any info additional info needed to get this implemented, please let me know.

G

[cazador481]

I can see the light, but not the fan.

[rmotapar]

Would really appreciate any info on this. I have two of these that I would like to connect to deconz on hassio.

[raymondoooo]

I'm in the same boat. I would love to have this capability. I'm trying to fully move off Wink and my two fans are the last stragglers. The lights work fine but I've yet to figure out a way to get the fans into the deconz interface. I know I can switch to zigbee2mqtt but I don't really feel like buying new hardware as I don't think my Conbee 2 will work. I'm not close to an SME, but if I make any progress I will post here....

[ebaauw]

Could you try my PR? It should enable setting the fan speed, by doing a PUT to the “light” state with a body of {"speed": 2}.

[gmitch64]

Any update on how this is coming along? I've just installed my fan, and the light is working, but there's no sign of the fan (and hence control) in the JSON that's being returned to Homeseer. I know my limitations at the moment, so building from source is probably beyond what I can do at the moment.

G

[ebaauw]

Can some-one please test if the speed can be set in v2.05.76?

[gmitch64]

OK. Upgraded to 76. Did the firmware upgrade. Rebooted the Pi/Conbee.

I did a reset of the Fan unit (the lights flashed on factory reset). Opened the network. The Light comes back in as before, but there doesn't seem to be anything in Phoscon for the Fan portion.

I've tried the reset on the fan 3 times, and the light always comes back, and is controllable, but I never see the fan unit appear.

G

[ebaauw]

Phoscon won't yet support it, but you should be able to control the speed through the API.

[gmitch64]

I'm actually using HomeSeer, and this is what's it's showing for the devices (lights, and lightgroup - no fan).

**** Object info **** { "name": "Office Fan", "lights": [ "18" ], "action": { "on": false, "bri": 254, "effect": "none", "xy": [ 0.0, 0.0 ] }, "type": "LightGroup", "state": { "all_on": false, "any_on": false }, "devicemembership": [], "etag": "0803034fe31665cf9698d295ca615451", "scenes": [], "id": "16" } End Object info ***

**** Object info **** { "type": "Fan", "name": "Office Fan Lights", "modelid": "HDC52EastwindFan", "swversion": "0x0000000F", "uniqueid": "00:22:a3:00:00:22:c9:44-01", "manufacturername": "King Of Fans, Inc.", "state": { "on": false, "bri": 254, "alert": "none", "reachable": true }, "etag": "cb693161c921b6f4fe79ade6b5936cc6", "hascolor": false } End Object info ***

[ebaauw]

There should be a speed attribute in the state, see listing above. I would be surprised if HomeSeer already support this: the API needs to support new devices before API clients can support them.

[gmitch64]

Been playing with things for a couple of days...

It seems that no matter what speed the fan is set to, doing a GET on /api/XXX/lights/18 always returns a speed of 0.

I've also tried doing ta PUT via postman (/api/XXX/lights/18/state, { "speed":2} in the body, and it doesn't seem to set the fan speed at all, but I do get a 200 back, so it's not objecting to it.

G

[ebaauw]

It seems that no matter what speed the fan is set to, doing a GET on /api/XXX/lights/18 always returns a speed of 0.

Did the API setup the binding and attribute reporting for Fan Mode? See above.

I've also tried doing ta PUT via postman (/api/XXX/lights/18/state, { "speed":2} in the body, and it doesn't seem to set the fan speed at all, but I do get a 200 back, so it's not objecting to it.

Bummer. Can you run deCONZ with --dbg-info=2 --dbg-aps=1 and check in the log if the API is sending command 0x00 to cluster 0x0202? Can you double-check that you can change the speed from the GUI?

[gmitch64]

This is what I get back from a GET on /api/XXX/lights/18

{ "etag": "0c55ef4e4114e314b4a5b4845309687e", "hascolor": false, "lastseen": "2020-05-28T14:37:52.262", "manufacturername": "King Of Fans, Inc.", "modelid": "HDC52EastwindFan", "name": "Office Fan Lights", "state": { "alert": "none", "bri": 254, "on": true, "reachable": true, "speed": 0 }, "swversion": "0x0000000F", "type": "Fan", "uniqueid": "00:22:a3:00:00:22:c9:44-01" }

Not sure what you mean by changing the fan speed from the UI? The only thing I can change in the UI is the lights off/on.

I'll see if I can start deCONZ with the debug info and see what I can find in the logs (after finding them - lol).

G