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

Hi Peter,

I just contacted you via our support channel so I can do some additional tests to your connection.

Can you please send my your IMEIs as a response to the email which you just got.

Many thanks!

Regards, Roland

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.

@Lauwie007 For my understanding there is no difference if the function transfers “hi” or “01AB” as value.
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

@Lauwie007 Hi,

If I send “hi” with

PUT https://iot.netwerk.t-mobile.nl:443/m2m/endpoints/IMEI:867997031341158/downlinkMsg/0/data
and
BODY {
“resourceValue”: “hi”
}

I receive

AT+QISENDEX=1,11,48656c6c6f20576f726c64
OK
SEND OK
+QIURC: “recv”,1
AT+QIRD=1,100
+QIRD: 2
hi
OK

on the device.

Regards, Roland

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

@Gijs-Mos
I checked the UDP logs for your device and I agree. Your device doesn’t send the messages twice.

If your application end-point doesn’t return to our platform within 1 second we go into a re-try loop to re-deliver the message. We re-try max. 5 times. Every minute ones. If within the period of re-trieng additional messages from other devices arrive they are put into the same post request and delivered as an additional element of the “reports” array. But in this case you would see different serialNumbers and timestamps.

Is it possible that your callback returns sometimes slower than 1 second. In this case our platform would re-deliver the message a second time.

I saw cases where the application end-point didn’t publish the message into a queue for asynchronous processing. It processed the message directly and stored it away into a DB. Sometimes the DB blocked. By the this the response time was bad and the messages have been delivered a second time.

Regards, Roland

Hi,

many users ask via which IP address IoT Creators SCS forwards received uplink messages to the registered application callback URL:

IoT Creators SCS forwards the uplink messages to your application callback URL via one of the two IPs

• 18.195.119.162
• 18.195.17.174

Hope this helps you to configure the IP whitelists of your application.

Regards, Roland

• Before activating radio module Set APN with AT+QCGDEFCONT rather than **AT+CGDCONT
• Set frequency band explicity with AT+QBAND
• Configure first APN, fequency band and mobile operator ID before switching on automatic attachment

As you know the very-first-attachment to the network can take multiple minutes. Sometimes this creates problems in the production process.

Out of this reasons we are looking for possible measures to improve the very-first-attachment time.

Regards, Roland