Jackalope.Handler behaviour (jackalope v0.7.3) View Source
Behaviour defining callbacks triggered during the MQTT life-cycle
The jackalope handler is stateless, so if state is needed one could route the messages to stateful processes, and inform the system about connection and subscription state.
Most of the callbacks are optional.
Link to this section Summary
Callbacks
Called when the MQTT connection changes status
Handle errors produced by Jackalope that should be reacted to
Called when receiving a message matching one of the subscriptions
Produces the last will message for the current connection, or nil if the last will in the connection options is to be used Example: [topic: hub_serial_number/message", payload: %{code: "going_down", msg: "Last will message"}, qos: 1]
Called when a topic filter subscription state changes
Link to this section Types
Specs
last_will() :: [topic: topic(), payload: payload(), qos: non_neg_integer()]
Specs
payload() :: term()
Specs
topic() :: Tortoise311.topic()
Specs
topic_filter() :: Tortoise311.topic_filter()
Specs
topic_levels() :: [String.t()]
Link to this section Callbacks
Specs
connection(status :: :up | :down) :: any()
Called when the MQTT connection changes status
This can be used to inform other parts of the system about the state
of the connection; possible values are :up
and :down
, where up
means that the MQTT client has a connection to the broker; down
means that the connection has been dropped.
Specs
handle_error(reason) :: any() when reason: {:publish_error, {topic(), payload(), opts}, error_reason :: term()} | {:publish_error, jackalope_work_order :: term(), :ttl_expired}, opts: Keyword.t()
Handle errors produced by Jackalope that should be reacted to
During the connection life-cycle various errors can occur, and while
Jackrabbit and Tortoise311 will try to correct the situation, some
errors require user intervention. The optional handle_error/1
callback can help inform the surrounding system of errors.
@impl Jackalope.Handler
def handle_error({:publish_error, work_order, :ttl_expired}) do
Logger.error("Work order expired: #{inspect(work_order)}")
end
def handle_error(_otherwise) do
_ignore = nil
end
If this callback is implemented one should make sure to make a catch-all to prevent unhandled errors from crashing the handler.
Specs
handle_message(topic_levels(), payload()) :: any()
Called when receiving a message matching one of the subscriptions
The callback will receive two arguments; the MQTT topic in list form, where each of the topic levels are an item. This allows us to pattern match on topic filters with wildcards.
Specs
last_will() :: last_will() | nil
Produces the last will message for the current connection, or nil if the last will in the connection options is to be used Example: [topic: hub_serial_number/message", payload: %{code: "going_down", msg: "Last will message"}, qos: 1]
Specs
subscription(status :: :up | :down, topic_filter()) :: any()
Called when a topic filter subscription state changes
This can be used to inform other parts of the system that we should
(or shouldn't) expect messages received on the given topic_filter
.
The status values are :up
and :down
, where up means that the
broker has accepted a subscription request to the specific
topic_filter
, and down means that the broker has accepted an
unsubscribe request.