-
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
Protocol connection events #565
Comments
We could also send the notifications over this new "alerting" functionality. But we could change the naming of this functionality to not imply the alerting functionality has to be used. |
Maybe "protocol connection events" work better:
|
That was my concern. |
Is the changed title an improvement? |
This change adds connection events which protocol adapters may send out in order to notify listeners that a device has connected/disconnected. Those events are "best effort", but there are no guarantees about them. Hono supports different ways of handling those events and comes with two default implementations. One "logging" implementation which simply logs to the logging system. And one event base implementation, which sends out events using the *Hono Event API*. The implementations may be wired up using the Spring Boot configuration.
This change adds connection events which protocol adapters may send out in order to notify listeners that a device has connected/disconnected. Those events are "best effort", but there are no guarantees about them. Hono supports different ways of handling those events and comes with two default implementations. One "logging" implementation which simply logs to the logging system. And one event base implementation, which sends out events using the *Hono Event API*. The implementations may be wired up using the Spring Boot configuration.
Closed by PR #569 |
In addition to the device notification functionality, we discussed in Berlin that we do need some kind event which notifies of the fact that "someone" (not necessarily a device) connected.
This would be a more "debug" like event and might not make sense for all protocol adapters. It may however make sense for MQTT, where a connection can be successfully established and be kept open for a longer period of time. This might be useful when the device/gateway connections successfully, but doesn't transmit any data over the MQTT link.
The same might be useful for the (hopefully) upcoming AMQP protocol adapter.
This functionality should not be seen as a replacement for the "device notification" feature currently being discussed in #562, #535 and #537.
My proposal would be to start with an interface which being called to handle those events. Providing a "logging only" implementation.
I tried to re-cap in this issue the discussion we had in the last Hono call, splitting off the "device notification" we need for command & control, vs the MQTT connection notification event we need for better debugging.
The text was updated successfully, but these errors were encountered: