Open derwehr opened 10 months ago
Are you referring to the Consumed or Exposed side?
e.g., on ExposedThing
side
Do you mean that a Scripting API implementation needs to look into the DataSchema
and detect whether it has default
or const
and report it accordingly without adding a handler?
On the ExposedThing
side.
If I understand it correctly, then a TD already describes this case perfectly and there should not be a need for adding handlers.
Call 29/01:
ExposeThing
side is saving 1 line of JS, but there might be even more use case for different automation needs. Is it really worth it? Thank you for discussing my proposal :) My understanding of the WoT is that when adding new devices to a WoT application or exchanging existing ones, ideally, you'd only need to consume a TD and should not need to modify any code. Therefore, I'm trying to describe everything in the TD and to avoid adding handlers. Would my proposal to improve this 'out of the box TD compatibility' be a better fit for other WoT specifications like the protocol bindings, or is this something every developer would decide upon independently?
hello, I'd like to propose the scripting API to define variables the consumer leaves undefined with the
default
values from the TD (orconst
values?).A simple use-case would be a Thing, expecting a fixed payload parameter based on the Interaction Affordance, like in the TD below.
Now with the scripting API using the default values a user won't have to worry about knowing the correct
commandId
.