Hi,

just published the first version of a tutorial how to integrate a “real” comfort sensor with IoT Creators, AWS Lambda, AWS Timestream DB and Grafana in our documentation library.

• Step 1: Register and activate sensor device
  • Register device in IoT Creators
  • Activate IMBUILDING comfort sensor

• Step 2: Create AWS user and role with IAM
  • Create Role for Lambda Function
  • Create User for Grafana Client

• Step 3: Create AWS Timestream DB
  • Create IoT DB
  • Create IoT Table

• Step4: Create AWS Lambda function for data decoding and injection
  • Create Lambda function
  • Create up-to-date boto3 library Layer and bind it to Lambda function
    • Create updated boto3 library with Timestream support
    • Create Lambda Layer for updated boto3 library
    • Assign updated boto3 library Layer to Lambda function

• Step 5: Make Lambda function accessable from the internet
  • Create API Gateway
    
  • Bind Lambda function to API Gateway
  • Test Lambda function and verify if data is written to Timestream DB
    

• Step 6: Add static authentication token to Lambda function
  
  • Create Lambda authorizer function
  • Bind Lambda authorizer to API Gateway
  • Test the authorization

• Step 7: Integrate IoT Creators with AWS Timestream DB
  • Register your AWS Lambda function as application callback in your IoT Creators project
  • Test the integration

• Step 8: Integrate Grafana with AWS Timestream
  
  • Add Amazon Timestream Plugin to your Grafana
  • Add Amazon Timestream Data Soruce to your Grafana

• Step 9: Create an IoT Dashboard in Grafana

• Step 10: Integrate AWS Simple Queue Service

Hi,

today we took a nice comort sensor (CO2/Temp/Humidity/BodySense) in Barcelona into operation.

We configured

• 21401 as PLMN ID for Vodafone Spain
• and used 20 for the frequencyband (800Mhz).
• cdp.iot.t-mobile.nl as APN for IoT Creators

It worked immediately without any problems.

Regards, Roland

Hi Stefan,

you are a cool guy!! This solved the problem. It was the whitespace.

Many many thanks for your support!!

Regards, Roland

Hi Stefan,

again many thanks. It works now. I can send data to my App. The following sequence works for Quectel BC66:

Deactivate auto sleep mode

AT+QSCLK=0

Persistent network and APN setup

AT+QBAND=1,8
AT+CFUN=0
AT*MCGDEFCONT="IP","cdp.iot.t-mobile.nl"

Restart the module as some configurations only take place after a reboot.

AT+QRST=1

After reboot wakup from sleep, deactivate auto sleep mode again and wait for network connect

AT+QSCLK=0

+IP: 10.128.0.134

Create a UDP socket and for UDP server

AT+QIOPEN=1,1,"UDP","172.27.131.100",15683,1001,0,0

Send message “Hello World”

AT+QISEND=1,11,48656c6c6f20576f726c64

Currently the API supports the following for functions/URLs to send downlink messages to the device

• downlinkMsg/0/data
  Sends regular queued downlink messages to device when uplink is received.

• downlinkMsgBase64/0/data
  Sends queued binary data blob message to device when an uplink is received. The function expects base64 encoded payload from the applaction as input into this function. Before the message is sent to the device it is decoded back to binary and sent to the device.

• downlinkMsgDrx/0/data
  Same like downlinkMsg/0/data but without queuing.

• downlinkMsgBase64Drx/0/data
  Same like downlinkMsgBase64/0/data but without queuing.

Hi,

we just published in our Documentation Library the description how to integrate development kit SODAQ SARA AFF R410M with LTE-M network and send and receive messages via MQTT.

It is located at https://docs.iotcreators.com/docs/sodaq-sara-r410m.

If you find bugs please let us know by sending an email to doclib@iotcreators.com.

Many many thanks to Erik!!

Regards, Roland

Hi Joop,

I will fix this.

Could you please give me your IMEI?

Regards, Roland

@paulvha This URL and headers work for me:

To get the list of all devices:
URL:
GET https://iot.netwerk.t-mobile.nl:443/rest/device?iDisplayLength=-1

Headers:
Content-Type:application/json
Authorization:Basic base64(<USERNAME>:<PASSWORD>)
Accept:application/json

This should work with your credentials:
curl -X GET https://iot.netwerk.t-mobile.nl:443/rest/device?iDisplayLength=-1 -H 'Authorization:Basic base(<USERNAME>:<PASSWORD>)

As you can see the request works also without Content-Type and Accept.

To get the details of a single device:
URL:
GET https://iot.netwerk.t-mobile.nl:443/rest/device/<ID>

Headers:
Content-Type:application/json
Authorization:Basic base64(USERNAME:PASSWORD)
Accept:application/json

To get the details of the device don’t use the deviceId!

Regards, Roland

Hi Mario,

Tuino 096 is an Arduino Zero (M0) compatible board. Grove Base Shield V2.0 doesn’t support this explicitity.

I recommand to try"ARDUINO MKR CONNECTOR CARRIER (GROVE COMPATIBLE)" instead. With this shield you can bridge from Zero/M0 to sensors with Grove connectors.

Regards, Roland

Hi guys,

after we integrated the connectivity from Magenta Austria in the last days with IoT Creators/SCS platform succesfully I tryed with my devkit Quectel BG96 not only NB-IoT but also LTE-M and GSM - unfortunately pure LTE is not supported by the devkit.

It worked immediatly

With following AT commands I could connect to our Telekom network in Germany and send UDP messages to our server:

# Set frequency band for Telekom Germany
AT+QCFG="band",0,0,80,1					

# Set our APN
AT+CGDCONT=1,"IP","scs.telekom.tma.iot"

# Use 0 for GSM  ...
AT+COPS=1,2,"26201",0

# ... or 8 for LTE-M
AT+COPS=1,2,"26201",8

# ... or 9 for NB-IoT
AT+COPS=1,2,"26201",9              

# Connect to our UDP server
AT+QIOPEN=1,1,"UDP","172.27.131.100",15683,1001,0

# Send "hello world" as hex
AT+QISENDEX=1,"48616c6c6f20576f726c64"

This is really cool !!

Cheers, Roland

@Hans-Liefting: Can you please send me the IMEI of your device to support@iotcreators.com? I will check the logs to understand when uplink and downlink messages are received and when downlink messages are sent by the udp server.

Regards, Roland

@Hans-Liefting Hi,
I am not sure if I understood your process correctly …

Process ?

1. Device wakes up and connects to the network
2. Device send uplink message
3. Application receives the message and response with a downlink acknowledgment
4. Device waits for 10 seconds
5. Device closes the connection and shuts down.
6. After one hour process is repeated at 1.

Problem ?
Downlink message isn’t received by the device reliable.

If you send a non-eDRX downlink message our UDP broker queues the messages until it receives the next uplink message from the device. This means your application acknowledgement message requires an additional uplink messages to let UDP broker deliver the queued downlink message to your device.

In case you send an eDRX downlink message you can try to extend the 10 secs wait to e.g. 30 secs and see what happens. As you know eDRX messages are not queued by the UDP broker. eDRX messages are immediately pushed to your device by the UDP broker. In case you device sleeps the downlink messages are queued by the mobile network. If you are using eDRX downlinks it could be possible that 10 secs not enough for the network to deliver the message and 1 hour of buffering is to long. Maybe this is reason why it works if you wakeup every 5 minutes.

Regards, Roland

@magnatron Did you already send me your account, the project and the imei of the device. I like to check the logs. You can send it to roland.baldin@telekom.de.

Regards, Roland

@magnatron In case you still not able to send downlink messages to your device please provide your account, project and the device imei to our support@iotcreators.com . I will take a look on it.

Regards, Roland

Last comment …

This is valid only for non eDRX downlink messages. eDRX messages are sent directly into the network and will be buffered by the mobile network until the device is available.

Unfortunately I don’t know how long the downlink message is buffered by the mobile Telekom network

Regards, Roland

In case of UDP our middleware manages for each device an out-queue for downlink messages.
The max. size of the queue is 10 messages.
After an uplink messages has been received all queued downlink messages are delivered to the device 1 messages / sec.
If the devices never sends an uplink messages the downlink message stays in the out-queue for ever.
If the device is deleted the out-queue for downlink messages is deleted as well.

Hope this info helps.

Regards, Roland

@magnatron Hi, I double checked our “Elastic IPs” and found out, that the 18.195.119.162 as documented in the documentation library is wrong

The correct IP is 18.197.119.162. It was a typo. Sorry!

I checked it with my application and I could see the IP in the x-forwarded-for header field of my Azure function.

Thanks for let us know this!

Regards, Roland

We integrated a broker for standard CoAP devices with the middlware platform of IoT Creators.
Even when the portal application of IoT Creators doesn’t support standard CoAP yet we want to provide you the possibility to play arround with it and do some tests.
In the following I describe the steps to register a standard CoAP device and subscribte to it with the API. By this the messages of the device can be forwarded to your application URL in the same way like it is done by the portal application.

As UDP or the Neul protocol standard CoAP requires the usage of an IoT Creators SIM card and you can reach the CoAP server at IP 172.27.131.180 and port 5683 only by setting APN: cdp.iot.t-mobile.nl (or scs.telekom.tma.iot if you use SIM card from Magenta Austria)

1. Register your application URL for the API user
You need to register at least a dummy application URL for the
API user because otherwise it will not be possible to create
new devices via the API.

You find the username and the password of your API user in the
page “YOUR APPLICATION SERVER” of your IoT Creators Projects.

REQUEST PUT https://api.scs.iot.telekom.com:443/m2m/applications/registration
REQUEST HEADERS: {
  'Content-Type': 'application/json', 
  'Accept': 'application/json', 
  'Authorization': 'Basic <base64(API-USER:API-USER-PASSWORD)>'
}
REQUEST BODY: {
    'url': 'https://dev.scs.iot.telekom.com/scs-callback-dummy', 
    'headers': {
      'key1':'value1'
    }
}

RESPONSE BODY: {
    "msg": "Success",
    "code": 1000
}

2. Create the Std. CoAP device in IoT Creators
You find the username and the password of your API user in the
page “YOUR APPLICATION SERVER” of your IoT Creators Projects.
You find there also the “groupName” for the request body in
this page as well.

You can add a list of key/value pairs as addtional “customAttributes”
to the device. Those key/value pairs are passed along with each
message of the device to the configured application URL.

REQUEST POST https://api.scs.iot.telekom.com:443/m2m/endpoints

REQUEST HEADERS: {
  'Content-Type': 'application/json', 
  'Accept': 'application/json', 
  'Authorization': 'Basic <base64(API-USER:API-USER-PASSWORD)>'
}

REQUEST BODY: {
  'serialNumber': 'IMEI:512668894698385', 
  'groupName': 'CON_0000002299', 
  'protocol': 'HTTP', 
  'additionalParams': {
    'adaptationLayerName': 'STDCOAP_TEST'
  }, 
  'address': '', 
  'identifier': '', 
  'customAttributes': {
    'deviceType': 'Efento'
  }
}

RESPONSE BODY: {
    "msg": "Device added successfully",
    "code": 3000
}

3. Create subscription for the Std. CoAP device
Because the support for Standard CoAP devices are not 100%
finished in the IoT Creators portal I recommand to
add the suscription also with the API.

REQUEST POST https://api.scs.iot.telekom.com:443/m2m/subscriptions?type=resources

REQUEST HEADERS: {
  'Content-Type': 'application/json', 
  'Accept': 'application/json', 
  'Authorization': 'Basic <base64(API-USER:API-USER-PASSWORD)>'
}

REQUEST BODY: {
  'subscriptionType': 'resources', 
  'groupName': 'CON_0000002299', 
  'deletionPolicy': 0, 
  'resources': [
    {
      'conditions': {}, 
      'resourcePath': 'uplinkMsg/0/data'
    }, 
    {
      'conditions': {}, 
      'resourcePath': 'downlinkMsg/0/data'
    }
  ], 
  'criteria': {
    'serialNumbers': ['IMEI:512668894698385']
  }
}

RESPONSE BODY: {
    "subscriptionId": "8974985d-fa8c-472d-8ae3-202e18143e1d",
    "msg": "Success",
    "code": 1000
}

Have Fun

Regards, Roland

Hi,

instead of creating and deleting complete subscriptions after you added or deleted devices you can add or remove the device to or from from the existing subscription.

In the following the Nokia IMPACT API samples

• to get the devices of an existing subscription,
• list itemto add a devices to an existing subscription,
• list itemto delete a devices from an existing subscription (important: if the last device of a subscription is delete the subscription it-self is deleted as well).

Get devices of an existing subscription

GET https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
 "Content-Type": "application/json", 
 "Accept": "application/json", 
 "Authorization": "Basic QVBJX0NPTsl8wMDssAswMDAbxNcTU4XzNlZmEzOkpySS9YOC45Y19CrrRmI0OEY="
} 
BODY: {
 "serialNumbers": [
 "IMEI:452749630137052", 
 "IMEI:351938100191440"
 ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "serialNumbers": [
    "IMEI:454596441983713",
    "IMEI:351938100191440",
    "IMEI:866425033313638",
    "IMEI:452749630137052",
    "IMEI:352656100979544"
  ]
}

Add devices to an existing subscription

POST https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
  "Content-Type": "application/json", 
  "Accept": "application/json", 
  "Authorization": "Basic QVBJsX0NPTl8wMDsssswMDAbxNcTU4XzNlZmEzOkpySS9YOfgC45Y19CRmI0OEY="
}
BODY: {
  "serialNumbers": [
    "IMEI:452749630137052", 
    "IMEI:351938100191440"
  ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "subscriptionId": "f37b094d-307f-4d43-82c5-73f81104e22f",
  "msg": "Success",
  "code": 1000
}

Delete devices from an existing subscription

DELETE https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
 "Content-Type": "application/json", 
 "Accept": "application/json", 
 "Authorization": "Basic QVBJsX0NPTl8wcMDssAwMDAbxNabcTU4XzNlZmEzOkpySS9YOC45Y19CRmI0OEY="
} 
BODY: {
 "serialNumbers": [
 "IMEI:452749630137052", 
 "IMEI:351938100191440"
 ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "subscriptionId": "f37b094d-307f-4d43-82c5-73f81104e22f",
  "msg": "Success",
  "code": 1000
}

@magnatron It was never possible to store the application url if the application didn’t return 200.

In the old version the inital request contained an empty body to test if the URL is valid. This has actually changed. No an empty dictionary structure is put as payload.

Regads, Roland