Fan Module (Hampton Bay)
Closed this issue · 77 comments
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
I'd like to second this too please. Fan control is the one main area that I've not touched automation wise.
G
I have a couple of these that I’d love to integrate.
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
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.
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).
Any other info needed? Been sitting on these units for a while after switching off smartthings. Would love to help in anyway.
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.
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
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>
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?
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:
That’s how it’s supposed to work, according to the ZCL spec.
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.
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 ***************************
I have two of these installed and ready at home. I can provide testing and debugging to get fan control working, too.
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.
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"
}
Damn, no state.speed. On the good side: the REST API plugin did accept the device type.
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)?
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.
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.
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.
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:
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?
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.
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.
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.
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.
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.
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:
Has there been any development on this recently?
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.
Anybody have luck with the fan component?
Anyone still working on getting the fan control going? Just finished installing this and I'm only getting light control as well.
Same here, I ended up switching to ZHA and both work.
I ended up switching to zigbee2mqtt. Can access all of the fan functions now
Any update on this?
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
I can see the light, but not the fan.
Would really appreciate any info on this. I have two of these that I would like to connect to deconz on hassio.
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....
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}.
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
Can some-one please test if the speed can be set in v2.05.76?
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
Phoscon won't yet support it, but you should be able to control the speed through the API.
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 ***************************
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.
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
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?
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
Just noticed there is an update to 77. Didn't look like there were any changes that would affect this. I've upgraded to 77, and it's still showing the same results. I can set the speed from 0 to 6, anything else gives an invalid value error.
Interesting, I'm not seeing any option in the Fan Control cluster to set the speed - only read.
I'll take that back... I can change from the cluster
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
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
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)
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?
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
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?
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
Is that Raspbian stretch?
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]
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.
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
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.
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
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.
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
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?
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
Thanks, I'll ignore it for now, until finding a proper way to support it.
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.
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.
How would I go about adding this fan to home assistant?
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.
Reading through the comments, it appears that this device at least mostly works. Is there something special I need to do to use it?