Bucket - From Device Resource: Sampling Interval vs Stream by Device

George_Santiago · January 20, 2022, 4:18pm

I did tests with Sampling Interval vs Stream by Device. And I thought that Sampling Interval exhibited behavior that I would like to understand better.
I decided to write this post, because I understood that Sampling Interval caused an unexpected behavior when using an unstable internet connection via GSM (Module SIM800C).

I connected two devices (ESP8266) with SIM800C (internet via GSM) and did tests for 22 hours. On the first device, I used Sampling Interval to write the data to the Bucket. On the second device, I used Stream by Device (I used the thing.stream function).

Result: The Sampling Interval mode caused unexpected results in the final part of the test when sending too much data to the bucket, causing the device to be disabled on the Thinger Server.

I thought that in Sampling Interval mode, the Thinger Server synchronized with the device to guarantee sending data in a certain time. The “problem” I identified is that this synchronization does not exist. And Thinger Server always requests data from the device in case of disconnection and connections, without respecting the interval time. After 22 hours of testing, there were several disconnections and connections of the device, which made the Thinger Server frequently request data, without respecting the configured time interval. See the images below:

I set the Sampling Interval to 5 minutes. But at various times he was not respected. Probably because of device disconnections and connections on the Thinger platform.

After 22 hours of testing, the Sampling Interval mode caused a critical situation, which made the Thinger Server disable my device after too many Bucket writes. OBS: Maybe it’s a bug in the Private Server or is it necessary to configure this warning with NodeRED? See image below:

In Stream by Device mode, everything went more smoothly and as expected. The device sent data, respecting the 5 minute interval I set in the code with the thing.stream function.

Questions: Is the behavior of the Sampling Interval mode correct? Does it request data from devices at each connection, without respecting the configured time interval?

If yes, then when using an unstable internet connection (especially via GSM or distant WiFi) should we use Stream by Device mode?
If so, the downside is that we will have to create an API to control Stream by Device intervals. I made it. I created an input variable to control the Stream by Device time. But I don’t think that’s ideal.

For me, the Sampling Interval mode should respect the configured interval, even in case of disconnecting and connecting the device.

Finally, it would be interesting to check the reason why the Private Thinger Server did not send the communication email informing the deactivation of the device. Maybe it’s a bug. Or is it necessary to do this configuration via NodeRED?

Another “problem”: After the Thinger Server had disabled the device for overwriting data in the bucket, I went to the settings and enabled the device again. But I couldn’t get the Thinger Server to allow its connection and authentication. So I deleted the device from the Server and re-registered it with the same Device Id and Device Credentials. Only with this procedure did the Thinger Server accept the device connection. Wouldn’t that be a bug?

ega · January 21, 2022, 4:31am

Hi,

The server synchronizes the data interval when the devices connects, I mean, if you setup the device to get data each 5 minutes, but it reconnects before it reach the 5 mins interval, each reconnection will ask for the value and will start the 5 min counter since last connection.

The stream by device works better because the device does not reset the counter, if you set it up to send data each 5 minutes, it will try to do it each 5 minutes, that is why you see a better behaviour, the server is not designed to have interrupted or unstable communication to the devices, that is the main reason of the unwanted behaviour.

Did you modify the email server or something? because the cloud should send the notification email, but when it is modified sometimes it doesn’t work properly.

The disable-enable behaviour is weird, I’ve had the same situation and enabling the device at its page it works without issues, even yesterday I had that situation, and I noted that when it is disabled neither the nodered detects the conn attempt, but I could get connection just enabling it again.

Hope this helps.