How can I test 'brightness' if I don't have a fan with lights?

Integrations
1

Is it possible in the app to create a fake fan which supports dimmer - so I can test my integration?

2

I have fans with the “A1a” and “RCF98v2” templates both of which include dimmers. Maybe you could create a device via API with one of those templates to test against.

3

Here’s my recent response to a similar request:

Here’re four templates for the four dimming “schemes”:

  • A1: single light, dimmer cycles between up and down, the action is named StartDimmer (a continuous transmission until you send the Stop action, or timeout at 30 seconds)
  • A1a: double-light version of A1, it has individual dimmers so we’ve gone with StartUpLightDimmer and StartDownLightDimmer (continuous like A1)
  • RCF98v2: has directional dimmers. Similar to A1-style dimmer, but increases to max brightness with one signal and decreases to min brightness with another: StartIncreasingBrightness and StartDecreasingBrightness (continuous like A1)
  • RCF118: the only one of these with the brightness state. You can directly SetBrightness with an argument or Increase/DecreaseBrightness with an argument. This particular remote script has a minimum brightness of 20, and a max of 100.

The first and the last styles are by far the most common.

1 Like
4

Works like a charm, thank you!

5

Question about setting brightness. It seems like the increment/decrement is 10% and minimum brightness is 20%?

Is it the same for all lights? Or it’s device specific? If so - how do I get it via API?

6

Another question - RCF98v2 has StartDecreasingBrightness and StartIncreasingBrightness - but doesn’t report “brightness” in the status.

Is it normal? Or a bug?

7

Normal. There’s no brightness encoded in the signal, so including a brightness state would involve some serious guesswork.

Eventually, if we can reliably time sequenced requests, we could expose the Brightness state and actions, and use the fact that X milliseconds of dimming maps to Y% brightness increase. Until then, we do not expose it.

1 Like
8

Question about setting brightness. It seems like the increment/decrement is 10% and minimum brightness is 20%?

Is it the same for all lights? Or it’s device specific? If so - how do I get it via API?

9

It’s device-specific. We’ve attempted to approximate the user’s experience with the remote. You could get this from the argument of the command, but it’s just presentational. You can also directly set the brightness (with SetBrightness), or increase the brightness by an arbitrary number.

10

No, SetBrightness doesn’t seem to work if values are not increments of 10%
Increase/Decrease works if the value is 10%
Not sure what you mean by “You could get this from the argument of the command”

11

You’re using RCF118 right?

Any argument to SetBrightness or Increase/DecreaseBrightness in the range [20, 100] should work (and did work when I was putting this one together ~6 months ago). And any input outside that range should be limited to the min or max. The actual remote sends signals for brightnesses in intervals of 2, but we found that the receiver accepts odd-numbered brightnesses as well.

What _error_msgs are you seeing?

The mobile apps panels are built from Commands, a device created by RCF118 for instance creates, among others, an IncreaseBrightness Command with argument 10, and a DecreaseBrightness Command with argument 10. You shouldn’t rely on this though, it’s just a convenience so the user doesn’t have to press the button 40 times to go from min to max brightness. We will likely replace it with a slider eventually.

12

Hi @jacob unfortunately SetBrightness doesn’t seem to work at all. It doesn’t return any errors - just brightness doesn’t change. And yes, I do use RCF118.

The code I’m using for SetBrightness is the same as any other action with an argument, so it can’t be the code:

public void IncreaseBrightness(int change)
{
    ExecuteAction("IncreaseBrightness", change);
}

public void DecreaseBrightness(int change)
{
    ExecuteAction("DecreaseBrightness", change);
}

public void SetBrightness(int brightness)
{
    ExecuteAction("SetBrightness", brightness);
}

public void ExecuteAction(string action, int argument)
{
    bridge.ExecuteAction<State>(id, action, new ActionDataInt (argument));
}

class ActionDataInt : DeviceBondBridge.Data
{
    public ActionDataInt(int arg)
    {
        argument = arg;
    }

    public int argument { set; get; }
}

class Bridge:

public T ExecuteAction<T>(string devid, string action, Data data = null)
    where T : class, new()
{
    string command = $"/v2/devices/{devid}/actions/{action}";

    // Note: since it's using Method.PUT - there's no return value
    T t = ExecuteAction<T>(command, data);

    // so need to request state
    return GetDeviceState<T>(devid);
}
13

Just two cents worth of opinion on integration philosophy: if a light device doesn’t support the SetBrightness() command (and, by extension, doesn’t have a “brightness” property), I am not enabling dimming commands at all, just on and off, for that light. My thought process is that interactive brightness are not all that valuable to my home controller if the controller cannot rely on state, since the controller can’t “look” at the light and make a decision. IMO, 95% of the reason to integrate a device with my home controller is for automation, especially if that device has plenty of user interactive options available otherwise (Alexa, Bond Home App, remote that came with it, etc.). So a light that requires the user to be present to determine the brightness and indicate start and stop of dimming commands will only be turned on and off by the controller - never dimmed, as part of scenes or for motion, schedules, etc. My fan light is configured to turn on to it’s last brightness setting, so I can configure the “on” brightness with the Bond Home App (or just the original remote), and then rely on the controller to turn it on and off as desired in my automation routines. Where the “brightness” state and the SetBrightness() command are available, they and the DecreaseBrightness() and IncreaseBrightness() commands are integrated into the device model.

14

@jacob Also, FYI, StartIncreasingBrightness and StartDecreasingBrightness don’t appear in the current v2.9 docs.

15

Thanks for pointing that out. I’ve got an open request to merge this (among many other fixes), it’ll get merged in soon.

Pull Request

16

Interesting, I’ll get on this tomorrow.

17

It does have SetBrightness, IncreaseBrightness and DecreaseBrightness, also does have “brightness” property.

18

I was responding to:

19

…Any news @jacob ?

20

Working in most recent versions of firmware (v2.10.16), with test coverage. I’ll send to beta this afternoon.