A schema to describe a Web of Things Gateway (with a things resource which lists all the things it exposes).

Could have an action for "reboot".

See also WebThingsIO/api#91

Should the following optionally support an enum to limit possible values?

• LevelProperty
• BrightnessProperty
• ColorProperty
• ColorTemperatureProperty

Do we even need to specify that enums are acceptable for all types, or should it be optional for everything?

Inspired by WebThingsIO/gateway#1467

As a device developer I want to tell a Web of Things client that my device acts as a push button.

Example Thing Description:

{
  "@context": "https://iot.mozilla.org/schemas",
  "@type": ["PushButton"],
  "name": "Push Button",
  "properties": {
    "pushed": {
      "@type": "PushedProperty",
      "type": "boolean"
    }
  }
}

There are many thermostats that support temperature and humidity values.

This is what zigbee2MQTT's API might output:

https://github.com/Koenkk/zigbee-herdsman-converters/blob/0c34d244d97d0213ae56274f4da18a4a65b4ca3c/lib/exposes.js#L507

from here

Change "name" in example to "title"

No matter how WebThingsIO/gateway#1439 goes I think it'd make sense to have schema types for both a percentage based battery property and a boolean property for low battery.

Even if you only have voltages, you should still be able to give a percentage, since you should know your device's minimum required voltage and maximum battery voltage. And if either of those parameters is missing there's still the VoltageProperty for raw values.

Currently the smart lock has a number of states it can be in. If memory serves, it's:

• locked
• unlocked
• unknown
• jammed

I would like to suggest two more:

• Stealth locked
• Stealth unlocked

Stealth locked
Imagine a teenager that wants to spend some small amount of time in a room with the knowledge that the door will be locked. But at the same time they don't want to signal to others in the household that the door is now in the locked state, as that could create unwanted social scenario's. For example, they may not want to signal to log every time they masturbate.

Stealth unlocked
Some situations may require the reverse scenario. A door is locked, but a user wants to unlock it for a short period of time without indicating this in the system, let alone in the logs. For example, a husband might let in some friends through the back door in order to prepare for a surprise birthday party. Or perhaps the mailman has arrived with the ring he/she wants to use to propose marriage with, but doesn't want any "who was at the door?" question later.

In either case it would be necessary for the system to pretend to stay in / be in one state, while actually being in another.

Locks are just an example of this. There are many social situations and cultures where a smart home that would help the user to 'save face' would be highly valued. Situations where the "owner" of a device has access to the actual information, while others may be left in the dark for a little while.

At least until they try to actually open the door and find it locked, hearing only a faint sigh of relief from the other side.

More on this, including a mock-up, can be found here.

More about the need for this sensitivity can be read here.

I'm currently working on integrating a plant sensor.
It provides temperature, soil moisture and conductivity.
There is already a TemperatureProperty.
The moisture in provided in percent.
The conductivity is provided in μS/cm while the SI unit would be μS/m.
I think the moisture should be the primary value.

As a user i would like trigger a notification on my device.
The notification may contain a message of type string.
It may also contain an urgency level like INFO or ALERT.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

Contrary to popular opinion :-) Wattage does not equal Voltage times Current. In AC, the only thing we know is that Wattage is not larger than Voltage times Current and not smaller than -Voltage times Current. Where it is in the interval depends on the power factor (or the relative phase of Voltage and Current).

So: add Power Factor as a property. Devices such as the Iotawatt directly report on it, see "pf:" in this screen shot: https://iotawatt.com/assets/img/screenshot%20status.png

https://en.wikipedia.org/wiki/Power_factor

Currently the PushButton capability exposes a single PushedProperty property.

It turns out that many buttons only expose events for a press, double press and long press which would require hacks to expose as a single pushed property because there are no release events.

What do people think of adding:

• PressedEvent
• DoublePressedEvent
• LongPressedEvent

in addition to or instead of PushedProperty?

I just got a xiaomi "weather" sensor which has temperature, humidity, and barometric pressure.

It would be nice to be include TemperatureSensor, HumiditySensor and BarometricSensor in the list of @types so that the user can choose the most important to them.

As far as I know the gateway implements an EnumProperty cabapility. This capability is currently not in the schema. Or is that inherited from some other place?

As a device developer I want to tell a Web of Things client that my device acts as a door (or window) sensor.

Example Thing Description:

{
  "@context": "https://iot.mozilla.org/schemas",
  "@type": ["DoorSensor"],
  "name": "Door Sensor",
  "properties": {
    "active": {
      "@type": "OpenProperty",
      "type": "boolean"
    }
  }
}

As a device developer I want to tell a Web of Things client that my device acts as a motion sensor.

Example Thing Description:

{
  "@context": "https://iot.mozilla.org/schemas",
  "@type": ["MotionSensor"],
  "name": "Motion Sensor",
  "properties": {
    "active": {
      "@type": "MotionProperty",
      "type": "boolean"
    }
  }
}

The URL in the about section of this repo should be updated to https://webthings.io/schemas/

How about continuous deploying the current version of the master branch using travisci?
Or is there already a jenkins in the background which is doing that?

See also WebThingsIO/api#61

Consider adding example Thing Descriptions for each capability (e.g. w3c/wot@ec2981b).

Also note the current example at the top doesn't use the new links format.

Some devices have a built-in light sensor which provides the current illuminance in lux.

Use cases:

• Tracking a phone, to perform an action when you enter, leave or stay in an area
• Tracking a vehicle, like a car, truck or a plane
• Tracking a pet or a wild animal for research
• Knowing where a security camera is located

All my use cases point towards a read-only property.

Sub properties

• longitude (required)
• latitude (required)
• altitude (optional)
• horizontalAccuracy – precision of longitude/ latitude (optional)
• verticalAccuracy – precision of the altitude (optional)

I'm unsure in which unit the accuracy is commonly exchanged – maybe meters.

Another option is to define all these proposed "sub" properties as properties and define a Geolocation capability.

As a user i would like to have a property for my weight scale.

In the Thing Description specification, the property type can be one of: null, boolean, object, array, number, integer or string. However, in the schema specification, integer is never used, only number. Most of the properties in schemas that have type: number could be type: number/integer.

Originally from WebThingsIO/gateway#1467

After getting closer to implementing this schema, having a LockAction and UnlockAction which update a LockedProperty seems to make more sense than a TargetLockedProperty.

This seems like a good use of actions given locking can take a while to complete and can both succeed and fail, and using actions avoids some strange interplays between LockedProperty and TargetLockedProperty.

WebThings currently adds various proprietary top level members to WoT Thing Descriptions.

It would be good to document these as schemas so that WoT Consumers can understand them better, and they can potentially be used with JSON-LD prefixes in the future.

Proprietary members of a Thing used by WebThings Gateway that are likely to stick around include:

• floorplanX
• floorplanY
• layoutIndex
• selectedCapability
• groupId (currently group_id)

Also being added in WebThings Cloud:

• buildingId
• floorCode

See also: WebThingsIO/gateway#2832

(specialisation of Alarm)

There's some interest in consolidating the capability schemas at webthings.io/schemas with those at iotschema.org so that multiple projects (e.g. WebThings, ThingWeb, openHAB and HomeAssistant) can eventually share a common standard ontology.

In order to do this I think the first step is to evaluate where these schema repositories currently overlap and where the gaps are in the iotschema.org repository for the capabilities currently supported in WebThings.

We should also evaluate differences in the way schemas are defined, because I think WebThings schemas currently provide more in the way of constraints than those at iotschema.org, e.g. by defining mandatory properties/actions/events for certain device capabilities and being more prescriptive about things like data types, units and media content types.

In WebThingsIO/zigbee-adapter#292 there's a request for a feature to show the user when a device was last seen, so that they know when a gateway exposing the Web Thing API for a web thing last had contact with the actual device.

I propose that new type of property schema be defined which provides a machine readable value like an ISO 8601 date stamp, an integer representing milliseconds past the epoch, or an integer representing a time period in milliseconds. This machine readable value can then be converted into a human-readable string like "3 hours ago" in a user interface.

I'm open to ideas on the naming. It would be nice if this could be more generic like "DateTimeProperty", but the request was specifically for a property to be displayed as a string like "3 hours ago", which wouldn't be obvious from such a generic type.

The more specific option LastSeenProperty would be a bit of a strange name to standardise because it wouldn't make sense for devices which host their own Thing Description.

I wonder if we can make the PushButton writable so it can also be triggered by the gateway UI.
This would be useful for the scene adapter for example.

Make the AlarmProperty of the Alarm capability writable, so that an alarm condition can be triggered as part of an automation, rather than just reading an alarm state form an alarm.

Some systems like the hue lights allow initiating a short flash cycle.
There should be an appropriate action for this.

Several devices may have some kind of alarm/alert that could be critical to the safety of a building's occupants. This includes smoke alarms, CO detectors, alarm systems, and possibly door/window locks and other security-related devices. Perhaps there is room in the schema for an AlarmProperty or AlarmEvent, in conjunction with an Alarm Capability, to denote devices with high-priority notifications.

As an example, I'm working on interfacing with a Nest Protect, smoke/CO detector. It has separate interfaces for the smoke alarm status and CO alarm status, both of which have 3 states: ok, warning, and emergency.

(Originally from WebThingsIO/gateway#995)

This more a feature request than an issue, but would be great to natively support and standardize the shutters and/or blinds devices.
For a shutter we have the position and for the blinds we have in addition the slat angle in % (this could be in degres or radian too, but conversion would be easy)

Basically, the properties are:

• position % (mandatory)
• slat angle % (optional)

and the actions:

• UP, (optional)
• DOWN, (optional)
• STOP, (optional)
• STEP_UP, (optional)
• STEP_DOWN (optional)

As events :

• bottom reached (optional)
• top reached (optional)

What do you think ?

This this specification superseded by the Web of Things (WoT) Thing Description
W3C Candidate Recommendation or is it still developed?

Carbon monoxide alarm

(specialisation of Alarm)

A good plant health sensor would have:

• the moisture percentage in the ground
• the conductivity of the soil
• the lumen level falling on the plant
• the temperature of the soil
• the temperature of the air

As per WebThingsIO/api#113

As a web thing developer I want to expose a camera or video camera as a web thing so that users can capture video, audio and images.

See WebThingsIO/gateway#1438 for implementation in Things Gateway

Currently there is only one type of alarm.

Some devices contain multiple alarms. For example, it is quite common to have a combined Smoker/Carbon Monoxide alarms.

As a user I should be able to choose if I want it to display primarily as a Smoke Detector or as a Carbon Monoxide Detector.