While investigating this same issue on the Java SDK, I noticed that this SDK can take several minutes to notice that the device was disabled from the service side when the hub is a gwv2-enabled hub.
When a device is disabled on a gwv2 hub, that hub sends a "link detached" event to any open links that the device has. However, it seems that this client doesn't notify the user that the connection is lost until several minutes later (after the next keep-alive ping?) which is incorrect. This client should be listening for this "link detached" event and invoke the connection status callback as soon as it is received.
While investigating this same issue on the Java SDK, I noticed that this SDK can take several minutes to notice that the device was disabled from the service side when the hub is a gwv2-enabled hub.
When a device is disabled on a gwv2 hub, that hub sends a "link detached" event to any open links that the device has. However, it seems that this client doesn't notify the user that the connection is lost until several minutes later (after the next keep-alive ping?) which is incorrect. This client should be listening for this "link detached" event and invoke the connection status callback as soon as it is received.