thingsboard / thingsboard-gateway

Open-source IoT Gateway - integrates devices connected to legacy and third-party systems with ThingsBoard IoT Platform using Modbus, CAN bus, BACnet, BLE, OPC-UA, MQTT, ODBC and REST protocols
https://thingsboard.io/docs/iot-gateway/what-is-iot-gateway/
Apache License 2.0
1.72k stars 829 forks source link

[BUG] Does not disconnect device from old gateway after new incoming connection request!!! #748

Closed gohm-tech closed 2 years ago

gohm-tech commented 2 years ago

There are two gateways (A and B) and a sensor in our environment. Below is the sequence of how the error occurred.

  1. Firstly the sensor sent connect request to gateway A via the MQTT connector using the sensor/connect topic. 1
  2. This change event reaches the gateway when we change the shared attribute. sss1 2
  3. After a while a time. The sensor sent connect request to gateway B via the MQTT connector using the sensor /connect topic.
  4. When the second step was performed again, the attributeUpdates request reached gateway A.

I think that after a connection request from another gateway, ThingsBoard should clear the association between the device and the old gateway in the background.

Client Environment OS: Linux(Ubuntu) Browser: Chrome, Firefox Version Ubuntu Version 20.04

Connector name MQTT Connector

Configuration mqtt.txt

Versions: OS: Raspbian GNU/Linux 10 (buster) Thingsboard IoT Gateway version [e.g. 2.7] Python version 3.7.3

Best Regards, Gohm Team

samson0v commented 2 years ago

Hi @gohm-tech, thanks for your interest in ThingsBoard IoT Gateway! For your question: you have to send a message to disconnectRequests topic for disconnecting a device from one gateway and send connect message for connecting to another one. RPC will not be sent to two gateway because the session on ThingsBoard wasn't be closed. We are thinking that the device sending data via the first gateway and we will send the attributeRequests there and it doesn't duplicate for other gateways. It is the architecture feature.

gohm-tech commented 2 years ago

Hi @samson0v,

Thanks for your quick reply. We don't want to duplicate it. When the device sends connect request via a second gateway. Thingsboard should only send attributeRequests for gateway B.

  1. Firstly the sensor sent connect request to gateway A via the MQTT connector using the sensor/connect topic.
  2. This change event reaches gateway A when we change the shared attribute of the device.
  3. Gateway A died (it has no connection with Thingsbord) or the device is not near gateway A. So step 4 occurred.
  4. After a while a time. The sensor sent connect request to gateway B via the MQTT connector using the sensor /connect topic.
  5. This change event did not reach gateway B Because Thingboard sent the attributeRequests gateway A when we change the shared attribute of the device. (it does not matter gateway A alive or not)

Thingsboard throws attributeRequests on the gateway that is not connected to it or the gateway whose device is no longer connected to it. Actually, since the device is now connected to a new gateway, Thingsboard should throw it to the new gateway. It should not send to two gateways at once.

samson0v commented 2 years ago

@gohm-tech you have to send a message to disconnectRequests topic for disconnecting a device from one gateway and send connect message for connecting to another one.

gohm-tech commented 2 years ago

Hi @samson0v

Suppose that the gateway to which the device sent the first connectRequest is not working. What should we do? How do we send to disconnectRequests from the first gateway? How do we connect the device to the second gateway in this situation?

Best Regards, Gohm Team

gohm-tech commented 2 years ago

Hi @samson0v , I would like to clarify our use case in this situation. The sensor is initially created by the gateway A and the first messages from the sensor are relayed by gateway A to the Thingsboard.

This situation is working without any problem: We are sending a disconnect request to the gateway A and send a new connection to the gateway B (tested and no problem, this is not what we are looking for)

The problem: But our problem is different, we would like to create a fail-safe solution for our sensors. In our problem, the gateway A is non-functional (maybe because of a connection or electricity problem). That means gateway A is not capable of sending disconnect requests on its own for disconnecting the sensor. We can detect this dead situation of gateway A and would like to handover the sensor to gateway B. In this case, we have all the required credentials of gateway A and we can send a disconnect request as it is sent by gateway A using gateway B (or from another backend program). But the handover of the sensor was not successful. The following messages from thingboard (like attributeUpdateRequest to change parameters of the sensor) is not delivered to the correct gateway (in this case now it should be gateway B)

I think there are some other internal confirmation (or packages) sent by gateway A to complete the disconnection of the sensor. Can you please comment on this?

Best Regards, Gohm Team

imbeacon commented 2 years ago

Hi @gohm-tech ,

Connect/Disconnect logic was implemented in the very beginning of the gateway project. And we decided to use the logic like you described (Connect/Disconnect request) to give ability to manage connected devices. Please notify, that ThingsBoard also has an inactivity logic If device doesn't send a data for some time, it will be disconnected and sessions for this device will be closed. (You can read about special parametrs here or looking for inactivityTimeout on our site, please also note that inactivity timeout can be configured for every device separately by setting inactivityTimeout server side attribute).

samson0v commented 2 years ago

Hi @gohm-tech, any updates? Can we close this issue?