Is there a built in way to check with hivemq-mqtt-client if a specific topic matches another topic in advance?
For instance, a message published with topic:
publishedTopic= "sensors/sensor1";
A client that subscribes:
subscribedTopic = "sensors/#";
Is there something like
publishedTopic.matches(subscribedTopic)
?
The exact situation:
I run a broker in my house, several devices publish values with different topics. Some like sensor/humi[45], some like sensor/data[JSON Payload]. For my personal use I run an application using Java HiveQM MQTT clients. One client is subscribed to relevant topics using mosquitto on raspberryPi. The other client is publishing selected data to a public accessible broker. Receiving a new message will not only process all data in the way I process it but also trigger a publishing the received message to the public broker.
Yes, I can
if(topic.equals("sensor/xxx")) {
//publish to public broker here
}
But doing some like subscribing to "sensor/#", from my internal broker, and "forwarding" something like "sensor/+", and letting a library doing the job of determining if a certain message that is received with "sensors/#", will be republished to the public broker, limited to "sensors/+" is what I am looking for.
Is the logic inside HiveMQ mqtt-client library, which obviously filters in that exact way, when I subscribe to "sensors/#", accessible for the library user?
One way to achieve what you want is to use a particular callback for the topics you want to forward.
Using HiveMQ library you can define a callback to consume the received message per subscribe or globally matching a given filter.
In your case you could use a per subscribe consumer for the topics which should be handled in a special way:
Followed by a global filter matching all topics which are not yet consumed:
client.publishes(MqttGlobalPublishFilter.REMAINING, <callback for other topics>))
(and the subscription to
sensors/#
of course)This way only
sensors/sensor1
will be consumed in your first callback andsensors/sensor2
,sensors/sensor3
(and so on) are consumed by the other callback