[Question] Edge activity information is not showing on a dashboard widget assigned to Edge instance

[akseerali]

Component

• UI

Description Normally, the Thingsboard status can be monitoring on both the Cloud and Edge. While at Cloud, it can be monitored either by clicking on the Edge name and by creating a widget with the help of alias, on Edge it be monitored by clicking on "Edge Status" from the left menu of screen.

In our case, I am trying to use a widget for the Edge connectivity status on a dashboard for the following reasons:

1. The user don't have to click on too many options for checking the Edge Status every time.
2. The UI can always be set to be in full-screen mode.

Issue The widget option is only working on the Cloud server, not on Edge. Please see the below attached screenshots:

• screenshot taken from Cloud server

• screenshot taken from local Edge

Question Is there any way to show the Edge status on edge dashboard? I have tried to observe the Edge activity events from Edge rule chains; however, so far I am unable to find a solution.

Environment

• OS: Ubuntu 22.04
• ThingsBoard Edge: 3.4.3EdgePE

[volodymyr-babak]

Hello @akseerali

at the moment this is not possible, because activity events for edge entity is not pushed to the rule engine. As a result - you cannot push them to the edge from cloud using 'push to edge' rule node. But this could be easily added to next 3.5 release. This release is planned in next 1-2 months.

Please let me know if you are using open-source version of cloud and edge - then I can provide you what should be changed to achieve this by building custom deb or docker images from sources.

[akseerali]

Hi @volodymyr-babak

Thanks for the information. I am currently having a trial of Thingsboard PE Edge and Cloud. I am planning to go for the subscription. Please let me know about the instructions if it's possible to clear this issue in Thingsboard PE Edge.

[volodymyr-babak]

hi @akseerali

unfortunately I cannot provide you instructions for ThingsBoard PE Edge. I can provide steps only for the Community Edition version, that you can build on your own. For the ThingsBoard PE Edge it's going to be available only next release - 3.5.

[akseerali]

Hi @volodymyr-babak

Thanks. I am looking forward to release 3.5.

[volodymyr-babak]

Related pull request was merged into develop 3.5 branch, and starting from next release you can push connect and disconnect events to the edge using Push To Edge node:

[akseerali]

HI @volodymyr-babak

Is there any method to set the delay for the edge connectivity/disconnectivity events? We have observed that the TB Cloud occasionally generates disconnectivity events and then quickly changes it to connected within 2-3 seconds.

We have also set an alarm to notify the cloud dashboard in case of a disconnectivity event, which generates alarms quite often. Is there a method to set up a delay for edge connectivity events similar to the Devices at TB Platform?

We will be waiting for your kind response. Thanks

[volodymyr-babak]

@akseerali

Could you please provide more details on "set up a delay for edge connectivity events similar to the Devices at TB Platform". What exactly you are referring to?

Regarding delay for edge connectivity events - we don't have anything at the moment out of the box. Once edge is connected/disconnected, respective event is pushed to the rule engine.

[akseerali]

Hi @volodymyr-babak

Thank you for the reply.

Regarding the query, I mean a configurable timeout option for the edge-connected/disconnected events. For example, we set the edge disconnectivity timeout to be 5 minutes, and the edge suddenly disconnects/connects. In that case, the cloud should change the edge status to "disconnected/connected" based on the configuration time.

[volodymyr-babak]

@akseerali

I suppose you can play around with keep alive parameters of gRPC connectivity between Edge and Cloud and increase default values to avoid getting disconnect/connect events quite often.

On the server side you can tune next parameters EDGES_RPC_CLIENT_MAX_KEEP_ALIVE_TIME_SEC, EDGES_RPC_KEEP_ALIVE_TIME_SEC, EDGES_RPC_KEEP_ALIVE_TIMEOUT_SEC. https://thingsboard.io/docs/user-guide/install/config/#edges-parameters

Here are the details on these parameters.

• EDGES_RPC_CLIENT_MAX_KEEP_ALIVE_TIME_SEC: Specifies the minimum amount of time that should elapse between keepalive pings sent by the client. This prevents clients from sending pings too frequently, which can be a nuisance to the server (potentially even a denial-of-service attack vector if abused). If a client sends pings more frequently than this interval, the server may terminate the connection. 1 second by default.

• EDGES_RPC_KEEP_ALIVE_TIME_SEC: Sets the time of inactivity (no read operations on the connection) after which the server will send a keepalive ping to the client. This is used to ensure that the connection is still alive and to prevent network intermediaries from dropping connections due to inactivity. It's a way for the server to proactively check if the client is still responsive. 10 seconds by default.

• EDGES_RPC_KEEP_ALIVE_TIMEOUT_SEC: Specifies the maximum amount of time the server waits for a response to its keepalive ping. If the ping is not acknowledged within this time frame, the server considers the connection dead and may close it. This timeout helps detect unresponsive clients. 5 seconds by default.

In the same time you'll need to modify Edge (gRPC client) parameters CLOUD_RPC_KEEP_ALIVE_TIME_SEC and CLOUD_RPC_KEEP_ALIVE_TIMEOUT_SEC to fit next server side values. https://thingsboard.io/docs/edge/user-guide/install/config/#cloud-parameters

Here are the details on these parameters.

• CLOUD_RPC_KEEP_ALIVE_TIME_SEC: Specifies the amount of time in seconds the client waits in idle (with no read operations on the connection) before sending a keepalive ping to the server. This setting is crucial for ensuring that the connection remains alive during periods of inactivity and helps prevent the server from closing the connection due to a timeout. It's used to probe the server periodically to check if it is still responsive and maintain the connection through potential network devices that might drop inactive connections (like NATs and load balancers). 10 seconds by default.

• CLOUD_RPC_KEEP_ALIVE_TIMEOUT_SEC: Specifies how long the client will wait for a response to its keepalive ping. If the ping isn't acknowledged within this timeframe, the client assumes the connection is dead or unreachable. This timeout is essential for detecting when the server side might have issues or when there might be network failures preventing communication. If the server does not respond to a keepalive ping within this period, the client will consider the connection as lost and may attempt to reconnect or take other recovery actions. 5 seconds by default.

[akseerali]

Hi @volodymyr-babak

Thank you for the detailed information.

We don't have a server, as the edge is directly connected to the cloud. Additionally, we tried the configuration below, but this combination does not work. Please share the compatible configuration. The configuration added to resolve this issue is highlighted in bold.

version: '3.8' services: mytbedge: restart: always image: "thingsboard/tb-edge-pe:3.6.3EDGEPE" container_name: tb-edge ports:

• "8080:8080"
• "1883:1883"
• "5683-5688:5683-5688/udp"
• "8383:8383" environment: SPRING_DATASOURCE_URL: jdbc:postgresql://postgres-db:5432/tb-edge EDGE_LICENSE_INSTANCE_DATA_FILE: /data/instance-edge-license.data CLOUD_ROUTING_KEY: "routing key" CLOUD_ROUTING_SECRET: "routing secret" CLOUD_RPC_HOST: thingsboard.cloud CLOUD_RPC_PORT: 7070 CLOUD_RPC_SSL_ENABLED: 'true' # set it to 'true' if you are connecting edge to thingsboard.cloud CLOUD_RPC_KEEP_ALIVE_TIME_SEC: 360 CLOUD_RPC_TIMEOUT: 20 REPORTS_SERVER_ENDPOINT_URL: http://tb-web-report:8383 SQL_TTL_TS_ENABLED: true SQL_TTL_TS_EXECUTION_INTERVAL: 86400000 SQL_TTL_TS_TS_KEY_VALUE_TTL: 158112000 . . .

[volodymyr-babak]

hi @akseerali ,

Could you please double check your previous question. According to bold settings, they are not related to the topic:

[akseerali]

Hi @volodymyr-babak

I have just updated my previous query.

[volodymyr-babak]

Hi @akseerali,

I'm not sure why you set CLOUD_RPC_TIMEOUT, as this parameter is only responsible for setting the timeout in seconds for channel termination and will not affect disconnection behavior.

Could you please set the following parameters on the Edge side for testing and let me know your results if it improves the situation: CLOUD_RPC_KEEP_ALIVE_TIME_SEC: 30 CLOUD_RPC_KEEP_ALIVE_TIMEOUT_SEC: 25

Thank you.

[akseerali]

Hi @volodymyr-babak

Thank you for the information. We are not sure if the edge status at the edge UI has improved, but the cloud still identifies it as soon as the edge is disconnected.

Here is a scenario of what we are trying to do When the edge is disconnected from the cloud for the last 2-3 minutes, the cloud should raise an alarm on the UI, including the email. In our case, the cloud can only raise the alarm and send an email when the edge immediately gets disconnected. While this is advantageous for a quick process, users get more alerts than required. An alert feature based on the configurable time in the cloud would ensure checking the edge in case of network or power disconnectivity.