Home Assistant - Random Presets

Integrations
1

Are you able to route this to the dev team or whoever works on the
python package/home assistant integration?

I want to mention, that before you see my feedback below, that I love
my bond hub. Its awesome. Brilliant product at a great price and it
JUST works, with LOCAL support for smart homes. Amazing in today’s
world. The docs are all also very good, really end-to-end its amazing
and should be a model for other smart products and technology in
general.

I have a DC 9 speed fan that uses template RCF98v2.

It exposes “Random 1”, “Random 2”, “Random 3”.

These are effectively different breeze modes.

I use home assistant and its not exposing these modes as “Breeze”.

I see inside of the python API that it exposes device, device
properties, and device_state.

I was going to refactor the Home Assistant integration so that it can
dynamically detect the “random” settings and set those are presets,
but the python library doesnt return the commands to dynamically
figure that out based on the template.

If not this, then maybe a “custom” service to call an action with an
argument via home assistant? I may try to take a stab at this.

Update 1
I wrote this and then eventually cloned home assistant and made some tweaks so that if OEMRandom is a supported action, that exposes “Random 1” “Random 2” and “Random 3”.

I then had it call the action with the appropriate arguments.

It works, but its not good enough to expand to others.

Here are the changes that work for me. But ideally we get access to the command list to make the preset match the dynamic amount of random modes?

image
image765×1060 21.7 KB

2 Likes
2

Thanks for the kind words and feedback regarding the undocumented “OEM” actions.

What we do is, we look at the remote controls for many ceiling fans (or other product) and we design our Features (sets of actions/states/properties) to be like abstract superclasses (or, if you are into Rust, Traits). The Bridge maps from the Features onto the various RF commands. This allows us to have parity of control between all integrations and the app.

But, as you point out, what ends up happening is that there are some remotes with special functions that don’t exist in our Features scheme, and users expect that that “woosh” button on the remote will also be in the app. So, occasionally, we break our parity principle and just add an “OEM” command that ends up only appearing on the app. If you really want to show these, you can sync the devices/{}/commands endpoint and get a list of these buttons and display using the name.

image
image2338×1298 249 KB

The upshot is that, in the shade world, and for new templates going forward, we don’t add anymore these “OEM” commands. If we support a feature at all, we support it as a Feature, that is, documented on the API docs.

https://docs-local.appbond.com/#section/Features

Lastly, seems like for your specific case, we should have used the Breeze feature instead of going with an OEM command.

1 Like
3

That all makes a ton of sense and I definitely thought at one point this OEM thing seems weird since it is more or less breeze mode. The thing is my remote has “3 breeze modes” where as all other remote I assume only have one generic “breeze” mode?

Either way I have a fix in for OEMRandom in home assistant but it just arbitrarily puts in random 1 random 2 and random 3. Since that’s what I have and in the python library there is no way to determine how many arguments the remote supports.

So my fix is “ok” but may not be ideal for others? I’m tempted to just raise the PR and see if it gets approved.

If not then maybe I’ll have to create an endpoint in node-red that I can call to then call the bond with my oem random mode. Or maybe in HA itself but HA api calling stinks in my opinion.