How to stop RUT906 sending unsent data using Data to Server

[karan]

Setup

• A Delta PLC connected to the RUT906 using ETH on ETH1

Configuration

• Used Modbus TCP Client To fetch some data registers from the PLC
• Used Data to Server to send those Modbus data to my API in JSON using HTTP method

Issue

• For example, if my API goes down for some reason
• The gateway is still polling the PLC in real time but cannot send that data since the API is unreachable
• Those unsent requests get stored in a database or RAM
• The moment the API is live again, the gateway floods my API with all that backlog of data without any delay continuously until everything is sent

This flooding of data is effectively DDoS’ing my server with a ton of data

Is there any way i could disable this feature or limit the number of unsent data to be sent?

I also had another doubt, What exactly is this configuration option supposed to do: Services > Modbus > Modbus TCP Client > Global Settings > Enabled (True/False) i tried disabling this as it seemed like the database that stored the unsent data but it just resulted in the gateway sending {“example_data”:”N/A”}

[Matas]

Hello,

One way to disable the collection and re-sending would be to edit the Collection settings, and simply disable “Retry”: RUT906 Data to Server - Teltonika Networks Wiki

There’s no specific setting to limit the amount, but you can limit the number of retries instead.

@karan

I also had another doubt, What exactly is this configuration option supposed to do: Services > Modbus > Modbus TCP Client > Global Settings > Enabled (True/False) i tried disabling this as it seemed like the database that stored the unsent data but it just resulted in the gateway sending {“example_data”:”N/A”}

This either enables or disables the Modbus Client service, I don’t believe it has anything to do with the data you mentioned prior to this. More information here: https://wiki.teltonika-networks.com/view/RUT906_Modbus#Modbus_TCP_Client

Regards,
M.

[karan]

I have tried turning off retry but it still sends the unsent data.

[Matas]

Hello,

Perhaps the said data is the one that has been queued from your previous disconnections? The change in your configuration will now stop only the new incoming data, the old one will still have to go through in one way or another.

Regards,
M.

[karan]

Hmm, it could be let me try it again and i will update you on it.