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.
GitHub Repo: ST-SmartHome/BigAssFan-Driver
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
- 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.
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
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:
- Adding an alternatives: list directly under the config.values[ ] entry, hoping to supply new label strings for keys “5”/“6”/“7”.
- 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.
- 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)?
Update: light is now its own device, direction-change safety pause, plus new LED/Beep/IR controls
1. Each fan’s light now gets its own separate SmartThings device.
Previously the light was just a component on the fan’s own device. It’s now split out into a child device automatically — no action needed, no preference to toggle. This was done so the light shows up as its own entity to Alexa, which discovers by device, not by component, so it couldn’t see a fan’s light before this change. Your existing fan device keeps everything else (speed, mode, direction, whoosh, eco); the new child device just handles on/off + brightness for the light. If you see a new device appear next to your existing fan after updating, that’s expected — it’s the light, not a duplicate fan.
2. Direction changes now stop the fan first, and leave it off afterward.
Reversing direction now: stops the fan, confirms it’s actually stopped, then changes direction — rather than flipping direction while still spinning. This is meant to be safer for the motor, but it does mean the fan will not restart on its own after a direction change — you’ll need to turn it back on manually. Confirmed working end-to-end on real hardware: stop → reverse → restart cleanly in the new direction, no leftover bad state. One thing to be aware of: the app’s own status display can lag behind a direction change for a while — the change has usually already happened even if the app hasn’t caught up yet.
3. LED Indicators / Fan Beep / Legacy IR Remote controls added.
Three fields that were previously only reachable from the official app’s More screen are now exposed as SmartThings toggles:
- LED Indicators — on/off
- Fan Beep — on/off
- Legacy IR Remote — on/off
They live in a new Settings section on the fan’s device page. (same scrollable Controls screen, grouped separately below the main fan controls)
No changes to existing fan speed/mode/whoosh/eco behaviour beyond the direction-change note above.
All three changes apply automatically once the driver update reaches your hub — this can take a little while to propagate, so give it some time if you don’t see it right away.
Driver version: 2026-08-27T00:00:05.908710713
Update: Sleep/Wake Up settings, plus a real bug fix
New in the driver:
Sleep tab settings are now fully exposed as SmartThings controls, under a new “Sleep” section on each fan: Auto fan mode (Off/On/Auto) with its own ideal temperature, a Sleep Timer with duration, “Return to Auto” with its own duration, and the light’s separate Sleep and Wake Up brightness presets (mode + brightness + motion timeout for Wake Up).
Two Sleep Auto screen fields (“Min Speed”/“Max Speed”) aren’t exposed yet — couldn’t pin down their exact mapping confidently, so left out rather than guess.
Also fixed a real bug: setFanSpeed could silently fail to apply depending on how a specific command was assembled internally — fixed, speed changes now apply reliably on the first try.
No action needed if you’re already on the shared channel — this is live.
Current live version: 2026-08-28T00:29:02.078625432