@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

Unfortunately, LTE-M is not commercially available yet. I will answer to your email to give you some options.

@roalnd-baldin It seems to work with curl in command if the data-raw is rewritten like so:

–data-raw “{
\“resourceValue\”: \“48656c6c6f20446576696365\”
}”

In command we get a nice “msg”:“Accepted”,“code”:1002 response but in Postman it does not work. And with the registration to https://{{base_url}}/m2m/applications/registration this was not an issue.

@jeroen-van-bussel it’s great to hear 👍

NB-IoT and LoRa - partners in crime🕵🏽

@lauwie007 It’s a new feature we added a while ago - at the moment, unfortunately, you need to set it when registering the devices and cannot be changed later. So you would need to re-add the devices to make it work.

Let’s set up a call and we can go through some options regarding the different end-points with multiple projects. Please just send me an email to florian@iotcreators.com with some meeting proposals.

Hello again toustousio,

the reason why devices have to send an uplink message first to receive downlink messages lies in the nature of low-power wide-area devices, which are designed to use as little energy as possible to maximize battery life. This is achieved by putting devices to sleep. Keeping an open channel that can constantly receive data would go against any power-saving measures. Therefore, a device has to initiate the communication and basically send a “heartbeat” message to show that it is awake and available to receive information. Just like LoRaWAN class A devices, which do not maintain a constant network connection to reduce power consumption.

Using NB-IoT and eDRX, it is possible to move the buffering function of messages into the network to send the messages directly to your devices, without sending an uplink message to our platform every time before receiving downlink messages.
This is possible via our API and works just like sending a downlink message as described here with a few changes that I have detailed below.

URL: https://api.scs.iot.telekom.com:443/m2m/endpoints/<SERIAL-NUMBER>/downlinkMsgBase64Drx/0/data

HEADER:
Content-Type: application/json
Accept: application/json
Authorization: Basic <based64(<API-USERNAME>:<API-PASSWORD>)>

BODY:
{
“resourceValue”:<YOUR base64 encoded VALUE>
}

KEEP IN MIND:

This function requires that <YOUR VALUE> is a base64 encoded. Before it is sent to the device <YOUR VALUE> is decoded, to be able to send binary data without double the data volume caused by the hex format. eDRX messages are sent to the mobile network and buffered/queued by the network provider while the device is sleeping. Because eDRX messages need to be sent to an IP address our server stores the last IP address from the last uplink message and if you haven’t send any uplink messages or if your device has renewed its IP address, the eDRX message cannot reach your device. Deutsche Telekom’s network is configured to store a max of 10 messages with 500 bytes per IMSI. This is also limited to a certain percentage of the specified number of devices (overall capacity). This behavior can deviate for roaming scenarios, since not all networks are configured the same way.

I hope this answers your question.
Do not hesitate to reach out, if you have any addtional questions or problems.

Hej Gerrit,

I’m sorry to hear that you are having problems with additional devices. Unfortunately, we won’t be able to troubleshoot easyconnect SIMs from T-Mobile as they are not connected to IoT Creators.
T-Mobile should have a support number, which you can call for help or you could reach out to 1nce, since the service is based on their platform.
If you are using SIM cards from IoT Creators, then the APN advice from fm would be your best bet and you can also contact us again with the SIM card details to troubleshoot them on our end, if that hasn’t solved your issues.

And it works ! I could register my SIM card, and after starting my FiPy test program it connected within 30 seconds. Thank you.

@cees-meijer we plan to offer LTE-M in 2 flavors in the future:

replacement for GSM with communication over public APN without any middleware layer in between module and your servers - AVAILABLE NOW alternative to NB-IoT with secure communication and access to data via webhook through IoT Creators platform (for this one we need a new component in our backend and still investigate the customer needs that helps us with proper planning) - FUTURE

@sergii-skorostetskyi we didn’t get to integrate the LTE-M traffic with our device management platform yet. We’re still working on displaying some SIM related data in the portal. We’ll hopefully launch this feature soon, please watch our release log page. Device management will come hopefully beginning of 2022.
Do you need sonething urgently? Please let me know what you are planning, because we usually plan our priorities according to user feedback.
(I’m sorry for the late response! Somehow this post wasn’t noticed in the “General discussion” section. My apologies.)
Regards, Uta

@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

@derko-drukker

I think you have been in touch with Roland already, right?

Just to be sure 🙂

Hello guys

@Yassine-Amraue : thank you for explaining that there is a GUI and an API user. I’ve been banging my head trying to send a downlink message via API and always getting an ‘unauthorized’ error. But after registering a callback URL for the API user as well I can now send downlink messages via API to my device. Thanks again.

@magnatron : I am using a SIM7020 based device and previously via API sent downlink messages are getting delivered to it as soon as the device sends an uplink message.

Thanks
Felix

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

@Ederuiter @afzal_m
Thanks.
We were thinking in that direction (sending version)
Another reason why I asked is that since I started sending downlinks to a (devkit) device for testing purposes, the device now is extremely slow in sending messages. It takes minutes, sometimes hours to send a single message (uplink).
Could that be linked to not “collecting” the downlink messages?

Hi @magnatron,

I agree this can be a bit confusing, but this is currently necessary for the portal to work correctly.

Devices added are visible for both

^ This is correct; devices belong to a project and both users belong to the same project.

The application added through portal will NOT be subscribed to devices added through API

^ This a bug and we are working on a fix for this

The application added through API seems tp be subscribed to devices added through portal (or is it?)

^ as far as I know only the subscription of the portal is updated, not your own subscriptions

It’s not possible to verify through portal what you did through API

^ this is correct. As the api provides a lower level access with more flexibility, it is currently not possible to show what you did in the portal.

Most of these issues you can workaround by using the mysubscriptions endpoint you will only see the subscriptions of your own user; not the portal user.

The reasoning behind the different functionality in the api / portal was to have an option for users needing more functionality than offered by the portal (ie: multiple endpoints) by giving them access to the underlying api … downside is the complexity of it.

Ideally the portal should cover all the functionality and we have and we can add an high level api so you can automate all the actions you do in the portal. So if you have any suggestions on what functionality is missing that you need the api for, let us know your use-case so we can see if that is a good fit for integration in the portal.