-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AMQP/MQTT: Gateways may subscribe for commands to disabled devices #1764
Comments
While I tend to agree that the adapters should reject a subscription request if the device is disabled at the point in time of the subscription request, I wonder how we want to deal with a situation where the device is being disabled after the subscription has been created? |
@calohmn any additional thoughts? |
If we implement a periodic command subscription renewal, done by the protocol adapters (to prevent stale |
@calohmn IMHO the least we should do is perform the check during subscription establishment. |
The fix for #293 includes closing a MQTT device connection if the device got disabled. In case an MQTT gateway is connected and a device connected to that gateway gets disabled, any existing command subscriptions for that disabled device are left unchanged at the moment.
@sophokles73 yes, that check should be added. |
Actually, that check has already been added in #2377. |
Currently, when a gateway subscribes for commands of a specific device, there is no check whether that device is actually enabled.
See this example trace:
The command subscription is successful - only sending the notification event fails.
(When a northbound application actually tries to send a command to that device, that request will be rejected however - the device registration data is checked when trying to find the mapped gateway.)
The text was updated successfully, but these errors were encountered: