Bond Bridge support for Fanimation TR305S

Hi,

I have a Fanimation Aireflex. The remote that is used seems to be a fairly new remote, as it supports changing the color temperature of the light in the fan. When adding the remote to the Bond Bridge, the list of known remotes does not seem to contain the particular remote for this fan. More specifically, there is no way in the UI of the iOS bond app to add the color temperature commands.

I have attempted to use the local API reference (http://docs-local.appbond.com) to create these commands, but there does not appear to be a way to add the SetColorTemp to the list of actions, as this action is not added to the actions list initially when creating a new remote on my bond bridge.

In short, can you please add this remote to the database? Here are the details:

Fan: Fanimation Aireflex - https://fanimation.com/products/fans/damp-rated/aireflex
Remote: Fanimation TR305S

While you are waiting for Bond staff to see this message (you can also contact them via in-app chat or emailing customerservice@olibra.io), you can repurpose a button from a manually recorded fan device to be the color /light temperature changing command, and then rename it with the API to allow the name of the command which shows in the Bond app to make more sense.

It also doesn’t have to be from the LIGHT section of a manually recorded ceiling fan - could leverage an unused button from the FAN section since there are more in that group. For instance, if you didn’t need the Bond to be able to control summer / winter modes, or breeze (though yes, I think I see the original remote had those as well), you could record the color / light temperature toggle button as one of those.

It will help the Bond staff either on here, or when you contact them via app or email, to provide the FCC ID as indicated somewhere on the original remote.

Indeed we do not support ColorTemp feature on Bridge devices, only on Smart by Bond fans.

The problem is, (most of) these ceiling fan RF protocols with the “Color Temp” button transmit just a single “change color temp” signal, with the true state of the CCT stuck inside the ceiling fan receiver. There’s no way for us to deliver a good user experience there… you could get a dumb button on the app that’s the same as the remote, but there would be no slider to control which CCT value you get, and no way to control from Alexa/GH, and other integrations could just have the same “change” action, no ability to get feedback or set specific value.

I know it doens’t help you with that fan, but we are working with most of the major ceiling fan brands in USA and some abroad to solve this problem in their forthcoming products. Color temperature adjustability is very highly requested, and we are “doing it right” on the new CCT-enabled Smart by Bond products. None are currently on the market… needs a few months more.

1 Like

I think there is potentially value in exposing a single color temp button / action at the Bridge level, as many ceiling fans / other RF devices using built in ColorTemp abilities just toggle between 2 or 3 color modes.
I know you said ColorTemp sliders would be hard, but that’s more likely for bulbs that have a full dynamic spectrum available.

You could keep it as “dumb” as a single button / action that is the same thing sent every time, or you could go as “smart” as asking the user how many ColorTemp steps there are for the device being added, and track it like a fan speed integer, if Trust State was enabled (though not sure what the names of any such would be - “ColorTemp 1”, “ColorTemp 2”, and so on?)

One additional piece of the puzzle here: We’ve gotten so much negative feedback about the light state support on ceiling fans, that we’re planning on removing it by default in the V3 firmware. You’ll still be able to enable “trust state” to get the behavior we have today, but if trust_state is disabled, there will be no “TurnLightOn|Off” and no “light” state variables. Also no availability of the light from Alexa|GH if trust_state is disabled. — This is a pre-requisite for some new partners who get very upset if a consumer asks to turn the light on and then it turns off!

I suppose we could expose just a CycleColorTempPreset button. It would not bring any other actions or state variables along for the ride. So, no feedback, no tracking. Just a button, available in the apps, and possibly on integrations like LCD wall controls where they can put a “CCT” button. Voice integration is out of luck, because they require actions of the form “Set LIGHT to VALUE Kelvin”.

[And, for completeness, some kind of trust_state for CCT would be theoretically possible, but is significantly more complex as there’s not just on/off states… we’d need to know a value in Kelvin for each preset. Given how poorly the trust_state thing works in practice, the higher complexity CCT version would be just not workable.]

Ahh, thanks for the expanded details and background.

I can understand, and try to explicitly remember, a lot of things depend on voice integration capabilities.
Since I only rarely use voice assistant integrations, and usually through a custom method vs first party when I do, I always want “more” than the voices can handle. :laughing:

As in, I’d love the ability to create Actions and make corresponding custom buttons; since I can’t, I really like the idea of an official Bond CCT “dumb” Action + button for some additional integration options for me for some of my devices.

You gave me an idea… what if we had a little badge on the command icons which are exported to voice assistants. Or the reverse, some badge to say that they are not exported. So we could set the expectation. Hmm.

1 Like

I like that idea, or an evolution of it as you think it over.