Hey there, do you have a command with action “SetSpeed” with argument 3?
One quick check to see what “SetSpeed” arguments that should be supported is: GET the properties endpoint for the device, does it have a “max_speed” field?
I’ll need to reach out to the beta tester. There is no max_speed field available. Does that mean that there is no SetSpeed options? If so why is SetSpeed an available action?
It’s likely that “SetSpeed” action is present because the “IncreaseSpeed” or “DecreaseSpeed” command is present, but for now a “SetSpeed” command is the only source of “max_speed”.
This is because “IncreaseSpeed” is indicative of a stateful device, which is not readily-handleable by a command-based approach (with 4 speeds and 40 brightnesses, typical of a simple stateful remote, there are 160 possible signals). For now, this is the type of device that we let the backend handle, and is also known as a “cloud device”. My main focus at the moment is bringing such “cloud” devices on the Bond itself, defined by a signal-building script.
I believe that we’ve seen non-stateful remote that has Increase/Decrease Speed buttons. I need to think about how to handle this one… probably just with a PATCH to its properties…
Near future: Beta release, this sort of remote is supported as a “Cloud device” and works with our integrations and app.
~1 month after beta release: (*If everything goes smoothly with the public release) Our scripted devices moved offline, at which point they’d be accessible by the local API
Beyond: support for custom, user-defined scripts
so for now do you think i should utilise the speed feedback to determine what speed they are currently on and then increase and decrease based upon that feedback?
I reached out to the beta tester about this. His remote has discrete codes.which is displayed as discrete codes in the Bond app as well. See photo of remote below.
Any reason why it wouldn’t have max speed if it did have discrete commands?
I expect to see 6 commands with the following structure {“name”: “Speed 1”, “action”, “SetSpeed”, “argument”: 1} and so on, upon getting the properties endpoint, the Bond should just find the highest “SetSpeed” argument to be its "max_speed"
There was no max_speed key available. We don’t look at commands in our software and rely purely on actions. Should we grab a list of all commands and parse it to look for the command with the highest number for the max speed?
This shouldn’t be necessary, as this is already what is done when the properties endpoint of a device is requested. Both the apps should populate the proper actions/arguments for a given command, and users of the local API can just ignore commands and use actions.
I’m not sure where the error is, if the user can supply a Bond serial I can investigate further.
@jacob I have a fan remote that is non-stateful and has increase/decrease speed buttons. I have no expectation that the bridge attempt to fake saving state for such a remote. Just send the requested command as-is.
It turns out that there was no need for a new app release to make this change. Try it out now, there should be an option to record Increase/Decrease Speed commands, which should work for your normal control purposes. The corresponding actions may give you some trouble (as I hadn’t yet accounted for lack of max_speed), but I hope to have a fix in the next version, which I’ll release in the next couple days bundled with some other fixes/features.
I would if it were possible. unfortunately, my bridge is now in bad shape. The light ring is now a steady orange. unplugging, waiting 15 seconds, plugging back in results in the bridge returning to the same state. I have made no changes since it was working two days ago.
The old link here says solid orange indicates that the Bond Bridge was unable to connect to WiFi and suggests a green reset (reset button held for 5 seconds, not just a hard reboot).
Thought we had better options now in the new firmware but I can’t find it right now, of course.
Still, a green reset shouldn’t delete any devices.
Now, the Config AP will re-enable if the Bond was unable to connect to our backend. @j4nd3rs0n mentioned that his config AP re-enabled at an inappropriate time, leading me to believe that the Bond is unable to connect to our backend. The Bond will also eventually reboot if it’s unable to connect, which would explain the frequent DHCP requests.
If SetSpeed is not supported you can still use the BOND API to transmit the appropriate signal to your fan (Assuming the BOND has recognized your fan already.) Use the “GET command” API to find the appropriate command then use the “PUT command” API to control your fan.
