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,

currently the customers split up firmware images into chunks of eg. 512 byte and push them to the device via downlink API requests (https://docs.iotcreators.com/reference/using-the-cdp-api).

We are currently working on a better support for FOTA in our IoT Creators portal. The portal will provide a capability to upload to and manage files in the device-download-space. From there the devices are able to download the files via e.g. HTTP or CoAP.

Regards, Roland

Hi Joop,

I will fix this.

Could you please give me your IMEI?

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,

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

@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 Rik,

can we have a conf-call about this topic. We are currently making customer interviews to understand your requirements better.

Yes, we can raise priority for this topic :)

I will send you and email to schedule a conf-call.

Regards, Roland

Hi,

currently the customers split up firmware images into chunks of eg. 512 byte and push them to the device via downlink API requests (https://docs.iotcreators.com/reference/using-the-cdp-api).

We are currently working on a better support for FOTA in our IoT Creators portal. The portal will provide a capability to upload to and manage files in the device-download-space. From there the devices are able to download the files via e.g. HTTP or CoAP.

Regards, Roland

@GrandPep I had a look to your configurations. I saw that you registered for your API account an application URL but I cannot see any subscriptions. I will verify it and come back to you…

Regards, Roland

@grandpep The API response “Accepted” with code “1002” doesn’t mean that the downlink message has been delivered to the device. It means the the message has been accepted and queued by the protocol specific IoT adapter.

Can you please send the IMEI of the device for which you try to send a downlink message with the API to our support box support@iotcreators.com?

Regards, Roland

@GrandPep Did you send an uplink message from the device after you posted a downlink message?

Downlink messages are not delivered immediately to the device. They are queued in the middleware.

Queued downlink messages are delivered to the device after the device has sent an uplink message.

The middleware queues up to 10 messages.

Regards, Roland

@GrandPep Hi, normally you should get the “Invalid Json format” only if something is wrong with the JSON in the HTTP body.

Can you please provide the HTTP code snippet which you get displayed in Postman when you click the “</>” symbol on the very right side of the Postman window ?

Please make sure that you change the Authorization tokoen oand the IMEI before you share it with us.

Many thanks!
Roland

Hi,

the first version of documentation for SIMCom SIM7022 how to

• attach the device to Telekom NB-IoT network of IoT Creators and get assigned an IP address.
• Send “Hello World” uplink message via UDP from device to IoT Creators UDP server.
• Send “Hello Device” downlink message via UDP from IoT Creators portal to device.
• Receive “Hello Device” downlink message on device via UDP from IoT Creators UDP server.

is available now in IoT Creators documentation library.

https://docs.iotcreators.com/docs/simcom-sim7022

Would be great if you check it and give me some feedback for improvements and corrections.

Regards, Roland

@Lauwie007 Can you please send your IMEIs to support@iotcreators.com? I like to analyse the problem in more depth and fix it.
Many many thanks for your support!
Regards, 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