Why such limited actions?

Mozilla IoT
#1

I think I mostly understand the WebThings spec and the IOT gateway code. I’ve installed a few devices and looked at my .mozilla-iot/data/zwave-adapter/ozwcache_0xf8fbee03.xml (zwave cache of device xml descriptions.)

My question is why did the designers of WebThings (or is it the Gateway?) choose such limited options for each node? My nodes have many COMMAND_CLASS actions which are not exposed through the WebThings API. For instance, my switch can allow me to set it so the LED is on all the time, when the switch is on, or when the switch is off. It’s a nice feature. I’d like to be able to change it.

It seems like Gateway automatically discovers features from the Zwave device xml data, right? And then it maps it to a WebThing object.

Why not expose all the features? They are even self documented.

And if it is too complicated to show all that to a user, why not have an “Advanced Options” button which allows a user to activate it? Or expose them though the REST API so developers can activate them?

I’m sure the designers did this intentionally, but I don’t get it.

Thanks for any education.

2 Likes
#2

There is nothing preventing these from being exposed. However, the primary developer could only test with devices he has.

If you know how to code, or just have specific suggestions for what’s missing, please feel free to contribute to the code.

1 Like
#3

First let me see if I understand how it is currently working - the zwave adapter looks at the openzwave database for xml descriptions of each device that it finds - presumably from some unique device id. Then it matches it to a simple WebThing, but a generic one. So a “on off switch” with 100 features is just an on/off switch.

Right?

So to add functionality I’d either have to create a custom thing for a specific device, or create some generic thing that opens up all of a discovered device’s COMMAND_CLASSes, right?

#4

There is a whole lot of code in zwave-classifier which looks at a node and all of its command classes and tries to dynamically build properties and such out of those. Obviously, there are a lot or properties missing, so we just need help adding support for those.

#5

zwave-classifier - that helps a lot. Ok - so I will try to do as you suggest, but will wait for a device where I need something. I have an install coming up that I’ve just been dawdling on.

To summarize what I think you are saying: your design plan is to enable a mapping from zwave capabilities to thing capabilities and it is a fairly laborious process of manually mapping and testing. So over time the capabilities of individual devices will be realized as more complete classification is coded.

Correct?

#6

Yes, that sounds accurate.

#7

As I understand it, exposing only the command classes which correspond to properties, actions and events in WoT capability schemas is intentional. This is because the gateway UI currently represents every property and action in the UI and displaying every obscure feature of a device (many of which are internal settings rather than physical characteristics) using their raw data types would make for a very crowded and unfriendly UI.

The W3C Thing Description specification currently has no way to annotate particular features of a device as being more important to users than others, so the UI has no way to differentiate and therefore displays them all. The decision of which properties, actions and events to expose is left to the developer of a given adapter.

Changing this approach would either require adding features to the Thing Description specification, or changes to the gateway UI, or both. One possibility is to only display properties and actions with semantic annotations which the gateway recognises, and then have a separate advanced view of all the other properties and actions with their raw data types as you suggest. The downside of this is that some relatively important features of devices which just don’t correspond to an existing capability schema may get buried in a list of large number of obscure features.

We could allow the user to configure which properties and actions are displayed in the main view, but that adds further complexity.

I think there probably is a way to keep the core UI looking quite simple while adding these more advanced features in the background, it just requires some UI design work.

We’d been planning a big overhaul of the UI this year, possibly getting rid of the current fun but impractical “splat” design, but it unfortunately didn’t happen due to a lack of resources. I hope we’ll get to tackle this in the new year.

#8

Currently, these features are not exposed, so adding this advanced functionality interface would be all positive.

My user perspective:
I think it would be ideal to have every feature fully supported in a perfect way. And I imagine that as WebThings becomes the adopted standard, and as Gateway improves, this will likely happen.

But for now, the tradeoff is either a simple UI with only partial features, or an advanced UI with full functionality. For early adopters like myself, full functionality is extremely important.

And for those non technical early adopters, having the “advanced” features hidden in an “advanced - use at your own bewilderment” button seems a reasonable burden.