moved from thingsboard/thingsboard#15595 to here at request of https://github.com/mykhailokornieiev as it seems both Thingsboard server and client SDK is involved.
When we work with embedded devices with limited receive buffer size due to RAM constraints the buffer is often large enough for 1 or 2 shared attributes' JSON but too small for many of them all at once ( especially if there are multiple shared attributes to control device features or teh contents of the shared attributes is large Strings or JSON / XML configs ).
when one uses shared attributes to control settings / functionality / configurations on these devices ( for persistent server set configurations or config change scheduling when the device is offline )
The issue happens when a device powers on subscribes to shared attributes, then requests them from the server ( to get current values ) .
The server will respond with a single message publish to the telemetry MQTT topic containing all of the shared attributes for a device. If there are many attributes the single JSON message can be larger than a device's recieve buffer ( in thingsboard-client-sdk the message will be dropped and none of the shared attributes will be parsed until they are individually changed on the server ( then they are pushed as they change , and thus small enough to fit the RX buffer)
Describe the solution you'd like
a setting / flag in TB for shared attributes ( perhaps on the device profile ) where one can set whether Shared attributes are sent down/ published as one large message when they are requested, or sent down in sequence with a delay / rate limit between publishes
Describe alternatives you've considered
using PSRAM on my ESP32 devices to have a very large RX buffer, STM/ other embedded devices don't have this convenience.
Additional context
another approach is to have parameter as part of the attribute request / subscribe sequence of a device to set this flag on a -per device- level, in thingsboard-client-sdk or the device registration in in thingsboard-client-sdk ( like what is done when gateways subscribe to identify them as a gateway , but the 2nd approach touches on client-SDK, TB-ateway, python sdk.. whereas a mod to that thingsboard server is only 1 ' surface' and is backward compatible if the default for "sendChunked" is false..
moved from thingsboard/thingsboard#15595 to here at request of https://github.com/mykhailokornieiev as it seems both Thingsboard server and client SDK is involved.
When we work with embedded devices with limited receive buffer size due to RAM constraints the buffer is often large enough for 1 or 2 shared attributes' JSON but too small for many of them all at once ( especially if there are multiple shared attributes to control device features or teh contents of the shared attributes is large Strings or JSON / XML configs ).
when one uses shared attributes to control settings / functionality / configurations on these devices ( for persistent server set configurations or config change scheduling when the device is offline )
The issue happens when a device powers on subscribes to shared attributes, then requests them from the server ( to get current values ) .
The server will respond with a single message publish to the telemetry MQTT topic containing all of the shared attributes for a device. If there are many attributes the single JSON message can be larger than a device's recieve buffer ( in thingsboard-client-sdk the message will be dropped and none of the shared attributes will be parsed until they are individually changed on the server ( then they are pushed as they change , and thus small enough to fit the RX buffer)
Describe the solution you'd like
a setting / flag in TB for shared attributes ( perhaps on the device profile ) where one can set whether Shared attributes are sent down/ published as one large message when they are requested, or sent down in sequence with a delay / rate limit between publishes
Describe alternatives you've considered
using PSRAM on my ESP32 devices to have a very large RX buffer, STM/ other embedded devices don't have this convenience.
Additional context
another approach is to have parameter as part of the attribute request / subscribe sequence of a device to set this flag on a -per device- level, in thingsboard-client-sdk or the device registration in in thingsboard-client-sdk ( like what is done when gateways subscribe to identify them as a gateway , but the 2nd approach touches on client-SDK, TB-ateway, python sdk.. whereas a mod to that thingsboard server is only 1 ' surface' and is backward compatible if the default for "sendChunked" is false..