Replies: 4 comments 10 replies
-
We had a productive discussion on this API design, in which we formulated the following wishlist:
|
Beta Was this translation helpful? Give feedback.
-
For multi-device scheduling:
For single-device scheduling, the existing scheduling trigger endpoint can be used. Because that url already contains the sensor id, the flex-context can move up one level, which gives:
|
Beta Was this translation helpful? Give feedback.
-
I'm tending to use the term "flex-model" over "flex-context". |
Beta Was this translation helpful? Give feedback.
-
Linking #537 (comment) so we can continue the discussion here and resolve the PR comment.
|
Beta Was this translation helpful? Give feedback.
-
I'm thinking about making the triggering of scheduling clearer to use.
Problem now: we don't discuss the parameters well and the way in which the trigger endpoint handles them doesn't translate to a situation when we'll have multiple schedulers.
I believe right now for that to be simple and clear, we should:
Let's review what stakeholders want:
Here is an example request:
My next PR will make the Marshmallow adjustments and the deprecation. And add documentation.
Other issues for the future:
Beta Was this translation helpful? Give feedback.
All reactions