IEC 62394:2006

INTERNATIONAL IEC
STANDARD 62394
First edition
2006-06
Service diagnostic interface for consumer
electronics products and networks –
Implementation for ECHONET
Reference number
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.
Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD 62394
First edition
2006-06
Service diagnostic interface for consumer
electronics products and networks –
Implementation for ECHONET
 IEC 2006  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale XA
International Electrotechnical Commission
МеждународнаяЭлектротехническаяКомиссия
For price, see current catalogue

– 2 – 62394  IEC:2006(E)
CONTENTS
FOREWORD.4
INTRODUCTION.6

1 Scope.7
2 Normative references .7
3 Terms, definitions and abbreviations .8
3.1 Terms and definitions .8
3.2 Abbreviations .8
4 Different types of service diagnostics .8
4.1 Stand-alone products .8
4.2 Facilities or household appliances network.8
4.3 Remote diagnosis.9
5 SDI requirements .9
5.1 Hardware .9
5.2 Software.9
6 Tester software requirements .10
6.1 Reading the property diagnostic unit .10
7 Control protocol.11
7.1 Message structure (frame format).11
8 ECHONET objects: detailed specifications .40
8.1 Basic concept.40
8.2 ECHONET properties: basic specifications .41
8.3 Device object super class specifications.43
9 Supplementary information .49
9.1 Property map description format.49
9.2 All router data description format.50
9.3 Instance list description format .50
9.4 Class list description format .50

Figure 1 – ECHONET frame for plain data format .12
Figure 2 – EHD detailed specifications.13
Figure 3 – Configuration of SEA and DEA when an individual address is specified .14
Figure 4 – DEA (broadcast-stipulated) address configuration .14
Figure 5 – Broadcast target stipulation code .15
Figure 6 – Node group stipulation bit specifications .15
Figure 7 – OHD detailed specifications .16
Figure 8 – EOJ detailed specifications .16
Figure 9 – EPC detailed specifications.18
Figure 10 – ESV detailed specifications .18
Figure 10 – EpESV configuration .32
Figure 12 – Relationship between write request (requiring no response) and write
"process-not-possible" response.35
Figure 13 – Relationship among write request (requiring a response), write "accepted"
response, and write "process-not-possible" response .36

62394  IEC:2006(E) – 3 –
Figure 14 – Relationship among read request (requiring a response), read "accepted"
response, and read "process not possible" response .38
Figure 15 – Relationship between notification request and notification response.38
Figure 16 – Relationship between property value notification (requiring a response)
and property value notification response.39
Figure 17 – Processing target property counter for three requests .39
Figure 18 – Property data counter.40

Table 1 – List of class group codes.17
Table 2 – List of ESV codes for requests .20
Table 3 – List of ESV codes for response/notification.20
Table 4 – List of ESV codes for “response-not-possible” responses .21
Table 5 – List of CpESV codes for request/notification.34
Table 6 – List of CpESV codes for "accepted" response .34
Table 7 – List of CpESV codes for "process-not-possible" response .34
Table 8 – Data types, data sizes, and overflow/underflow codes.42
Table 9 – List of device object super class configuration properties .44
Table 10 – Relationship between the space name of the installation location and the
assigned bit .46
Table 11 – Fault content property value assignments.47

– 4 – 62394  IEC:2006(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
SERVICE DIAGNOSTIC INTERFACE FOR CONSUMER
ELECTRONICS PRODUCTS AND NETWORKS –
IMPLEMENTATION FOR ECHONET
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62394 has been prepared by IEC technical committee 100: Audio,
video and multimedia systems and equipment.
The text of this standard is based on the following documents:
FDIS Report on voting
100/1077/FDIS 100/1102/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

62394  IEC:2006(E) – 5 –
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

– 6 – 62394  IEC:2006(E)
INTRODUCTION
Consumer products are often repaired by service workshops, which service a wide range of
products developed by different manufacturers.
For highly complex products, fault diagnosis becomes increasingly difficult and time-
consuming. To make diagnosis possible, manufacturers often develop built-in diagnostic
software, which can be used for fault-finding together with an external diagnostic unit through
a service diagnostic interface (SDI).
To avoid the need for a service workshop to purchase several different diagnostic units from
different manufacturers for different products, a standardized SDI is proposed for use by all
manufacturers and in all products in which such diagnostic interfaces are required. The result
will be that only one SDI is needed in the service workshops.
The SDI should also be suitable for diagnosis in a network (facilities or household appliances
network) in which different products from different manufacturers are connected together. The
interface should also allow for future development.
The standard SDI which has to be specified, should
• be usable in future products;
• be easily connectable to a product or a network;
• be cheap;
• not limit product design.
62394  IEC:2006(E) – 7 –
SERVICE DIAGNOSTIC INTERFACE FOR CONSUMER
ELECTRONICS PRODUCTS AND NETWORKS –
IMPLEMENTATION FOR ECHONET
1 Scope
This International Standard specifies requirements for service diagnostic software to be
implemented in products that incorporate a digital interface. It does not specify requirements
for carrying out remote diagnosis or for manufacturer-dependent software.
The SDI requires the use of a controller (exclusive controller or general-purpose controller/PC)
into which service diagnostic software can be loaded. Part of this controller software should
be standardized while another part of this controller software is manufacturer-/product-related.
To reach a common approach in servicing all products from all manufacturers it is necessary
to standardize specific items in the products (device under test (DUT)) as well as in the
diagnostic software on the controller.
The SDI is based upon the ECHONET specification because this interface will be used in
most future products. The use of this connection and existing communication protocols enable
implementation in products at low cost and gives maximum flexibility and efficiency.
The SDI consists of
• the specific hardware and software requirements of the DUT;
• the specific requirements of the controller:
– the service software;
– an ECHONET interface (to be built in if not already present);
• the connection between the controller and the DUT.
This specification is the minimal specification necessary to be able to carry out computerized
diagnosis and covers the standardized software of the controller as well as the standardized
software and provisions in the DUT.
2 Normative references
The following referenced documents are indispensable for the application 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.
ECHONET Specification:2002, Version 2.11

– 8 – 62394  IEC:2006(E)
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
ECHONET specifications
ECHONET specifications were designed to enable the use of various kinds of transmission ®
media (for example, power line, low-power radiofrequency, ETHERNET, Bluetooth ) ®
NOTE Ethernet is a registered trademark of the Xerox Corporation. Bluetooth is a trademark owned by
Bluetooth SIG, Inc.
3.1.12
remote diagnosis
diagnosis of a product via telephone, Internet, etc.
3.2 Abbreviations
EHD ECHONET headers
SEA Source ECHONET address
DEA Destination ECHONET address
EBC ECHONET byte counter
EDATA ECHONET data
OHD Object message header
EOJ ECHONET objects
EPC ECHONET property
ESV ECHONET service
EDT ECHONET property value data
CpESV Compound ECHONET service
DUT Device under test
OEM Original equipment manufacturer
PC Personal computer
ROM Read-only memory
SDI Service diagnostic interface
4 Different types of service diagnostics
4.1 Stand-alone products
For stand-alone products, a connection is made between the diagnostic controller and the
DUT, where the DUT is from any manufacturer and of any type.
4.2 Facilities or household appliances network
In a facilities or household appliances network, a connection is made between the diagnostic
controller and a network of facilities or household appliances. Several different facilities or
household appliances are interconnected and not all of them are necessarily from the same
manufacturer.
62394  IEC:2006(E) – 9 –
In this case, the SDI shall list the products on the network, detect which facilities or appliance
is causing problem, and diagnose the product concerned.
4.3 Remote diagnosis
In addition to the configurations described in 4.1 and 4.2, a link can be made (for example, via
telephone, the Internet, etc.) between the diagnostic controller in the workshop and a
DUT/network at the customer’s home. Therefore, if a product has both an ECHONET interface
and a remote connection capability, this product should be able to transfer the diagnostic data,
as described in this standard, through the remote connection.
5 SDI requirements
The SDI consists of
• hardware and software, both in the DUT and in the test equipment (“tester”);
• the connection between the tester and the DUT.
The total SDI can be divided into the parts described in 5.1 and 5.2.
5.1 Hardware
5.1.1 Tester hardware
The hardware used for testing shall be a controller exclusive computer or general-purpose
controller (for example, desktop or laptop PC) provided with at least one suitable network
interface which enables the transfer of the ECHONET frame, as specified in 7.1, and running
the necessary diagnostic software.
NOTE The minimum specification for the tester hardware depends on the respective tester platform.
5.1.2 Facilities or household appliances network
For the connection between the tester and the DUT, the “facilities or household appliances
network” shall be used. For the diagnosis of the DUT using the network, the tester shall be
connected to the facilities or household appliances network that conforms to the requirements
of 7.1.
5.1.3 DUT hardware
5.1.3.1 General
The DUT shall be provided with at least one network interface which enables the transfer of
the ECHONET frame as specified in 7.1.
5.1.3.2 Facilities or household appliances network
For diagnosis on a network, the tester shall, where possible, be connected to a “facilities or
household appliances network” that conforms to the requirements of 7.1.
5.2 Software
NOTE The software for the SDI can be divided into two parts (tester and DUT) of which each part again can be
divided into mandatory (SDI common) software and non-mandatory (manufacturer-dependent) software.
5.2.1 Tester software
The software platform of the tester shall be able to handle the ECHONET frame as specified
in 7.1.
– 10 – 62394  IEC:2006(E)
The SDI common software on the tester shall have the following functionalities:
a) to initiate a service of “property value read request”, as specified in 7.1.9;
b) to read out the service of “property value read response” and “property value notification”
of all products, as specified in 7.1.9;
c) to display a list of all products connected to the facilities or household appliances network
to which the tester is connected. On the display shall be listed the
• manufacturer code property;
• place-of-business code property;
• product code property;
• serial number property;
• date-of-manufacture roperty;
d) to display an indication of the fault status property which describes the occurrence of an
error in an actual device. The property code used as a property value is 0 × 41 when an
error exists or 0 × 42 when no error exists and is found to be “OK” or “Not OK” as
specified in 8.3.5;
e) to display an indication of the fault content property which describes the content of an
error in an actual device as specified in 8.3.6.
5.2.2 DUT software requirements for the SDI
The DUT shall be able to handle the ECHONET frame as specified in 7.1.
In addition, the SDI common software in the DUT shall be able to
a) run a self-test routine;
b) receive a service of “property value read request” as specified in 7.1.9 which is initiated
by the tester and response a service of “property value read response” as specified in
7.1.9;
c) initiate a service of “property value notification” as specified in 7.1.9.
6 Tester software requirements
6.1 Reading the property diagnostic unit
6.1.1 General
The common application shall be able to retrieve from the SDI-compliant devices and display
the information specified in 6.1.1 to 6.1.3.
6.1.2 General information (product identification)
The manufacturer code property, the place-of-business code property, the product code
property and the serial number property shall be read from the DUT and displayed. These
property data shall always be available as specified in 8.3. The tester shall display this
information for all devices in the system.
NOTE The manufacturer code displayed might not be the same as the name on the physical device.
6.1.3 Diagnosis information
After start-up of the general information software, the diagnosis information shall be displayed.

62394  IEC:2006(E) – 11 –
7 Control protocol
7.1 Message structure (frame format)
The ECHONET specifications were designed to enable the use of various kinds of
transmission media (for example, power line, low-power radiofrequency, ETHERNET,
Bluetooth®). Slow transmission speeds discourage large data transfers, and it is desirable to
reduce the mounting load on simple devices. In the light of this situation, ECHONET specifies
the frame format for the ECHONET communication middleware block to minimize the
message size while fulfilling the requirements of the communications layer structure.
7.1.1 Frame format
Figure 1 shows the content of the ECHONET communication middleware frame format.
Detailed specifications for each message component will be provided in the following
subclauses.
7.1.1.1 Message configuration for exchange between ECHONET communications
processing blocks
In the ECHONET communication middleware specifications, messages exchanged between
ECHONET communications processing blocks are called ECHONET frames. ECHONET frames
are roughly divided into two types depending on the specified EHD: the secure message
format, of which the EDATA section is enciphered, and the plain message format, of which the
EDATA section is not enciphered. The secure message format and the plain message format
are subdivided into three formats depending on the specified EHD (see Table 2). Therefore,
the following six different message formats are available for ECHONET frames.
a) Plain basic message format
Insecure communication is performed so that one message is used to view or change the
contents of one property.
b) Plain compound message format
Insecure communication is performed so that one message is used to view or change the
contents of two or more properties.
c) Plain arbitrary message format
Insecure communication is performed so as to exchange information that complies with
vendor-unique specifications.
d) Secure basic message format
Secure communication is performed so that one message is used to view or change the
contents of one property.
e) Secure compound message format
Secure communication is performed so that one message is used to view or change the
contents of two or more properties.
f) Secure arbitrary message format
Secure communication is performed so as to exchange information that complies with
vendor-unique specifications.
Figure 1 shows the ECHONET frame structure for the plain message format.

– 12 – 62394  IEC:2006(E)
Format III (multiple property
simultaneous control form at
multiple property simultaneous
control format)
Format II (compound
Cp
PDC・・ PDC EPC EDT ・・ EPC EDT
OHD SEOJ DEOJ OPC
data format)
ESV
・ ・
Size of
Size of
request
request Request Request
n
1 n
OHD : object message header    (1B)
SEOJ : specifies source ECHONET Object    (3B)
DEOJ : specifies destination ECHONET Object (3B)
CpESV : compound ECHONET service    (1B)
OPC : number of processed properties    (1B)
PDC : property data counter    (1B)
EPC : ECHONET property    (1B)
EDT : property value data             (max. 245 bytes)
Format I (basic data format)
OHD SEOJ DEOJ EPC ESV EDT
OHD : object message header    (1B)
SEOJ : specifies source ECHONET Object    (3B)
DEOJ : specifies destination ECHONET Object (3B)
EPC : ECHONET property    (1B)
ESV : ECHONET service    (1B)
EDT : property value data            (max. 247 bytes)
(ECHONET frame)
EHD SEA DEA EBC EDAT
EHD : ECHONET message header (1B)
SEA : source ECHONET Address (2B)
DEA : destination ECHONET Address (2B)
EBC : EDATA area byte counter (1B)
EDATA : ECHONET data           (max. 256 bytes)
IEC  1133/06
Figure 1 – ECHONET frame for plain data format

7.1.2 ECHONET headers (EHD)
This subclause provides detailed specifications for the ECHONET header (EHD) shown in
Figures 1 and 2.
62394  IEC:2006(E) – 13 –
b7 b6 b5 b4 b3 b2 b1 b0
１ ＊ ＊ ＊ ＃ ＃ ☆ ☆
EDATA/PEDATA configuration specification
b1:b0=0:0 Message format I (basic message format)
0:1 Message format II (compound message format)
1:0 Message format III (arbitrary message format)
1:1 Reserved for future use
Secure message specification
0: plain message; 1: secure message
DEA code type specification (individual/broadcast)
0: Individual 1: Broadcast
Routing hop counter
Fixed
IEC  1134/06
NOTE When b7=0, b0 to b6 will be specified separately (reserved for future use).

Figure 2 – EHD detailed specifications
The combination of b1 and b0 specifies the message format for EDATA/PEDATA. When b1:b0
= 0:0, it indicates Message Format I (basic message format), which allows one message to
operate on one property of one object. When b1:b0 = 0:1, it indicates Message Format II
(compound message format), which allows one message to operate on two or more properties
of one object. When b1:b0 = 1:0, it indicates Message Format III (arbitrary message format),
of which EDATA/PEDATA section is in an arbitrary format.
Bit b2 indicates whether the EDATA section is enciphered or not. When b2 = 1, it means that
the EDATA section is enciphered. When b2 = 0, it means that the EDATA section is not
enciphered. Detailed information about enciphered and other secure messages is set forth in
Clause 10.
Bit b3 specifies whether the DEA (destination ECHONET address) shown in Figures 3 and 4
is a broadcast address or an individual address. When b3 = 1, it indicates that a broadcast
address is stipulated by the DEA code. When b3 = 0, it indicates that an individual address is
stipulated by the DEA code. Broadcast address codes are discussed in 7.1.3.
Bits b4, b5, and b6 constitute a routing hop counter, which can be manipulated only by
ECHONET routers. When a message received at one subnet of an ECHONET router is
forwarded to another subnet, the counter is incremented. For every transmission from an
ordinary node, a hop count of 0 is used. The relationship between b4, b5, and b6 and the hop
count is shown in the table below. The number of hops can be set to a value between 0 and 7.

b6 b5 b4 Hop count (router passes)
0 0 0 0
0 0 1 1
0 1 0 2
0 1 1 3
1 0 0 4
1 0 1 5
1 1 0 6
1 1 1 7
– 14 – 62394  IEC:2006(E)
7.1.3 Source/Destination ECHONET address (SEA/DEA)
This subclause provides detailed specifications for the source ECHONET address (SEA) and
destination ECHONET address (DEA) shown in Figure 3. Figure 4 shows the configuration of
the source ECHONET address (SEA) and the destination ECHONET address (DEA) prevailing
when an individual address is stipulated by setting b3 of EHD to 0.

1st Byte
2nd Byte
NodeID (1Byte)
NetID (1Byte)
IEC  1135/06
Figure 3 – Configuration of SEA and DEA when an individual address is specified
When b3 of EHD is set to 1 to specify a broadcast, the destination ECHONET address (DEA)
becomes a code indicating a broadcast message for a specific ECHONET address group
(including a general broadcast). The DEA configuration in this case is shown in Figure 4. The
broadcast target stipulation code is shown in Figures 5 and 6.

1st Byte
2nd Byte
NodeID (1Byte)
NetID (1Byte)
Broadcast type Broadcast target stipulation code Remarks
stipulation code
0x00 Specifies the node groups to be targeted for a An intra-domain broadcast. In all
broadcast within all subnets. For node group subnets within a domain, a broadcast is
selection, see Figure 5 sent to the nodes stipulated by the
broadcast target stipulation code
0x01 Specifies the node groups to be targeted for a An intra-own-subnet broadcast. In the
broadcast within its own subnet. For node own subnet, a broadcast is sent to the
group selection, see Figure 5 nodes stipulated by the broadcast target
stipulation code
0x02 All nodes within the subnet having the Net ID A general broadcast within a specified
code stipulated by the "broadcast target subnet. A broadcast is sent to all nodes
stipulation code" are targeted within the subnet stipulated by the
broadcast target stipulation code
Reserved for future use
0x03～0x7F
0x80～0xFF Open to user Used when a system manager will
manage the system in a collective
housing unit or small office building

IEC  1136/06
Figure 4 – DEA (broadcast-stipulated) address configuration

62394  IEC:2006(E) – 15 –
b7 b6 b5 b4 b3 b2 b1 b0
☆ ☆ ☆ ☆ ☆ ☆ ☆ ☆
Broadcast to node group 0 YES/NO
Broadcast to node group 1 YES/NO
Broadcast to node group 2 YES/NO
Broadcast to node group 3 YES/NO
=1: YES
0: NO
Broadcast to node group 4 YES/NO
Broadcast to node group 5 YES/NO
Broadcast to node group 6 YES/NO
Broadcast to node group 7 YES/NO
IEC  1137/06
Figure 5 – Broadcast target stipulation code

0 8 4 C 2 A 6 E 1 9 5 D 3 B 7 F
0         Group 0
4         Group 1
C
2         Group 2
A
6         Group 3
E
1         Group 4
5         Group 5
D
3         Group 6
B
7         Group 7
F
IEC  1138/06
Figure 6 – Node group stipulation bit specifications

7.1.4 ECHONET byte counter (EBC)
EBC Indicates the size of the ECHONET data region (EDATA region) shown in Figure 1. The
size is variable in 1-byte increments. The acceptable EDATA region size ranges from 6 to 256
bytes (0x06 to 0xFF; 0x00 = 256). The lower limit is 6 bytes, which indicates that a message
consists of at least 6 bytes. The reason is that either the SEOJ or the DEOJ needs to be
specified with the EPC to ESV options specified for a plain message. A 6-byte message can
be a message requesting an ESV with the DEOJ specified or a message carrying a "response
of processing impossible" for ESV with the SEOJ specified.
7.1.5 ECHONET data (EDATA)
The DATA region for messages exchanged by the ECHONET communication middleware.
Maximum size: 256 bytes.
– 16 – 62394  IEC:2006(E)
7.1.6 Object message header (OHD)
This subclause provides detailed specifications for the object message header (OHD) shown
in Figure 1. The state in which b1 and b0 are both 0 will never occur.

b7 b6 b5 b4 b3 b2 b1 b0
１ ０ ０ ０ ０ ０ ☆ ☆
Source object stipulation 1:YES 0:NO
Source object stipulation 1:YES 0:NO
All “0” fixed
Fixed (reserved for future use)
IEC  1139/06
NOTE When b6 and b7 have values other than b6 = 0 and b7 = 1, b0 to b5 will have different meanings.
The meanings of bits b0 to b5 when b6 and b7 have values other than b6 = 0 and b7 =1 will be stipulated in the
future (reserved for future use).

Figure 7 – OHD detailed specifications
7.1.7 ECHONET objects (EOJ)
This subclause provides detailed specifications for the source ECHONET object (SEOJ) code
and destination ECHONET object (DEOJ) code shown in Figure 1.

1st Byte 2nd Byte 3rd Byte
b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0
０ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ☆ ☆ ☆ ☆ ☆ ☆ ☆ ☆ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊
X3: instance code
X2: class code
X1: class group code
0: fixed
IEC  1140/06
NOTE The meanings of the bits when b7 of the 1st byte is 1 will be stipulated in the future (reserved for future
use).
Figure 8 – EOJ detailed specifications
ECHONET objects are described using the format [X1.X2] and [X3], with these formats to be
specified as shown below. (However, “.” is used only for descriptive purposes and does not
mean a specific code.) The object class is designated by the combination of X1 and X2, while
X3 shows the class instance. A single ECHONET node may contain more than one instance
of the same class, in which case X3 is used to identify each one.
The specific items in Table 1 were specified on the basis of JEM 1439 (see Clause 9).
Detailed specifications for the objects shown here will be developed over time and, during this
phase, specifications for the objects themselves (i.e., present/not present) will be further
reviewed.
62394  IEC:2006(E) – 17 –
The instance code 0x00 is regarded as a special code (code for specifying all instances).
When a DEOJ for which this code is specified is received, it is handled as a code specifying a
broadcast to all instances of a specified class.

・ X1 : class group code 0x00-0x7F. For details, refer to Table 1.
・ X2 : class code 0x00-0xFF. For detailed examples, refer to Tables 2 to 8.
・ X3 : instance code 0x00-0xFF.
The identifier code is used when more than one of the same
class specified by [X1.X2] exists within the same node.
However, 0x00 is used as a general broadcast to all
instances of class specified with [X1.X2].

Table 1 – List of class group codes
Class group
Group name Remarks
code
Sensor-related device class group
0x00
0x01 Air conditioner-related device class group
0x02 Housing/facility-related device class group Includes lighting
0x03 Cooking/housework-related device class group
0x04 Health-related device class group
Management/control-related device class group
0x05
AV-related device class group
0x06
0x07～0x0C Reserved for future use
0x0D Service class group
0x0E Profile class group
0x0F User definition class group
0x10～0x1F Communications definition class group for stipulation of status notification
method
Communications definition class group for stipulation of setting control
0x20～0x2F
reception method
Communications definition class group for linked settings (action settings)
0x30～0x3F
Communications definition class group for linked settings (trigger settings)
0x40～0x4F
Secure communication access property set-up class
0x50～0x5F
Reserved for future use
0x60～0x7F
7.1.8 ECHONET property (EPC)
This subclause provides detailed specifications for the ECHONET property (EPC) code shown
in Figure 1. The EPC specifies a service target function. Each object stipulated by X1 (class
group code) and X2 (class code), described in 7.1.7, is specified here. (When a specified
object changes, the target function also changes even when the code remains unchanged.
However, the detailed specifications are designed to ensure that, whenever possible, the
same functions will have the same code.) Specific code values for each object are stipulated
in 8.3. These codes correspond to the object property identifiers in the object definitions.

– 18 – 62394  IEC:2006(E)
b7 b6 b5 b4 b3 b2 b1 b0
１ ☆ ☆ ☆ ☆ ☆ ☆ ☆
Stipulated for four regions: shared by all objects;
shared by each object super class; unique to each
object class; and user-defined. (See Table 2.9)
Fixed
IEC  1141/06
NOTE When b7 = 0, the other bits will be defined differently.
Figure 9 – EPC detailed specifications

7.1.9 ECHONET service (ESV)
This subclause provides detailed specifications for the ECHONET service (ESV) code shown
in Figure 1.
b7 b6 b5 b4 b3 b2 b1 b0
０ １ ☆ ☆ ☆ ☆ ☆ ☆
For details see Table 2.10
Fixed
IEC  1142/06
NOTE In cases other than when b7:b6 = 0:1, the meaning of values b0 – b5 will be specified separately.
Figure 10 – ESV detailed specifications
This code stipulates manipulation of the properties stipulated by EPC. The three main kinds of
operations are shown below. There are also two kinds of responses: the “response,” which is
given when the stipulated properties exist; and the “response not possible,” which is given
when the requested properties (including array elements) do not exist or when the stipulated
service cannot be processed.
“Request”/“Response” (response/response not possible)/“Notification”
A “response” is considered to be a reply to a “request” that requires a response; when the
object stipulated in the DEOJ exists, as a rule it is either “response” or “response not
possible” (stipulated processing cannot be accepted, or the stipulated object exists but the
property does not). When the request requires no response and the stipulated object does not
exist, no response is made.
There are two types of "notification": one for transmitting the own-property information
autonomously and the other for sending a response to a notification request. However, these
two types have the same code.
Three specific operations are provided: write (response required/no response required), read,
and notification (notification/notification with response required). The 12 operations shown
below are set in consideration of whether or not the content of the given property is an array.
a) Property value write (response required/no response required)
b) Property value read
c) Property value notification

62394  IEC:2006(E) – 19 –
d) Property value array-element-stipulated write (response required/no response required)
e) Property value array-element-stipulated read
f) Property value array-element-stipulated notification
g) Property value array-element-stipulated addition (response required/no response required)
h) Property value array-element-stipulated deletion (response required/no response required)
i) Property value array-element-stipulated existence confirmation
j) Property value array element addition (response required/no response required)
k) Property value notification (response required)
l) Property value array-element-stipulated notification (response required)
The relationship between the message configuration (presence or absence of SEOJ and
DEOJ) and EPC and ESV is described below.
– The EPC in an ECHONET message stipulating only SEOJ indicates the properties of the
sender object specified in SEOJ. Here, ESV contains an autonomous “notification” or
“notification” or “response” in response to a request for properties specified in SEOJ and
EPC. If ESV is a “request” in such a case, the received message is treated as an illegal
message.
– The EPC in an ECHONET message stipulating only DEOJ indicates the properties of the
destination object specified in DEOJ. Here, ESV contains a “request” regarding the
properties specified in DEOJ and EPC. If ESV is a “response” or a “notification” in such a
case, the received message is treated as an illegal message.
– For ECHONET messages stipulating both SEOJ and DEOJ, the ESV value is used to
determine whether the EPC is stipulated by the SEOJ or the DEOJ. When the ESV is a
“response” or a “notification”, the EPC is considered to be a component of the object
specified by SEOJ and is viewed as a “response” or “notification” directed towards the
object stipulated in the DEOJ. When the ESV is a “request,” the EPC is considered to be a
component of the DEOJ and is viewed as a “request” from the object stipulated in the
SEOJ.
Tables 1 through 3 show specific ESV code assignments based on the content described
above. Specific descriptions of a) through l) above are provided in (1) through (12) of the
remarks column in the relevant table. In the figures given in (1) through (12), the DEOJ for
"requests" is shown as an individually stipulated code. However, when the DEOJ indicates a
broadcast to all instances of a specified class (when the DEOJ's X3 = 0x00), a response is
transmitted with both "process-not-possible" response and "response" configured for each
target instance. Note that in the table, the “array elements” described above are presented as
“elements.”
– 20 – 62394  IEC:2006(E)
Table 2 – List of ESV codes for requests
Service
code ECHONET service content Symbol Remarks
(ESV)
0x60 Property value write request (no response required) SetI (1)
0x61 Property value write request (response required) SetC
0x62 Property value read request Get (2)
0x63 P
...