Version: 2.5.0.136
There is an available fan setting in HBFC: "off" (and two others) that are not exposed in the GUI. Alexa can send the "off" command to turn the fan off, as can the Maker API, but the device view from the GUI cannot use those speed settings. Providing a screen shot of the GUI would not be useful, since the enumerations for the speed are in a limited box not all of the available list are visible... But take my word, the three available enumerations are not there :-).
Here I set a fan to low and then off:
Notice in the JSON response that it lists 'off', 'on', and 'medium-high' as available enums:
{"name":"speed","currentValue":"low","dataType":"ENUM","values":["low","medium-low","medium","medium-high","high","on","off","auto"]}
However the 'supportedFanSpeeds' does not list 'off', 'on', 'medium-high':
{"name":"supportedFanSpeeds","currentValue":"["high","medium","medium-low","low","auto"]","dataType":"JSON_OBJECT"}
I suspect that the driver code needs have an enumeration modified to include those extra two or three terms. ('medium-high' might need to be removed or back-end code updated, as it seems to be the same as 'high' from what I can tell of the speed, and the JSON response).
When issuing Maker API commands in the following order:
setSpeed/medium-high (which winds up as 'high')
setSpeed/off
setSpeed/on
The fan does go off and then return to the previously set speed (high) which is good.
The initial JSON response (which returns quickly) from each of those Maker API commands sometimes shows the {"name":"speed","currentValue":"xxxx" ...} as the previous value, and not the one expected from issuing the command. That can be seen in the above image, as the command to set the speed to 'low' returned a currentValue of 'off', and the command to set the speed to 'off' returned a currentValue of 'low'. Not shown, but subsequent check for the data does show the value being returned correctly, so it appears that the JSON is (sometimes/often?) returned before all the variables are correctly updated.
This lag in the correct data maybe (an untested assumption on my part) the reason behind Alexa indicating that the device is unresponsive, even though the commands issued via Alexa are carried out by the fan. There could be other reasons as well.... I have not tried to capture the packets for that exchange.
Thanks for your consideration,
Paul