As I understood it the network only buffers upto 10 packets for a device. So depending on how long your devices sleep and how fast the data is pushed to the device, you can easily overrun that buffer. If the underlying protocol does not have a retry mechanism (eg: udp) the data is lost.
The impact platform is not aware of this as this is handled by the telco network.

The ideal solution would be to use something like lwm2m and let the device request the firmware in boot sequence and let the device download the firmware from our platform … unfortunately this is not yet supported.

@afzal_m probably has some examples/best practices of how this can currently be achieved

As I understood it the network only buffers upto 10 packets for a device. So depending on how long your devices sleep and how fast the data is pushed to the device, you can easily overrun that buffer. If the underlying protocol does not have a retry mechanism (eg: udp) the data is lost.
The impact platform is not aware of this as this is handled by the telco network.

The ideal solution would be to use something like lwm2m and let the device request the firmware in boot sequence and let the device download the firmware from our platform … unfortunately this is not yet supported.

@afzal_m probably has some examples/best practices of how this can currently be achieved

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.

Hi @Cees-Meijer ,

Yes you are right, I was thinking of the mysubscriptions endpoint:

{{base_url}}/m2m/mysubscriptions

This endpoint should only list the subscriptions associated with your user.

Hi Cees,

The portal uses a different user to manage the subscriptions for all the devices in the project; so you will not see those subscriptions when using the API.
How you manage the subscriptions for your user is completely up to you, you can choose to add a new subscription for each device or you can reuse a subscription and add devices to it.

Multi endpoint capabilities are on the backlog/wishlist for the portal but we currently don’t have a date/sprint for it. If your use case requires this, please contact the iotcreators team to discuss this with them.