How to add Action to a device using API

I am trying to create devices using the API. There is an API to create a new Command. I don’t see an API to create a new Action.

How can I add Action to a device?

Also when using the API to create a device, the API doesn’t take the Template parameter.

curl -H "BOND-Token: xyz" -X POST -i http://192.168.1.2/v2/devices -d "{"name": "Test2","type": "GX","subtype": "AWNING","template": "A1","location": "Kitchen"}"

Response:
HTTP/1.1 500 Internal Server Error
Content-Length: 46
Content-Type: application/json; charset=utf-8

{"_error_id":1,"_error_msg":"name required"}

How can I either add actions to a device or use a Template when creating a device?

EDIT: wow, just noticed this is an old post, but just saw it today to reply. :face_with_peeking_eye::sweat_smile:

I’ve also been wanting the ability to add Actions and States / Properties for awhile, but it’s not the most heavily requested feature and the Bond team has other priorities they’re addressing for the time being.
I end up customizing Commands a decent bit, then behind the scenes just using whatever Action and States / Properties were created or recorded originally. There are even some things that I have to basically copy the Command contents to a new Command to get a more full amount of customization (though still not everything I wish for, at times :stuck_out_tongue_closed_eyes:).

Here’s an old post from a former Bond staff member I reference whenever I’ve added templated devices in the past:

Users cannot add arbitrary new Actions because they would not work with integrations.

Reading the forum posts, I was a little bit confused on this point, but I’ve noticed that if you add commands for stock actions that your device doesn’t otherwise have, it gains those actions

I do wish there was a list of actions, and icons, things like that. And which actions require arguments. I ended up guessing wrong. So even though I can successfully send some extra rf codes to my fan with the bond signal cli command, I don’t quite have them working with the app yet. I added them with the API, but guessed some things wrong, so I ended up with generic icons and it errors out when I try to use the commands. And updating the commands is either giving me errors or no response at all.

I’m going to delete the new commands that I added and recreate them to exactly match the same commands from another fan’s template (except with a different signal of course).

My situation is I have a fan that I’m using the “L2” template on. And that template is exactly right for my ceiling fan. All features of the real remote work correctly.

However, I really wanted up and down buttons for the light dimmer, and the remote only has a dimmer cycle button.

But, I took the signals from those 6 commands, and looked at which bits were different, and noticed only 4 bits actually changed between commands. So I tried out the other 10 bit patterns, and found 3 new commands that aren’t on the remote: Light Off, Dim Down, and Dim Up. (The remote only has CycleDim, and ToggleLight, as well as fan off and fan 1-3).

AWESOME!!! Would you mind sharing your Bond ID and the device name in a DM? We would add those to the template.

I wonder how many of the fans with toggle-only lights actually have hidden light on/off commands.

We could do that in the context of something like BondScript, where we could get community contributions to a remotes database. :thinking:

1 Like

DM sent.

I wonder how many of the fans with toggle-only lights actually have hidden light on/off commands

Good question.

I’ll bet it’s pretty common to use the same firmware across models.

Also, I don’t know what the QA / QC / Production Line testing is like at a ceiling fan company. But I could imagine that they could have a test harness that sends some commands that are not on the remote, either because they’re faster or because they work better for automated tests.

So my guess is a lot of them will have something extra. But maybe I just got lucky.

Generally there is really excellent QA testing that every kit that ships works out of the box. However, inter-operability of product between revisions is usually not on their radar, because automation is not considered. So, we often discover different near-cousins of the same protocol. (It’s so much like biology that we internally use a Linnean naming scheme…)


We’re going to be doing some more test automation and we could test additions to the L2 template as part of that. (Or maybe it will be L2B).

Would be handy to have a breakdown of official Bond template IDs and Actions they support, as well as the Community-sourced BondScripts.
In addition to the list of Actions in general, slug icons, etc.

So, we often discover different near-cousins of the same protocol. (It’s so much like biology that we internally use a Linnean naming scheme…)

Ah ok, interesting. I guess its more like they fork the last project for the new one. Still. that could explain extra features. (Plus, sometimes requirements change. And unless you need to save the bytes, which I know is a real thing on embedded systems, it’s easier to leave stuff in than take it out.)

Anyway, just guessing why there would be a few extra commands.

We could do that in the context of something like BondScript, where we could get community contributions to a remotes database. :thinking:

That would be pretty cool. I noticed there’s a few community IR databases. But I couldn’t find anything like that for RF.

From a business standpoint, that could be both good and bad. Good because the community’s contributions would lead to a better product. But bad because some other company could use the database to create a rival product, but without what I assume was a massive expensive of time and money that you all invested in creating and testing your database.

1 Like

Reminds me of the Harmony and other IR-based media remote days where there were absolutely more commands able to be received and acted upon by a decent number of devices than were included on their OEM remote.

@tim bumped you up so you can see this thread.