EMQX Bride Config error

EMQX
1

I am using EMQX 5.0 (local and remote) in Windows 10. When i am starting the broker with a bridge configuration, i am getting the error.

2023-01-04T16:10:44.991000+05:30 [error] failed_to_check_schema: emqx_conf_schema
2023-01-04T16:10:44.991000+05:30 [error] #{kind => validation_error,path => “bridges.mqtt.mqtt_bridge_egress”,reason => unknown_fields,unknown => <<“connector,direction…”>>,unmatched => <<“ingress,max_inflight”>>}
2023-01-04T16:10:45.007000+05:30 [error] #{kind => validation_error,path => “bridges.mqtt.mqtt_bridge_ingress”,reason => unknown_fields,unknown => <<“connector,direction…”>>,unmatched => <<“egress,max_inflight”>>}

C:\Tools\emqx-5.0.12-windows-amd64>C:\Tools\emqx-5.0.12-windows-amd64\erts-12.2.1\bin\erl.exe -mode embedded -boot “C:\Tools\emqx-5.0.12-windows-amd64\releases\5.0.12\start” -config “C:\Tools\emqx-5.0.12-windows-amd64\data\configs\app.2023.01.04.16.10.42.config” -args_file “C:\Tools\emqx-5.0.12-windows-amd64\data\configs\vm.2023.01.04.16.10.42.args” -mnesia dir ‘c:/Tools/emqx-5.0.12-windows-amd64/data/mnesia/emqx@127.0.0.1’
{“could not start kernel pid”,application_controller,“error in config file "c:/Tools/emqx-5.0.12-windows-amd64/data/configs/app.2023.01.04.16.10.42.config" (none): configuration file not found”}
could not start kernel pid (application_controller) (error in config file “c:/Tools/emqx-5.0.12-windows-amd64/data/configs/app.2023.01.04.16.10.42.config” (none): configuration file not found)

Crash dump is being written to: erl_crash.dump…done

Below is the configuration

bridges {
  mqtt {
    mqtt_bridge_ingress {
      connector {
        bridge_mode = false
        clean_start = true
        keepalive = "60s"
	max_inflight = 32
        mode = "cluster_shareload"
        password = "pwd1"
        proto_ver = "v5"
        reconnect_interval = "10s"
        retry_interval = "1s"
        server = "test.com:1883"
        ssl {enable = false}
        username = "user1"
      }
      direction = "ingress"
      enable = true
      local_topic = "test"
      local_qos = 0
      remote_qos = 0
      remote_topic = "test"
      payload = "${payload}"
      retain = false
    }

    mqtt_bridge_egress {
      connector {
        bridge_mode = false
        clean_start = true
        keepalive = "60s"
	max_inflight = 32
        mode = "cluster_shareload"
        username = "emqx"
        password = "emqx"
        proto_ver = "v5"
        reconnect_interval = "15s"
        retry_interval = "15s"
        server = "test.com:1883"
        ssl { enable = false }
      }
      direction = "egress"
      enable = true
      local_topic = "test"
      remote_qos = 0
      remote_topic = "test"
      payload = "${payload}"
      retain = false
    }
  }
}
2

Any updates on this?

3

Sorry for missing your issue, the configuration structure of bridge has changed a bit in the latest version, so you need to configure it like this:

bridges {
  mqtt.test { 
    enable = true
    server = "test.com:1883"
    reconnect_interval = 15s
    proto_ver = v4
    bridge_mode = false
    ingress {
      remote {
        topic = "test"
        qos = 1
      }

      local {
        topic = "test"
        qos = "${qos}"
        retain = "${retain}"
        payload = "${payload}"
      }
    }

    egress {
      local {
        topic = "test"
      }

      remote {
        topic = "test"
        qos = "${qos}"
        retain = "${retain}"
        payload = "${payload}"
      }
    }
  }
}

Unfortunately we do not currently have a configuration structure compatible with older versions.

The example configurations in the MQTT Bridge doc have not been updated. You can first refer to Configuration - MQTT Bridges doc.

4

Thank you so much. let me try with this.

5

I tried this and works

6

Using the above configuration, I created a bridge (local EMQX => remote EMQX). Now I am sending the data to remote client. It keeps on sedning data even when I stopped publishing the same. This happens only when I am using bridge.

What may the reason? Is there any configuration I have to do?

Thanks
Prem

7

It may be because you have configured the same local topic and remote topic, causing the message to enter an infinite loop.