Fan Module (Hampton Bay) #932

mjruotolo · 2018-11-08T04:33:58Z

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 · 2018-11-13T02:14:36Z

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

G

jjlawren · 2019-02-03T14:39:33Z

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

manup · 2019-02-03T15:59:44Z

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 · 2019-02-03T16:10:07Z

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 · 2019-02-03T16:16:01Z

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 · 2019-04-15T03:35:46Z

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

ebaauw · 2019-04-15T21:05:00Z

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 · 2019-04-15T23:53:55Z

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 · 2019-04-16T03:09:24Z

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 · 2019-04-16T05:47:21Z

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 · 2019-04-19T05:22:57Z

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 · 2019-04-19T06:25:18Z

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

ebaauw · 2019-04-19T09:58:07Z

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 · 2019-04-23T02:46:47Z

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 · 2019-05-26T03:50:39Z

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

ebaauw · 2019-05-26T05:48:38Z

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 · 2019-05-26T06:41:24Z

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 · 2019-05-26T06:59:39Z

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

ebaauw · 2019-05-26T07:18:09Z

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 · 2019-05-26T07:45:30Z

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 · 2019-05-26T08:15:20Z

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 · 2019-05-26T16:26:50Z

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 · 2019-05-26T18:29:21Z

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 · 2019-05-26T19:10:24Z

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 · 2019-05-26T20:24:43Z

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 · 2019-05-27T21:19:19Z

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.

Include `state.speed` in light state map, see #932.

gmitch64 · 2020-05-28T17:04:30Z

I've started deCONZ with the 2 debugging options. I'm probably looking in the wrong place, but all I see are entries in syslog for..

phoscon deCONZ[883]: 12:59:36:961 Poll light node Office Fan Lights

That's the only thing I can see that mentions the fan. I've tired a couple of times setting from PostMan, and nothing else is showing up.

Am I looking in the right place, or is there some other log file that I need to check somewhere?

G

ebaauw · 2020-05-28T18:25:51Z

Am I looking in the right place, or is there some other log file that I need to check somewhere?

No, there's only one log. Could you try --dbg-info=2 --dbg-aps=2 --dbg-error=1? I'm hoping for a "write attribute" message in the log like:

write attribute of 0x0022A3000022C944 ep: 0x01 cluster: 0x0202: 0x0000

gmitch64 · 2020-05-28T19:02:31Z

OK... Just to make sure it's running correctly..

/usr/bin/deCONZ --http-port=80 --dbg-info=2 --dbg-aps=2 --dbg-error=1

Trying to set the speed to 2....
Here's Postman not complaining about it...

[
{
"success": {
"/lights/18/state/speed": 0
}
}
]

Here's what I'm getting in syslog... the 2nd one has a bit more context around it...

ay 28 14:55:46 phoscon deCONZ[881]: 14:55:45:852 Poll APS request to 0x000D6FFFFE2DDB6B cluster: 0x0006 dropped, values are fresh enough
May 28 14:55:46 phoscon deCONZ[881]: 14:55:45:878 ZclAttribute::setValue() unsupported datatype 0x30
May 28 14:55:46 phoscon deCONZ[881]: 14:55:45:878 write attribute of 0x0022A3000022C944 ep: 0x01 cluster: 0x0202: 0x0000
May 28 14:55:46 phoscon deCONZ[881]: 14:55:45:878 add task 2326 type 14 to 0x0022A3000022C944 cluster 0xFFFF req.id 160
May 28 14:55:46 phoscon deCONZ[881]: 14:55:45:878 ~Resource() /groups 0x7e86a8c8

May 28 14:57:09 phoscon deCONZ[881]: 14:57:04:912 Poll light node TRADFRI Outlet Dining Room
May 28 14:57:09 phoscon deCONZ[881]: 14:57:04:965 Poll APS request to 0x000D6FFFFE2DDB6B cluster: 0x0006 dropped, values are fresh enough
May 28 14:57:09 phoscon deCONZ[881]: 14:57:04:991 APS-DATA.request id: 64, addrmode: 0x03, addr: 0x00212effff017190, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 2 len: 2 tx.options 0x00
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:035 APS-DATA.confirm id: 64, status: 0x00 SUCCESS
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:035 APS-DATA.confirm request id: 64 -> confirmed, timeout 25359560
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:061 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 130, rssi: 0
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:061 #011asdu: ca000a0401907101ffff2e2100815d4a02008d1500c941120000f7
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:062 APS-DATA.indication request id: 64 -> finished
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:062 APS-DATA.request id: 64 erase from queue
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:100 ZclAttribute::setValue() unsupported datatype 0x30
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:100 write attribute of 0x0022A3000022C944 ep: 0x01 cluster: 0x0202: 0x0000
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:100 add task 2655 type 14 to 0x0022A3000022C944 cluster 0xFFFF req.id 67
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:100 ~Resource() /groups 0x7e86a8c8
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:100 APS-DATA.request id: 67, addrmode: 0x03, addr: 0x0022a3000022c944, profile: 0xFFFF, cluster: 0xFFFF, ep: 0x01 -> 0x01 queue: 2 len: 0 tx.options 0x04
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:177 #0110x0022A3000022C944 force poll (2)
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:177 Erase task req-id: 67, type: 14 zcl seqno: 0 send time 0, profileId: 0xFFFF, clusterId: 0xFFFF
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:177 APS-DATA.confirm id: 67, status: 0x00 SUCCESS
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:177 APS-DATA.confirm request id: 67 -> erase from queue
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:232 aps request id: 67 finished, erase from queue
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:715 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:862 poll node 00:15:8d:00:02:ed:b3:76-01
May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:862 Poll light node Office Curtain South (small)

ebaauw · 2020-05-28T19:47:12Z

Trying to set the speed to 2....
Here's Postman not complaining about it...

[
{
"success": {
"/lights/18/state/speed": 0
}
}
]

That's not good: it reports having set the speed to 0? Did you specify a body of {"speed": 2}?

May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:100 ZclAttribute::setValue() unsupported datatype 0x30

Datatype 0x30 is deCONZ::Zcl8BitEnum. Is deCONZ::ZclAttribute broken for that one as well?!

Could you please humour me, turn the fan on using the remote (or the GUI) and see of the API call turns if off?

May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:100 write attribute of 0x0022A3000022C944 ep: 0x01 cluster: 0x0202: 0x0000

This is what I wanted to see.

May 28 14:57:09 phoscon deCONZ[881]: 14:57:05:100 add task 2655 type 14 to 0x0022A3000022C944 cluster 0xFFFF req.id 67

Not good. Looks like I'm sending a half-initialised task. I'll remove that.

Would you be able to compile the REST API plugin for testing?

gmitch64 · 2020-05-28T20:04:04Z

Could you please humour me, turn the fan on using the remote (or the GUI) and see of the API call turns if off?

No, it does not. I've tried it from all different speeds, changing to different speeds, including off, and nothing happens.

Would you be able to compile the REST API plugin for testing?

That's probably beyond what I'd be able to do - I've not tried to build deCONZ from scratch before, and there's probably too much I could mess up in the interim with setting up a toolchain - unless it's a straight pull from git and compile on the Pi?

Now, if you want to send me an updated binary, I'd be happy to drop that in place on my Pi for testing if you'd like.

G

ebaauw · 2020-05-28T20:06:00Z

unless it's a straight pull from git and compile on the Pi?

Pretty much so, see README.

Now, if you want to send me an updated binary, I'd be happy to drop that in place on my Pi for testing if you'd like.

What Pi are you on? What OS?

gmitch64 · 2020-05-28T20:11:40Z

pi@phoscon:~/deCONZ $ grep Revision /proc/cpuinfo
Revision : a21041

So a Pi 2 Model B

Linux phoscon 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

Originally installed from the SD card image, and have been doing apt-get updates ever since.

G

ebaauw · 2020-05-28T20:13:18Z

Is that Raspbian stretch?

gmitch64 · 2020-05-28T20:15:22Z

Is that Raspbian stretch?

Yes it is.

pi@phoscon:~/deCONZ $ sudo apt-get update
Get:1 http://archive.raspberrypi.org/debian stretch InRelease [25.4 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease [15.0 kB]
Hit:3 http://phoscon.de/apt/deconz stretch-beta InRelease
Get:4 http://archive.raspberrypi.org/debian stretch/main armhf Packages [201 kB]

ebaauw · 2020-05-28T20:22:35Z

libde_rest_plugin.so.gz

Unzip with gunzip, stop deCONZ, copy to /usr/share/deCONZ/plugins, and start deCONZ.

If you want to save the current version, move it out of the plugins directory - don't rename it. deCONZ loads anything from there, irrespective of the file name.

gmitch64 · 2020-05-28T20:43:54Z

ok.. So, we're running again...

824 ? Ssl 0:04 /usr/bin/deCONZ --http-port=80 --dbg-info=2 --dbg-aps=2 --dbg-error=1

And you have a winner... :)

I've managed to change the fan speed between all 4 values (0 - 4), as well as to 6, which is the comfort-breeze according to the manual. I've also changed it to 5, but I have NO idea what that does - the fan doesn't seem to make any noticable changes.

Thank you very much for working on it.

I am presuming that we won't see a separate device entry for the fan (it'll be a light) until API v2?

G

ebaauw · 2020-05-28T21:28:31Z

I am presuming that we won't see a separate device entry for the fan

I've been struggling how best to deal with the fan function. It's on the same Zigbee endpoint as the light function, which supports groups. I don't know if the fan state is also saved and restored to Zigbee scenes, but might very well be. That means we want to expose the fan function as a /lights resource, for (future) group (and scene) support. Since both the light function ( On/Off and Level Control clusters) as well as the fan function (Fan Control cluster) are on the same endpoint, they share the Groups cluster. Meaning both functions share group membership. Exposing both functions as separate /lights resources would be very complex (to make sure both are listed under the same /groups resources) and confusing to the user (I add one "light" to the group, but another is added as well?). I see no other option than to combine both functions in a single /lights resource.

I've also changed it to 5, but I have NO idea what that does - the fan doesn't seem to make any noticable changes.

Speed 5 is "Auto" according to the ZCL spec (see also the dropdown values in the GUI). I don't think the Hampton Bay supports it.

gmitch64 · 2020-05-28T21:37:36Z

Speed 5 is "Auto" according to the ZCL spec (see also the dropdown values in the GUI). I don't think the Hampton Bay supports it.

Should the API return an invalid value when it's set to 5 then?

I've been struggling how best to deal with the fan function.

I noticed that on another thread, and commented there..
As I said there, the fan is the main thing - there's always going to be a fan. The lights are the optional device here, depending on whether the user fits, or doesn't fit, the light kit. I suspect that the remote controller won't know, or care, and will presume that the lights always exist.

G

ebaauw · 2020-05-28T21:49:08Z

Should the API return an invalid value when it's set to 5 then?

Could be, but would need another whitelist (assuming we will eventually support other fans that do support this). More interesting: do we want to continue to use these number values, or should the API expose string values?

I suspect that the remote controller won't know, or care, and will presume that the lights always exist.

The wired dimmer to control the lights is integral part of the module. Whether you wired one or more lights to it is a different question. In theory, the module could measure current and check whether a light is connected, but I doubt it does. It's not exposed over Zigbee, as far as I can tell.

As I said there, the fan is the main thing - there's always going to be a fan. The lights are the optional device here, depending on whether the user fits, or doesn't fit, the light kit.

So it's gonna be interesting how to expose the module to HomeKit in Homebridge Hue. The logical mapping would be a single accessory with a Lightbulb and a Fan v2 service, which should show as two tiles in Home. Since it's the same /lights resource, I wouldn't know how to indicate that the Lightbulb should be suppressed in case no light has been connected.

gmitch64 · 2020-05-29T12:20:39Z

More interesting: do we want to continue to use these number values, or should the API expose string values?

I'm a computer guy, so I like numbers :) But it should probably be consistent with what the majority of other devices in the API return/use for settings.

The wired dimmer to control the lights is integral part of the module

I agree, and as you say, I doubt the current draw etc is even measured. What I was just pointing out, is that this is a fan unit, with optional lights, rather than a lighting unit, with a fan. If you're going to start a new "class" of device, then I'd suggest making it a fan. If you're going to overload the lights, then what you're saying makes sense - and I suspect you're going to have to overload the lights class, at least in v1 of the API.

I wouldn't know how to indicate that the Lightbulb should be suppressed in case no light has been connected.

In HomeSeer speak, what would make logical sense to me (and I don't have to maintain the code), would be to have a root device which would be the whole unit, with 2 child devices, one for the fan, and one for the lights. I think (but I'm not 100% sure), that you could put some configuration in the root device to enable/disable the light unit.

I'm not sure how Wim is going to expose it in Homeseer - we'll see when he does a beta release :)

G

ebaauw · 2020-05-31T10:34:03Z

I've managed to change the fan speed between all 4 values (0 - 4), as well as to 6, which is the comfort-breeze according to the manual.

@gmitch64 for Homebridge Hue I need to map the speed to HomeKit's Rotation Speed, which is in %. So something like 0 => 0%, 1 => 25%, 2 => 50%, 3 => 75%, 4 => 100%. Not sure what to do with speed 6, can you please advice me? Is speed 6 equal to one of the other speeds, or is it a separate speed. In that case: where would I position that?

- Add support for Hampton Bay fan modules, see dresden-elektronik/deconz-rest-plugin#932; - Use `state.lift` and `state.tilt`for window covering devices; - Don't sound siren on warning devices on _Identify_.

gmitch64 · 2020-05-31T12:58:34Z

That's going to be a tricky one, since it's a variable speed. According to the install guide, "comfort mode" (speed 6)

Randomly alternates fan speeds to create an organic breeze effect.

I wouldn't quite have worded it that way, but it does somewhat randomly alternate the fan speeds. I haven't used that long enough to pay attention to whether it's a straight up and down, or a random speed change.

G

ebaauw · 2020-05-31T13:24:59Z

Thanks, I'll ignore it for now, until finding a proper way to support it.

stale · 2020-06-21T13:51:10Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

gmitch64 · 2020-06-21T16:20:51Z

I'm good with the way it's been added at the moment - seems to work well. I'm not the original issue opener, but I am good with this being closed.

BBru62 · 2020-06-23T03:17:23Z

How would I go about adding this fan to home assistant?

stale · 2020-07-14T05:34:39Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

avboy72 · 2021-01-16T12:33:14Z

Reading through the comments, it appears that this device at least mostly works. Is there something special I need to do to use it?

manup added the Device Request label Nov 8, 2018

ebaauw mentioned this issue Apr 19, 2019

Various enhancements #1444

Merged

ebaauw mentioned this issue May 26, 2019

Support iCasa in-wall switch, Hampton Bay fan controller #1542

Merged

manup pushed a commit that referenced this issue Jun 10, 2019

Update rest_lights.cpp

eb1faff

Include `state.speed` in light state map, see #932.

ebaauw mentioned this issue May 28, 2020

Hampton Bay fan module #2842

Merged

stale bot added the stale label Jun 21, 2020

stale bot removed the stale label Jun 21, 2020

stale bot added the stale label Jul 14, 2020

stale bot closed this as completed Jul 25, 2020

ebaauw mentioned this issue Jun 30, 2022

IKEA Starkvind Air Purifier #6124

Merged

Fan Module (Hampton Bay) #932

Fan Module (Hampton Bay) #932

Comments

mjruotolo commented Nov 8, 2018

gmitch64 commented Nov 13, 2018

jjlawren commented Feb 3, 2019

manup commented Feb 3, 2019

jjlawren commented Feb 3, 2019

ebaauw commented Feb 3, 2019

anacozero commented Apr 15, 2019

ebaauw commented Apr 15, 2019

anacozero commented Apr 15, 2019

anacozero commented Apr 16, 2019 • edited

ebaauw commented Apr 16, 2019

anacozero commented Apr 19, 2019

ebaauw commented Apr 19, 2019

ebaauw commented Apr 19, 2019

anacozero commented Apr 23, 2019

rtclauss commented May 26, 2019

ebaauw commented May 26, 2019

anacozero commented May 26, 2019

ebaauw commented May 26, 2019

ebaauw commented May 26, 2019

anacozero commented May 26, 2019 • edited

ebaauw commented May 26, 2019 • edited

rtclauss commented May 26, 2019

ebaauw commented May 26, 2019

anacozero commented May 26, 2019

ebaauw commented May 26, 2019

rtclauss commented May 27, 2019

gmitch64 commented May 28, 2020

ebaauw commented May 28, 2020

gmitch64 commented May 28, 2020

ebaauw commented May 28, 2020 • edited

gmitch64 commented May 28, 2020

ebaauw commented May 28, 2020

gmitch64 commented May 28, 2020

ebaauw commented May 28, 2020

gmitch64 commented May 28, 2020

ebaauw commented May 28, 2020 • edited

gmitch64 commented May 28, 2020

ebaauw commented May 28, 2020 • edited

gmitch64 commented May 28, 2020

ebaauw commented May 28, 2020 • edited

gmitch64 commented May 29, 2020

ebaauw commented May 31, 2020 • edited

gmitch64 commented May 31, 2020

ebaauw commented May 31, 2020

stale bot commented Jun 21, 2020

gmitch64 commented Jun 21, 2020

BBru62 commented Jun 23, 2020

stale bot commented Jul 14, 2020

avboy72 commented Jan 16, 2021

anacozero commented Apr 16, 2019 •

edited

anacozero commented May 26, 2019 •

edited

ebaauw commented May 26, 2019 •

edited

ebaauw commented May 28, 2020 •

edited

ebaauw commented May 28, 2020 •

edited

ebaauw commented May 28, 2020 •

edited

ebaauw commented May 28, 2020 •

edited

ebaauw commented May 31, 2020 •

edited