FYI I was able to get the gateway to work properly on a 64 bit Raspberry pi 400 machine.

pi@sixfour:~ $ cat /proc/cpuinfo | grep Model && uname -a
Model		: Raspberry Pi 400 Rev 1.0
Linux sixfour 5.10.5-v8+ #1392 SMP PREEMPT Sat Jan 9 18:56:30 GMT 2021 aarch64 GNU/Linux

I'm not sure if it's required, but installing the bcm2835 v 1.68 (that includes an earlier patch for pi 4) may have helped along with removing the bcm2711 flags from the configure file.

pi@sixfour:~/MySensors $ ./configure  --my-gateway=serial --my-serial-is-pty --my-serial-pty=/dev/ttymysgw --my-rf24-ce-pin=22 --my-rf24-cs-pin=24 --my-rf24-irq-pin=15 --my-serial-groupname=dialout --soc=BCM2711
Warning: --my-serial-pty is deprecated, please use --my-serial-port
[SECTION] Detecting SPI driver.
  [OK] SPI driver detected:BCM.
[SECTION] Gateway configuration.
  [OK] Type: serial.
  [OK] Transport: rf24.
  [OK] Signing: Disabled.
  [OK] Encryption: Disabled.
  [OK] CPPFLAGS:  -DMY_RADIO_RF24 -DMY_GATEWAY_SERIAL -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_LINUX_SERIAL_GROUPNAME="dialout" -DMY_RX_MESSAGE_BUFFER_FEATURE -DMY_RF24_IRQ_PIN=15 -DMY_RF24_CS_PIN=24 -DMY_RF24_CE_PIN=22 -DMY_LINUX_SERIAL_PORT="/dev/ttymysgw" -DMY_LINUX_SERIAL_IS_PTY 
  [OK] CXXFLAGS:  -std=c++11
[SECTION] Detecting init system.
  [OK] Init system detected: systemd.
[SECTION] Saving configuration.
  [OK] Saved.
[SECTION] Cleaning previous builds.
  [OK] Finished.

granted I have not fully tested this since I do not yet have a radio connected, but I think it went ok.

Jan 28 15:08:50 INFO  Starting gateway...
Jan 28 15:08:50 INFO  Protocol version - 2.3.2
Jan 28 15:08:50 DEBUG Serial port /dev/ttymysgw (115200 baud) created
Jan 28 15:08:50 DEBUG MCO:BGN:INIT GW,CP=RNNGL-Q-,FQ=NA,REL=255,VER=2.3.2
Jan 28 15:08:50 DEBUG TSF:LRT:OK
Jan 28 15:08:50 DEBUG TSM:INIT
Jan 28 15:08:50 DEBUG TSF:WUR:MS=0
Jan 28 15:08:50 DEBUG !TSM:INIT:TSP FAIL
Jan 28 15:08:50 DEBUG TSM:FAIL:CNT=1
Jan 28 15:08:50 DEBUG TSM:FAIL:DIS
Jan 28 15:08:50 DEBUG TSF:TDI:TSL
Jan 28 15:09:00 DEBUG TSM:FAIL:RE-INIT
Jan 28 15:09:00 DEBUG TSM:INIT
Jan 28 15:09:00 DEBUG !TSM:INIT:TSP FAIL

I will plop a radio in this weekend and see if it still works.

Just a small addendum...

I tried swapping my Pi3B+ install into a Pi 400 with the BCM2711 and it did not work.

I needed both the BCM2835 v 1.68 and to remove the flags from the "configure" script BCM2711 section.

@fredswed Honestly, I've moved on to playing with HASS... but I can still share my thoughts.

So there is no practical reason you need to run the MySensors MQTT stuff as OpenHAB can handle all the MQTT messages already without MySensors AddOn--it's just not very convenient to decipher a bunch of five level deep numeric topics that aren't intuitive. I guess I thought I was trying to be clever by doing it all in MQTT style instead of using something else (like Serial).

So what I did when I was switching over to HASS was rebuild the gateway as a serial gateway and avoid the whole conflict. I don't technically need MQTT visibility of the sensors and HASS now autodiscovers the serial sensor gateway sensors just fine. I suspect OpenHAB would do the same.

It's pretty trivial to rebuild the mysgw using serial as long as you're able to make your own /dev/ttyMySensorsGateway accessible by the openhab system (it might require changing owners or groups or both). For whatever reason, mine was root/root and not dialout or accessible to the automation software username. I just changed everything to the tty group and it all worked fine.

The end result of using the serial gateway should be identical within OpenHAB--in theory it should auto discover your sensors and populate them in PaperUI. But I haven't tried or tested it.

I'm using a raspberry pi with onboard MQTT broker and nRF24 connected to the GPIO. Everything works just fine but I can't find anything on the site about how to set a temperature units preference (metric = false) from the gateway side.

reference this line in the atmospheric pressure sketch:

bool metric = true;                // Variable that stores if the sensor will output the temperature in Fahrenheit of Celsius. The gateway sends this preference to the node, so you dont need to change it here.

So then... where do I change it? I checked the obvious places (./configure --help, mysensors.conf, the serial API, the MyConfig.h file itself...) but I can't find a clear answer.

Thanks!

Just a small addendum...

I tried swapping my Pi3B+ install into a Pi 400 with the BCM2711 and it did not work.

I needed both the BCM2835 v 1.68 and to remove the flags from the "configure" script BCM2711 section.

FYI I was able to get the gateway to work properly on a 64 bit Raspberry pi 400 machine.

pi@sixfour:~ $ cat /proc/cpuinfo | grep Model && uname -a
Model		: Raspberry Pi 400 Rev 1.0
Linux sixfour 5.10.5-v8+ #1392 SMP PREEMPT Sat Jan 9 18:56:30 GMT 2021 aarch64 GNU/Linux

I'm not sure if it's required, but installing the bcm2835 v 1.68 (that includes an earlier patch for pi 4) may have helped along with removing the bcm2711 flags from the configure file.

pi@sixfour:~/MySensors $ ./configure  --my-gateway=serial --my-serial-is-pty --my-serial-pty=/dev/ttymysgw --my-rf24-ce-pin=22 --my-rf24-cs-pin=24 --my-rf24-irq-pin=15 --my-serial-groupname=dialout --soc=BCM2711
Warning: --my-serial-pty is deprecated, please use --my-serial-port
[SECTION] Detecting SPI driver.
  [OK] SPI driver detected:BCM.
[SECTION] Gateway configuration.
  [OK] Type: serial.
  [OK] Transport: rf24.
  [OK] Signing: Disabled.
  [OK] Encryption: Disabled.
  [OK] CPPFLAGS:  -DMY_RADIO_RF24 -DMY_GATEWAY_SERIAL -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_LINUX_SERIAL_GROUPNAME="dialout" -DMY_RX_MESSAGE_BUFFER_FEATURE -DMY_RF24_IRQ_PIN=15 -DMY_RF24_CS_PIN=24 -DMY_RF24_CE_PIN=22 -DMY_LINUX_SERIAL_PORT="/dev/ttymysgw" -DMY_LINUX_SERIAL_IS_PTY 
  [OK] CXXFLAGS:  -std=c++11
[SECTION] Detecting init system.
  [OK] Init system detected: systemd.
[SECTION] Saving configuration.
  [OK] Saved.
[SECTION] Cleaning previous builds.
  [OK] Finished.

granted I have not fully tested this since I do not yet have a radio connected, but I think it went ok.

Jan 28 15:08:50 INFO  Starting gateway...
Jan 28 15:08:50 INFO  Protocol version - 2.3.2
Jan 28 15:08:50 DEBUG Serial port /dev/ttymysgw (115200 baud) created
Jan 28 15:08:50 DEBUG MCO:BGN:INIT GW,CP=RNNGL-Q-,FQ=NA,REL=255,VER=2.3.2
Jan 28 15:08:50 DEBUG TSF:LRT:OK
Jan 28 15:08:50 DEBUG TSM:INIT
Jan 28 15:08:50 DEBUG TSF:WUR:MS=0
Jan 28 15:08:50 DEBUG !TSM:INIT:TSP FAIL
Jan 28 15:08:50 DEBUG TSM:FAIL:CNT=1
Jan 28 15:08:50 DEBUG TSM:FAIL:DIS
Jan 28 15:08:50 DEBUG TSF:TDI:TSL
Jan 28 15:09:00 DEBUG TSM:FAIL:RE-INIT
Jan 28 15:09:00 DEBUG TSM:INIT
Jan 28 15:09:00 DEBUG !TSM:INIT:TSP FAIL

I will plop a radio in this weekend and see if it still works.

@jet who knew! ultimately clientid isn't really a critical piece of info to provide, but not knowing that providing it causes the error is unfortunate.

would this apply to future mqtt bindings using esh-io-transport-mqtt even besides mysensors, essentially rendering the broker.clientid setting useless?

@fredswed Honestly, I've moved on to playing with HASS... but I can still share my thoughts.

So there is no practical reason you need to run the MySensors MQTT stuff as OpenHAB can handle all the MQTT messages already without MySensors AddOn--it's just not very convenient to decipher a bunch of five level deep numeric topics that aren't intuitive. I guess I thought I was trying to be clever by doing it all in MQTT style instead of using something else (like Serial).

So what I did when I was switching over to HASS was rebuild the gateway as a serial gateway and avoid the whole conflict. I don't technically need MQTT visibility of the sensors and HASS now autodiscovers the serial sensor gateway sensors just fine. I suspect OpenHAB would do the same.

It's pretty trivial to rebuild the mysgw using serial as long as you're able to make your own /dev/ttyMySensorsGateway accessible by the openhab system (it might require changing owners or groups or both). For whatever reason, mine was root/root and not dialout or accessible to the automation software username. I just changed everything to the tty group and it all worked fine.

The end result of using the serial gateway should be identical within OpenHAB--in theory it should auto discover your sensors and populate them in PaperUI. But I haven't tried or tested it.

@fixjunk replying to myself...

seems like installing esh-io-transport-mqtt in karaf causes the broker problem.
without it installed the logs show:

2018-04-16 16:28:35.914 [ERROR] [org.openhab.binding.mysensors       ] - FrameworkEvent ERROR - org.openhab.binding.mysensors
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.mysensors [210]
  Unresolved requirement: Import-Package: org.eclipse.smarthome.io.transport.mqtt
	at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1600) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
2018-04-16 16:28:36.870 [INFO ] [penhab.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2018-04-16 16:28:36.885 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'habianbroker'

But then after feature:install esh-io-transport-mqtt I get this:

2018-04-16 16:30:13.506 [INFO ] [penhab.io.transport.mqtt.MqttService] - Stopping broker connection 'habianbroker'
2018-04-16 16:30:14.135 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection 'habianbroker' to 'tcp://<MY.IP.GOES.HERE>:1883' with clientid mysensors and file store '/var/lib/openhab2/tmp/habianbroker'
2018-04-16 16:30:14.208 [WARN ] [rthome.io.transport.mqtt.MqttService] - MqttBroker start failed: Persistence already in use
org.eclipse.smarthome.io.transport.mqtt.MqttException: Persistence already in use
	at org.eclipse.smarthome.io.transport.mqtt.MqttBrokerConnection.start(MqttBrokerConnection.java:572) [219:org.eclipse.smarthome.io.transport.mqtt:0.10.0.b1]
	at org.eclipse.smarthome.io.transport.mqtt.MqttService.modified(MqttService.java:145) [219:org.eclipse.smarthome.io.transport.mqtt:0.10.0.b1]
	at org.eclipse.smarthome.io.transport.mqtt.MqttService.activate(MqttService.java:157) [219:org.eclipse.smarthome.io.transport.mqtt:0.10.0.b1]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.apache.felix.scr.impl.inject.BaseMethod.invokeMethod(BaseMethod.java:229) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.inject.BaseMethod.access$500(BaseMethod.java:39) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.inject.BaseMethod$Resolved.invoke(BaseMethod.java:650) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.inject.BaseMethod.invoke(BaseMethod.java:506) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.inject.ActivateMethod.invoke(ActivateMethod.java:307) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.inject.ActivateMethod.invoke(ActivateMethod.java:299) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:298) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) [42:org.apache.felix.scr:2.0.12]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212) [?:?]
	at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:496) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461) [?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:619) [?:?]
	at com.eclipsesource.jaxrs.publisher.internal.ResourceTracker.addingService(ResourceTracker.java:39) [15:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) [?:?]
	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) [?:?]
	at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) [?:?]
	at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) [?:?]
	at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) [?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:915) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127) [?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225) [?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:464) [?:?]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:887) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:874) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:132) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:941) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:741) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:675) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:430) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:657) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:341) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:390) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.Activator.access$200(Activator.java:54) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:265) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:254) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:227) [42:org.apache.felix.scr:2.0.12]
	at org.apache.felix.utils.extender.AbstractExtender.addingBundle(AbstractExtender.java:187) [42:org.apache.felix.scr:2.0.12]
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469) [?:?]
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415) [?:?]
	at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) [?:?]
	at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) [?:?]
	at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) [?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:903) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) [?:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120) [?:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) [?:?]
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:156) [?:?]
	at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) [?:?]
	at org.eclipse.osgi.container.Module.start(Module.java:467) [?:?]
	at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:470) [?:?]
	at org.eclipse.osgi.container.ModuleContainer.start(ModuleContainer.java:736) [?:?]
	at org.eclipse.osgi.container.ModuleContainer.applyDelta(ModuleContainer.java:727) [?:?]
	at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:497) [?:?]
	at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:443) [?:?]
	at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:987) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1368) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
Caused by: org.eclipse.paho.client.mqttv3.MqttPersistenceException: Persistence already in use
	at org.eclipse.paho.client.mqttv3.persist.MqttDefaultFilePersistence.open(MqttDefaultFilePersistence.java:112) ~[?:?]
	at org.eclipse.paho.client.mqttv3.MqttAsyncClient.<init>(MqttAsyncClient.java:286) ~[?:?]
	at org.eclipse.paho.client.mqttv3.MqttAsyncClient.<init>(MqttAsyncClient.java:167) ~[?:?]
	at org.eclipse.smarthome.io.transport.mqtt.MqttBrokerConnection.start(MqttBrokerConnection.java:570) ~[?:?]
	... 79 more
2018-04-16 16:30:14.330 [INFO ] [penhab.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2018-04-16 16:30:14.335 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'habianbroker'

It looks like the openhab broker and the eclipse brokers are conflicting?

I have a general question that I can't seem to find an answer to either here, in the openhab docs, or anywhere googling between the two.

On a Raspberry Pi 3 running openhabian 1.4 (stretch 9.4)
running openhab 2.2
Mosquitto 1.4.10
mysgw 2.2.0 (MQTT)

And an arduino pro mini 3.3v test sensor node running the door/button sketch at version 2.2.0 also.

The sensor node can communicate over rf24 just fine and the broker receives and sends messages to it without issue.

My question is this: Does this openhab 2.2 mysensors binding replace or work in concert with the original openhab 2.2 PaperUI-installed MQTT binding? And same for the MySensors MQTT Gateway that's part of the Mysensors binding and mysgw?

I ask because when I follow the installation instructions from the github wiki and start everything up, I get a persistence in use error in org.eclipse.smarthome.io.transport.mqtt.MqttService. And it appears that my original broker is running fine, which suggests I'm trying to run two brokers and they're uninterested in cooperating.

The installation instructions I've seen (a couple places) say to use mqtt.cfg and org.eclipse.smarthome.mqtt.cfg with the same settings.

Hoping the answer is a simple, "stop mysgw and just run the paperUI MQTT Gateway" or the like.

Thanks!