as it had hit master. I fired up a docker with recent snapshot, and the main page shows “openHAB 2.5.0 Build #1698”. I do see the new zigbee fan control channel which shows as a switch and I can successfully use it to turn the fan on and off via openhab. However the commit shows that it can be controlled by a DecimalType as well as a OnOffType. I have tried assigning the fancontrol channel to a Number as well as a switch
Switch Fan1 “Fan Switch” {channel=“zigbee:device:2bdc6a21:0022a3000020cc15:0022A3000020CC15_1_fancontrol”}
Number Fan1_Speed_n “Fan Speed N” {channel=“zigbee:device:2bdc6a21:0022a3000020cc15:0022A3000020CC15_1_fancontrol”}
and then to a selection in the sitemap
Selection item=Fan1_Speed_n label=“Fan Speed”
This does result in the selection updating to the correct value (On, Low, Off, etc) when the fan is changed via the remote, but the fan speed doesn’t change when the selection is updated in openhab. Am I supposed to cast it to a number like this to get the additional speed settings, or do I need to set it up a different way ?
I have tried to get a debug log, but haven’t succeeded yet, for some reason when I use the karaf commands in the docker console, no additional logging is created. I’ll continue to look at this to see what I’m doing wrong to get the debugging.
Fan speed controllers depend on a number of factors. I stumbled upon this trying to set-up this: https://www.itead.cc/sonoff-ifan03-wifi-ceiling-fan-light-controller.html
The speed of a fan is basicaly controlled through phase shifting. This is normally achieved by passing the current feeding the motor coils though a series of capacitors of different values to achieve different speeds.
In discrete speed controllers (OFF, LOW, MEDIUM, HIGH) there will be 2 or 3 capacitors (Or one combined component)
The speed the then controlled by switching between these capacitors (relays normally)
Do you hear relays switching inside your controller?
Are they solid state relays or mechanical?
Are you in the US or Europe or elsewhere and what rating are the capacitors inside the controller.
If the controller is for 220V/240V, the speed control will not work on 110V and you will have to change the capacitors.
Is your fan manual switch/speed control set to MAX?
Please can you open an issue on github for this and I’ll take a look shortly. If you can get a log it would be very useful as I personally can’t test this as I’ve no such devices.
I’m assuming the instructions for logging here still good ?
For some reason I just can’t get it to work (and I’ve tried DEBUG in caps since karaf seemed to want it that way). I’ll have another look tomorrow but before I open this issue I’ll try a few more tests just to see if I can rule out it being my fault.
I forgot before, but … thanks for adding this feature. I was expecting the testing was going to be on me, it’s why I jumped on it. It’s what I can do to help with it right now.
I’ve set up a clean docker with just zigbee and seeing odd, and different results. This time I got :
0022A3000020CC15: Error opening device fan controls
which seems to be coming from ZigBeeConverterFanControl.java
public boolean initializeDevice() {
ZclDoorLockCluster serverCluster = (ZclDoorLockCluster) endpoint.getInputCluster(ZclDoorLockCluster.CLUSTER_ID);
if (serverCluster == null) {
logger.error("{}: Error opening device fan controls", endpoint.getIeeeAddress());
return false;
}
stupid question, should line around serverCluster in initializeDevice be of type ZclFanControlCluster instead of ZclDoorLockCluster ? I’m thinking it’s failing as it’s looking for the doorlockcluster.cluster_id instead of the fan one.
I’ve fixed these issues, although I’m not super sure this will really solve anything. This method is the initializeDevice method, which is really only responsible for configuring the device to send periodic reports. It shouldn’t impact the actual operation of the binding.
Thankfully, I’ve managed to get to the point where I can build (decided to ignore eclipse and all the issues I had with it and use intelliJ, which just automagically built it correctly - don’t care which tool I use as long as it works). You were right, that line didn’t clear the issue, and I think it’s related to the ITEM_TYPE returned in getChannel. Changing the ITEM_TYPE_SWITCH to ITEM_TYPE_NUMBER and deleting/rediscovering the thing now lets you set the numeric speed value, but you can no longer use a switch to turn it on and off and use the previously set speed - at least that’s how the hardware remote works. Now I’m OK with that, but not sure if it’s what you want long term. I have seen some weird interaction with the secondary dimmer channel that represents the light, but I’ll chase that down over the coming week.
I can do some more testing with this small tweak and submit a pull request if you’re good with these two changes ? (and once I work how to do that … it’ll be my first)
wow, that was quick, thanks. I think I did figure the pull thing out just as I saw your update, so hopefully I can help out in other areas as I find them.
