ISO/IEC 30118-18:2021

INTERNATIONAL ISO/IEC
STANDARD 30118-18
First edition
2021-10
Information technology — Open
Connectivity Foundation (OCF)
Specification —
Part 18:
OCF resource to Z-wave mapping
specification
Technologies de l'information — Specification de la Fondation pour la
connectivité ouverte (Fondation OCF) —
Partie 18: Spécification du mapping entre les ressources OCF et
Z-wave
Reference number
© ISO/IEC 2021
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2021 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 2
3.1 Terms and definitions . 2
4 Document conventions and organization . 2
4.1 Conventions . 2
4.2 Notation . 2
5 Theory of operation . 3
5.1 Interworking approach . 3
5.2 Mapping syntax . 3
5.2.1 Introduction . 3
5.2.2 General . 3
5.2.3 Value assignment . 3
5.2.4 Property naming . 4
5.2.5 Range . 4
5.2.6 Arrays . 4
5.2.7 Default mapping . 4
5.2.8 Conditional mapping . 4
5.2.9 Method invocation . 4
6 Z-Wave translation . 4
6.1 Operational scenarios . 4
6.1.1 Introduction . 4
6.1.2 Overview of OCF-Z-Wave bridging . 5
6.1.3 Use case for OCF Client and Z-Wave server . 5
6.2 Requirements specific to Z-Wave bridging function . 5
6.2.1 Requirements specific to Z-Wave . 5
6.2.2 Exposing Z-Wave servers to OCF clients . 6
7 Device type mapping . 13
7.1 Introduction . 13
7.2 Z-Wave device types to OCF device types . 13
8 Resource to command class mapping . 14
8.1 Introduction . 14
8.2 Z-Wave command classes to OCF resources . 14
8.2.1 Introduction . 14
8.2.2 Battery command class mapping . 15
8.2.3 Binary switch command class mapping . 15
8.2.4 Door lock command class mapping . 15
8.2.5 Multilevel sensor command class mapping . 16
8.2.6 Multilevel switch command class mapping . 16
8.2.7 Notification command class mapping . 16
8.2.8 User code command class mapping . 17
© ISO/IEC 2021 – All rights reserved iii

9 Detailed mapping APIs . 17
9.1 Battery command class . 17
9.1.1 Derived model . 17
9.1.2 Property definition . 17
9.1.3 Derived model definition . 18
9.2 Binary switch command class . 18
9.2.1 Derived model . 18
9.2.2 Property definition . 19
9.2.3 Derived model definition . 19
9.3 Door lock command class . 20
9.3.1 Derived model . 20
9.3.2 Property definition . 20
9.3.3 Derived model definition . 20
9.4 Multilevel sensor command class carbon dioxide . 21
9.4.1 Derived model . 21
9.4.2 Property definition . 21
9.4.3 Derived model definition . 22
9.5 Multilevel sensor command class carbon monoxide . 23
9.5.1 Derived model . 23
9.5.2 Property definition . 23
9.5.3 Derived model definition . 24
9.6 Multilevel sensor command class smoke density . 25
9.6.1 Derived model . 25
9.6.2 Property definition . 25
9.6.3 Derived model definition . 26
9.7 Multilevel sensor command class water flow . 27
9.7.1 Derived model . 27
9.7.2 Property definition . 27
9.7.3 Derived model definition . 28
9.8 Multilevel switch command class . 29
9.8.1 Derived model . 29
9.8.2 Property definition . 29
9.8.3 Derived model definition . 29
9.9 Notification command class . 30
9.9.1 Derived model . 30
9.9.2 Property definition . 30
9.9.3 Derived model definition . 31
9.10 User code command class . 33
9.10.1 Derived model . 33
9.10.2 Property definition . 33
9.10.3 Derived model definition . 34

iv © ISO/IEC 2021 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described in
the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO list
of patent declarations received (see www.iso.org/patents) or the IEC list of patent declarations received
(see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not constitute
an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see  www.iso.org/iso/foreword.html. In
the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the Open Connectivity Foundation (OCF) (as OCF Resource to Z-Wave
Mapping, version 2.2.0) and drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS
procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.
A list of all parts in the ISO/IEC 30118 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2021 – All rights reserved v

Introduction
This document, and all the other parts associated with this document, were developed in response to
worldwide demand for smart home focused Internet of Things (IoT) devices, such as appliances, door
locks, security cameras, sensors, and actuators; these to be modelled and securely controlled, locally
and remotely, over an IP network.
While some inter-device communication existed, no universal language had been developed for the
IoT. Device makers instead had to choose between disparate frameworks, limiting their market share,
or developing across multiple ecosystems, increasing their costs. The burden then falls on end users
to determine whether the products they want are compatible with the ecosystem they bought into, or
find ways to integrate their devices into their network, and try to solve interoperability issues on their
own.
In addition to the smart home, IoT deployments in commercial environments are hampered by a lack
of security. This issue can be avoided by having a secure IoT communication framework, which this
standard solves.
The goal of these documents is then to connect the next 25 billion devices for the IoT, providing secure
and reliable device discovery and connectivity across multiple OSs and platforms. There are multiple
proposals and forums driving different approaches, but no single solution addresses the majority of
key requirements. This document and the associated parts enable industry consolidation around a
common, secure, interoperable approach.
ISO/IEC 30118 consists of eighteen parts, under the general title Information technology — Open
Connectivity Foundation (OCF) Specification. The parts fall into logical groupings as described herein:
– Core framework
– Part 1: Core Specification
– Part 2: Security Specification
– Part 13: Onboarding Tool Specification
– Bridging framework and bridges
– Part 3: Bridging Specification
– Part 6: Resource to Alljoyn Interface Mapping Specification
– Part 8: OCF Resource to oneM2M Resource Mapping Specification
– Part 14: OCF Resource to BLE Mapping Specification
– Part 15: OCF Resource to EnOcean Mapping Specification
– Part 16: OCF Resource to UPlus Mapping Specification
– Part 17: OCF Resource to Zigbee Cluster Mapping Specification
– Part 18: OCF Resource to Z-Wave Mapping Specification
– Resource and Device models
– Part 4: Resource Type Specification
– Part 5: Device Specification
vi © ISO/IEC 2021 – All rights reserved

– Core framework extensions
– Part 7: Wi-Fi Easy Setup Specification
– Part 9: Core Optional Specification
– OCF Cloud
– Part 10: Cloud API for Cloud Services Specification
– Part 11: Device to Cloud Services Specification
– Part 12: Cloud Security Specification

© ISO/IEC 2021 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 30118-18:2021(E)

Information technology — Open Connectivity
Foundation (OCF) Specification —
Part 18:
OCF resource to Z-wave mapping specification
1 Scope
This document provides detailed mapping information between Z-Wave and OCF defined Resources.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 30118-1 Information technology – Open Connectivity Foundation (OCF) Specification – Part 1:
Core specification
https://www.iso.org/standard/53238.html
Latest version available at: https://openconnectivity.org/specs/OCF_Core_Specification.pdf
ISO/IEC 30118-2 Information technology – Open Connectivity Foundation (OCF) Specification – Part 2:
Security specification
https://www.iso.org/standard/74239.html
Latest version available at: https://openconnectivity.org/specs/OCF_Security_Specification.pdf
ISO/IEC 30118-3 Information technology – Open Connectivity Foundation (OCF) Specification – Part 3:
Bridging specification
https://www.iso.org/standard/74240.html
Latest version available at: https://openconnectivity.org/specs/OCF_Bridging_Specification.pdf
Derived Models for Interoperability between IoT Ecosystems, Stevens & Merriam, March 2016
https://www.iab.org/wp-content/IAB-uploads/2016/03/OCF-Derived-Models-for-Interoperability-
Between-IoT-Ecosystems_v2-examples.pdf
Z-Wave Plus Device and Command Class Types Specification
https://www.silabs.com/documents/login/miscellaneous/SDS11847-Z-Wave-Plus-Device-Type-
Specification.pdf
Z-Wave Plus v2 Device Type Specification
https://www.silabs.com/documents/login/miscellaneous/SDS14224-Z-Wave-Plus-v2-Device-Type-
Specification.pdf
© ISO/IEC 2021 – All rights reserved 1

3 Terms, definitions, symbols and abbreviated terms
For the purposes of this document, the terms and definitions given in ISO/IEC 30118-1,
ISO/IEC 30118-2, and ISO/IEC 30118-3 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
– ISO Online browsing platform: available at https://www.iso.org/obp
– IEC Electropedia: available at http://www.electropedia.org/
3.1 Terms and definitions
3.1.1
Command Class
collection of commands used for controlling, querying, and reporting information corresponding to
specific function supported by a Z-Wave device.
4 Document conventions and organization
4.1 Conventions
In this document a number of terms, conditions, mechanisms, sequences, parameters, events, states,
or similar terms are printed with the first letter of each word in uppercase and the rest lowercase (e.g.,
Network Architecture). Any lowercase uses of these words have the normal technical English meaning.
In this document, to be consistent with the IETF usages for RESTful operations, the RESTful operation
words CRUDN, CREATE, RETRIVE, UPDATE, DELETE, and NOTIFY will have all letters capitalized.
Any lowercase uses of these words have the normal technical English meaning.
4.2 Notation
In this document, features are described as required, recommended, allowed or DEPRECATED as
follows:
Required (or shall or mandatory).
These basic features shall be implemented to comply with the Mapping Specification. The phrases
"shall not", and "PROHIBITED" indicate behavior that is prohibited, i.e. that if performed means the
implementation is not in compliance.
Recommended (or should).
These features add functionality supported by the Mapping Specification and should be
implemented. Recommended features take advantage of the capabilities the Mapping Specification,
usually without imposing major increase of complexity. Notice that for compliance testing, if a
recommended feature is implemented, it shall meet the specified requirements to be in compliance
with these guidelines. Some recommended features could become requirements in the future. The
phrase "should not" indicates behavior that is permitted but not recommended.
Allowed (or allowed).
These features are neither required nor recommended by the Mapping Specification, but if the
feature is implemented, it shall meet the specified requirements to be in compliance with these
guidelines.
2 © ISO/IEC 2021 – All rights reserved

Conditionally allowed (CA)
The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is allowed, otherwise it is not allowed.
Conditionally required (CR)
The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is required. Otherwise the definition or behaviour is allowed as default
unless specifically defined as not allowed.
DEPRECATED
Although these features are still described in this document, they should not be implemented except
for backward compatibility. The occurrence of a deprecated feature during operation of an
implementation compliant with the current document has no effect on the implementation’s
operation and does not produce any error conditions. Backward compatibility may require that a
feature is implemented and functions as specified but it shall never be used by implementations
compliant with this document.
Strings that are to be taken literally are enclosed in "double quotes".
Words that are emphasized are printed in italic.
5 Theory of operation
5.1 Interworking approach
The interworking between Z-Wave defined Command Classes and OCF defined Resources is modelled
using the derived model syntax described in Derived Models for Interoperability between IoT
Ecosystems.
5.2 Mapping syntax
5.2.1 Introduction
Within the defined syntax for derived modelling used by this document there are two blocks that define
the actual Property-Property equivalence or mapping. These blocks are identified by the keywords "x-
to-ocf" and "x-from-ocf". Derived Models for Interoperability between IoT Ecosystems does not define
a rigid syntax for these blocks; they are free form string arrays that contain pseudo-coded mapping
logic.
Within this document we apply the rules in defined in clause 5.2 to these blocks to ensure consistency
and re-usability and extensibility of the mapping logic that is defined.
5.2.2 General
All statements are terminated with a carriage return.
5.2.3 Value assignment
The equals sign (=) is used to assign one value to another. The assignee is on the left of the operator;
the value being assigned on the right.
© ISO/IEC 2021 – All rights reserved 3

5.2.4 Property naming
All Property names are identical to the name used by the original model; for example, from the OCF
Temperature Resource the Property name "temperature" is used whereas when referred to the derived
ecosystem then the semantically equivalent Property name is used.
The name of the OCF defined Property is prepended by the ecosystem designator "ocf" to avoid
ambiguity (e.g. "ocf.step")
5.2.5 Range
The range on the OCF side is fixed.
5.2.6 Arrays
An array element is indicated by the use of square brackets "[]" with the index of the element contained
therein, e.g. range [1]. All arrays start at an index of 0.
5.2.7 Default mapping
There are cases where the specified mapping is not possible as one or more of the Properties being
mapped is optional in the source model. In all such instances a default mapping is provided. (e.g.
"transitiontime = 1")
5.2.8 Conditional mapping
When a mapping is dependent on the meeting of other conditions then the syntax:
If "condition", then "mapping".
is applied.
E.g. if onoff = false, then ocf.value = false
5.2.9 Method invocation
The invocation of a command from the derived ecosystem as part of the mapping from an OCF
Resource is indicated by the use if a double colon "::" delimiter between the applicable resource,
service, interface or other construct identifier and the command name. The command name always
includes trailing parentheses which would include any parameters should they be passed.
6 Z-Wave translation
6.1 Operational scenarios
6.1.1 Introduction
The overall goals are to:
– make Bridged Z-Wave Servers appear to OCF Clients as if they were native OCF Servers in the
local network or cloud environment
“Deep translation” between a specific Z-Wave device and an OCF Device is specified in clause 9. “On-
the-fly” translation is out of scope (refer to clause 5.1 “Deep translation” vs. “on-the-fly” of
ISO/IEC 30118-3).
4 © ISO/IEC 2021 – All rights reserved

Z-Wave Bridging
Function
6.1.2 Overview of OCF-Z-Wave bridging
An OCF Z-Wave Bridge Platform provides the bridging function between an OCF Client and a Bridged
Z-Wave Server. The asymmetric bridging is applied to Z-Wave Bridging Function. Z-Wave Bridging
Function is performing the translation to or from the Z-Wave Protocol. The Z-Wave Bridge Platform
exposes Bridged Z-Wave Servers to OCF Clients and any OCF Cloud. A Bridged Z-Wave Server
provides Z-Wave specific data via the Z-Wave protocol for a Virtual Bridged Z-Wave Client. Figure 1
presents the overview of an OCF Z-Wave Bridge Platform and its general topology.
OCF Bridge
Platform
Virtual
Virtual
Bridged
Bridged
OCF Z-Wave
OCF
Z-Wave
Client Z-Wave Protocol
Server
Server
Client
Figure 1 – OCF Z-Wave Bridge Platform and Components
6.1.3 Use case for OCF Client and Z-Wave server
A use case for an OCF Client and Z-Wave Server is presented in Figure 2. A smartphone device acting
as the OCF Client is allowed to send commands for controlling, querying and reporting the information
of Z-Wave devices via an OCF Z-Wave Bridge Platform. For that, Z-Wave Server devices such as door
locks with a keypad and light dimmer switch are represented as virtual OCF Z-Wave server devices on
an OCF Z-Wave Bridge Platform. Any connectivity that OCF supports is used to communicate between
OCF Client and an OCF Z-Wave Bridge. Furthermore, an OCF Client can also communicate with an
OCF Z-Wave Bridge Platform via an OCF Cloud.

Figure 2 – OCF Client and Z-Wave Server
6.2 Requirements specific to Z-Wave bridging function
6.2.1 Requirements specific to Z-Wave
The version of Z-Wave device type for OCF Z-Wave Bridging shall be Z-Wave Plus or Z-Wave Plus v2.
The Z-Wave Bridging Function shall act as Z-Wave Controller which sets up and performs maintenance
operations such as inclusion and exclusion of devices in a Z-Wave network.
© ISO/IEC 2021 – All rights reserved 5

6.2.2 Exposing Z-Wave servers to OCF clients
6.2.2.1 General
The translation rule between Z-Wave and OCF data model is described in Table 1. The nature of how
Z-Wave devices are structured may be different than how an OCF Device is structured. For example,
Light Dimmer Switch is mapped to OCF Light with the device type "oic.d.light" and a Sensor – Multilevel
and a Sensor – Notification is mapped to OCF Sensors with the Device Type "oic.d.sensor". A Z-Wave
Command Class may be mapped to one or more OCF Resources. For instance, Multilevel Switch
Command Class is mapped to OCF binary switch and dimming light. Each Command Class parameter
is conditionally required to be mapped to a Property of an OCF Resource.
Table 1 – Translation Rule between Z-Wave and OCF data model
From Z-Wave Mapping To OCF Mapping
count count
Z- Wave Plus Device Type n OCF Device 1
Command Class 1 OCF Resource n
Parameter 1 OCF Resource property 1
Table 2 is a mapping example of this rule.
Table 2 – Z-Wave  OCF mapping example (Light Dimmer Switch)
Z-Wave OCF
Z- Wave Plus Device Light Dimmer Switch OCF Device "oic.d.light"
Type
(Light)
Command Class Multilevel Switch Command OCF Resource(s) "oic.r.switch.binary"
Class
(Value)
(Multilevel Switch
"oic.r.light.dimming"
Set/Get/Report)
(dimmingSetting)
Manufacturer Specific Command "oic.wk.d" (Device)
Class
"oic.wk.p" (Platform)
(Manufacturer Specific
Get/Report)
Version Command Class
(Version Get/Report)
Z-Wave Plus Info Command
Class
(Z-Wave Plus Info Get/Report)
Z-Wave Command Value OCF Resource "value"
Parameter Property
(255 or 0) (True or False)
Value "dimmingSetting"
(1~99) (Integer)
6 © ISO/IEC 2021 – All rights reserved

If Z-Wave Plus device, Z-Wave Command Class, Z-Wave Command Parameter are enlisted in the well-
defined set as specified in OCF Z-Wave Data Model Mapping, Bridging Function shall follow the
requirements for translating it to an OCF device, OCF resource or OCF resource property (i.e., “deep
translation”).
A Z-Wave Server device maps to a single OCF Device Type. The OCF Device Type is provided by
using the Device identifier of the Z-Wave Server device. Z-Wave Bridging Function has a table which
includes the mapping information between the Z-Wave device identifier and the OCF Device Type.
Based on the table, the Z-Wave Bridging Function finds the Device Type according to the Z-Wave
device identifier.
A Z-Wave device includes one or more Z-Wave Command Class. If a Z-Wave Command Class maps
to resource type on a single OCF resource, there should be a single Virtual OCF Resource. If a Z-
Wave Command Class maps to multiple OCF resource, an OCF resource may exist with an OCF
Resource Type of [“oic.wk.col”] which is a Collection of links. The links in the collection are the
Resources with translated Resource Types. The resource mapping between Z-Wave Server and OCF
Resources is defined clause 8. The Z-Wave Bridging Function have a table which includes the mapping
information between the identifier of Command Class and OCF Resource Type(s). After a virtual
Bridged Z-Wave Client and Bridged Z-Wave Server device have done the inclusion procedure as
specified in the Z-Wave Plus Device and Command Class Types Specification, a Z-Wave Bridging
Function obtains the list of Command Class identifiers. Based upon the table, a Z-Wave Bridging
Function finds the matched OCF Resource Type(s) according to the identifier of Z-Wave Command
Class.
Since the Bridging Function knows all relationships between OCF Resources and Z-Wave servers, the
path component of URI can be freely chosen. To maintain the relationship information and URI
definition is implementation specific.
If a Z-Wave operation fails, the Bridging Function sends an appropriate OCF error response to the
OCF Client. It constructs an appropriate OCF error message (e.g., diagnostic payload if using CoAP)
from the Z-Wave enumerated status value and Z-Wave error message (if any), using the form " name>: ", with the and taken from the Z-Wave error
message and the error code for the OCF network set to an appropriate value.
6.2.2.2 Translation for well-defined set
Table 3 is the list of Z-Wave Plus device types which have corresponding OCF Resources.
Table 3 – Z-Wave Device & Command Class – OCF Device & Resource mapping
Z- Wave Plus Z-Wave Command OCF Resource Type OCF Device Type OCF Device Name
Device Class
Light Dimmer Multilevel Switch oic.r.switch.binary oic.d.light Light
Switch Command Class
Multilevel Switch oic.r.light.dimming
Command Class
Manufacturer Specific oic.wk.d
Command Class
oic.wk.p
Version Command Class
Z-Wave Plus Info
Command Class
© ISO/IEC 2021 – All rights reserved 7

Z- Wave Plus Z-Wave Command OCF Resource Type OCF Device Type OCF Device Name
Device Class
Door Lock – Door Lock Command oic.r.lock.status oic.d.smartlock Smart Lock
Keypad Class
User Code Command oic.r.lock.code
Class
Battery Command Class oic.r.energy.battery.
Manufacturer Specific oic.wk.d
Command Class
oic.wk.p
Version Command Class
Z-Wave Plus Info
Command Class
On/Off Power Binary Switch Command oic.r.switch.binary oic.d.switch Switch
Switch Class
Battery Command Class oic.r.energy.battery.
Manufacturer Specific oic.wk.d
Command Class
oic.wk.p
Version Command Class
Z-Wave Plus Info
Command Class
Sensor - Multilevel Sensor oic.r.sensor.carbondio oic.d.sensor Generic Sensor
Multilevel Command Class xide
Multilevel Sensor oic.r.sensor.carbonmo
Command Class noxide
Multilevel Sensor oic.r.sensor.water
Command Class
Multilevel Sensor oic.r.sensor.smoke
Command Class
Battery Command Class oic.r.energy.battery.
Manufacturer Specific oic.wk.d
Command Class
oic.wk.p
Version Command Class
Z-Wave Plus Info
Command Class
Sensor - Notification Command oic.r.sensor.carbondio oic.d.sensor Generic Sensor
Notification Class xide
Notification Command oic.r.sensor.carbonmo
Class noxide
Notification Command oic.r.sensor.water
Class
Notification Command oic.r.sensor.smoke
Class
Battery Command Class oic.r.energy.battery.
Manufacturer Specific oic.wk.d
Command Class
oic.wk.p
Version Command Class
Z-Wave Plus Info
Command Class
Z-Wave Plus v2 device types which are equivalently mapped to the Z-Wave Plus device types that
supports deep translation are should be translated as specified in the table as well.
8 © ISO/IEC 2021 – All rights reserved

6.2.2.3 Exposing a Z-Wave server as a virtual OCF server
Table 4 shows how OCF Device properties, as specified in ISO/IEC 30118-1, shall be derived, typically
from fields of Command Parameter of Z-Wave Command Classes specified in Z-Wave Plus Device and
Command Class Types Specification. As specified in ISO/IEC 30118-2, the value of the “di” property
of OCF Devices (including Virtual OCF Devices) shall be established as part of on-boarding of that
Virtual OCF Device.
Table 4 – "oic.wk.d" Resource Type definition
To OCF OCF OCF OCF From Z-Wave Z-Wave Description Z-Wave
Property title Property Description Mandat Field name Mandatory*
name ory
(Device) Name n Human friendly Y Translate Product ID Product ID: a unique ID Product ID: Y
name to Human friendly identifying the actual
For example, name based upon product as defined by
“Bob’s the Product the manufacturer for
Thermostat” ID/product name each product of a given
table within Z-Wave product type.
Controller Defined in Manufacturer
Specific Command
Class
Spec Version icv Spec version of Y (none) Bridge Platform should
ISO/IEC 30118-1 return its own value
this device is
implemented to,
The syntax is
"core.major.mino
r”]
Device ID di Unique identifier Y (none) Use as defined in
for Device. This ISO/IEC 30118-2
value shall be as
defined in
ISO/IEC 30118-2
for Device ID.
Protocol- piid Unique identifier Y (none) Bridging Function should
Independent ID for OCF Device return a random-
(UUID) generated UUID as
specified in the section
4.4 of IETF RFC 4122
Data Model dmv Spec version(s) of Y (none) Bridge Platform should
Version the vertical return its own value
specifications this
device data model
is implemented to.
The syntax is a
comma separated
list of
".major.
minor”].
is the name of the
vertical (i.e. sh for
Smart Home)
© ISO/IEC 2021 – All rights reserved 9

To OCF OCF OCF OCF From Z-Wave Z-Wave Description Z-Wave
Property title Property Description Mandat Field name Mandatory*
name ory
Localized ld Detailed N (none)
Descriptions description of the
Device, in one or
more languages.
This property is an
array of objects
where each object
has a "language"
field (containing an
RFC 5646
language tag) and
a "value" field
containing the
device description
in the indicated
language.
Software sv Version of the N Firmware 0 Version Dedicated to the Z-Wave N
Version device software. chip firmware as defined
by the manufacturer
which assigns a version
number
Defined in Version
Command Class
Manufacturer dmn Name of N Translate Manufacturer ID: the Y
Name manufacturer of Manufacturer ID to unique ID identifying the
the Device, in one Human friendly name manufacturer of the
or more based upon the device.
languages. Manufacturer Defined in Manufacturer
ID/Manufacturer Specific Command
This property is an
name table within Z- Class
array of objects
Wave Controller
where each object
has a "language"
field (containing an
RFC 5646
language tag) and
a "value" field
containing the
manufacturer
name in the
indicated
language.
Model Number dmno Model number as N Product ID A unique ID identifying Y
designated by the actual product as
manufacturer. defined by the
manufacturer for each
product of a given
product type.
Defined in Manufacturer
Specific Command
Class
Table 5 shows how OCF Device Configuration properties, as specified in ISO/IEC 30118-1, shall be
derived:
10 © ISO/IEC 2021 – All rights reserved

Table 5 – "oic.wk.con" Resource Type definition
To OCF OCF OCF Description OCF From Z-Wave Field Z-Wave Z-Wave
Property Property Mand name Description Mandatory*
title name atory
(Device) n Human friendly Y Translate Product ID to Product ID: a Product ID:
Name name Human friendly name unique ID Y
For example, “Bob’s based upon the Product identifying the
Thermostat” ID/product name table actual product as
within Z-Wave Controller defined by the
manufacturer for
each product of a
given product type
Defined in
Manufacturer
Specific Command
Class
Location loc Provides location N (none)
information where
available.
Location locn Human friendly N (none)
Name name for location
For example, “Living
Room”.
Currency c Indicates the N (none)
currency that is used
for any monetary
transactions
Region r Free form text N (none)
Indicating the
current region in
which the device is
located
geographically. The
free form text shall
not start with a quote
(").
Localize ln Human-friendly N Translate Product ID to Product ID: a Product ID:
d Names name of the Device, Human friendly name unique ID Y
in one or more based upon the Product identifying the
languages. This ID/product name table actual product as
property is an array within Z-Wave Controller defined by the
of objects where manufacturer for
each object has a each product of a
"language" field given product type
(containing an RFC Defined in
5646 language tag) Manufacturer
and a "value" field Specific Command
containing the Class
device name in the
indicated language.
If this property and
the Device Name (n)
property are both
supported, the
Device Name (n)
value shall be
included in this
array.
Default dl The default language N Language Specify the N
language settings
Languag supported by the
e Device, specified as on a device
an RFC 5646 Defined in
language tag. By Language
default, clients can Command Class
treat any string
property as being in
this language unless
the property
specifies otherwise.
© ISO/IEC 2021 – All rights reserved 11

Table 6 shows how OCF Platform properties, as specified in ISO/IEC 30118-1, shall be derived,
typically from fields of Command Parameter of Z-Wave Command Class specified in the Z-Wave Plus
Device and Command Class Types Specification.
Table 6 – "oic.wk.p" Resource Type definition
To OCF OCF OCF Description OCF From Z-Wave Field name Z-Wave Z-
Property Property Mand Description Wave
title name atory Mand
atory
Platform ID pi Unique identifier for Y (none) Bridging Function
the physical platform should return a
(UIUID); random-generated
this shall be a UUID UUID as specified in
in accordance with the section 4.4 of IETF
IETF RFC 4122. It is RFC 4122.
recommended that
the UUID be created
using the random
generation scheme
(version 4 UUID)
specific in the RFC.
Manufacturer mnmn Name of Y Translate Manufacturer ID to Manufacturer ID: the Y
Name manufacturer (not to Human friendly name based unique ID identifying
exceed 16 upon the Manufacturer the manufacturer of the
characters) ID/Manufacturer name table device.
within Z-Wave Controller Defined in
Manufacturer Specific
Command Class
Manufacturer mnml URL to N (none)
Details Link manufacturer (not to
(URL) exceed 32
characters)
Model mnmo Model number as N Product ID A unique ID Y
Number designated by identifying the actual
manufacturer product as defined
by the manufacturer
for each product of a
given product type
Defined in
Manufacturer
Specific Command
Class
Date of mndt Manufacturing date N (none)
Manufacture of device
Platform mnpv Version of platform – N (none)
Version string (defined by
manufacturer)
OS Version mnos Version of platform N (none)
resident OS – string
(defined by
manufacturer)
Hardware mnhw Version of platform N Hardware Version A value which is Y
Version hardware unique to this
particular version of
the product
Defined in Version
Command Class
Firmware mnfv Version of device N Firmware 0 Version Dedicated to the Z- N
version firmware Wave chip firmware
as defined by the
manufacturer which
assigns a version
number
Defined in Version
Command Class
12 © ISO/IEC 2021 – All rights reserved

To OCF OCF OCF Description OCF From Z-Wave Field name Z-Wave Z-
Property Property Mand Description Wave
title name atory Mand
atory
Support link mnsl URI that points to N (none)
support information
from manufacturer
SystemTime st Reference time for N (none)
the device
Vendor ID vid Vendor defined N (none)
string for the
platform.
The string is
freeform and up to
the vendor on what
text to populate it.
6.2.2.4 On-the-fly translation
If a Z-Wave Plus device is not listed in the well-defined set, a Z-Wave Bridging Function shall not
translate it.
7 Device type mapping
7.1 Introduction
This clause contains the mappings to Device Types.
7.2 Z-Wave device types to OCF device types
Table 7 captures the mapping between Z-Wave Plus defined Device Types (see Z-Wave Plus v2 Device
Type Specification) and OCF defined Device Types.
Table 7 – Z-Wave to OCF Device Type Mapping
Classification of Z-Wave Z-Wave Device Type Z-Wave OCF Device Type
Generic Type Device
Type ID
Multilevel Switch Light Dimmer Switch 0x01 oic.d.light
Entry Control DoorLock - Keypad 0x03 oic.d.smartlock
Binary Switch On/Off Power Switch 0x01 oic.d.switch
Multilevel Sensor Sensor - Multilevel 0x01 oic.d.sensor
Notification Sensor Sensor - Notification 0x01 oic.d.sensor
Z-Wave Plus v2 device types are equivalently mapped to the Z-Wav
...