SC14DECTIPBS

SC14DECTIPBS
Web Application Interface (API)

Web Application Interface

Responsible
KZ
KZ

SC14DECTIPBS

Revision history:
Version
Released
V1.0
13-Dec-11
V1.1
10-Apr-12

Comments
Initial release
Updated commands to reflect latest API

1.0 API DESCRIPTION

1.1 General command format
This document describes the interface which is used to access ULE functionality from any IP based network. For the
command structure a JSON (Javascript Serial Object Notation) format is used, which is a fat-free alternative to XML.
The format is used due to the extensive number of libraries available for different languages (PHP, C++, C#,
Javascript, Qt, Java, ASP). Please visit www.json.org for more information.
1.2 Using the web based API
The JSON command string will be passed over standard HTTP traffic. The general idea of the DECT IP BS
terminated API is the following:
The DECT IP BS uses DHCP to obtain an IP address within the network (LED 1 will light up upon successful
address discovery).
The DECT IP BS can then be reached by its hostname DECTIPBS<number> (number is printed/written on
the PCB itself). If the DHCP router does not resolve DNS name, the board can be directly accessed by its IP
address. The address can be obtained by running the DECT-ULE-SetupWizard in VM /home/uleuser/ folder.
The API can be accessed through a HTTP GET call in the following way
o http://DECTIPBS<number>/getJson.json?jsonString=.... for sending/receiving single command
strings.
o http://DECTIPBS<number>/testJson.json for test page to test the response for given JsonString
o This call can be done in a number of ways:
Using a standard browser (or cURL) allows the user to test single commands and read the
output in the browser window
Some type of webapplication using AJAX calls or HTTP forms
An extensive example using this interface is the demo webpage code found in the source code
/RHEA_ULE_Release_<version>/SW/source/user/sc1445x_dect_apps/ULE/apps.

Please note that:

The IP BS will be reachable through hostname in the internal network, but NAT translations will need to be
done to reach the device outside of the network gateway. Alternatively the board can connect to outside
network to a server from which user can access any registered board. The board is connected automatically
during boot up and no port forwarding is needed in this case. For more details refer to SW manual at SW
Architecture portal server section.
1.3 Testing the commands
Use the following steps to go to an API test page running on the DECT IP BS:
Run the DECT-ULE-SetupWizard. Locate the board and note down the IP.
As an example the IP could be 192.168.0.101
Open a browser and go to http://192.168.0.101/testJson.json
In the command entry box JSON commands can be entered
The commands examples can be executed as examples in the Command entry box.
Alternatively the SmartPulse portal server can be used to test various commands on the board. Please see the Quick
Start Guide in order to see how JSON commands can be tested through the portal server.

Web API

April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 2 of 13

General ULE command format

The following string is a typical example of a JSON string used for the DECT IP BS:
[{"cmdType":0,"portId": 1,"packId": 12,"data":[0,1,2]}, {"cmdType":1,"portId":{},"param":[{"paramId":8,"paramValue":1}]
The string is an array (indicated by []) of commands (indicated by comma separated {}). All high level commands
contain the following common elements:
Parameter
cmdType

Description
Identifies command type

portId

Identifies the port to which

the command is sent to or
received from

Values
0 Data command
1 Configuration command
2 System command
3 User command
7 64

SC14DECTIPBS

1.4

Comments

PortID 1-6 is reserved

for no ULE devices.

Web API

April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 3 of 13

SC14DECTIPBS

Detailed ULE command formats

1.5

1.

Data command: (cmdType: 0)

Data commands are used for holding send and receive data for sensors.
They are issued in the following format:
Packet holding send data:
{ cmdType":"0","portId": "<portId>","EarlyBit":"< EarlyBit >",data:<data>}
Example:
[{"cmdType":0,"portId":1,"data":[49,69,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}]
Example with paging and earlybit set:
[{"cmdType":0,"portId":1," EarlyBit": 1,"data":[49,69,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}]
Packet holding received data:
{ cmdType":"0","portId": "<portId>"," packId":"< packId>"," TimeStmp":"< TimeStmp>", " SensorType":"<
SensorType>", " DataType":"< DataType>", " NextMess":"< NextMess>", data:<data>}
Example:
[{"cmdType":0,"portId":1, >"," packId":12," TimeStmp":2345, " SensorType":49, " DataType":29,
"NextMess":0, "data":[14,15,16,1,1,0,0,0,0,0,0]}]
Fields are numbers and data field is an array of decimal data values.
This command is used to send data to sensors.
Note: Refer to Appendix B for payload format.
Returns JSON string status:
{"cmdType":0,"portId":<portID>,errDesc": UleErrEnum }
UleErrEnum : ULE_Success for success or else refer to APPENDIX A for error type
Important: ULE_Success does not mean that the packet was transmitted successfully. Refer to Appendix C.
Parameter
PortId
PackId

Timestamp
SensorType

DataType

NextMessage
EarlyBit

April 10, 2012 v1.1

Values
00-64

Identifies whether all the information is

contained in one message or not.
Identifies whether paging and Early Bit
feature will be used or not. Used only
when sending a packet.

0 One message
1 Data continue in next message
0 Paging enabled and send EarlyBit =0
1 Paging enabled and send EarlyBit =1
2 Paging disabled (default value if
omitted)
1 to 56 decimal numbers

Data payload send to the portable

device

00 0xFFFFFFFF

00 0xFFFFFFFF
SENSOR_TYPE_GENERIC = 0x01
ACTUATOR_TYPE_GENERIC = 0x02
MMI_DATA_TYPE_KEEP_AWAKE=0x01
MMI_DATA_TYPE_HAL= 0x13
MMI_DATA_TYPE_WAKEUP_CFG=0x14

Dialog Semiconductor B.V.

Web API

Data

Description
Identifies the portable part from which
the message is send from/to.
Identifies packet number. Used only
when receiving a packet. It is 32 bit
number unique for each sensor
received packet.
Identifies the time in seconds which
the packet got received
Identifies the type of sensor which
send the packet for example (button,
actuator, relay, etc)
Identifies the type of message
(wakeup, alarm, HAL, batterylow,etc)

page 4 of 13

SC14DECTIPBS

2.

ULE configuration command (cmdType: 1):

Parameters commands are issued in the following format:

{"cmdType":1,"portId":"<portId>,"param":[{"paramId":<paramId>,"paramValue":<paramValue>}, }]}
Or for a single paramID:
{"cmdType":1,"portId":"<portId>, paramId":<paramId>,"paramValue":<paramValue>}

Example:
{"cmdType":1,"portId": 1,"paramId":8,"paramValue":1}
Fields are numbers and Param field is an array of JSON paramId/Paramvalue structure.
For write command this command returns:
{"cmdType":1,"portId":<portID>,errDesc": UleErrEnum }
UleErrEnum : ULE_Success for success or else refer to APPENDIX A for error type

For read/request command this command returns:

{"cmdType":1,"portId":<portID>, errDesc":0, "paramId":<paramId>, paramValue:<field_status>} for SUCCESS
{"cmdType":1,"portId":<portID>,"paramId":<paramId>, errDesc": UleErrEnum } for FAIL. Refer to APPENDIX A for
error type
When issuing a read request with portiD:{}, the response is gernerated for all available portID.
Valid range for portID is from 7 to 64.
When issuing a read request for a parameter an empty array is used, so the format shall be:
<paramValue >:{}
ParamID
Values
18

Description

Read
/Write
-

Comments

1 Node
status

Indicates the node status

When PortID is empty then ALL
node status is returned

paramValue:
2 offline
1 online
0 Not registered

2
Message
status
request

Request message status. Currently

there is support for sending one
packet at a time. This command
returns the status for this sending

3 Tx
Abort

In case Tx buffer is still full, send

abort command is send to abort data
transmition
When sending data to a port, the
packet will indicate timeout after

April 10, 2012 v1.1

R/W

See values below for details

paramValue:
0)Tx_Buff_Empty
1)Tx_Buff_Empty_TxSuccess, Buffer
empty after last Tx transmition succedded
(RTS received)
2)Tx_Buff_Empty_TxRejected
Buffer empty after last Tx transmition
failed (Reject received)
3)Tx_Buff_Empty_TxAborted
Buffer empty after last Tx transmition
was aborted (Abort command send)
4)Tx_Buff_Full
paramValue: PortID

paramValue:
0x0000-0xFFFF

Dialog Semiconductor B.V.

page 5 of 13

Web API

4 Data
packet

Port parameters

5 Node
communic
ation
timeout [s]

6 Return
data

7- Node
type

8- Node
attribute

9 Latest
event data

10 IPEI
read

Data packet timeout seconds.

When packet is not transmitted
withing this time, an Abort command
will be send to CVM unit in order to
cancel transmittion.
When no data has been received
from a Node after Node
communication timeout the port will
be considered offline. A write will set
the timeout value for the sensor, a
read will return both this value, along
with the elapsed time since the
sensor was seen alive.
Request to return data packets from
a port stored in the receive buffer.
Receiver buffer is 32 packet large
cyclic buffer. Data will be returned
using the Data Command. User
must take care of tracking packId.
Packid should match the latest
packID already read from a previous
read command. Note: Refer to
Appendix B for payload format.
Returns the sensor type for the
given portID

Returns the attribute value for a

given node. There are 4 attributes
available per node. Attribute values
are assigned from the user
application which runs in the board.
Returns the latest packet stored for
a given datatype (event). Data will
be returned using the Data
Command. Note: Refer to Appendix
B for payload format.
Returns the IPEI value of a sensor
(unique 5 byte number). In contrast
to portID number, IPEI value does
not depend on registration
sequence.

R/W

paramValue:
0x0000-0xFFFF

paramValue:
0 Return all data
1 FF: return ALL data starting from
corresponding packId.

SC14DECTIPBS

timeout [s]

Use this command when interested for a

history of received data, for example to
post process values, create statistics,
graphs,etc
SENSOR_TYPE_NONE = 0x00
SENSOR_TYPE_GENERIC =0x01
ACTUATOR_TYPE_GENERIC = 2
SENSOR_TYPE_BUTTON=0x14
SENSOR_TYPE_TEMP=0x15
SENSOR_TYPE_REDRELAIS=0x18
TYPE_SWITCH_220=0x45

It is used when only interested for latest

packets. In contrast to paramID=6, this
one doesnt require extra handling and
parsing of returned data on the user side
to extract latest value.

Examples:
For every sensor ID get its status value:

{"cmdType":1,"portId":{},"param":[{"paramId":1,"paramValue":{}}]}
For sensor ID=7 get its status value:

{"cmdType":1,"portId":7,"param":[{"paramId":1,"paramValue":{}}]}
For every sensor ID get its type:

{"cmdType":1,"portId": {},"param":[{"paramId":7,"paramValue":{}}]}
For every sensor ID get before how many seconds an activity was recorded:

Web API

{"cmdType":1,"portId": {},"param":[{"paramId":5,"paramValue":{}}]}
For sensor ID=8 set timeout value:

{"cmdType":1,"portId": 8,"param":[{"paramId":5,"paramValue":3600}]}
For sensor ID=8 read its attribute value 0:

{"cmdType":1,"portId": 8,"param":[{"paramId":8,"paramValue":0}]}
April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 6 of 13

System command (cmdType: 2):

System commands are issued in the following format:

{ cmdType":"2","portId": {},sysParamType:<sysParamType>,sysParamValue:<sysParamValue>}
Example:
{ "cmdType":2,"portId": {},"sysParamType":2,"sysParamValue":1}
Fields are numbers.

SC14DECTIPBS

3.

For write command this command returns:

{"cmdType":2, errDesc":0} for SUCCESS
{"cmdType":2, errDesc":Val} for FAIL. Error description is Val
For read/request command this command returns:
{"cmdType":2, errDesc":0, sysParamValue:<field_status>,} for SUCCESS
{"cmdType":2, errDesc": Val } for FAIL. Error description is Val
NOTE:
The portId parameter is included in the common command format, but is ignored in a system command. The DECT
IP BS will return system commands with a blank portId (blank array {}).
When issuing a read request for a parameter an empty array is used, so the format shall be:
<sysParamType >:{}
The parameter value will be returned by the DECT IP BS in the following format:
{ <sysParamType >:<sysParamValue>}
SysParamType
Values

Description

Read
/Write

Comments

03

Port parameters

See values below for

details

0 Set registration
mode

Enable/disable registration mode

R/W

1 Set access code

Set or read the access PIN code for registratino

R/W

2 Deregister
device

Delete registration of a sensor node.

Use the configuration command to check status of
a port to double check if the node is deregistered.
Returns the ULE system time in seconds
Returns a string with the board syslog file for
remote debugging system status request
It returns 0 if user presses board button within 30
sec, or else 1 for timeout. It can be used as part of
registration/aunthedication process to request
user physical interaction with the board.
It returns an array of three 3 strings containing the
SW version of the application, the stack and
whether it supports voice.
Example for flat design and no VOIP:
IPBASE_1_0_1_00018:NatalieV0711:VOIP_DIS
Example for CVM module design with VOIP:
IPBASE_1_0_1_00018:CVMV0711:VOIP_EN

paramValue:
1 enable
other disable
paramValue:
0x0000-0xFFFF
paramValue:
0x00 0xFF: portId to
be deregistered.

3 Get system time

4- Read syslog File
5- Request button
press

6 Request SW
version

R
R
R

Web API

Examples:
Read registration mode:
{"cmdType":2,"portId": {},"sysParamType":0,"sysParamValue":{}}
Set registration mode:
April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 7 of 13

SC14DECTIPBS

{"cmdType":2,"portId": {},"sysParamType":0,"sysParamValue":1}
Read access code:
{"cmdType":2,"portId": {},"sysParamType":1,"sysParamValue":{}}
Read system time:
{"cmdType":2,"portId": {},"sysParamType":3,"sysParamValue":{}}
Degister device with ID =8
{"cmdType":2,"portId": {},"sysParamType":3,"sysParamValue":8}
User command (cmdType: 3):
User commands are issued in the following format:
{ cmdType":"3"," UserAppData:<user data json object>}
Example:
{ "cmdType":3," UserAppData ": {user_parameter1:123, user_parameter2:456, user_parameter3:789}}

This command is used as a link between the web and a user application running in IP base station. The UserAppData
field can contain any data in any format which the user defines to get interpreted in his application. On the IPS base
side the user in the main function during application Init registers the function he wants to execute when such
command is received by using the function ULE_UserWebReqHandler_CallBack. The result depends on the
processing made in this function, as the web application gets exactly the JSON object which is returned from this
function. A typical usage example of this command is the ability to control through the network different options and
parameters of the user application running in the IP base. For example, in the release demo this command is used to
pass the event-activities pairs that the user wants the IP base to run in the background.

Web API

April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 8 of 13

SC14DECTIPBS

4.

VOIP configuration command (cmdType: 4):

VOIP configuration commands are issued in the following format:

{"cmdType":4,"portId":"<portId>,"param":[{"paramId":<paramId>,"paramValue":<paramValue>}, }]}
Or for a single paramID:
{"cmdType":4,"portId":"<portId>, paramId":<paramId>,"paramValue":<paramValue>}

Example:
{"cmdType":4,"portId": 1,"paramId":7,"paramValue":1}
Fields are numbers and Param field is an array of JSON paramId/Paramvalue structure.
For write command this command returns:
{"cmdType":4,"portId":<portID>,errDesc": UleErrEnum }
UleErrEnum : ULE_Success for success or else refer to APPENDIX A for error type

For read/request command this command returns:

{"cmdType":4,"portId":<portID>, errDesc":0, "paramId":<paramId>, paramValue:<field_status>} for SUCCESS
{"cmdType":4,"portId":<portID>,"paramId":<paramId>, errDesc": UleErrEnum } for FAIL. Refer to APPENDIX A for
error type
When issuing a read request with portiD:{}, the response is gernerated for all available portID.
Valid range for portID is from 1 to 6.
When issuing a read request for a parameter an empty array is used, so the format shall be:
<paramValue >:{}
ParamID
Values
18

Description

1 Node
status

Indicates the node status

when PortID is empty then ALL node
status is returned.

7- Node
type

Returns the handset type for the

given portID

8- Node
attribute

Returns the attribute value for a

given node. There are 4 attributes
available per node. Attribute 0 for
pendants holds any ALARM or
EVENT indications.
Returns the IPEI value of a sensor
(unique 5 byte number). In contrast
to portID number, IPEI value does
not depend on registration
sequence.
Retrieves/Set the number the
pendant will call when alarm button

10 IPEI
read

April 10, 2012 v1.1

Comments

paramValue:
1 online
0 Not registered

See values below for details

HANDSET_TYPE_NONE = 0x00
HANDSET_TYPE_GENERIC = 0x0A
HANDSET_TYPE_PENDANT = 0x0B
RW

Web API

11
Configure

Port parameters

Read
/Write
-

R/W

Dialog Semiconductor B.V.

page 9 of 13

SC14DECTIPBS

pendant
direct call
number
12
Configure
ringing
melody
13
Configure
ringing
volume
14
Configure
vibration
mode
15
Configure
speech
volume

is pressed.

Retrieves/Set the ringing melody.

Valid values are from 1 to 7

R/W

Retrieves/Set the ringing volume.

Valid values are from 0 -5

R/W

Retrieves/Set the Vibration mode.

0 - Disabled
1 - Enabled

R/W

Retrieves/ Set the speech volume.

Valid values are from 0 -5

R/W

Web API

April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 10 of 13

ErrDesc UleErrEnum is
0.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.

ULE_Success, // Operation Succeed

ULE_Fail,
// ULE generic error
ULE_InitFail, // ULE failed to initialize
ULE_NotInitialized, // ULE is not initialized. Run ULE_Init first
ULE_PP_OutOfRangeError, // Tried to access a portable device out of range: id > PP_COUNT_MAX (64)
ULE_PP_AttrOutOfRangeError, // Tried to read an attribute value out of range MAXUSERATTRIB
ULE_PP_BusTimeOutError, // SPI bus failed to initialize during ULE system Init
ULE_AlreadyInitialized, // ULE sys is already initialized
ULE_PP_Reserved2,
ULE_PP_Reserved3,
ULE_SetRegModeError, // Failed to set ULE registration mode
ULE_PP_Reserved4,
ULE_PP_SetCodeError, // Failed to set ULE access code
ULE_PP_GetCodeError, // Failed to get ULE access code
ULE_PP_NotRegisteredError, // ULE ID device in not registered
ULE_Get_Registration_CountError, // Failed to read which devices are registered
ULE_TxAbortError, // Failed to Abort TX data transmit
ULE_TxBuffNoSpaceError, // Tx buffer is full
ULE_CmdTypeFmtWrong, // Json string : Format of Cmdtype field is wrong
ULE_IncorrectJsonInput, // Json string : Cannot parse Json string
ULE_CmdTypeWrongValue, // Json string : cmd type field is out of range
ULE_PortIdFmtWrong, // Json string : Format of portID field is wrong
ULE_PackIdFmtWrong, // Json string : Format of PackID field is wrong
ULE_DataFmtWrong, // Json string : Cannot read data field
ULE_DataFmtTypeMismatch, // Json string : data field is not an array
ULE_DataArrayTooLarge, // Json string : data field array is too large
ULE_sysParamTypeFmtWrong, // Json string : SysParamType format error
ULE_WriteOnly, // Json string : Can only write to property. Need to specify ParamValue
ULE_sysParamTypeUnknown, // Json string : SysParamType is out of range
ULE_ConfPortIdFmtWrong, // Json string : portID is not specified or is not a number
ULE_ParamFmtWrong, // Json string : Need to specify parameter array
ULE_ConfParamFmtIsnNotArray,// Json string : Need to specify parameter array
ULE_ConfParamFmtArrayErr, // Json string : Need to specify parameter array
ULE_ConfParamTypeFmtWrongID, // Json string : ParameterID is not specified
ULE_sysParamTypeFmtWrongVal, // Json string : Parameter value is not specified
ULE_NotImplemented, // Feature not implemented yet
ULE_ReadOnly, //Json string : Can only read this attribute and not set
ULE_ParamTypeUnknown, // Json string : Parameter ID is unknown
ULE_DeregistrationError, // Failed to deregister device
ULE_SensortypeoutOfRange, // User registers a function for a non valid sensor type
ULE_DatatypeoutOfRange, // User registers a function for a non valid data type
ULE_UserDataJSONOBJECTNotDefined, // JSON user command does not specify UserData field
ULE_UserDatahandleFunctionNotDefined, // JSON user command handler function is not specified yet
ULE_EarlyBitConfigurationInvalid, // JSON early send configuration bit is not 0,1 or 2
ULE_IPUIreadError, // Dect API failed to read IPUI

SC14DECTIPBS

APPENDIX A

Web API

April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 11 of 13

Payload format
A typical payload from/to a sensor is consisted of a maximum of 20 bytes. As described in the
MmiUlePdu_common_t structure in the MmiFpPpCommon.h, it is consisted of the following bytes:
rsuint8
MmiDataType_t

Length;
PayloadType;

SC14DECTIPBS

APPENDIX B

MmiUleSensHdr_t SensorType;
rsuint8

NextMess;

rsuint8

Data[16];

Byte 1: Length: This is how many bytes exist in the payload.

Byte 2: PayloadType: This byte is the payload data type. It defines the meaning of the Data[16] bytes.
Typical values for this byte are described in the MmiDataType_t structure.
Byte 3 sensor type: This is the type of the sensor that this message comes from/to. Typical values for this
byte can be the following. Typical values for this byte are described in the MmiUleSensHdr_t structure.
For the current release only a generic actuator and a generic button are implemented.
Byte 4: Nextmessage: This byte indicates whether all the data information is included in this message or
there is going more to be padded in the next one.
Byte 5-Byte 20: Data: 16 Bytes of data containing the information transmitted from/ to sensor. For
example for a HAL data type (MMI_DATA_TYPE_HAL) the meaning of this field is defined by the
MmiUleData_MmiDataTypeHal structure. For a wake up config data type
(MMI_DATA_TYPE_WAKEUP_CFG) the meaning of this field is defined by the
MmiUleData_MmiDataTypeWakeupCfg structure.

Each of those data structures may contain the UleAction field, which defines whether to read or write
the corresponding attribute value of the payload. For example in a switch with the following payload
format:
MmiUleAction_t
rsuint8
rsuint8

Switch_Cmd_Action;
Switch_Cmd;
DummyData[14];

// 1 = On, 0 = Off

The Switch_Cmd byte is treated by the device as described by the first byte Switch_Cmd:
IGNORE= 0,
WRITE_ONCE= 1,
WRITE_TO_NVS=2,
READ= 3

April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 12 of 13

Web API

Therefore the portable device can send a message to the fixed part to indicate its current status by
sending this payload:
[49,69,0,3,STATUS]
while the fixed part can set the value of an actuator ON/OFF by sending this payload to the portable
device:
[49,69,0,1,STATUS].

Network / IP-BASE / DECT data flow

This article here describes how data flows through the different components of the system by taking the
example in which user sends a JSON command to switch ON an actuator. A user does this by sending a
[{"cmdType":0,"portId":7," EarlyBit": 1,"data":[49,69,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}]

SC14DECTIPBS

Appendix C

Json command to IP base. The IP base replies back to the user with
[{"cmdType":0,"errDesc":0}]
indicating that the command was accepted (nothing was wrong with the parameters) and this message has
been scheduled to be send to the sensor. A positive reply back doesnt mean that the message was actually
send. The sensor may be sleeping at this time and may take minutes or even hours depending on the sleep
cycle configuration of the sensor to wake up and receive the message. Considering that only one message
per sensor can be send at a time, the user has to check the status of transmit buffer by sending Tx status
request for the sensor:

{"cmdType":1,"portId":7,"param":[{"paramId":2,"paramValue":{}}]}
At this point the TX buffer will remain full until the sensor wakes up and receives the message, or the
message gets rejected for some reason by the DECT radio or the user explicitly decides to abort the current
transmition and allow the sending of another higher priority payload:

{"cmdType":1,"portId":7,"param":[{"paramId":3,"paramValue":{}}]}
Now on the other way around, when a sensor sends a message back to IP BASE, the IP BASE will keep
placing the messages in a Receive cyclic buffer, one after the other, recording the timestamp in seconds and
assigning an incremental packetID to each packet. This buffer is 32 packets large.
Now the user has three options to read the data:
1)

By reading the Receive buffer through the JSON command (6 Return data)

{"cmdType":1,"portId":7,"param":[{"paramId":6,"paramValue":0}]}
User SW has to do the parsing regarding timestamps and packet IDs and every time send a new JSON
command with updated ParamValue=LatestPacketID to filter out messages already read.
This approach is encouraged to get used only if the user wants a history of the data, create graphs,
statistics, or do other data processing.
2)

By reading sensor attribute values

{"cmdType":1,"portId": 8,"param":[{"paramId":8,"paramValue":0}]}
In IP base there is the user application which run and can act with minimum latency in any sensor event.
This application can do any processing and pass information to the network though the "attributes"
In this demo the SW software is simply written to pass the value of latest switch read to attribute 1.
This method relies on user SW running in IP BASE to pass proper data to attribute values.
3)

By reading latest event data

{"cmdType":1,"portId": 8,"param":[{"paramId":9,"paramValue":49}]}

April 10, 2012 v1.1

Dialog Semiconductor B.V.

page 13 of 13

Web API

In most cases the user usually is interested for the latest data coming from a sensor of a given data type.
Past values may be of no interest and likely there may be no attribute written by the user application to pass
latest data. In the switch example datatype MMI_DATA_TYPE_SWITCH_220=49 gives the switch status,
therefore the user can send the command above to get the latest packet of this data type received from the
sensor and avoid option1 which requires extra effort on user side to do the necessary parsing.