How to define read-only properties with the Things Framework?

WebThings
#1

I am writing a Thing for a thermostat I’m developing myself using the Things Framework in node.js. I need to define a property for the temperature sensor that is not editable from the UI. I have seen that other things such as the Virtual Power Plug define properties such as the voltage or power that can not be edited, they just show a sensor value. But in my case I get a text box that allows the user to change the value.

I’ve read about writable in the spec https://w3c.github.io/wot-thing-description/#introduction, and followed https://github.com/mozilla-iot/wot/issues/38 and https://github.com/mozilla-iot/gateway/issues/1261. My question is why there is already support for read-only properties (voltage, power) while the spec is not implemented yet ? How can I do the same meanwhile ?

#2

The gateway currently has no direct support for read-only properties. The solution is to error when a property is being set for now. For JS adapters I use this very simple pattern for that: https://github.com/freaktechnik/sonos-adapter/blob/master/readonly-property.js

#3

Thanks for the tip. I’ve adapted it for the Things Framework, with no success.

This is the ReadOnlyProperty:

const { Property, Value } = require('webthing');

class ReadOnlyProperty extends Property {
  constructor(thing, name, value, metadata) {
      metadata.writable = false;
      super(thing, name, new Value(value), metadata);
  }

  setValue(value) {
      return Promise.reject("Read only property");
  }
}

module.exports = ReadOnlyProperty;

and this is the output on the console for the things server when I change its value from the thing UI:

(node:46744) UnhandledPromiseRejectionWarning: Read only property
(node:46744) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:46744) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

But that’s what I see:

36

Are properties with the @type VoltageProperty or InstantaneousPowerProperty handled specifically on the gateway UI ?

This is what I would like to achieve, but for temperature:

19

I’ve tried to specify one of those types in the metadata of my temperature property without success.

#4

I am not sure the visual representation of those values can be achieved yet.

The Things Gateway picks these styles based on the @type of a Property.

Where the decision is made:

Code for the InstantaneousPower-Blob:

#5

If your define a @context on your WebThing that references Mozilla’s types, you can use the following @type values for a Property:

https://iot.mozilla.org/schemas/#properties

Two properties for temperature (current and target) have already been mentioned here: (Thread: Web Thing API: Read-only and slow properties)[Web Thing API: Read-only and slow properties]

Would be cool, if we could get those into the schema. I don’t know what is missing for the decision to include them.

#6

@jaller94 thank you very much for the detailed response. After taking a look to the code I can understand why it is so difficult to add new types of properties. I am wondering if this is going to scale well.
Anyway, it seems that my only option for now is to wait for those new types to be added :frowning:

#7

As already mentioned, we haven’t implemented the writable property in Thing Descriptions yet because we were waiting for the W3C to settle on a term. I’m hoping we can get this into the 0.6 release. Once that is implemented you should be able to make any kind of property read-only.

The way the Thing Description format works is that you can use JSON Schema to give properties primitive types (boolean, object, array, number, integer or string), units, minimums, maximums and enums and these will be reflected in the UI.

You can then use semantic annotations (@context and @type) to give additional semantic information about what that property is used for (e.g. a TemperatureProperty). Anyone can create their own schemas to define new types in order to encourage interoperability, but if you want to see special treatment in the UI then it has to be in a schema repository the WoT client supports (so far Mozilla’s gateway implementation only supports our experimental schema repository at https://iot.mozilla.org/schemas/ but we plan to support others like iot.schema.org once they mature).

The idea is for the type system to be extensible, and this is the solution the W3C Working Group have come up with.

#8

@benfrancis thanks for the explanation. Despite my concerns on how the gateway will be able to scale with semantic types, I think that this is a great project with a lot of potential. Looking forward for 0.6 :wink:

#9

FYI, it has been implemented you can create Properties using readOnly: true config option