Adventures with Fanco ceiling fans & LocalTuya

Share your Projects!
1

My fans are:

  1. Fanco Sanctuary DC - 70’’ no light (433MHz RF remote, not smart or Tuya compatible)
  2. Fanco Infinity-iD DC 48” & 54” with light (an older version on sale, Tuya compatible, Tuya Cloud product name DC吊扇)
  3. Fanco Infinity-iD DC 54” with light (new/current version, available in Tuya compatible or not, Tuya Cloud product name NEW_FP智能风扇灯_COMBO)

There is no obvious way just looking at them, to distinguish the old and new Infinity-iD versions, although the remotes are quite different. Online shops don’t make it clear which you are getting. I believe only the new version is available now.

RF Remote Control

For the non-Tuya Sanctuary DC fan I bought a Broadlink RM4 Pro Remote (universal IR & RF remote) on Amazon. I learned the fan’s remote codes using the Broadlink app and checked that it could control the fan (a not strictly necessary step). Then I used this script in HA for it to learn the remote’s codes:

sequence:
  - action: remote.learn_command
    target:
      entity_id: remote.rm4_remote
    data:
      device: living_room_fan
      command:
        - speed 1
        - speed 2
        - speed 3
        - speed 4
        - speed 5
        - speed 6
        - turn off
        - reverse
      command_type: rf

HA Template Fan

You can define a Template Fan in HA to send these RF codes and that way get the same user interface as the other fans using Tuya or LocalTuya. However that user interface assumes that the current state of the fan (possibly modified using the fan’s supplied remote) is available and that is not the case. The “turn off” and “reverse” commands toggle the fan’s state, so the Template Fan can easily get out-of-sync with the actual fan. You could use the remote again to set the fan state to agree with HA or add extra hacks to HA to change its state. That was unacceptable for me.

HA UI with less state

Instead of using Template Fan I created a UI that just sends remote commands (irrespective of the fan’s state):

  • input_select.living_room_fan_speed with values Off and 1 to 6
  • input_button.living_room_fan_direction

Automations send remote commands when these are modified.

The only state based issue with this is due to the “turn off” command being a toggle. If:

  1. HA fan speed is 1 to 6
  2. The fan’s remote is used to turn the fan off
  3. HA is used to select fan speed “Off” and send the “turn off” command, which will actually turn the fan on

HA can be brought back into sync by setting a fan speed 1 to 6. That is acceptable to me as the least bad solution.

LocalTuya

Google Gemini was pretty helpful with this.

I found that the xZetsubou fork of LocalTuya is more up to date than the original, so I switched to that.

With my fans added to the Tuya Smart app and working there, I queried the device properties in Tuya Cloud (you’ll first need to create a Tuya Cloud project as described in the LocalTuya documentation).

Tuya IoT Platform
IoT Core
Device Control > Query Properties

This shows a list of DP’s: DP (an int reference to a control variable), the control variable’s name, data type and current value.

To get the range of acceptable values I searched in Tuya Cloud APIs for “Specification” and found “Get the specifications and properties of the device”, which provides DP, acceptable values and data type; and I found some differences between the old and new versions of the fans:

  • fan speed is Integer for old fans, but Enum for new fans (LocalTuya seems to take care of this)
  • fan mode is normal or nature (speed varies like a breeze) for old fans, but new fans have a third value sleep (presumably quieter)
  • max brightness and colour temperature are 1000 for old fans, but 100 for new fans.

When configuring the fans in the xZetsubou fork of LocalTuya, I found the Auto Configure option didn’t get everything right and used Manual Configuration. The Manual Configuration UI helpfully mostly chooses the right DP for each control and displays its name and current value.

The fans do not broadcast a zeroconf hostname, so must be assigned static IP addresses to be used in LocalTuya.

To add or modify a LocalTuya device, select the cog icon on LocalTuya.

Old Version Fans

Use Protocol Version: 3.5.

For each fan device, configure entities: Fan, Light and Select.

Fan Entity DP 1 (on/off):

  • these should be automatically set correctly:
    • fan speed control: DP 3
    • fan oscillating control: unset (this is for floor fans)
    • fan direction: DP 8, with string values “forward” and “reverse”
    • min fan speed 1
  • set a Friendly Name
  • set max fan speed = 6

Light Entity DP 15 (on/off):

  • these should be automatically set correctly:
    • brightness: DP 16
    • colour temperature: DP 17
    • brightness lower: 10
    • brightness upper: 1000
    • min colour temperature: 2700 (actual light values are 3000, 4000 and 5000)
    • max colour temperature: 6500

Select Entity DP 2 (mode):

  • Friendly Name: “Mode”
  • Entity Category: None
  • Select options values:
      normal: Normal
      nature: Nature

New Version Fans

Use Protocol Version: 3.5.

I have not managed to get the LocalTuya Light entity to handle the new fan’s colour temperature DP 17 range of min: 0, max: 100. So, for the new fans, we unset this in the Light entity configuration and instead create a Number entity for DP 17. This will have only 3 values corresponding to the 3 colour temperatures available: 0 for 3000°K, 50 for 4000°K and 100 for 5000°K.

For each fan device, configure entities: Fan, Light, Select and Number.

Fan Entity DP 1 (on/off):

  • these should be automatically set correctly:
    • fan speed control: DP 3
    • fan oscillating control: unset (this is for floor fans)
    • fan direction: DP 8, with string values “forward” and “reverse”
    • min fan speed 1
  • set a Friendly Name
  • set max fan speed = 6

Light Entity DP 15 (on/off):

  • these should be automatically set correctly:
    • brightness: DP 16
    • brightness lower: 1
    • brightness upper: 100
    • min colour temperature: 2700 (doesn’t matter, not using)
    • max colour temperature: 6500
  • unset Colour Temperature (do not use DP 17)

Select Entity DP 2 (mode):

  • Friendly Name: “Mode”
  • Entity Category: None
  • Select options values:
      normal: Normal
      nature: Nature
      sleep: Sleep

Number Entity DP 17 (light colour temperature:)

  • Friendly Name: “Colour Temperature”
  • category: None
  • min value: 0
  • max value: 100
  • increment between numbers: 50

In the UI, I use an input_select with values:

  • Warm (3000°K)
  • Neutral (4000°K)
  • Cool (5000°K)

and an automation to set the Number Entity when this changes.