Generic Profiles V 1 - EnOcean Alliance · System Specification Generic Profiles Specification v1.2...
Transcript of 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.
System Specification
GenericProfilesSpecificationv1.2 Page2/42
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
System Specification
GenericProfilesSpecificationv1.2 Page3/42
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
System Specification
GenericProfilesSpecificationv1.2 Page4/42
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
System Specification
GenericProfilesSpecificationv1.2 Page5/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.
System Specification
GenericProfilesSpecificationv1.2 Page6/42
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
System Specification
GenericProfilesSpecificationv1.2 Page7/42
Outbound Outgoing-outgoingcommunicationfromdescribeddeviceperspective
System Specification
GenericProfilesSpecificationv1.2 Page8/42
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).
System Specification
GenericProfilesSpecificationv1.2 Page9/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page10/42
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:
System Specification
GenericProfilesSpecificationv1.2 Page11/42
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).
System Specification
GenericProfilesSpecificationv1.2 Page12/42
Layer Services
ApplicationGeneratesGenericProfilesmessageasabitstreamanddeterminesmessagetype
GenericProfilesAPI(addedserialsupport)
Createsserialmessage(s)
DolphinAPI Sendsserialmessage(s),e.g.viaESP3
EnOceanDolphinchip Physicalserialtelegramtransmission
FIGURE2.5:LAYERMODELOFSERIALCOMMUNICATION
System Specification
GenericProfilesSpecificationv1.2 Page13/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page14/42
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
System Specification
GenericProfilesSpecificationv1.2 Page15/42
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’
System Specification
GenericProfilesSpecificationv1.2 Page16/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page17/42
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’
System Specification
GenericProfilesSpecificationv1.2 Page18/42
‘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)
System Specification
GenericProfilesSpecificationv1.2 Page19/42
𝐸𝑛𝑔𝑚𝑖𝑛=𝐹𝑋𝑚𝑖𝑛𝑚𝑖𝑛
𝐸𝑛𝑔𝑚𝑎𝑥=𝐹𝑋𝑚𝑎𝑥𝑚𝑎𝑥
𝑛=𝑁× 𝑥−𝑋𝑚𝑖𝑛𝑋𝑚𝑎𝑥−𝑋𝑚𝑖𝑛
𝑥=𝑛𝑁×(𝑋𝑚𝑎𝑥−𝑋𝑚𝑖𝑛)+𝑋𝑚𝑖𝑛
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
Measurement Channeldefinition
Concentrationsensor
Range:1–1e+06ppmResolution:32bit
Purpose:currentvalue
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
Measurement Channeldefinition
Voltmeter
Range:-230–230VResolution:16bit
Purpose:currentvalue
Channeltype: Data 01Signaltype: Voltage 00011100Valuetype: Currentvalue 01
Resolution: 16bit 1001Scaledeng.minimum: -23V [11101001]2Scalingminimum: x10 0010Scaledeng.maximum: 23V [00010111]2Scalingmaximum: x10 0010
System Specification
GenericProfilesSpecificationv1.2 Page20/42
HVACMode Channeltype:Signaltype:Valuetype:
EnumerationHVACModeCurrentvalue
110000010001
Purpose:currentvalue
FIGURE3.5:EXAMPLEVOLTMETERDEFINITION
3.5.2. FlagchanneldefinitionMeasurement Channeldefinition
Occupancysensor
Purpose:currentvalue
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
System Specification
GenericProfilesSpecificationv1.2 Page21/42
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
System Specification
GenericProfilesSpecificationv1.2 Page22/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page23/42
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
System Specification
GenericProfilesSpecificationv1.2 Page24/42
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
System Specification
GenericProfilesSpecificationv1.2 Page25/42
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’
System Specification
GenericProfilesSpecificationv1.2 Page26/42
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/
System Specification
GenericProfilesSpecificationv1.2 Page27/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page28/42
FIGURE4.11:GENERICPROFILETEACH-INACTIVITYDIAGRAM
System Specification
GenericProfilesSpecificationv1.2 Page29/42
FIGURE4.12:GENERICPROFILETEACH-INSEQUENCEDIAGRAM4.3.4. Channelacknowledgement
IfnotallchannelscanbeadoptedbythereceiveralistofinformationabouttheacknowledgementstatusofeverychannelisprovidedtothetransmitterwithintheTeach-in
System Specification
GenericProfilesSpecificationv1.2 Page30/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page31/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page32/42
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
Man.ID 11111111111 = MultiuserManufacturerID
Datadir. 1 = Bidirectional
Purpose 10
= teach-inordeletionofteach-inUndefined xx
FIGURE4.15:EXAMPLEOFTEACH-INREQUESTHEADERWITHOPTIONALDELETIONOFTEACH-IN
System Specification
GenericProfilesSpecificationv1.2 Page33/42
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
System Specification
GenericProfilesSpecificationv1.2 Page34/42
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
Man.ID 11111111111 = MultiuserManufacturerID
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
System Specification
GenericProfilesSpecificationv1.2 Page35/42
Channelacknowledgementlistbin 111111000000 = Channel0-5supported
Channel6-11rejected
FIGURE4.21:TEACH-INRESPONSEACKNOWLEDGEMENTLIST
System Specification
GenericProfilesSpecificationv1.2 Page36/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page37/42
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:
System Specification
GenericProfilesSpecificationv1.2 Page38/42
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
System Specification
GenericProfilesSpecificationv1.2 Page39/42
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.
System Specification
GenericProfilesSpecificationv1.2 Page40/42
FIGURE6.1:CONNECTIONSCENARIOS
6.3. TransitionPlanWithoutanofficialpressurebythedefinitionoftheGenericProfilesitisuptothemarketandthedifferentmanufacturersofEnOceandevicestoestablishgenericbaseddevicesandsystems.
EEP’swillbevalidinthefuturebutGP’sofferadditionalfunctionalityforflexibleradiosystemswithgrowingrequirementsconcerningdataexchange.
System Specification
GenericProfilesSpecificationv1.2 Page41/42
2011
FIGURE6.2:TRANSITIONFROMEEPTOGP
GP
EEP GP
EEP GP
EEP 2013
System Specification
GenericProfilesSpecificationv1.2 Page42/42
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/