Hi,
I’m having an issue with the API and the DecreaseFlame command. If I set the argument to 1 it works however anything other than 1 and it seems to error out and not work. I get the following error from the server: 400 Bad Request
The IncreaseFlame command works as expected with different values for the flame.
I’m on firmware v2.21.4
Some of our fireplace templates don’t properly emulate all the actions. It depends on what signals are available in the underlying remote. However, we should be able to improve the templates so that any value is available.
Can you please share the template ID? Also the Bond ID would let us look it up on our end.
Caveat Lector: Everything I say below pertains only to raw-recorded fireplaces; that is, fireplaces that do not use one of our one-click templates from our database. The template fireplaces will “do the right thing” for Increase/Decrease Flame actions with arbitrary arguments. — Raw recorded devices are hard because we try to make a generic behavior with a few signals provided without knowing about the underlying behavior of the fireplace.
Ok, I checked our code here, and indeed this looks like a bug. But, it doesn’t really make a practical difference. I’ll explain:
You program some number of RF signals into the Bond Bridge, and you tell us what actions these signals correspond to. Together these signals, actions, and some other metadata like name and icon are called a “command”. For example, you’ve programmed:
Now when the Bridge receives an action, it has to run some algorithm to figure out which RF signal(s) to transmit to fulfill that request. In the simple case, you ask for “IncreaseFlame(1)” and we know what to do: just send the command that is an exact match. However, in the case of “IncreaseFlame(7)”, it’s not a priori clear what the Bridge should do. What we actually do is, send the “Flame Up” command just once, but we update the flame state variable, increasing it by 7. That way the feedback on the API seems reasonable.
What else could we do? I suppose we could play dumb and transmit the Flame Up signal 7 times, but that would not be what you want, since the Flame Up signal actually causes the fireplace to increase the flame level by more than 1%. — We could allow the user (or API client at least) to modify the argument associated with the Flame Up command to be some estimate of the % increase that it causes, and then we could make that mapping appropriately.
But all that above is just theorizing. Don’t currently have plans to mess with this, we don’t have many fireplace users and the code operating this is a bit arcane.
So, I’d recommend just sending argument=1 all the time.
The bug I referred to had to do with the handling of the DecreaseFlame action when there’s no template (that is, a “raw recorded” device). I’ve got a fix for this, but it doesn’t change the fact that we will still only send the signal once.
Relevant source code copied below if you are very curious.
static void bbridge_action_handler_increase_flame(bond_req_t *req,
cJSON * seq,
bbridge_dev_t *dev)
{
BBRIDGE_STATE_GET_INT("flame");
BBRIDGE_ACTION_CHECK_INT();
int power = 0;
BBridge_State_Get_Int(dev, "power", &power);
int target_flame;
if (!power) {
target_flame = 1;
} else {
target_flame = current_value + argument_int;
}
if (target_flame > 100) {
target_flame = 100;
}
if (bbridge_action_add_seq_cmd(seq, dev, BBRIDGE_ACTION_INCREASE_FLAME,
cJSON_CreateNumber(1))) { // <----- this was `argument_int` for DecreaseFlame handler
BBridge_State_Set_Int(dev, "flame", target_flame);
BBridge_State_Set_Int(dev, "power", 1);
} else {
bbridge_cmd_t * set_cmd =
bbridge_action_find_next_command(dev, BBRIDGE_ACTION_SET_FLAME,
target_flame, true);
if (set_cmd) {
cJSON * set_argument = cJSON_Parse(set_cmd->rec.argument);
bbridge_action_add_seq_cmd(seq, dev, set_cmd->rec.action, set_argument);
BBridge_State_Set_Int(dev, "flame", set_argument->valueint);
BBridge_State_Set_Int(dev, "power", 1);
} else {
Bond_Req_Set_Bad_Request(req, BE_400_BAD_ARGUMENT);
}
}
}
Thank you very much. Makes perfect sense. I was using the argument and the flame value to track the level of the flame in my driver.
Forexample, when the on command is issued the fireplace always starts at 100 so I set the flame to that. Its roughly 10 steps to go from 100-1 so I increment/decrement by 10 to keep track of where it is and expect that it only sends 1 command. I my mind I alway separated the argument and the sending of the command.
What I ended up doing is just tracking the flame level in the driver itself and not in the Flame attribute in the api as a work around but wanted to report this anyways incase it impacted anything else.