-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which is better to actuate devices, invoking ACTION or writing PROPERTY? #1020
Comments
I think, the major issue here is that the Hue device has designed this interface and the TD from TUM simple follows this. You are right, this may not be perfect and can be designed differently. Would you like more clarification on when to use PROPERTIES and when to use ACTIONS? Maybe the WoT profile can be a good place to have that clear definition. What do you think? |
In case it's helpful, Mozilla's draft specification provided this rule of thumb:
|
I agree, some kind of non-normative guidelines may be useful. Having said that, in the end it depends a lot on various aspects and it seems impossible to me to prescribe when to pick what
|
@sebastiankb Thank you for your comment apologize for my late reply. In my opinion, the description of ACTION in the TD document should be modified, because it can be interpreted as having to use ACTION to invoke devices. Mozzila's draft is useful for this point. When I talked to the chair of ECHONET Web API WG several weeks ago, he said "ECHONET Web API respects the idea of WoT, but writing properties of the devices are natural to control them. ECHONET Web API cannot be aligned with WoT to this point." If the WoT specification allows writing properties for the invocation of the devices, some modifications of TD doc are needed. If you agree with this, I'll create a text to clarify it. It's important to make the specification acceptable from existing standards like ECHONET, OPC UA, and so on. If you know experts of them, could you have their opinions? |
For the case of Philips Hue, it is possible to model everything as properties, however, the responses of the API for making a change is completely different than when reading something. We had chosen actions in order to use the clear input/output mechanism and not do super messy granular readOnly/writeOnly clauses. We could of course omit this since the response of the API is anyway not so easy to parse. |
@mryuichi Many thanks for the clarification. You are right we should be more clear in the TD specification about this point.
That would be great if you can provide a proposal.
100% agree with this and we should doing so. One question: Is it possible to have a device available for the next PlugFest that follows ECHONET Web API?
As you know, there is a plan for OPC UA to start a common activity to design TDs that fit well with OPC UA interfaces. Maybe we should also think about doing this with ECHONET consortia. What do you think? |
@sebastiankb Thanks for your comment.,
OK. I will make a proposal to clarify that.
I'll ask a member of ECHONET consortium if they can join our next plugfest.
That's a great idea. First, why not take the opportunity to hear from them about the differences between ECHONET Web API and WoT? |
Many thanks.
That would be great.
Yes, that makes sense. |
@egekorkan, thank you for your comment. I think your comment is appropriate. Sorry for the late reply. It's great to be able to represent product-specifc specifications with TD. But at same time, I'm worried it might build silos over the WoT.
(If you are an expert for these standards, please check if these are correct. The blank shows no correspoinding item.) In these standards, the devices can be operated by changing the value of the property (using WriteProperty) instead of invoking the action. Therefore, I think the description of the WoT documents should be modified so that the device can be operated by writing the property in TD as well. |
I think the advantage of Thing Description is that it can handle protocol binding and interaction affordance separately. |
I talked to steering members of the ECHONET consortium about their participation in the WoT plugfest and found they have an ECHONET device simulator running on the cloud. to check the connection to their Web API. Unfortunately, the introduction to the ECHONET Web API and the gaps to the WoT is difficult for a while due to the busy schedule. |
@mryuichi the table above is actually really helpful, thank you for the contribution! :) |
Totally agree here. Here's my comment on our rule of thumb when designing TDs:
|
From today's TD call: |
In the presentation (see slide 25 here) of ECHONET lite on the Open day of vf2f, we found that ECHONET Lite device is basically controlled by setting its property in Web API, but there are exceptions. Case (1) is defined as only 4 cases in Web API (see document) at the moment. Reset the cumulative power generation value of Fuel cell, etc.
I found an amazing slide in OCF presentation. (See slide 5 in here) This slide shows two approaches to device interface representation. One is to define by device resources and their properties. This definition is equivalent to Property in WoT. The other is to define by device functions and operations. This is equivalent to Action in WoT. When describing a device as a property, for example, turning on the switch of the bulb, only the property of the switch is changed after this operation. On the other hand, when describing a device operation with Action, different properties can be assigned to the input and the output of the Action. Therefore, only when the input and the output are the same property, it can be described by both Property and Action. A quick look at the specifications shows that OCF, KNX, BACnet, and ECHONET are defined based on the property so that these devices are easy to map to both Properties and Actions of WoT. I would like to write a formal description of the usage of property and action.
The definitions of Action and Property in the architecture document are as follows:
These two definitions say that when you control a device, you’d rather use Action. If we can use both Action and Property, the word “optionally” in the property definition above should be deleted. |
@mryuichi As part of the WoT Profile I'm working on payload definitions, that should be clearly defined there. Can you please help with a proposal of the required payload structure for Echonet? |
@mlagally |
In the last plugfest, TUM gave us a very precise description of the devices with TDs, but I feel them a few complicated descriptions. For example, in HueColorLight, the description of property "on" appears in three places: "properties" and "input" and "output" in the "actions". If stopping to use ACTION to change the value (e.g. ON/OFF) the property "on" and writing the value to the property "on" instead, all operation to the device can be performed by reading or writing the value from/to the properties. It's very simple. The description can be shortened to a third of the original TD.
In fact, in some standards such as BACnet, KNX, and ECHONET, the lamp is turned on by writing the value to PROPERTY, not invoking ACTION. It should be more natural to describe in PROPERTY instead of ACTION according to the existing standards of the device interfaces.
I think that ACTION should be limited to use when it's necessary to interrupt the process in the middle, etc.
The text was updated successfully, but these errors were encountered: