Hi
I have quite a few blinds at home with a mix of Dendo & Somfy motors. They work fine with the hub and manually. When i am control a dendo blind via the Bond Hub app, I get an option to open the blind to a set location (A, center, B) which is same as 25%/50%/75% in addition to open/close
However, when i try to do this via a schedule in the bond app, i don’t get these additional set positions. I can just set it to open (fully) or close (fully). I also dont get these option in Home Assistant. I will like to set schedule where , say 11am it is position A.
So I managed to set ‘A’ position in a group schedule by patching the existing schedule and changing the action from ‘Open’ to ‘OEMTimer’ and argument = 1.
Argument value 1 = Position A
Argument value 2 = Center
Argument value 3 = Position B
I found my preset groups ID and then patched its sunrise open schedule as follows:
Note: replace your_bond_bridge_token, your_bond_bridge_ip, your_group_id, your_schedule_id with the relevant data.
In the Android App it shows there is no action set for that schedule (i.e. What is showing ‘Not set’), but so long as its not updated on the app it should remain fine.
Sorry about this OEMTimer business. Should not have been this way. It should have been “Preset” with argument 1, 2, or 3. — Will be fixed in this week’s beta 4.27.50-beta. It will automatically migrate the action. This will not break anybody using the app, but @RaMoNsTeR you’re using schedules or integrations based on this OEMTimer action on RMS115 (Dendo), in which case you will need to change to Preset.
Thanks for the reply @merck and info about the upcoming change.
It would be great if we could get the A, B and Center position options for group schedules etc in the application. The buttons for A, B and Center show for individual devices but not for groups or group schedules, only Open and Close can be set.
I understand in a group that not all devices may support the OEMTimer (to be ‘Preset’) with arguments 1 to 3, maybe this is why devs elected to not allow it. But I think it would be better to allow all the groups devices available actions, and ignore error at scheduled run time, or filter at save time (keep list of qualified devices for action). You’ll figure it out
I can confirm the above worked this morning, all grouped shutters at position A at sunrise.
@RaMoNsTeR with today’s beta you should have the ability to schedule Presets. Should also work in the Groups. I’m actually not sure if it will show Presets 1 and 3 or just the default “Preset” (2). We are still testing, but releasing the beta anyways. Your feedback would be valuable.
I updated my BE-1000 and the app was saying “Syncing…” in status and then Unreachable, however the PIN/account entry http page was still accessible. I tried a few power cycles to no avail. Left it quite a few hours, no go, stuck on sync then unreachable.
Changing OEMTimer in my API changed schedule to Preset via API did heal the issue, it went from syncing to online! So the update seems to fall over on unsupported schedule actions during upgrade or sync checks. Might be worth having a way to deal with that.
I can confirm group schedule is showing “What: Preset to 1” in the application (Android), but only because i set it from the API directly. I am not sure what happens when setting ‘Preset’ from the app, as it does allow Open, Close and now Preset, but there is no way to specify the Preset argument, so changing or adding via app just says “What: Preset” whereas the API modified schedule says “What: Preset to 1”
Huh. It shouldn’t do that. I wonder if it just took a while to fully resync with the app. I don’t know why it would fail with even an unsupported action in the sked endpoint.
Thanks for the detailed report! You’re correct — the apps currently don’t support specifying which preset to use when creating schedules. The firmware handles Preset with arguments correctly (as you discovered via the API), but the app UI never prompts for the argument.
We’ve opened internal issues to track this for both firmware and apps. In the meantime, the API workaround you found is the right approach for scheduling specific presets.
OEMTimer (1) = Position A.
I wonder if it just took a while to fully resync with the app. I don’t know why it would fail with even an unsupported action in the sked endpoint.