openHAB 2.2 binding

[TimO]

@seeers yes, I've located a bug in the expert mode an fixed it recently!

[LastSamurai]

@TimO I saw that you fixed some other bugs too in the repo. Will you create a new version 2.3 of the binding soon? Or will there be more changes first?
As most of the changes (at least also) concern RGBW lighting I would really like to use it but I can't seem to build the binding locally (I postet the error in the git pr).

[NickBuilder]

@jocke4u, I really want my power node to work so I was going to try to make my own rule based on the "expert" strategy and the 999 node/child.

But first I tried an even simpler approach, I added a var1-item from the power thing and now I have communication between node and gateway. Please give it a try yourself and see if it works for you.

More specifically I defined the following item:
Number PulseVar "Var1 [%d]" { channel="mysensors:power:gateway:pulseThing:var1" }

Be sure to also persist the item. I store it in a mapdb dataset:
PulseVar : strategy = everyChange, restoreOnStartup

FYI, my thing is defined as follows:
power pulseThing [ nodeId=50, childId=1 ]

Please give it a try and come back with the outcome.

EDIT: this feels like a too simple fix, I suspect that @TimO has made some changes in the 2.3 snapshot...

[รอเรือ]

Hi there!

Maybe someone would like to help me a bit?

I'm on openHAB 2.2 with mysensors binding 2.3.0.201801160936. I'm using a serial gateway that I reflashed today using MySensors 2.2.0 library. I have turned off debugging in the sketch.

The problem is that I encounter an exception each time OH starts up.

2018-02-11 11:05:59.342 [WARN ] [rsAbstractConnection$MySensorsReader] - Exception on reading from connection
java.io.IOException: Underlying input stream returned zero bytes
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:288) [?:?]
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) [?:?]
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) [?:?]
        at java.io.InputStreamReader.read(InputStreamReader.java:184) [?:?]
        at java.io.BufferedReader.fill(BufferedReader.java:161) [?:?]
        at java.io.BufferedReader.readLine(BufferedReader.java:324) [?:?]
        at java.io.BufferedReader.readLine(BufferedReader.java:389) [?:?]
        at org.openhab.binding.mysensors.internal.protocol.MySensorsAbstractConnection$MySensorsReader.run(MySensorsAbstractConnection.java:328) [255:org.openhab.binding.mysensors:2.3.0.201801160936]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

Thing config:

Bridge mysensors:bridge-ser:gateway [ serialPort="/dev/ttyUSBmys", baudRate=115200, sendDelay=200, startupCheckEnabled=false ]

Everything seems to work otherwise. The problem is that the warning draws my attention every time and of course I need to check if it's something serious that I'd need to act upon. I'd rather see that I get no exceptions/warnings in case the "problem" can be ignored.

My question to you guys is if there is anything that I can do about it? Thanks for your kind help.

Cheers!

[LastSamurai]

@TimO I finally got around to testing my pureWhite RGBW code and at least for me its working like it should be. I saw you already merged this so I guess others can use it too very soon.
What is still not working is the acknowledgment feature. I have one node that only gets about 90% of the messages without error, so I tried activating it there and on some other nodes too for testing. Result: success rate is down to ~50% for each node and I get messages about some acknowledgment on the console when no message has even been sent (nothing about a message from mysensors on the console and no rx/tx leds on the gateway). When I tested this some months ago I also saw no message at the client so I am pretty sure none gets send.
So I guess this issue is still unresolved ;) I have no clue why on a first glance but if I can help just send me a message.

[forexsieno]

Hello, I try to start using OpenHab as a controller and
need some help, regarding mysensors binding 2.3.0. I get the bindings installed, but in bundle:list it's just installed and i don't get it Active.

All other instruction for installation are done.
Did feature:install openhab-transport-serial and feature:install esh-io-transport-mqtt and and "nrjavaserial" is Active.

But mysensor binding just installed. How can I get it ACTIVE?

Thank you for your help.

[LastSamurai]

Do you still have an older version of Mysensors installed? Thats the only time I had such behaviour

[nick van alst]

Hello,

I've been using the binding for a while now!
must say that i still have some problems with auto discovery, but manually adding the sensors work fine!

I encountered a bug in 1 for the components.

The GAS meter should contain a variable for V_VOLUME but in the logs i'm getting errors that the variable does not exist.

i searched in the code and found out the the class for SGAS is not containing the V_VOLUME variable.
file: MySensorsChildSGas.java
github link: https://github.com/tobof/openhab2-addons/blob/MySensors_Binding/addons/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/internal/sensors/child/MySensorsChildSGas.java

as by: https://www.mysensors.org/download/serial_api_20#sensor-types SGAS should also include a V_VOLUME variable as wel as a V_FLOW

For now i adjusted my sensor to use one of the custom var fields. but it would be nice to use the V_VOLUME variable for this.

[fixjunk]

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!

[fixjunk]

@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?

[fredswed]

@fixjunk - I'm having the same problem and it's driving me crazy. I don't mind some troubleshooting but OpenHAB is new territory for me and I just can't find the problem.

I have set up two mqtt broker connections (in two config files) for debugging. For the Eclipse bundle I define the connection "huset_mqtt" with user "openhab". For the legacy OpenHAB binding I define a connection "huset_mqtt_legacy" with user "openhab-legacy. Both connect to the same mosquitto server.

I don't think there is a conflict between the openHAB MQTT Binding and esh-io-transport-mqtt. To test it I stopped the openHAB MQTT binding and transport bundles. The warning is still there even when only the Eclipse SmartHome MQTT Transport Bundle is running.

When all bundles are running, I first stop the legacy broker and the log looks as expected. But when I restart the Eclipse bundle the warning "Persistence already in use" is thrown (below):

2018-05-04 22:10:09.739 [INFO ] [penhab.io.transport.mqtt.MqttService] - Stopping broker connection 'huset_mqtt_legacy'
2018-05-04 22:17:47.270 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection 'huset_mqtt' to 'tcp://
192.168.1.5:1883' with clientid OpenHab and file store '/var/lib/openhab2/tmp/huset_mqtt'
2018-05-04 22:17:47.349 [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) [214:org.eclipse.sm
arthome.io.transport.mqtt:0.10.0.b1]

However, it is clear that the Eclipse broker connection does not fail completely. Mosquitto logs and mqtt-spy confirm that both transports/binding actually connect to the mosquitto server. One at a time or both at the same time.

Below is the mosquitto log when I restart the OpenHAB MQTT transport, the OpenHAB MQTT binding and last the Eclipse MQTT transport. Clearly the clients disconnect and then reconnects like they should.

1525466428: Client OpenHab_legacy disconnected.
1525466428: New connection from 192.168.1.5 on port 1883.
1525466428: New client connected from 192.168.1.5 as OpenHab_legacy (c1, k60, u'openhab-legacy').
1525466645: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
1525467392: Client OpenHab_legacy disconnected.
1525467393: New connection from 192.168.1.5 on port 1883.
1525467393: New client connected from 192.168.1.5 as OpenHab_legacy (c1, k60, u'openhab-legacy').
1525467446: Client OpenHab disconnected.
1525467446: New connection from 192.168.1.5 on port 1883.
1525467446: New client connected from 192.168.1.5 as OpenHab (c1, k60, u'openhab').

To test the two mqtt broker connections I have set up test switches in an .items file:

Switch MQTT_TEST_legacy "Testing..." { mqtt="<[huset_MQTT_legacy:testing/mqtt/topic:state:default], >[huset_MQTT_legacy:testing/mqtt/back-topic:command:*:default]" }
Switch MQTT_TEST_new "Testing..." { mqtt="<[huset_MQTT:testing/mqtt/topic:state:default], >[huset_MQTT:testing/mqtt/back-topic:command:*:default]" }

To test them I manually send the message "ON" to the topic "testing/mqtt/topic". The MQTT_TEST_legacy switch state changes to ON. So the legacy OpenHAB binding works fine.
However, the MQTT_TEST switch that uses the Eclipse mqtt broker/transporrt does not respond at all to my messages.

To summarize, the Eclipse mqtt feature throws a warning but connects to my mosquitto server,and then wont change items with messages I send.

Am I missing a component, or what could possibly be the reason?

It is a basic, fresh install of OpenHAB 2.2 on openhabian. I have cleaned caches and tmp, cleaned up config files in /var/lib/openhab/config and even reinstalled OpenHAB. The Mysensors binding 2.2.0.201710190834 is running.

Now I don't even have a clue on what to check next.
OpenHAB gurus out there - please help me!

[fixjunk]

@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.

[fredswed]

@fixjunk Thanks for responding - I have tried Domoticz and considered HASS but OpenHAB is the only controller that also supports my AllPlay speakers.

Anyway, I gave up and reinstalled Openhabian. It breaks my heart to admit but it also gave me a chance to fix a few bugs and try some new things on the server.

Net result: On a clean Openhabian 2.2 install with only the Eclipse MQTT bundle installed, the "Persistence in use" warning is still triggered. (I won't look further into it, it's only a warning.) The MySensors 2.3 binding connects as expected to the MQTT gateway and everything seems to work again.

Well, not really. I managed to break both of my sensors while experimenting. So I guess I'm back to soldering tomorrow. :-)

[Jet]

Re: Persistence in use error message, by accident (typo in specifying broker.clientId), I've figured out the cause:

[11:12:04] openhabian@openHABianPi:~$ netstat -a | grep 1883
tcp 0 0 0.0.0.0:1883 0.0.0.0:* LISTEN
tcp6 0 0 [::]:1883 [::]:* LISTEN
feature:install esh-io-transport-mqtt
[11:12:20] openhabian@openHABianPi:~$ netstat -a | grep 1883
tcp 0 0 0.0.0.0:1883 0.0.0.0:* LISTEN
tcp 0 0 localhost:1883 localhost:53256 ESTABLISHED
tcp 0 0 localhost:1883 localhost:53254 ESTABLISHED
tcp6 0 0 [::]:1883 [::]:* LISTEN
tcp6 0 0 localhost:53256 localhost:1883 ESTABLISHED
tcp6 0 0 localhost:53254 localhost:1883 ESTABLISHED

esh-io-transport-mqtt opens 2 connections to mosquito (not sure why), but as each connection needs a unique clientId, if you've specified a clientId, it will fail one of the connections with that error message.

The solution is to remove your <broker>.clientId definition in the config file (also remember to remove the backup file, otherwise it won't have any effect). When you do this a unique clientId is generated on every connection (which you can see in the mosquito log), and the error message goes away.

See these log files (Note without clientId, 2 connections from localhost are made and are pinging):
with clientId specified:
1525969562: Opening ipv4 listen socket on port 1883.
1525969562: Opening ipv6 listen socket on port 1883.
1525970154: New connection from 127.0.0.1 on port 1883.
1525970154: New client connected from 127.0.0.1 as openhab2 (c1, k60, u'openhabian').
1525970154: Sending CONNACK to openhab2 (0, 0)
1525970214: Received PINGREQ from openhab2
1525970214: Sending PINGRESP to openhab2
1525970274: Received PINGREQ from openhab2
1525970274: Sending PINGRESP to openhab2
1525970334: Received PINGREQ from openhab2

without clientId Specified:
1525971402: Opening ipv4 listen socket on port 1883.
1525971402: Opening ipv6 listen socket on port 1883.
1525971428: New connection from 127.0.0.1 on port 1883.
1525971428: New connection from 127.0.0.1 on port 1883.
1525971428: New client connected from 127.0.0.1 as paho31354324154 (c1, k60, u'openhabian').
1525971428: Sending CONNACK to paho31354324154 (0, 0)
1525971428: New client connected from 127.0.0.1 as paho31177339570 (c1, k60, u'openhabian').
1525971428: Sending CONNACK to paho31177339570 (0, 0)
1525971496: Received PINGREQ from paho31177339570
1525971496: Sending PINGRESP to paho31177339570
1525971496: Received PINGREQ from paho31354324154
1525971496: Sending PINGRESP to paho31354324154
1525971556: Received PINGREQ from paho31177339570
1525971556: Sending PINGRESP to paho31177339570
1525971556: Received PINGREQ from paho31354324154

and with debugging enabled on esh-io-transport-mqtt (when running feature:install esh-io-transport-mqtt) - again 2 connections:
11:25:46.778 [INFO ] [o.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection 'mosquitto' to 'tcp://localhost:1883' with clientid paho1741848008350 and file store '/var/lib/openhab2/tmp/mosquitto'
11:25:46.815 [INFO ] [o.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection 'mosquitto' to 'tcp://localhost:1883' with clientid paho1741975903334 and file store '/var/lib/openhab2/tmp/mosquitto'

I'm digging into the code for esh-io-transport-mqtt to see if I can find the root cause, but this openhab stuff is a whole load of bloatware :-)

[fixjunk]

@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?

[Jet]

This happens before mysensors is even loaded, so yes.

Here's the code: https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.transport.mqtt/src/main/java/org/eclipse/smarthome/io/transport/mqtt/MqttBrokerConnection.java

But I'm not seeing anything requesting 2 connections, unless openhab is requesting it of something is wrong or not working with the reconnect code

[Jet]

Couldn't figure out why it launches 2 instances or how to stop it, it seems to be 2 instances launches from just one module (esh-io-transport-mqtt) if anybody figures out why, please post an update. Otherwise not defining clientId for now is a workaround.

[doctor64]

@timo Looks like new binding no more support reporting of battery voltage from sensors, or I missed something?

[Guillermo Schimmel]

@timo Hi! Do you plan to continue the development into openhab 2.4?

[TimO]

@guillermo-schimmel Yes, the binding is (should) be compatible with OH 2.4 and I continue to hope for an integration in the main repository. ;-)
I've recently cleaned up the history of my git repository and will look forward to an integration in OH 2.5.