[ST EDGE DRIVER] Big A$$ Fans Haiku H/I Series via local "i6" protocol

Devices & Integrations
1

Controls Big A$$ Fans Haiku H/I Series ceiling fans (the models running firmware 3.0+, “i6” API — not the older SenseME app generation) entirely over the local LAN — no cloud account, no app pairing dance, and nothing to type in. Fan on/off, speed (0-7 native range), mode (Off/On/Auto), direction, whoosh, eco, plus the light’s on/off and brightness.

Channel invite: SmartThings. Add a little smartness to your things.

Tested against two Haiku H/I Series fans, firmware 3.3.7, api_version 8.

Requirements

  • A Haiku H/I Series fan on firmware 3.0+ (the “i6” protocol generation — see “Which fans this supports” below if you’re not sure which you have).
  • The fan already joined to your Wi-Fi (via the Haiku Home app, one-time setup — this driver doesn’t do initial provisioning, only ongoing control).
  • A SmartThings Hub on the same network as the fan.

Setup

Add Device → Scan Nearby. That’s it. The fan gets discovered and fully configured automatically — no IP address, no key, nothing to type. If you get more fans later, they get picked up automatically too on a later scan; there’s no button to press.

(There’s a “Manual IP Override” preference on each device if a specific fan ever isn’t showing up automatically — see “Known limitations” — but it’s not part of the normal flow.)

Big Ass Fans’ local protocol turned out to be a genuinely nice surprise: the fan advertises itself over standard mDNS (_api._tcp.local.), and there’s no authentication or pairing secret of any kind — anyone on the LAN who can reach the fan’s IP on port 31415 can query and control
it. SmartThings Edge Drivers have native platform support for mDNS discovery, so this driver just asks the platform “find me anything advertising _api._tcp,” filters the results down to actual Haiku fans (checking the advertised model name, since _api._tcp alone is a pretty
generic service name other things could theoretically use), and creates a fully-working device with zero further input.

Protocol notes, for anyone curious or extending this

  • Transport: plain TCP, port 31415, SLIP-framed (RFC 1055) protocol buffer messages — this driver hand-rolls both the SLIP framing and a minimal protobuf codec in pure Lua (no external deps), since neither exists in the Edge Driver Lua environment.
  • The protocol’s own “ALL” query category is a bit of a trap — despite the name, it only returns general/identity fields (model, firmware version, MAC), not fan or light state. Those need separate FAN- and LIGHT-category queries, confirmed by direct probing rather than any documentation (there isn’t much).
  • Schema reverse-engineered from jfroy/aiobafi6’s .proto file (credit where due — didn’t reverse-engineer this from raw packet captures myself, that project already did the hard part).

Known limitations

  • No color temperature control. Deliberate, not missing: this household’s fans have a fixed-temperature bulb (confirmed via a live query — warmest and coolest color temp report the same value), and the physical remote doesn’t expose that control either. If your fan’s light
    kit actually supports tunable white, this driver won’t control it — would be a small addition if anyone needs it.
  • Setting fan speed to a nonzero value also turns the fan on, and zero turns it off — a UX choice on my part, not a confirmed device behavior. The protocol keeps speed and on/off as genuinely separate properties.
  • Only tested against two fans, same model/firmware. If you try it on a different Haiku/i6 model (especially one without a light kit) and hit something broken, I’d like to hear about it.
  • mDNS discovery relies on your network actually passing mDNS traffic between the hub and the fan — if they’re on different VLANs without multicast/mDNS reflection enabled, discovery won’t find it and you’d need the manual IP override.
2

Update — connection efficiency fix (2026-08-13)

If you’ve noticed the light on your fan occasionally blipping/flickering, this update should help. The driver was opening two separate TCP connections per poll cycle (one for fan status, one for light status) every 30 seconds. On the fan’s small embedded network stack, that connection churn could destabilize its Wi-Fi connection over time, with a light flicker as a side effect.

This update combines both queries into a single connection per poll — same data, same polling interval, just half the connection overhead. No profile or capability changes, so no re-pairing needed; it’ll pick up automatically for anyone on the channel.

Version: 2026-08-13T13:54:24.857976562

3

The Edge Driver reports a real fan 8-speed range (0-7), but the standard fanSpeed capability’s own presentation only defines labeled alternatives for values 0-4 (Off/Low/Medium/High/Max). I can widen the slider range fine via an Embedded Device Configuration:

  - id: fanSpeed
    version: 1
    config:
      values:
        - key: "fanSpeed.value"
          range: [0, 7]

This works — the app now shows a functional 0-7 slider. But values 5-7 render as bare numbers with no label, since there’s simply nothing in the capability definition for the platform to point at above 4.

I tried three things to fix the display, all of which deployed cleanly (no validation errors, driver packages/installs fine) but produced no visible change to the generated presentation — verified via smartthings presentation before/after each, same JSON both times:

  1. Adding an alternatives: list directly under the config.values[ ] entry, hoping to supply new label strings for keys “5”/“6”/“7”.
  2. Using the config’s patch: field (PatchItem[ ], i.e. op/path/value) with op: add, path: “/slider/alternatives/-” to append new entries directly onto the rendered slider.
  3. The reverse — trying to suppress the built-in 0-4 labels instead (for a consistent all-numeric 0-7 display) via enabledValues: [ ]. Also silently ignored.

Is there any supported way, from either an Embedded Device Configuration or a standalone Device Presentation, to add alternatives/labels for capability attribute values beyond what the capability itself defines — or alternatively to suppress a capability’s built-in alternatives entirely for a plain numeric display? Or is the only real option a custom capability with its own full label set (accepting the loss of Alexa/Google Home/routine compatibility that comes with not being the standard fanSpeed capability)?