For a LwM2M device, C8Y always performs queuing even if queue mode is set to false (Binding Mode: U) on registration. This can be observed by:
Device successfully registers.
A read (or write) is issued from the shell, but due to say a temporary loss of connectivity the read timeouts. Because of this timeout the device is considered “offline” by C8Y.
Any subsequent read is then queued and will only be completed after the next successful registration update which could be up to 24 hours later.
So could C8Y be modified so that:
If on registration a device’s queue mode is set to false (Binding Mode: U). It should be assumed that the device is always online, and C8Y should try the read/write/operation immediately. If the operation fails (after the configured retries), say due to a timeout, it should be marked as failed and no further action taken. In other words the read/write/operation should never be queued to try at a later time.
If on registration a device’s queue mode is set to true (Binding Mode: UQ). C8Y should operate as it does now i.e. it should be assumed that the device maybe online. C8Y should try the operation & if it times-out it should be queued, until the next time the device is online. It would be useful to also add the following:
Some configurable job timeout like 48 hours i.e. what happens if a device never comes back online.
Deduplication. No sense adding the same read/write/operation to the queue again if it’s already present.
Hi Aaron,
Has there been any progress on this Feature Request? Has it been scheduled to be implemented in a particular upcoming version?
Regards
Iain
Hi Aaron,
Increasing the registration frequency could be a temporary workaround. But it has real cost implications as each registration update incurs at least 1 MEA, plus it’s extra cellular data that must be paid for as well. In my view, C8Y needs to properly honor the queue mode setting.
A typical scenario for us is realtime control of a LwM2M device from the server e.g. turning on a streetlight. The operator needs to know that the device has either successfully performed the action (streetlight is on) or it’s failed in a timely manner. Queueing it up to try at a later time (even if it’s just ten minutes later) makes no sense.
Regards
Iain Mackenzie
Hi Iain,
the underlying problem here is that for devices that are anyway online you don’t want to wait 24h for the device to pick up new operations. But if the device is anyway online all the time I assume that energy consumption is not an issue. In that case you could also change the frequency of registration updates to let’s say 10 minutes. Is there from your side anything that speaks against this approach?
Best regards,
Aaron
Hi Iain,
this is something we agreed on implementing once we find the time for it (as there are still many things in our backlog we need to work on first).
Best regards,
Aaron