Need to hold/repeat RF signal for a few seconds

if you use just this, with each Command and without the ‘Signal’ endpoint, you will see in the output a list of nodes and values that include the Name, Action, Argument, Button Type, Category Name, Feedback, Icon, etc (as well as Signal and Tx).

So the Action you see under each Command tells you the mapping of what is being called.

Thank You


1 Like

What is the maximum number of reps that the machine will allow?
Can there be a time set between sending the commands?
Can I string 2 commands together to form a 3rd. ie: On x 20, Off x 1 = Preset

Thousands. Rather, the limit is 20 seconds of transmission.

Short answer, no.

Long answer: Sort of. You can edit the signal data to add zero padding at the end. If using the command/signal.encoding=cq you can add large delays with codes like H. But for the hex encoding, you’re limited to a total 600 ms buffer for the whole signal.

We do not currently support that kind of thing. But, I see it gets asked fairly frequently on this forum. So something we can consider. — We’ve talked internally about making the cq encoding able to include repeats. So, if you wanted to send a packet with 101010 20 times, then a packet
110110 1 time, you could do it like this: (101010H){20}110110. Similar to regex syntax.

However, that extension of cq encoding doesn’t help when what you’re working with are the hex-encoded raw buffers. These are 600ms buffers of raw recording that the Bridge simply plays back. You’d need somehow to process the raw buffer down to the individual packets and then repeat/delay/sequence them.

I know you have been wary of making features that don’t translate well to voice assistants.
I think there could be a case made for some users that want native Bond “macros” (for lack of a better word) that could be called in the Bond app, via Bond API, and potentially be exposed to home assistants as simple On/Off (or momentary switches if supported).
Could even have separate settings in the Bond “macro” setup process to say ABC command(s)+rep(s) is ON and DEF command(s)+rep(s) is OFF.

Not sure if the requests have hit critical mass yet to invest the time in that sort of thing, or if it’s similar to things you and the team have already discussed - but figured I’d drop two cents into this conversation about that idea specifically.

From where we stand right now, the most sensible way to ship such a customizable feature would be as BondScript (lua). So you could have a bunch of raw recordings for a device with template=null. Then lets say that for “TurnOn” you actually want to send 5x the command originally recorded as “TurnOn”, then 2x another command recorded as “SetFlame(4)”. You could do that by PUT-ing to devices/{}/script something like the following lua pseudo-code:

-- override TurnOn action
function Action_TurnOn()
  for i in range(4)

This would then work just fine via the app or integrations (Alexa and local).

Of course, interacting with this API would be kind of annoying for many users, so we could drive it from a little webgui built into the product. You could copy-paste in a script for any of your devices in order to customize the protocol, or even define a totally new protocol without reference to any underlying recordings.

1 Like

Maybe I can explain my problem further.
I have an Acumen Tech Fireplace Remote (Acumen RCK-M Fireplace Remote Control with Flame Adjustment for Maxitrol Gas Valves)
This utilizes a ON-Up, OFF-Down two button function.
For whatever reason, the receiver/valve picks up the Bond signal but the repeat rate from the Bond is too rapid for the receiver to respond right away. It takes about 20 seconds of continuous hold on the physical remote to move the valve to a reasonable position for a fire. Even if I set the reps to 1000 because of some timeout feature in the Bond the valve only advances about 30% of its nominal range. It does not matter if the number of reps is 200 or 1000 as the Bond stops sending the signal after about 10 sec. I am hence forced to press the On button on the Bond x 3 to advance the valve to a usable position. The 600ms doesn’t seem to be the limiting factor.

I think I need a better explanation of your “Long answer”. How do I make the whole signal last that 0.6 sec.

Can you share here the body of the devices/x/commands/x/signal endpoint which corresponds to the “Up” function? Then I could talk specifics.

Also, I just saw the project @sriv74 put together: Bond Bridge RF/IR scanner & CQ Encoder It’s awesome! It can let you convert the HEX encoding into the CQ encoding. Then you can add additional delays to the end of the CQ encoding, and boost the reps, and you might get what you’re looking for.

Interesting about the 10 sec limit you are reporting. I thought the limit was 20 sec, but I could be wrong. Something we can review in the V3 effort (we will be doing some optimizations to the radio driver…)

1 Like

C:\Users\maxsp>curl -H “BOND-token: 86727107fe973d6e” -i -X PATCH -d “{“reps”: 250}”
HTTP/1.1 200 OK
Content-Length: 6259
Content-Type: application/json; charset=utf-8


Nice to find this topic … looked like the perfect solution/access to default to more reps for my shades. All good for me until I dig down to look for “signal” param options. I successfully find three commands associated with device: “open”, “close” and “hold”. All return “signal” as params but when I dig down to signal, I get “HTTP/1.1 204 No Content” (same with all 3 commands)

Not sure what I’m missing … or something changed for V3? (Firmware v 3.8.4)

Thanks for any help

I wonder if the “signal” endpoint can be non-existent on cloud-based devices.
It’s been a long time since I had occasion to ask the Bond team if there are any devices that are not fully stored locally (I think the goal at one point in time was to store all devices locally, but originally some had to be stored in the cloud).
@merck / someone else on the Bond team, do you have scenarios still that don’t fully store the signal locally?

To see if there is anything weird with the signal endpoint in the v3.8.4-beta firmware, I just verified a manually recorded device (guaranteed to be locally stored) returns the data as expected:

curl -H "BOND-Token: xxxxxxxxxxxxxxxx" -i http://nnn.nnn.nnn.nnn/v2/devices/aaaaaaaaaaaaaaaa/commands/bbbbbbbbbbbbbbbb/signal
HTTP/1.1 200 OK
BOND-Flags: 4
Content-Length: 6273
Content-Type: application/json; charset=utf-8


Thanks very much for the response. Ah, didn’t think about the cloud vs. local storage… makes sense though would leave me wondering how to apply remote/cloud settings if not local. Hope to hear from the Bond team!

Wondering if there’s any status I could get from the Bond team on this issue … is there any remedy (an addition to the app?) for setting repeat for bridges without the corresponding local storage?

@merck - suggestions?
Are we barking up the right tree, thinking it might still be a cloud device somehow? Or are Shade type devices special and the Signal API endpoint is somehow different?

(@ajh - if we don’t hear from the team here soon, have you tried chatting with Support in the app or sending an email to customersupport?)

Thanks, yes I’ve emailed support, who pointed me here as a place Bond tech support would be checking. I will try them again … not ideal obviously, but I’m thinking a second bridge timed to schedule the same events as the first might accomplish the same goal of each device getting a repeat command…

Ah, curious. The Bond staff (such as Merck, tagged above, and @endy ) do come through here as time permits, but I was under the impression that more real-time support was better served in the app’s Chat or via the email ticketing system.
Fingers crossed someone has a chance to stop by here this week!

All devices have been local for some time, and we’ve never had “cloud” devices for shades.

The “signal” endpoint is present for all raw-recorded devices (where you have to record each signal), and also present for some of the one-click devices. However, many shade protocols involve complex or rolling-code packets where we don’t have a signal endpoint: the packets need to be programmatically generated for each transmission, so there’s no way to modify the reps. Depends on the template.

Okay. Thanks for the details, so we don’t waste time trying to figure out “reps”.

@merck and @residualimages thank you. As far as scheduled opening/closing of shades, also thought redundant (e.g. “open at sunrise”) commands set in app might work. the app seemed to accept it, even though identical to previous set. Maybe that will work for me…

1 Like