Posts made by Yassine Amraue

Hi @magnatron, can you tell us if this solved your issue?

Best
Yassine

Hi @magnatron, Yes the devices are shown independent of whether you create them with the API or the GUI but regarding callback URLs (or better: northbound application) the logic is that each user has it’s own northbound application. That’s how the IAM works with the platform. End each user needs to have an application registered to be Authorized to use certain API calls (like downlink messages).

Best
Yassine

Hi @magnatron did you set the callback URL using the portal or the API? To use downlink messages with the API you need to set the callback URL using the API and the credentials for the API user.

Explenation: There is two different users associated with your tenant, an API user and a GUI user. If you set the callback URL with the portal it is done with the GUI user and only this user is then authorized to send downlink messages. If you send downlink messages using the API (i.e. with the API user credentials) that user also needs to have an application URL registered.

Best
Yassine

@Kurosh

I don’t see the URCs arriving at your screen. As described in my last message, please configure your URC port.
If it is configured correctly you should see something like this:

ate0 
ate0

OK

at+cfun=0 

OK

at+qcscon=1 

OK

at+cereg=2 

OK

at+cfun=1 

OK

+CPIN: READY

+QUSIM: 1

+QIND: SMS DONE

at+cops=1,2,"26201",8 

OK

+QCSCON: 1,1

+CEREG: 5,"6F55","18CB40E",8

+QCSCON: 1,0

+CEREG: 5,"6F55","18CB404",8

Notice that the +QCSCON: 1,1 and +CEREG: 5,“6F55”,“18CB40E”,8 pop up automatically.
Also right after turning on the radio with AT+CFUN=1 you can see

+CPIN: READY

+QUSIM: 1

+QIND: SMS DONE

popping up automatically. I dont see that in your logs. Please configure your URC port and issue the commands as I’ve shown in the example here.

Best
Yassine

Hi Kurosh,

In an earlier message when you changed the APN it was working fine. Is there anything you changed since than? In general your AT commands seem fine.

Can you please do the following:

Turn off the radio with AT+CFUN=0. Do a AT+CEREG=3 and AT+QCSCON=1 (or if that doesn’t work use AT+CSCON=1). This will automatically print URC messages giving us an indication about what the module is doing. You should see automatic +CEREG and +CSCON messages arriving on your screen when you try to attach. If that doesn’t happen, your URC Indication configuration is not correct. Try using the command AT+QURCCFG=“urcport”,[“usbat” or “usbmodem” or “uart1”]. This depends on which serial port you are using so just try out one after the other, reboot the module and see if you get the URCs (an indication that it’s configured correctly is that you get a +CPIN: READY automatically printed on the screen when the module boots up.)

After that please send the logs so we can try to figure out what is going wrong.

Best
Yassine

Awesome news ahead: LwM2M v1.2 specification is finally released! One of the headlining features of LwM2M v1.2 is LwM2M over MQTT! This is a good opportunity for LwM2M to get way more visibility, as MQTT (arguably the most popular IoT protocol) is currently missing any real data model.

LwM2M 1.2 feature highlights: [1]

• State-of-the-art energy-efficient security—Leveraging (D)TLS 1.3 and Connection ID enhances security while reducing the challenges and energy losses of connecting devices over LPWAs like NB-IoT.

• MQTT as a transport protocol—MQTT users can now add LwM2M device management functionality. Inversely, using MQTT as a transport mechanism for LwM2M simplifies connecting to the cloud in some scenarios.

• Single-step device commissioning—Now, bootstrapping a device requires just a single bi-directional session instead of the previous five exchanges, saving time, energy, and other resources.

• Optimized data reporting—LwM2M data-format optimizations shave bytes from each message, increasing energy-efficiency, device lifespan, and return-on-investment (ROI).

More details: [2]

• New transports for LwM2M; this allows LwM2M messaging to be conveyed over MQTT and over HTTP.
• Optimizations for the bootstrapping interface; this reduces the amount of data and the number of messages transmitted during the bootstrapping exchange.
• Optimizations for the registration interface; this reduces the amount of data transmitted during registration exchanges.
• Optimizations for the information reporting interface; observation attributes may now be included in an Observe operation.
• Support for LwM2M gateway functionality; this allows non-LwM2M IoT devices as well as LwM2M devices behind a gateway to be connected to the LwM2M ecosystem and to manage those devices remotely.
• New, highly optimized encoding format based on CBOR called LwM2M CBOR.
• Enhanced functionality for firmware updates.
• Definition of new notification attributes (edge, confirmable notification, and maximum historical queue). Edge allows notifications to be triggered on rising and falling edges. Confirmable notifications allow the control of reliable transmissions of notifications.
• Maximum historical queue allows the control of time-series data usage. Clarifications of object versioning rules.
• Updates to use the latest communication security protocols based on TLS and DTLS 1.3 (as well as the use of the Connection ID).
• Flexibility to control the use of TLS and DTLS 1.3 through configuration information.
  Untangling the relationship of security credentials and their server configuration.

[1] https://ioterop.com/lightweight-m2m-1-2-iot-device-management/
[2] http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/OMA-TS-LightweightM2M_Core-V1_2-20201110-A.pdf
[3] http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/OMA-TS-LightweightM2M_Transport-V1_2-20201110-A.pdf

@Holger-Wech: @Uta can help with that!

Dear Holger,

I am doing well, thanks! Hope you as well

Strictly speaking it will work when you have good coverage but it doesn’t make a lot of sense for NB-IoT especially because the battery is suffering a lot while trying to send that much data frequently.
In worse coverage conditions, where the latency is higher and the bandwidth lower you will run into problems, guaranteed.

Yes, we cover Frankfurt/Darmstadt area

In your case, you can’t go wrong with LTE-M and I think you will be very happy with it. Try it out!
The battery efficiency is still high and the bandwidth gives you more freedom for your use cases.

Best
Yassine

Hi Holger,

So in general it really depends on what you mean with “access AWS”.

One possibility is to get a Mobile IP-VPN where you have a private IPSec tunnel from an APN (i.e. Telekom Mobile Network Core) to a Site-to-Site VPN in your AWS account. Your devices can not reach the public internet then but only instances/services in AWS (using private IP adresses of the instances).

If you have a SIM card with a public APN (which you have) you can reach public IP addresses from your device. This includes of course also EC2 instances in AWS that have a public IP address. With NB-IoT you would have to make sure that the way you communicate with your EC2 instance is based on a UDP-protocol because NB-IoT is limited in regards to bandwith.

If you want to use AWS IoT/Greengrass, you are going to run into problems with NB-IoT and we do not recommend it. AWS IoT is based on MQTT which is based on TCP. NB-IoT is (as the name suggests) NarrowBand. The pipe is just too thin for protocols based on TCP. AWS IoT does currently not support protocols that are suited for Constrained Devices (e.g. CoAP, LwM2M).

It is a whole different story for LTE-M though, because LTE-M has way higher bandwidth and MQTT will work perfectly fine.

Hope this answers the question!

Best
Yassine