Self bridging Mosquitto MQTT broker

Question

I am trying to self-bridge a mosquitto broker. Let me explain the scenario for which I am doing this.

We have 2 parts to our application. One which is concerned with processing data and other is a modbus service that reads data from PLC devices. The processing part of the application is capable of handling multiple clients. I want to setup a test and a production tenant for the same client. The reason behind this is that this would give our clients the liberty to play around with the test tenant where as the production won't be affected by this.

The test client both sends as well as receives data from the broker. It is important that we don't send the test tenant's data to our modbus service. The topics follow the following format.

company/service/test/+ for the test client and company/service/prod/+ for the prod client.

The modbus service send data to the same broker in the format company/service/prod/+ .

Is there a way for me to remap this topic to company/service/test/+ so that both test and prod clients can receive data from the broker.

address 127.0.0.1:41888
topic /company/values/prod/+ in 2   
topic /company/values/prod/+ out 2 "" /company/values/test/+
remote_clientid test
remote_username mqttuser
remote_password broker-123

Remember I have a single broker instance and I'm trying to self bridge on this.

In my above configuration, the remapping doesn't happen cause it's not a valid prefix.

Can someone please help me figure out how to approach this?

Answer 1

The problem is the + on the end of the output topic mapping in

topic /company/values/prod/+ out 2 "" /company/values/test/+

You want

topic + out 2 /company/values/prod/ /company/values/test/

This will strip off /company/values/prod/ and replace it with /company/values/test/

You also want to remove the first topic line ( topic /company/values/prod/+ in 2 ) as this will lead to an infinity publish loop for any message published to /company/values/prod/+

ps starting topics with a leading / while valid in the spec is a REALLY bad idea, as it breaks things when you get round to needing shared subscriptions and injects an unneeded null to the start of every topic.