Generic Profiles V 1 - EnOcean Alliance · System Specification Generic Profiles Specification v1.2...

System Specification

GenericProfilesSpecificationv1.2 Page1/42

GenericProfilesV1.2

SanRamon,CA,USA,June20,2013

ExecutiveSummary

ThisdocumentprovidesthespecificationofGenericProfiles.ThefullspecificationincludestheGenericProfilesappendixdocument.

GenericProfilesarethesuccessorofEnOceanEquipmentProfilesandtargetstheshortcomingsofit.BothEnOceanEquipmentProfilesandGenericProfilesdescribethedatacommunicationof products utilizing The EnOcean Radio Protocol and enables manufacturers to developinteroperable products. The strength of Generic Profiles is to enable devices to have self-describeddynamiccommunication.

With this capability newproducts canbedevelopedwithout submissionof itsprofile to theEnOceanAlliance,allowinganunlimitedvarietyofpossibilities.

Ver. Editor Change Date

1.0 MH Firstrelease 20.6.2013

1.1 MH Finalrelease,removechapterofdevelopment,nochangeincontent

23.07.2018

1.2 MH Editiorialcorrections–TeachInInfoSignalcorrectedto8bits.

10.12.2019

Copyright©EnOceanAllianceInc.2012-2018.AllrightsReserved.



ThisinformationwithinthisdocumentisthepropertyoftheEnOceanAllianceanditsuseanddisclosurearerestricted.ElementsoftheEnOceanAlliancespecificationsmayalsobesubjecttothird party intellectual property rights, including without limitation, patent, copyright ortrademarkrights(suchathirdpartymayormaynotbeamemberoftheEnOceanAlliance.)TheEnOcean Alliance is not responsible and shall not be held responsible in any manner foridentifying or failing to identify any or all such third party intellectual property rights. Thisdocument and the information contained herein are provided on an “as is” basis and theEnOceanAlliancedisclaimsallwarrantiesexpressorimplied,includingbutnotlimitedto(1)anywarranty that the use of the information herein will not infringe any rights of third parties(including any intellectual property rights, patent, copyright or trademark rights, or (2) anyimpliedwarrantiesofmerchantability,fitnessforaparticularpurpose,titleornoninfringement.

InnoeventwilltheEnOceanAlliancebeliableforanylossofprofits,lossofbusiness,losofuseof data, interruption of business, or for any other direct, indirect, special or exemplary,incidental,punitiveorconsequentialdamagesofanykind,incontractorintort,inconnectionwith thisdocumentor the informationcontainedherein,even ifadvisedof thepossibilityofsuchlossordamage.AllCompany,brandandproductnamesmaybetrademarksthatarethesolepropertyoftheirrespectiveowners.

Theabovenoticeandthisparagraphmustbeincludedonallcopiesofthisdocumentthataremade.

TheEnOceanGenericProfilesSpecificationisavailablefreeofchargetocompanies,individualsand institutions for all non-commercial purposes (including educational research, technicalevaluationanddevelopmentofnon-commercialtoolsordocumentation.)

This specification includes intellectual property („IPR“) of the EnOcean Alliance and jointintellectual properties („joint IPR“) with contributing member companies. No part of thisspecificationmay be used in development of a product or service for sale without being aparticipantorpromotermemberoftheEnOceanAllianceand/orjointowneroftheappropriatejointIPR.EnOceanAlliancegrantsnorightstoanythirdpartyIP,patentsortrademarks.

TheseerratamaynothavebeensubjectedtoanIntellectualPropertyreview,andassuch,maycontainundeclaredNecessaryClaims.

EnOceanAllianceInc.

5000ExecutiveParkway,Suite302SanRamon,CA94583

USAGrahamMartinChairman&CEOEnOceanAlliance



Tableofcontent

1. Introduction............................................................................................................................5

1.1. Introduction.................................................................................................................................5

1.2. “Generic”–definition...............................................................................................................5

1.3. Terms&Abbreviations...........................................................................................................6

2. Communicationlayers........................................................................................................8

2.1. Introduction.................................................................................................................................8

2.2. Messagetypes.............................................................................................................................8

2.3. Radiocommunication.............................................................................................................9

2.3.1. Telegramchaining.........................................................................................................................10

2.4. Othercommunicationtypes..............................................................................................11

3. Convention...........................................................................................................................13

3.1. Introduction..............................................................................................................................13

3.2. Approach....................................................................................................................................13

3.3. Parameters................................................................................................................................14

3.3.1. Channelcharacterization............................................................................................................14

3.3.2. ADCparameters..............................................................................................................................15

3.4. Measurementvaluequantization....................................................................................18

3.5. Examples....................................................................................................................................19

3.5.1. Datachanneldefinition...............................................................................................................19

3.5.2. Flagchanneldefinition................................................................................................................20

3.5.3. ENUMchanneldefinition............................................................................................................20

3.5.4. Quantization.....................................................................................................................................20

4. Teach-inProcess................................................................................................................22

4.1. Introduction..............................................................................................................................22



4.2. Procedure..................................................................................................................................22

4.2.1. Generalprocedure.........................................................................................................................22

4.3. Definition...................................................................................................................................23

4.3.1. Teach-inrequest.............................................................................................................................24

Teach-inrequestheader......................................................................................................24

4.3.2. Channeldefinition.........................................................................................................................25

4.3.3. Teach-inresponse..........................................................................................................................26

4.3.4. Channelacknowledgement........................................................................................................29

4.4. Channelindexing....................................................................................................................30

4.5. Messagetimings......................................................................................................................30

4.6. UsingSmartAcknowledgeforcommunication.........................................................31

4.7. Examples....................................................................................................................................32

4.7.1. Teach-inrequestmessage..........................................................................................................32

4.7.2. Teach-inresponsemessage.......................................................................................................34

5. Operationalmode..............................................................................................................36

5.1. Introduction..............................................................................................................................36

5.2. Datamessagedefinition......................................................................................................36

5.2.1. CompleteDatamessage..............................................................................................................37

5.2.2. Selectivedatamessage................................................................................................................37

6. CompatibilitywithEEP...................................................................................................39

6.1. Introduction..............................................................................................................................39

6.2. Coexistence...............................................................................................................................39

6.3. TransitionPlan........................................................................................................................40

7. RemoteManagement.......................................................................................................42



1. Introduction

1.1. Introduction

EnOceanGmbHdevelopedthestructureoftheEnOceanEquipmentProfiles(EEP)toachieveastandardized communication between devices applying EnOcean’s energy harvesting andwireless technology. Based on this structure the EnOcean Alliance created andmaintains asystemspecificationby itsTechnicalWorkingGroup (TWG).This specificationsummarizesallprofilesfordifferentapplicationandimplementationscenariosdevelopedbythemembersoftheEnOceanAlliance.

AgrowingnumberofEEPsandanevenfastertime-to-marketrequirementcreatedtheneedfornew communication architecture between the various devices within an EnOcean wirelessinfrastructure.

In November 2010 the EnOcean Alliance tasked a team within the TWG to draft acommunicationarchitecturewhichcanovercomethechallengesseenfortheupcomingthreetofiveyears.Twoobjectiveswerefollowedupbytheteam–(1)acommunicationarchitectureabletohandlethe largevarietyofsensorsandactuatorswithoutcreatingacomplexsystem,and(2)acommunicationarchitecturewhichrequiresanadministrativeeffortmuchlowerthantoday’sEEP-scheme.

Contributionstothisteamweremadeby• AdHocElectronicsLLC,USA• alphaEOSGmbH,Germany• EnOceanGmbH,Germany• EnOceanInc.,USA• Kieback&PeterGmbH&Co.KG,Germany• ProbareGmbH,Germany• ServodanA/S,Denmark• ThermokonSensortechnikGmbH,Germany

1.2. “Generic”–definition

Theidealobjectivewasa“genericspecification”whichcouldmean:adeviceofamanufacturercommunicates with a device of another manufacturer and the ability to exchange data ispossible.

The pre-requisite for such a “worry-free” communication is either a long “synchronizationperiod” which requires a non-restricted energy source or a well-defined communicationarchitecturewhichenablesbothdevicestoexchangeinformationinacarefullystructuredway,withoutimposingunnecessarylimitsonthedesigners.



Thus,thedegreetowhichaspecificationwillallowfora“generic”implementationofdevicesdepends largely on the intelligence invested in the definition of such a communicationarchitectureandlanguage.

The EnOcean Alliance decided to aim for an architecturewhichminimizes the overhead forproductdesignersandprovidesenoughflexibilityforthenextthreetofiveyears.

ThisdocumentspecifiesthecommunicationarchitectureandthelanguagewhichcanbeappliedbythemembersoftheEnOceanAlliancefortheirfutureproductimplementations.

1.3. Terms&Abbreviations

4BS 4bytesSensortelegram

ADC Analog-to-digitalconverter

ADT AddressedDestinationTelegram

API ApplicationProgrammingInterface

CDM ChainedDataMessage

EEP EnOceanEquipmentProfiles

ERP EnOceanRadioProtocol

ESP EnOceanSerialProtocol

FCC FederalCommunicationsCommission

FW Firmware

GP GenericProfiles

Message Communicationentityconsistingofoneormoretelegrams.

OSI OpenSystemsInterconnectionReferenceModel

RMCC RemoteManagementControlCommand

RPC RemoteProcedureCall

R-ORG RadioOrganizationnumberforEnOceanradiotelegramtypes

TWG TechnicalWorkingGroupoftheEnOceanAlliance

Inbound Incoming-incomingcommunicationfromdescribeddeviceperspective



Outbound Outgoing-outgoingcommunicationfromdescribeddeviceperspective



2. Communicationlayers

2.1. IntroductionComputernetworkprotocolsareusingabstractionlayersforhidingimplementationdetailsfora particular set of functionality. To confine the tasks, abstraction layers for Generic Profilescommunicationareapplied.

GenericProfilecommunicationdefinesthefollowinglayers,similartotheOSIlayermodel:

Layer Services

Application Productspecificsoftwareapplication/GenericProfilemessagegeneration

Presentation Radiotelegramprocessing

Session NotusedforGenericProfiles

Transport NotusedforGenericProfiles

Network Addressingtelegrams/R-ORG/Statusprocessing

FIGURE2.1:LAYERMODELOFGENERICPROFILES

Adoptingsuchaviewofthetasksonewillbeindependentfromtheradio,serialoranyothercommunicationtypetoexchangetheGenericProfilesmessages.

2.2. Messagetypes

GenericProfilesdefinefourdifferentmessagetypesasdescribedinthefollowingtable:

Messagetype Properties Restrictions

Teach-inrequest GenericProfilesTeach-inrequest 512byteslength

Teach-inresponse ResponsetoaGenericProfilesTeach-inrequestmessage(ifbidirectionalcommunication)

512byteslength

Completedata Datamessagecontainingcompletemeasurementdata 512byteslength

Selectivedata Datamessagecontainingselectedpartsofmeasurementdata

512byteslength

TABLE2.1:TYPEOFMESSAGESDEFINEDBYGENERICPROFILES

EachmessagecanbeaddressedtoadestinationID(ADT).



2.3. RadiocommunicationFortheradiocommunicationofGenericProfilesthefollowinglayersaredefined:

Layer Services

ApplicationGeneratesGenericProfilesmessageasabitstreamanddeterminesmessagetype

GenericProfilesAPI SelectsR-ORGandtranslatesmessagetooneormoreradiotelegrams

DolphinAPI Sendsradiotelegram(s)

EnOceanDolphinchip Physicalradiotelegramtransmission

FIGURE2.2:LAYERMODELOFRADIOCOMMUNICATION

Telegramsummary

In the layer “Generic Profiles API” the R-ORG of EnOcean radio telegrams will be selecteddepending on the message type to transmit. If the message exceeds the length of onetelegramthenthemessagewillbesplit intothenecessarynumberof telegramsbytelegramchainingmechanismsdescribedinchapter2.3.1.



R-ORG Telegramtype Properties

0xB0 GP_TI=Teach-inrequest Teach-inmessageupto512byteslength.Allowedtelegramchaining:Broadcast:Unicast:

yesyesno

0xB1 GP_TR=Teach-inresponse ResponsetoaTeach-inmessageupto512byteslength.Allowedtelegramchaining:Broadcast:Unicast:

yesnoyes

0xB2 GP_CD=CompleteData Containsallchanneldataupto512bytespayload.Allowedtelegramchaining:Broadcast:Unicast:

yesyesyes

0xB3 GP_SD=Selectivedata Datamessagecontainingpartsofmeasurementdata.Allowedtelegramchaining:Broadcast:Unicast:

yesyesyes

TABLE2.2:R-ORGAPPLIEDWITHINGENERICPROFILES

2.3.1.TelegramchainingChained radio telegrams are required for a Generic Profilesmessage payload exceeding thepayloadofonetelegram(onEnOceanRadioProtocol1maximumpayloadis13bytesor9bytes,ifitisanADTmessage).SuchamessagewillbesplitintothenecessarynumberoftelegramsbytheEnOceanradiostack.

Example for a chained complete data message with 23 bytes payload with EnOcean RadioProtocol1telegram:



R-ORGCDM

SEQ IDX LEN R-ORGGP_CD

datafield

1stpartofmessage

senderid status crc8

1byte

2bit 6bit 2bytes

1byte

10bytes

4bytes

1byte

1byte

1byte

0x40 0x00 23 0xB2 12345678910 0x00000000 0x00 0xnn

FIGURE2.3:RADIOTELEGRAMSTRUCTUREOFFIRSTCHAINEDTELEGRAM–NOTADDRESSED

R-ORG

CDM

SEQ IDX datafield

2ndpartofmessage

senderid status crc8

1byte

2bit 6bit 13bytes

4bytes

1byte

1byte

1byte

0x40 0x01 111213141516171819202122 0x00000000 0x00 0xnn

FIGURE2.4:RADIOTELEGRAMSTRUCTUREOFSECONDORFURTHERCHAINEDTELEGRAM–NOTADRESSED

NOTE:

Fordetailedexplanationofthefieldsandprocesspleaselookupthe:

DolphinAPIUserManual(Chapter:EnOceanRadioProtocol(ERP)):http://www.enocean.com/fileadmin/redaktion/pdf/download/EO3000I_API_user_manual.zip

EnOceanRadioProtocol(1)Specification:http://www.enocean.com/fileadmin/redaktion/pdf/tec_docs/EnOceanRadioProtocol.pdf

2.4. OthercommunicationtypesTheconceptofusingmessagesinsteadofdefiningtelegramsprovidestheopportunitytouseGenericProfileswithothercommunicationtypesthanradio.

Theavailablelayersmaybeexpandedinthefutureasneeded(e.g.forserialcommunication).



Layer Services

ApplicationGeneratesGenericProfilesmessageasabitstreamanddeterminesmessagetype

GenericProfilesAPI(addedserialsupport)

Createsserialmessage(s)

DolphinAPI Sendsserialmessage(s),e.g.viaESP3

EnOceanDolphinchip Physicalserialtelegramtransmission

FIGURE2.5:LAYERMODELOFSERIALCOMMUNICATION



11001011

Parameters Digital input

Counter

Conversion

. . .

Actual value

OR

ADC

3. ConventionThischapterdescribesGenericProfiles.Itfocusesonthedataexchangebetweendevices,whichistheessentialfunctionofawirelesssensornetwork.

3.1. Introduction

The recent EnOcean Equipment Profiles consist of a set of tables to define each officiallysupporteddeviceanditstransmitteddata.ThespecificdefinitionofadeviceisreferencedbytheEEPnumber(R-ORG,FUNC,TYPE).TheGenericProfilesapproachinsteaddefinesalanguagetocommunicatethetransmitteddatatypesandranges.Thedevicesbecomeselfdescribingontheirdatastructuresincommunication.

Tohandlethehugevarietyofpossibledatathislanguagehastobeversatileandcompact.

3.2. ApproachThedatasentover-the-airisgenerallytheresultofananalogue-to-digitalconversion,thestateofacounterinthetransmittingdeviceoretc.Toconserveenergy,theserawmeasurementsaretransmitteddirectly,usingonlyasmanybitsasthenativeconversionproduced.Todeterminetheactualvalue,itisnecessarytohaveasetofparameterstomapthepuredigitalvaluesintophysical units. Declaring this set of parameters will enable the receiver to recalculate theoriginallymeasuredvalueasapreparationforfurtherprocessing.

TheGenericProfilesincludealanguagedefinitionwithaparameterselectionthatcoverseverypossible measured value to be transmitted. Therefore, the approach does not only defineparametersforthevaluerecalculationalgorithmbutalsoincludesspecificsignaldefinition.(e.g.physicalunits).

Sender Receiver

FIGURE3.1:GENERICDATATRANSMISSION

Foreverymeasurementthesetofparametershastobetransmittedbeforethefirstoperationaldataexchange.ThisisdoneduringtheTeach-inprocess.Usingthisprocessthedevicedescribesitsfuturecommunicationself.



3.3. ParametersThe defined set of parameters describes every aspect of a digital value to enable therecalculationoftheactualphysicalvalue.

Tomathematically reclaimofavalueconversion fromdigital to theactualphysicalvaluetheresolution, the actual minimum and the actual maximum value are needed. For theinterpretationofthatvaluethecharacter(e.g.setpoint,relativeorabsolutemeasurement)oftheoriginalmeasurementhastobeprovided,too.

Note:

All signednumbersused inover-the-air transmissionsarecoded in"two‘scomplement"alsocalled"complement-2"format.

All framesandbytesarecodedasbig-endian,meaningwhensendingorreceivingaseriesofbytes,themostsignificantbyteistransmittedandreceivedfirst.

3.3.1. ChannelcharacterizationAutomatedprocessingofdigitaldataisonlypossibleifallinformationabouttheacquisitiontypeof thereceiveddata isavailable.Throughthisclassificationavaluecanbecombinedwith itsphysical unit and its proposed use. Therefore, three different parameters have to becommunicated:

• channeltype• signaltype• valuetype

‘ChannelType’

Thechanneltypedividesallchannelsintodifferentfunctionalclassesofmeasurements.Withthe three defined channel types ‘data’, ‘flag’ and ‘enumeration’ measurement results andcomplexcountervaluesareseparatedfromsinglebitlogicalchannelsandenumeratedvalues.

Teach-in information is neither a measured value nor used during operational mode. ThischanneltypeisusedonlyduringtheTeach-inprocess.Fordetailedexplanationpleaserefertochapter4.

ChannelType2bitvalue Data

00 = Teach-ininformation Teach-insignals/flags01 = Data Complexbitvalues10 = Flag Singlebitvalue11 = Enumeration Enumeratedvalues

TABLE3.1:CHANNELTYPE



Fordetaileddefinitionofthemeasurablechanneltypesrefertotheappendix,please.

‘SignalType’

Thesignaltypeclassifiestheoriginofthetransmittedvalueitselfanditscharacter(e.g.physicalunitorfieldofuse).Thesignaltypesdifferbetweenthechanneltypes.

Fordetaileddefinitionofthesignaltypesandlistpleaserefertotheappendix,please.

‘ValueType’

ValueType2bitvalue Data

00 = Reserved 01 = Currentvalue10 = Setpointabsolute11 = Setpointrelative

TABLE3.2:VALUETYPE

Withthevaluetypethecontextofacertainvalueshallbedescribed.3.3.2. ADCparametersBesidetheinformationabouttheoriginandpurposeofthechannelitisessentialtotransmitallnecessaryparametersforthedataconversion.

‘Resolution’

Resolution4bitvalue Data,Enumeration

0000 = Reserved 0001 = 2bit0010 = 3bit0011 = 4bit0100 = 5bit0101 = 6bit0110 = 8bit0111 = 10bit1000 = 12bit1001 = 16bit1010 = 20bit1011 = 24bit1100 = 32bit1101 = Reserved1110 = Reserved1111 = Reserved

TABLE3.3:RESOLUTION‘DATA’AND‘ENUMERATION’



Forflagchannelstheresolutionisdefinedas1bit.Thisisanimplicitdefinitionandisvalidforallflagchannels.

Resolution Flag = 1bit

TABLE3.4:RESOLUTION‘FLAG’

‘Engineeringminimum’

Theengineeringminimumrepresentsthebottomofthemeasurementrange.Thetransmittedparameterhastobemultipliedwithitsscalingfactor.

Engineeringminimum8bit Data

= [-128…127] TABLE3.5:ENGINEERINGMINIMUM‘DATA’

Forflagchannelstheengineeringminimum isalwayszero.Thisisanimplicitdefinitionandisvalidforallflagchannels.

Engineeringminimum Flag = 0

TABLE3.6:ENGINEERINGMINIMUM‘FLAG’

‘Scalingminimum’

Toallowforawiderangeofminimumvaluestheengineeringminimumcanbescaledbyoneofthesupportedfactors.



Scalingminimum4bitvalue Data

0000 = Reserved N/A0001 = x1 x10010 = x10 x1e+010011 = x100 x1e+020100 = x1,000 x1e+030101 = x10,000 x1e+040110 = x100,000 x1e+050111 = x1,000,000 x1e+061000 = x10,000,000 x1e+071001 = x0.1 x1e-011010 = x0.01 x1e-021011 = x0.001 x1e-031100 = x0.000001 x1e-061101 = x0.000000001 x1e-091110 = Reserved N/A1111 = Reserved N/A

TABLE3.7:SCALINGMINIMUM‘DATA’

Forflagchannelsthereisnoscalingoption.

Scalingminimum Flag = x1

TABLE3.8:SCALINGMINIMUM‘DATA’

‘Engineeringmaximum’

Theengineeringmaximumworksthesamewayastheengineeringminimum.

Engineeringmaximum8bit Data

= [-128…127] TABLE3.9:ENGINEERINGMAXIMUM‘DATA’

Forflagchannelstheengineeringmaximumisalwaysone.Thisisanimplicitdefinitionandisvalidforallflagchannels.

Engineeringmaximum Flag = 1

TABLE3.10:ENGINEERINGMAXIMUM‘FLAG’



‘Scalingmaximum’

Toallowforawiderangeofmaximumvaluestheengineeringmaximumcanbescaledbyoneofthesupportedfactors.

Scalingmaximum4bitvalue Data

0000 = Reserved N/A0001 = x1 x10010 = x10 x1e+010011 = x100 x1e+020100 = x1,000 x1e+030101 = x10,000 x1e+040110 = x100,000 x1e+050111 = x1,000,000 x1e+061000 = x10,000,000 x1e+071001 = x0.1 x1e-011010 = x0.01 x1e-021011 = x0.001 x1e-031100 = x0.000001 x1e-061101 = x0.000000001 x1e-091110 = Reserved N/A1111 = Reserved N/A

TABLE3.11:SCALINGMAXIMUM‘DATA’

Forflagchannelsthereisnoscalingoption.

Scalingmaximum Flag = x1

TABLE3.12:SCALINGMAXIMUM‘FLAG’

3.4. MeasurementvaluequantizationThemeasurementvaluequantizationshouldfollowtheseequations:

𝑥=actual value

𝑋𝑚𝑖𝑛=actual engineering minimum 𝑋𝑚𝑎𝑥=actual engineering maximum

𝐸𝑛𝑔𝑚𝑖𝑛=scaled engineering minimum 𝐸𝑛𝑔𝑚𝑎𝑥=scaled engineering maximum

𝐹𝑚𝑖𝑛=scaling factor minimum 𝐹𝑚𝑎𝑥=scaling factor maximum

𝑛=quantized value 𝑁=number of steps (bit range)



𝐸𝑛𝑔𝑚𝑖𝑛=𝐹𝑋𝑚𝑖𝑛𝑚𝑖𝑛

𝐸𝑛𝑔𝑚𝑎𝑥=𝐹𝑋𝑚𝑎𝑥𝑚𝑎𝑥

𝑛=𝑁× 𝑥−𝑋𝑚𝑖𝑛𝑋𝑚𝑎𝑥−𝑋𝑚𝑖𝑛

𝑥=𝑛𝑁×(𝑋𝑚𝑎𝑥−𝑋𝑚𝑖𝑛)+𝑋𝑚𝑖𝑛

FIGURE3.2:MEASUREMENTFORMULAS

3.5. Examples3.5.1. Datachanneldefinition

Measurement Channeldefinition

Temperaturesensor

Range:0–40°CResolution:10bit

Purpose:currentvalue

Channeltype: Data 01Signaltype: Temperature 00011000Valuetype: Currentvalue 01

Resolution: 10bit 0111Scaledeng.minimum: 0°C [00000000]2Scalingminimum: x1 0001Scaledeng.maximum: 40°C [00101000]2Scalingmaximum: x1 0001

FIGURE3.3:EXAMPLETEMPERATURESENSORDEFINITION


Concentrationsensor

Range:1–1e+06ppmResolution:32bit


Channeltype: Data 01Signaltype: Concentration 00000101Valuetype: Currentvalue 01

Resolution: 32bit 1100Scaledeng.minimum: 1ppm [00000001]2Scalingminimum: x1 0001Scaledeng.maximum: 1ppm [00000001]2Scalingmaximum: x1e+06 0111

FIGURE3.4:EXAMPLECONCENTRATIONSENSORDEFINITION


Voltmeter

Range:-230–230VResolution:16bit


Channeltype: Data 01Signaltype: Voltage 00011100Valuetype: Currentvalue 01

Resolution: 16bit 1001Scaledeng.minimum: -23V [11101001]2Scalingminimum: x10 0010Scaledeng.maximum: 23V [00010111]2Scalingmaximum: x10 0010



HVACMode Channeltype:Signaltype:Valuetype:

EnumerationHVACModeCurrentvalue

110000010001


FIGURE3.5:EXAMPLEVOLTMETERDEFINITION

3.5.2. FlagchanneldefinitionMeasurement Channeldefinition

Occupancysensor


Channeltype: Flag 10Signaltype: Occupancy 00001001Valuetype: Currentvalue 01

FIGURE3.5:EXAMPLEOCCUPANCYSENSORDEFINITION

3.5.3. ENUMchanneldefinitionMeasurement Channeldefinition

FIGURE3.6:EXAMPLEHVACSTATEINFODEFINITION

3.5.4. QuantizationMeasurement

Temperature measurement

x = 25°C

N = 2^8 = 256

Quantized value

Temp. Range: 0-40°C Resolution: 8 bits

n = 256 * (25 - 0) / (40 – 0) = 160 => 10100000

FIGURE3.7:EXAMPLEQUANTIZATION



Quantized value

Temperature measurement

n = 192 Resolution: 8 bits

N = 2^8 = 256

Actual value

Eng.min. = 0 Scaling min. = 1 Eng. max. = 40

Scaling max. = 1

x = (192 / 256) * (40 * 1 – 0 * 1) + 0 * 1 = 30

FIGURE3.8:EXAMPLERECALCULATIONACTUALVALUE



4. Teach-inProcessTeach-in is the processwhere communication partners exchange information about how tointerpretdatawhichwillbeexchangedinthedatacommunication.ThischapterdescribeshowtoexecutetheTeach-inprocesstoenabledataexchangebasedonGenericProfiles.

4.1. Introduction

Following the guidelines of the defined communication layers and Generic Profiles, everygenericEnOceandevicecanexchangedatawithcompatibledevices.

Therefore,theinterpretationofreceiveddatamessagesisbasedontwoconditions:

1. Generally,themessagehastobeacceptedfirst.ThatmeansthatithastocarryavalidEnOceanIDthatisknownbythereceiveroritcanaddressthereceiversEnOceanID.

2. Thereceiverhastobeawareoftheuserdatastructure.Asthisstructureisalmostinfinitelyvariableduetothegenericapproach,thetransmitterhastotransmititschannelcharacteristicstoo.

TheprocessofconnectingtwoEnOceanradiodevicesandexchanginginitiatinginformationiscalled ‘Teach-in’ and has to be passed before the first operational communication. Anintentional disconnection of this binding, called ‘teach-out’, is also included in the followingdefinition.

AgenericTeach-inprocedureallowsadevicetoconnecttodifferentradiopartners.Itdoesnotpreventthecaseofconnectingtothewrongdevice.

4.2. Procedure

4.2.1. GeneralprocedureThe Teach-in process has a bidirectional character. Therefore, it consists of two consecutivemessages:

• First,afterthereceiverhasbeenswitchedintolearnmode,thetransmitterbroadcastsaTeach-inrequestmessage.

• ThereceiveranswerswithaTeach-inresponsemessagewhichshouldbeaddressedtothetransmitter.

If the receiver hasbidirectional communication capabilities, then it shall transmit a Teach-inresponse.ThisisrequiredtoenablecommissioningdevicestoseeanddocumenttheTeach-inresult.SimpleexampleisshowninFigure4.1.



4.3. DefinitionThegeneralstructureoftheTeach-inmessageisdividedintoaheaderandadefinitionarea.TheTeach-in request header does not contain the same information as the Teach-in responseheaderandwhiletheTeach-inrequestmessageincludesthechanneldefinitions,theTeach-inresponsegivesinformationaboutpossiblerejectedchannels.

In the definition area of the Teach-in request first the outbound channels are defined.Outbound/Outgoingchannelsarethechannelsthedevicewillsendindatacommunication.

Teach-inrequestmessageHeader Channeldefinition0 Channeldefinition1 …

FIGURE4.2:TEACH-INREQUESTMESSAGESTRUCTURE

Thereisnopaddingorbytealigningbetweenchanneldefinitions.Thefirstbytefollowingafteronedefinitionisalreadyusedforthenextdefinition.

Teach-inresponsemessageHeader Channelacknowledgementlist

FIGURE4.3:TEACH-INRESPONSEMESSAGESTRUCTURE

FIGURE4.1:TEACH-INPROCEDURE



When executing bidirectional Teach-in with inbound and outbound channel definitions thechannel definitions of outbound and inbound are separated with the appropriate Teach-ininformationchanneltype.FordetailsonTeach-ininformationchanneltypepleaseseechapter4.3.2.

Teach-inrequestmessagewithbidirectionalapplicationHeader Outboundchanneldef Teach-ininformation–Inbounddefinition

follows(signaltype=0x01)Inboundchannel

def.

FIGURE4.4:TEACH-INREQUESTMESSAGEWITHBIDIRECTIONALDEFINITION

Inbound / incoming channels are channels the device expects to receive in the datacommunication.

4.3.1. Teach-inrequestATeach-inrequestmessageisalwayspre-describedintheTeach-inrequestheader.Thisheaderisfollowedbythechanneldefinitionareawhereeverychannelisdefinedseparately.

Teach-inrequestheaderManufacturerID Datadirection Purpose Notused

11bit 1bit 2bits 2bits 0=unidirectional

1=bidirectional00=teach-in01=teach-indeletion10=teach-inor

deletionofteach-in

11=notused

FIGURE4.5:TEACH-INREQUESTHEADER

Fielddetailsandpurpose:

• ManufacturerIDIs the EnOceanAllianceManufacturer ID of the devicewhich transmits the Teach-inrequest.

• DataDirectionOperationaldatatransmissioncanbeunidirectionalorbidirectional.The‘datadirection’bitsdefinewhetherdataexchangewillbebilateralornot.Itdoesnotdefinethedevicehardwarecapabilities.IfdirectionisbidirectionalandnoresponseisreceivedthenitistoassumetheTeach-inprocesshasfailed.

• Purposeo 0b00teach-in–explicitrequesttoteach-in.

Possiblereturncodes:00=rejectedgenerally01=teach-insuccessful11=rejectedchannelsoutboundorinbound



o 0b01teach-indeletion–explicitrequesttoteach-indeletion/teach-out.Possiblereturncodes:

10=teach-out

o 0b10teach-inordeletionofteach-in–toggleteach.Possiblereturncodes:

00=rejectedgenerally01=teach-insuccessful10=teach-out11=rejectedchannelsoutboundorinbound

4.3.2. ChanneldefinitionThegoalofachanneldefinitionistoprovideallnecessaryinformationabouthowcertaindataiscodedfortransmissionandhowitshouldbeprocessedatthereceiver.However,itdoesnotdictatethepurposeofthisdata.

Duetothediversityofchanneldefinitionsandthetransmittedinformation,thegeneralchanneldefinitionisdividedintodifferentchanneltypes.Fordetaileddescriptionofthecharacterofthechannelspleaserefertochapter3.3.1.

Nextisthechanneldefinitionofallchanneltypes.Thechanneldefinitionframeisdifferentforeach channel type. Theonly common characteristics are the first twobits,whichdefine thechanneltype.Basedonthechanneltypeareceivercaninterprettheremaininginformation.

Theexactparameter listsandexplanationof thevaluesare shown in thechapter3.3.2.Thesignaltypedefinitiondependsonthechanneltype.ThesignaltypelistforeverychanneltypeisavailableintheGenericProfilesappendix.

Channeldefinition‘Data’Channeltype

Signaltype

Valuetype

Resolution Engineeringminimum

Scalingminimum

Engineeringmaximum

Scalingmaximum

2bits 8bits 2bits 4bits 8bits 4bits 8bits 4bits

FIGURE4.6:CHANNELDEFINITION‘DATA’

Thelengthofachanneldefinition‘Data’is40bits.

Channeldefinition‘Flag’Channeltype

Signaltype

Valuetype

2bits 8bits 2bits

FIGURE4.7CHANNELDEFINITION‘FLAG’



Thelengthofachanneldefinition‘Flag’is12bits.

Channeldefinition‘Enumeration’Channeltype

Signaltype

Valuetype

Resolution

2bits 8bits 2bits 4bits

FIGURE4.8:CHANNELDEFINITION‘ENUMERATION’

The length of a channel definition ‘Enumeration’ is 16 sixteen bits. The field resolution of‘Enumeration’shallbeusedfromTable3.3:Resolution‘data’and‘enumeration’andNOTfromtheappendix.

Channeldefinition‘Teach-ininformation’Channeltype

Signaltype Lengthindicationforfollowingdatainbytes.

Data

2bits 8bits 8bits N

FIGURE4.9CHANNELDEFINITION‘TEACH-ININFORMATION’

Thelengthofachanneldefinition‘Teach-ininformation’is18+Nbits.Thischanneldefinitionhasavariablelengthindicatorforthedatacontentfollowing.Thelengthofthedatacontentisdefined foreverysignal typeandcanbe found in theGenericProfilesappendix1.The lengthindicationofthefollowingdatainisgiveninbytes(e.g.iffield=0x04,then4bytesofdatawillfollow).TheTeach-in informationchanneltypeneitherhas influenceontheoperationaldatacommunicationnorontheindexing.

4.3.3. Teach-inresponseTheTeach-inresultprovidesinformationaboutthesuccessoftheTeach-inprocess.AsareactiontoareceivedTeach-inrequest,thereceiversendsanaddressedTeach-inresponsemessagetotheinitiatingradiopartner.ThismessageprovidesinformationaboutthedeviceitselfandtheTeach-instatus.

1 https://www.enocean-alliance.org/what-is-enocean/specifications/



Teach-inresponseheader

ManufacturerID Result undefined

11bits 2bits 3bits

00=rejectedgenerally

01=teach-insuccessful

10=teach-out

11=rejectedchannelsoutboundorinbound

FIGURE4.10:TEACH-INRESPONSEHEADER

AsuccessfulTeach-inorteach-outwillbereferredby‘01’or‘10’.

If at least oneof the inboundor outbound transmitters channels cannotbe adoptedby thereceivertheTeach-inresultis‘11’andfurtherinformationabouttherejectedchannelswillbegiveninthechannelacknowledgmentlistfollowingtheheader.Thechannelacknowledgementlist is described in chapter 4.3.4. Depending on the given list of channels the transmitterapplicationcandecidewhetheritwantstoaccepttheTeach-inorhastocancelitbysendingaTeach-inresponsemessagewithteach-outresult.

Incaseofacceptancenofurtheractionisrequired.IfnocancelationisreceivedbythereceiverthentheTeach-inissuccessfullyacceptedandonlythosechannelswillbeprocessedthathavebeenacknowledged.

ATeach-inrejectionwithoutaspecificreasonis‘00’.Inthiscasenochannelacknowledgementlistwillbegiven.

Detailed visualisation of the process described above can be seen in the activity diagram inFigure4.11andinsequencediagraminFigure4.12.



FIGURE4.11:GENERICPROFILETEACH-INACTIVITYDIAGRAM



FIGURE4.12:GENERICPROFILETEACH-INSEQUENCEDIAGRAM4.3.4. Channelacknowledgement

IfnotallchannelscanbeadoptedbythereceiveralistofinformationabouttheacknowledgementstatusofeverychannelisprovidedtothetransmitterwithintheTeach-in



responsemessage.Therefore,theheaderisfollowedbyabitstreamthatcontainsonebitforeverydefinedchanneltransmittingwhetherthechannelissupportedorrejected:

• 1=channelsupported;• 0=channelrejected

Teach-inresponseacceptedchannellistoutbound&inbound

OUTBOUND INBOUND

CH0 CH1 ... … …. CHN-3 CHN-2 CHN2-1

0/1

0/1

0/1

0/1

0/1

0/1

0/1

0/1

FIGURE4.13:TEACH-INRESPONSECHANNELLIST

Thebitorderisexactlythesameasthechanneldefinitionorder.AsthetransmitterknowsthisorderitcandecideiftheTeach-inprocessshouldberejectedoraccepted.

ThechannelacknowledgementlistwillonlybeaddedtoaTeach-inresponsemessageifTeach-inwasnotcompletelysuccessful(Result=‘11’).Inthiscase,thecomplete(inboundifavailable&outboundifavailable)channelacknowledgementlististransmitted.

4.4. Channelindexing

Achannelindexisdefinedtohaveauniquenumericreferencetotheindividualchannelsofasingledevice.Thechannelindexstartswith0andwillbecountedup.Indexingofchannelsstartswiththefirstdefinedoutboundchannel“index0”intheTeach-inrequestandendswiththelastinboundchannel“indexN-1”whereNisthecountofallchannels.

Teach-ininformationchanneltypesarenotindexed.

4.5. MessagetimingsInthischapterthemessagetimingconventionsaredefined.Thetimingdefinesthemaximumtimeout in a message exchange process. When the timeout is passed then the message isconsidered as unreceived.Messages arriving after this timeout have to be processed as notrelevantanymore. If amessageconsistsofmore telegrams, then the timeoutdescribes thetransmission/receptionofthefirstofthechainedtelegrams.

Timingconventions:

2 Nisthecountofallchannels-inbound&outbound.Theindexis0based.



Transmittertimeout: 750msATeach-inresponseshouldbereceivedwithin750msaftertransmissionoftheTeach-inrequest.

Receiverresponsetime: 500msATeach-inresponseshouldbetransmittedwithin500msafterreceptionofaTeach-inrequest.

Receivertimeout: 750ms

ATeach-inresponsewithteach-outresult-‘010’shouldbereceivedwithin750msaftertransmission of the Teach-in response (some channels are rejected inbound oroutbound)fromthereceiver.IfnosuchTeach-inresponsewasreceived,itisassumedthatthetransmitteracceptedtheteach-in.

Transmitterresponsetime: 500ms

ATeach-inresponsewithteach-outresult-‘010’shouldbetransmittedwithin500msafterreceptionoftheTeach-inresponse(somechannelsarerejected)fromthereceiver.

4.6. UsingSmartAcknowledgeforcommunication

TheuseofSmartAcknowledgefollowstherespectiveconventionsinthe‘EEPSpecification’.Theonly difference is the special generic EEP (R-ORG: B0 FUNC: 00 TYPE: 00) that generallyrepresents the generic communication. Beside that the procedure is equal to an EEP basedSmartAcknowledgeTeach-in.TheGenericProfilesTeach-in is thenexecutedseparated fromSmartAcknowledgeTeach-in.FirstthecommunicationlinkofSmartAcknowledgeisbuildandthen Generic Profiles Teach-in is executed. All timing conventions are given by the SmartAcknowledgedefinitionandtheapplication.

EXAMPLE

1. ControllerisputtoTeach-inmode(withSmartAcknowledgecapability).2. SensorsendsaSmartAcknowledgeTeach-inrequest.TheSmartAcknowledgeTeach-in

requestholdstheEEP0xB00x000x00.3. SmartAcknowledgeTeach-inisexecuted.PostmasterisdeterminedandSensoris

successfullytaughtin.4. SensorsendsaGenericProfilesTeach-inrequest.5. ControllerevaluatestheGenericprofilesTeach-inandsendsaGenericProfilesTeach-in

ResponsethroughSmartAcknowledge.

NOTE:

ThemostrecentEEPSpecificationcanbedownloadedfromthewebsiteoftheEnOceanAlliance.http://www.enocean-alliance.org.



SmartAcknowledgeSpecificationisavailablehere:http://www.enocean.com/en/knowledge-base/.

4.7. Examples4.7.1. Teach-inrequestmessage

Teach-inrequestheaderbin 11111111111 1 00 xxhex 0xFFF0dec 65520

Man.ID 11111111111 = MultiuserManufacturerID

Datadir. 1 = Bidirectional

Purpose 10

= teach-inordeletionofteach-inUndefined xx

FIGURE4.14:SIMPLEBIDIRECTIONALTEACH-INREQUESTHEADER

Teach-inrequestheaderbin 11111111111 1 10 xxhex 0xFFF8dec 65528


Datadir. 1 = Bidirectional

Purpose 10

= teach-inordeletionofteach-inUndefined xx

FIGURE4.15:EXAMPLEOFTEACH-INREQUESTHEADERWITHOPTIONALDELETIONOFTEACH-IN



Channeldefinition1bin 01 00000110 01 0101 00000000 0001 00000101 0001hex 0x4195001051dec 281672683601

Chan.type 01 = Data

Sig.type 00000110

= CurrentVal.type 01

= CurrentvalueRes. 0101

= 8-bitEng.Min. 00000000

= 0Scal.Min. 0001

= x1Eng.Max. 00000101

= 5Scal.Max. 0001

= x1

FIGURE4.16:EXAMPLEOFCHANNELDEFINITION‘DATA’

Channeldefinition'Teach-ininformation'

bin 00 000001 00000010 1000001001100000hex 0x814130dec 8470832

Chan.type 00

= Teach-ininformationSig.type 000001

= Teach-ininformation-InbounddefinitionfollowsLengthofdata[Bytes] 00000010

= 2ByteData 1000001001100000= Channeldefinition2(Occupancysensor)

FIGURE4.17:CHANNELDEFINITION‘TEACH-ININFORMATION’EXAMPLE



Channeldefinition2bin 100000100110hex 0x826dec 2086

Chan.type 10

= flagSig.type 00001001

= OccupancyVal.type 10

= Setpointabsolute

FIGURE4.18:CHANNELDEFINITION‘FLAG’EXAMPLE

4.7.2. Teach-inresponsemessage

Teach-inresponseheaderbin 11111111111 01 xxxhex 0xFFE8dec 65512


Result 01= teach-insuccessful

Undefined xxx

FIGURE4.19:SIMPLETEACH-INRESPONSEHEADER

Teach-inresponseheaderbin 11111111111 11 xxxhex 0xFFF8dec 65528

Man.ID 11111111111

= MultiuserManufacturerIDResult 11

= RejectedchannelsoutboundorinboundUndefined xxx

FIGURE4.20:EXAMPLEFORATEACH-INRESPONSEHEADERWITHREJECTEDCHANNELS



Channelacknowledgementlistbin 111111000000 = Channel0-5supported

Channel6-11rejected

FIGURE4.21:TEACH-INRESPONSEACKNOWLEDGEMENTLIST



5. OperationalmodeThischapterdescribeshowtheactualdatatransferworks.

5.1. Introduction

Inoperationalmode,eithercompleteorselecteddatamessageswillbesenttransmitted.Thischapterdescribeshowthedataisarranged.

EachoutboundchannelofthesensordeliversdatawithafixedlengthofbitswhichisdefinedintheTeach-inrequest.Thereceiverhastheknowledgeaboutthenumberofbitsofeachsensorsoutboundchanneldataandisabletodecodethedatacorrectlyafterthesensorencodedhismeasurementvaluestothedatamessage.

In bidirectional communication the same principle is applied. The reciever codes its datamessageaccording to the inboundchannelsdefinitionof theTeach-in request.Thesensor isthenabletodecodethemessageandthedata.

Adatarequestmechanismisalsopartofgenericprofiles.Thistopicismorecomplex.Thereforethedefinitionofdatarequestmechanismwillbeaddedtotheappendixafterthefirstfieldtrials.

5.2. Datamessagedefinition

Therearetwodifferentmessagetypes:

• CompletedatamessageItcontainsalldatathesensorcandeliver.

• SelectivedatamessageItcontainsdataonlyofselectedchannels.

ThelayeringmodelselectsthetypeoftheEnOceanradiotelegram(s)applieddependingonthelengthofthemessage.Messagescanconsistof

• singleradiotelegram–payloadfitsintoonetelegram.• moreradiotelegrams=chainedradiotelegrams–payloaddoesnotfitintoone

telegram.

Detailstothechainingprocesscanbefoundatchapter2.3.1.

Inthedatamessagesonlydata, flagorenumerationchanneltypeare included.TheTeach-ininformationchanneltype isonlyusedduringTeach-inprocess. It isNOT included inthedatacommunication.



5.2.1. CompleteDatamessageThedataofeachchannelwillbecompiledintoacompletedatamessageandconsistingofabitstream. There is no channel number information in the complete data message, only themeasurements.

Therulestoaddthemeasurementstothebitstreamare:• Startingwithchannel0,allusedbitsofeverychannelareconcatenatedtogethertoa

bitstream.• ThebitorderwillNOTbechanged,i.e.MSBstaysMSBinthestream.• Afterconnectingallbitsofthesensor,themessagewillbefilledwithunusedbits(0)till

thenextbyteborderisreached.• Everychannelhastobeaddedtothestream.• Acompletemessagecanbeeitheroutboundorinbound.

Example:

ThreeoutboundchannelsofasensoraredefinedintheTeach-inrequest:

• Channel0witha6bitmeasurementvalue• Channel1witha8bitmeasurementvalue• Channel2witha5bitmeasurementvalue

Channel0 Channel1 Channel2Measurements

Datamessage

1stbyte

2ndbyte

3rdbyte

FIGURE5.1:EXAMPLEOFACOMPLETEDATAMESSAGE

Thedatamessageconsistsofthesumofallmeasurementbitsofthesensor,i.e.19bits.There

are3bytesnecessarytotransmit.The5LSBofthe3rddatamessagebyteareunused().

5.2.2. SelectivedatamessageTheselectivedatamessagestartswitha4-bitheadercontainingthenumberofchannelsofthemessage. To relate the channel to the value the channel index will be inserted prior everychanneldata.Thechannelindexis6bitlong.Theindexingofchannelsisdescribedinchapter4.4.

Therulesofaddingachanneltotheselectivedatamessagebitstreamare:



Channel0witha6bitmeasurementvalue

• Thechannelindexis6bitswide.• Startingwiththefirstmeasurementchanneltobetransmitted,the6bitchannelnumber

andtheusedbitsofthatchannelareconcatenatedtogethertoabitstream.• Furtherchannelsareaddedtothebitstreamadequately.• ThebitorderwillNOTbechanged,i.e.MSBstaysMSBinthestream.• Afterconnectingalldatatotransmit,themessagewillbefilledwithunusedbitstillthe

nextbyteborderisreached.• Aselectivemessagecanbeeitheroutboundorinbound.

Example:

Measurements

Datamessage

Channel0 Channel1 Channel2

HeaderChannelno.

011.byte 2.byte

FIGURE5.3:EXAMPLEOFASELECTIVEDATAMESSAGE

ThreeoutboundchannelsofasensoraredefinedintheTeach-inmessage:FIGURE5.2:EXAMPLESELECTIVEDATAMESSAGE

• Channel1witha2bitmeasurementvalue• Channel2witha5bitmeasurementvalue

Onlychannel1measurementvaluechangedandshouldbetransmitted

The selective data message consists of the 4 bit header (0001), the 6 bit channel number(000001)andthe2bitmeasurementofchannel1ofthatsensor.Themessagelengthisonlytwobytes.

00010000



6. CompatibilitywithEEPIn this chapter the further coexistence and development of Generic Profiles and EnOceanEquipmentProfilesisexplained.

6.1. Introduction

Establishinganewconceptofradiocommunicationinaworldofexistingandhighlyintegratedsystemsrequiresastrategytoconnectdevicesfromboththerecentandthenewapproach.Thismeansthatupcomingproduct introductions intothemarketneedstoconsiderthe ‘EnOceanEquipmentProfilesSpecification’aswellasthe‘GenericProfiles’.

6.2. Coexistence

As theGeneric Profiles (GP) are notmeant to replace theEnOcean Equipment Profiles (EEP)immediately,thecoexistenceofbothconceptsismandatory.

CommunicationbetweenEEPdevicesisstandardizedandsoisthecommunicationbetweenGPdevices. Amixed data exchange is possible butwill not be enforced by theGeneric Profilesapproach.ThereforethespecialGenericProfilesR-ORG’sallowtoidentifygenerictelegramsandmanufacturersarefreetoimplementbothorjustoneoftheconceptsintheirproducts.Duringthe Teach-in process the two selected devices have to determinewhich approach theywillfollowfortheirdataexchange.UnsuccessfulTeach-inattemptscannotbepreventedbythenewapproach.

Bythatageneralcompatibilityofthetwodifferentprofileapproachescanbeguaranteedeventhoughitisnotnecessarythatalldeviceshavetobeabletoconnecttoeachother.



FIGURE6.1:CONNECTIONSCENARIOS

6.3. TransitionPlanWithoutanofficialpressurebythedefinitionoftheGenericProfilesitisuptothemarketandthedifferentmanufacturersofEnOceandevicestoestablishgenericbaseddevicesandsystems.

EEP’swillbevalidinthefuturebutGP’sofferadditionalfunctionalityforflexibleradiosystemswithgrowingrequirementsconcerningdataexchange.



2011

FIGURE6.2:TRANSITIONFROMEEPTOGP

GP

EEP GP

EEP GP

EEP 2013



7. RemoteManagementGenericProfilebaseddevicesthatarecontinuouslypoweredshallsupportaminimumfeatureset from the EnOcean Remote Management specification. In addition to the RemoteManagementControlCommands (RMCC) suchdevices shall supportRemoteProcedureCalls(RPC)definedinRemoteCommissioningSpecification.

MinimalrequiredfeaturesfromRemoteCommissioningSpecification:

• operationstocontrolTeach-inprocess• operationstoaccessandreadlinktable

In case any new RPC definitionwill be required, it shall be handled in accordancewith thestandardization process of the EnOcean Alliance TWG and defined within the SystemSpecificationonRemoteCommissioning.

NOTE:

RemoteManagementSpecificationisavailablehere:http://www.enocean.com/fileadmin/redaktion/pdf/tec_docs/RemoteManagement.pdf

RemoteCommissioningSpecificationisavailablehere:

http://www.enocean-alliance.org/en/home/

Generic Profiles V 1 - EnOcean Alliance · System Specification Generic Profiles Specification v1.2...

Documents

Transcript of Generic Profiles V 1 - EnOcean Alliance · System Specification Generic Profiles Specification v1.2...