We have MQTT devices that don’t use JSON but use a binary protocol instead to save power.
We could use Groovy rules to deserialize messages, but because rules execution is not instantaneous, it doesn’t work very well.
We want to rely on the internal broker and the MQTT API, so Agents also don’t seem to fit right.
And that’s why a custom MQTT handler comes to mind.
How can we add our own MQTT handler? Should we subclass the default handler or can there be more than one handler?
Note that this should only apply to specific types of assets.
Can the same be done for the HTTP API?
Is a custom MQTT handler actually the best option? Is there any other way?
In the default MQTT handler the payload is passed to ValueUtil. However, it is passed as a string. It it were passed as a byte buffer the custom handler could be in ValueUtil… Is ValueUtil also used in the HTTP API?
I am sorry but this message became a bit long. I can split it if you want.
Yes a custom MQTTHandler would be the way to go; you can have any number of MQTTHandlers in a system and they are loaded using the standard java ServiceLoader mechanism.
You need to extend the abstract MQTTHandler class and you will see there is a getPriority() method which determines the order of the MQTTHandlers.
Each handler decides whether it handles a topic for pub and sub requests so you either have to use your own topic format or if you want to override the DefaultMQTTHandler then you will need to give your custom handler a lower priority value.
You will see that MQTTHandler::onPublish has a ByteBuf for the payload which is a Netty object that will allow you to read out the raw bytes.
HTTP API uses standard JAX-RS resources for handling endpoints, a custom container service can register endpoints at startup, see the many standard ContainerServices that register HTTP endpoints.
Just to be sure: Rules (Groovy or otherwise) are not the best to handle this, right? (The delay associated with the execution of rules is a major downside.)
Correct, with current rules the engine doesn’t know which rules are affected by what attribute changes so all rules have to be evaluated and there is a simple rate limit on the firing to prevent performance degradation.