You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: In parentheses, I am providing an alternative user story about the same feature
Who (As a...): Device Manufacturer (as a Consumer Application)
What (I need...): Indicate in our TDs and TMs that some data ranges are dependent on the values of properties (Avoid displaying wrong value ranges in some states of the Thing I am communicating with)
Details: This is very common in devices where an electric motor can be wired in delta or wye formation (https://en.wikipedia.org/wiki/Y-%CE%94_transform). Once the wiring is done, the operator sets a configuration property to a string. If that property returns delta, the voltage minimum-maximum is simply the line voltage. If that property returns wye, the maximum is line voltage divided by sqrt(3).
Why (so that I can...): Make sure that Consumer applications read a property value before finding the value ranges of the other properties (Read the relevant property to understand different ranges and display them correctly on a dashboard or do appropriate input checking)
Notes:
There is a variation of this user story where a property needs to be read before an action can be invoked. This was shown in the last WoT CG meetup presentation by @VigneshVSV (see around time linked time at https://youtu.be/k2KMKd2ZVq0?si=09C4zX52cHuwCiJ7&t=2024). A more correct modeling would be via something like SCXML or XState, where some initial work by @FadySalama is available at https://github.com/tum-esi/Stateful-WoT, which also shows an example of a motor driver from Schneider Electric.
The text was updated successfully, but these errors were encountered:
Note: In parentheses, I am providing an alternative user story about the same feature
Notes:
The text was updated successfully, but these errors were encountered: