Posts made by TimO

@pikim Yes, I have tested with a blink example to light up an build in LED and that just worked as expected.

@pikim Wow, nice! Yes it is working just fine! Good work, thank you!

@pikim Yes, I do have a sensebender gateway that i am planning to use for an energy Meter. I am currently struggling with the circuit but the sensebender is running fine (with the arduino IDE though).

What did you copied where?

@pikim I found no (quick) solution yet and I'm interested in that as well.

@forexsieno Is the device accessible by the user that Openhab is running with?

I've solved the dependency error and the package compiles fine, but I had no time for testing yet.
If you're willing to test: Download

Hey @fabyte and @ncollins!

I just want you to know, that I'm still there, but out of time at the moment. My third child was born just recently and I don't have any time for the binding at the moment.
I'm really sorry you had to reverse engineer the binding to add your code. That's awfully wrong.
We need to create a new common base to continue the work on the binding.
I was not able to add the binding to the official repo because of the formal requirements from the Openhab Team. I'm sure these requirements are needed, but I'm no professional in java. I struggled mainly at the nonnull annotations that are needed.

@kerberos Interesting find. Haven't seen something like this till now. I suggest to delete the jar file, delete the cache and start over again.

I haven't tested textual configuration, but this should work just fine and your problem occurred before the textual configuration is initialized.

@Klabbe thank you for your feedback!

For those of you willing to help testing the OH3 integration here is a link:

Jar Download

Please don't forget to fulfill the requirements for mqtt und serial. Installation of bindings will do.

What's working after a quick test:

• binding loads in OH3
• serial gateway receives messages (ethernet gateway should work too)
• discovery is working

What's not working:

• MQTT gateway: it's broken some time and needs some tinkering

Please let me know if you found some time to test the binding.

I'll look into the changes needed to migrate the binding to OH3 and let you know.
Maybe it's no big deal and I'll provide a version 3 binding.

@Yveaux thank you for digging in!

I've disabled the signing feature and the !MCO:PRO:RC=1 issn't occuring anymore.

@frits Thank you for your input. My gateway definitely becomes unreliable after a while.

Maybe your hint regarding signing is worth some investigation. My sensors (temperature / humidity) which don't use signing seem to work fine over time. My actuators are using signing and become unreliable after a time. Currently I'm using a 2.2.0 gateway with 2.3.2 nodes and the suspicious debug message hasn't appeared yet. Maybe I will disable signing at all and test again.

@Yveaux Sure, here it is: https://github.com/mysensors/MySensors/issues/1458

Hey @joaoabs ,

no this is not an intended behaviour. The usage of the frequencies 433 MHz, 868 MHz etc. is limited by regulations. The devices aren't allowed to continously send packets and block a frequency.

I myself am using RFM69(HW) but in 868 MHz mode and Homematic devices that use the same frequency. Works without a problem!

Try to figure out which node jams the frequency by disabling all nodes and switch them on one by one and checkout at which time your garage door stops working.

@Yveaux I'm simply running the stock code from github:

https://github.com/mysensors/MySensors/blob/development/examples_linux/mysgw.cpp

I've only configured (./configure) the make process and that's it. No changes to the code.

Happens with 2.3.2 and 2.4-alpha.

Hello!

I've a strange problem with my RPi gateway that happens with my Wemo D1 gateway too. Both gateways are MQTT gateways with an attached RFM69.

For simplicity I focus on the RPi gateway. The gateway uses version 2.3.2 with the configure parameters set:

./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-is-rfm69hw --my-gateway=mqtt --my-controller-ip-address=192.168.2.13 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-signing=software

The gateway itself works but fires a lot Dec 02 16:09:11 DEBUG !MCO:PRO:RC=1 messages before a message is passed to the mysensors network. Receiving messages works fine.

Here's a debug output from the gateway:

Dec 02 16:08:08 INFO  Starting gateway...
Dec 02 16:08:08 INFO  Protocol version - 2.3.2
Dec 02 16:08:08 DEBUG MCO:BGN:INIT GW,CP=RPNGLS--,FQ=NA,REL=255,VER=2.3.2
Dec 02 16:08:08 DEBUG TSF:LRT:OK
Dec 02 16:08:08 DEBUG TSM:INIT
Dec 02 16:08:08 DEBUG TSF:WUR:MS=0
Dec 02 16:08:08 DEBUG TSM:INIT:TSP OK
Dec 02 16:08:08 DEBUG TSM:INIT:GW MODE
Dec 02 16:08:08 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Dec 02 16:08:08 DEBUG MCO:REG:NOT NEEDED
Dec 02 16:08:08 DEBUG MCO:BGN:STP
Dec 02 16:08:08 DEBUG MCO:BGN:INIT OK,TSP=1
Dec 02 16:08:08 DEBUG GWT:RMQ:CONNECTING...
Dec 02 16:08:08 DEBUG connected to 192.168.2.13
Dec 02 16:08:08 DEBUG GWT:RMQ:OK
Dec 02 16:08:08 DEBUG GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT
Dec 02 16:08:08 DEBUG TSM:READY:NWD REQ
Dec 02 16:08:08 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Dec 02 16:08:08 DEBUG TSF:MSG:READ,99-99-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0
Dec 02 16:08:08 DEBUG GWT:TPS:TOPIC=mysensors-out/99/255/3/0/21,MSG SENT
Dec 02 16:08:08 DEBUG TSF:MSG:READ,0-99-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
Dec 02 16:08:08 DEBUG TSF:MSG:BC
Dec 02 16:08:09 DEBUG TSF:MSG:READ,0-98-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
Dec 02 16:08:09 DEBUG TSF:MSG:BC
Dec 02 16:08:10 DEBUG TSF:MSG:READ,98-99-0,s=255,c=3,t=21,pt=1,l=1,sg=0:99
Dec 02 16:08:10 DEBUG GWT:TPS:TOPIC=mysensors-out/98/255/3/0/21,MSG SENT
Dec 02 16:08:10 DEBUG TSF:MSG:READ,0-97-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
Dec 02 16:08:10 DEBUG TSF:MSG:BC
Dec 02 16:08:10 DEBUG TSF:MSG:READ,97-99-0,s=255,c=3,t=21,pt=1,l=1,sg=0:98
Dec 02 16:08:10 DEBUG GWT:TPS:TOPIC=mysensors-out/97/255/3/0/21,MSG SENT
Dec 02 16:08:39 DEBUG TSF:MSG:READ,98-99-0,s=255,c=3,t=22,pt=5,l=4,sg=0:181035246
Dec 02 16:08:39 DEBUG GWT:TPS:TOPIC=mysensors-out/98/255/3/0/22,MSG SENT
Dec 02 16:08:42 DEBUG GWT:IMQ:TOPIC=mysensors-in/98/4/1/0/2, MSG RECEIVED
Dec 02 16:08:42 DEBUG TSF:MSG:SEND,0-0-99-98,s=4,c=3,t=16,pt=0,l=0,sg=0,ft=0,st=OK:
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
Dec 02 16:08:43 DEBUG TSF:MSG:READ,98-99-0,s=255,c=3,t=17,pt=6,l=25,sg=0:<NONCE>
Dec 02 16:08:43 DEBUG TSF:MSG:SEND,0-0-99-98,s=4,c=1,t=2,pt=0,l=1,sg=1,ft=0,st=OK:1
Dec 02 16:08:46 DEBUG TSF:MSG:READ,97-99-0,s=255,c=3,t=22,pt=5,l=4,sg=0:181033345
Dec 02 16:08:46 DEBUG GWT:TPS:TOPIC=mysensors-out/97/255/3/0/22,MSG SENT

git status ensures that there are no changes to the code.

Any idea what is happening here?

With the Wemos D1 MQTT gateway I've seen the same behaviour, and after a time it escalates to RC=2 and becomes less responsive.

The same happens with the current development version.

@Stefferd Don't use UDP for the connection between the gateway and Openhab, it is not supported by the binding.

Are you able to log into the gateway via telnet?

telnet  192.168.80.185 5003

@Stefferd Please fulfill the requirement for mqtt of the binding:

feature:install openhab-transport-serial
and
feature:install openhab-core-io-transport-mqtt

If you're starting from the scratch please consider using the MQTT Gateway instead of the binding. I've developed the binding and I am currently not quite sure if I'm able to maintain support for the binding, especially because OpenHAB3 is on its way.

@rex I've no experience with the Raspberry code, but my guess is, the delay() function is a problem. Replace it with a non blocking code.

@itbeyond I'm glad to hear you finally found the cause!

The current jar is published via the download link on the wiki page: https://github.com/tobof/openhab2-addons/wiki/Installation

And via eclipse marketplace. There is currently no active development, I only try to ensure the binding is running fine with the most current release of Openhab2.

@itbeyond So my guess was right. The gateway and so the binding receives requests for ids. Do you see this message continuously in the log?

You may stop the binding and connect via telnet to the gateway to rule out the binding. Are all your nodes running fine despite error? Or are there missing updates from nodes? Are there newly discovered nodes/things in Openhab?

Please post the content of the given_ids.cached file. It is usally located within the /var/lib/openhab2/mysensors/cache/ directory.

The error suggests that you have used all node ids from 1 to 253 and a new id is requested. The reason may also be a malfunctioning node that is requesting (continuously) an id although it already has one.

The node id is set in the sketches via MY_NODE_ID define.
I'm using the MQTT binding a lot, but not for MySensors. I'm using the MySensors binding with my ethernet gateway. So I can't give you a working example, but it should be possible. Stick to the MQTT binding documentation and the documentation of the MQTT gateway on the MySensors site.
I myself use PaperUI to get familiar with new bindings and things and then copy for example the channelname from the ui in the text files to reduce typos. I don't have had any problems mixing both ways of configuration. Just be sure to only have one definition left at the end, either in UI or in text files.

Hey @P72endragon!

The right binding depends on the way you like to configure the things and nodes in Openhab. If you're using the text files for configuration the better choice may be the MQTT binding. The hardest part will be the initial configuration but from there it is copy and paste. Don't forget to use static node ids here.

If you like to setup your configuration via PaperUI the binding may be the better choice, because the binding will discover new things in the MySensors network and you're able to link them to items with a few clicks.

@CraigDubya is your user which is executing the Arduino ide also in the dialout group? Did you program the gateway via this ide?
Please ensure, that only one software is using the serial connection at a time. But you are able to switch between Arduino ide and Openhab if you shut down the other software before using the other.

@ThkUF Oh yeah, thank you. I've changed the download link and I'm glad it is working for you!

@ThkUF Please update the MySensors binding jar (manually or by eclipse marketplace). The bundleContext error is produced by the older binding version for 2.4. I've updated both sources at the weekend and they should present you the latest version.

@Marcin-Szyda please set requestAck=false and try again. Is the error appearing again?

In the relay actuator example the methods saveState() and loadState() are used. The current status of the pin (RELAY_ON or RELAY_OFF) is stored in the EEPROM with every change and restored after a restart of the node.

The node will return to the last known state after a restart.

BUT: while restarting the state of the pin may change (from on to off to on again while booting up). In case you want the relays to stay activated while booting up you may use an external pull up.

@vidin https://github.com/tobof/openhab2-addons/wiki

@niccodemi yes, you need to use different names for different things in Openhab. Name it as you like.
The node id is unique per gateway, so you may use the same node id on different gateways/networks.

@niccodemi Yes! There is no limitation.

@ribaaa My guess: you restarted Openhab or the binding. I'm glad it works now!

@ribaaa Is the MySensors gateway service running and connected to Mosquitto?

@ribaaa What type of MQTT gateway are you using? RPi, Arduino...? I don't see it in den Mosquitto log. The Openhab side looks good, but there is no gateway responding to the requests send to Mosquitto.

Well, the Openhab and Mosquitto side looks good so far. I don't see a connection from the MySensors MQTT gateway in den Mosquitto log.
What gateway are you using?

@crumpy10 Well, that may seem confusing, but this is how the binding does work.
You may create as much things as you like and it doesn't matter if you create those things via PaperUi or the text files. If node id and child Id do match on an incoming messages the thing gets updated.
Discovery by Openhab is only possible if and when the node presents itself. In most MySensors sketches this is done on initialization of the code. This is why a reboot of the node is needed for discovery. There is no list of known nodes (in the gateway) that the binding may read out.
There is some code in the binding that should prevent the discovery (inbox) of already known things but that doesn't work in some cases. I've the same problem with my sonos things which get discovered all the time although I've already configured them via text files.
The discovered things in inbox will disappear after a timeout.

@crumpy10

1. There is no need to. You may configure your devices in PaperUi or in the files (or use both types)

2. No. The ID is assigned automatically by the binding. But you are free to define one in the sketch.

The screenshot from PaperUi with the things looks good. What is the problem? Are there any updates in the control view from Openhab? What does the log say?

@nizoo91 Stick to addons.cfg in /etc/openhab2/conf/services and don't fiddle with the file you mentioned above.
With package=standard (look for the examples in the comments) the UIs should reappear.

@waspie I'm testing the binding against a mosquitto in my development environment (eclipse IDE) and it is working fine there. That makes it so hard for me to debug the issue.

@waspie Well, it's working for @Guillermo-Schimmel and it's working in my development environment. This bugs the hell out of me. But maybe that's a problem that will be fixed with a update to OH2.

@waspie Well, I do use an MySensors ethernet gateway with the MySensors binding which works fine.
In addition to that I have MQTT devices, for example may heating unit (ebusd) which I connect via Mosquitto and the generic MQTT binding to OpenHAB. MySensors is not involved here.
My advice: use the ethernet gateway with the MySensors binding and keep Mosquitto for the rest. There were some changes in the MQTT implementation of Openhab in 2.4 which lead to some problems, like the one in this thread and I've found some more, while trying to adapt the new configuration and I'm sure there will be some changes to that in the next release. I'm currently using two Openhab instances (2.3 and 2.4) in parallel till all problems are solved.

@waspie you're able to use more than one controller with the MQTT gateway. So while using Openhab for automation you may use My Controller for wireless node updates / firmware uploads. That is not yet possible with the binding.

@jimmy-loyens Could you please check if the embedded-mqtt-broker thing is online? I suppose not. If the embedded broker addon (misc) is installed OpenHAB automatically discovers this embedded broker, just add that thing from inbox.
Now connect your MySensors MQTT gateway (hardware) to the IP and Port of the embedded-broker. After that your MySensors-bridge configuration should work. The port configuration at this point is not needed, but should do no harm, it'll be ignored.

Documentation for the binding: https://github.com/tobof/openhab2-addons/wiki

I've still found no solution but if I use the new embedded broker in OpenHAB2 and connect the the MySensors MQTT gateway to that broker everything works fine.
But I'd no success in connecting the MySensors MQTT gateway to a working MQTT-broker (MQTT2) or in creating a SystemBroker (MQTT2).

So for those of you that are willing to use the embeeded broker, this works fine with the MySensors MQTT gateway.
Just use embedded-mqtt-broker as broker name in the MQTT gateway configuration.

@guillermo-schimmel OK, next question: how did you define the system broker named mosquitto? Because that's the one the MySensors binding seems to use. In a service (cfg) file? I've had no success defining one and maybe that's the key.

@guillermo-schimmel You've mixed up attributes from the MySensors binding and the MQTT binding in the bridge definition. brokerName, topicSubscribe and so on are attributes from the MySensors binding. But this won't do any harm.

How is the MySensors gateway defined?

Hey @jimmy-loyens !

I needed some time to investigate the problem and after looking into it, I've no clue why this is working for you @Guillermo-Schimmel .

With version 2.4.0 and the changes to the mqtt binding I'm not able to connect the MySensors binding to the MQTT broker connection configured in OpenHAB. The MySensors binding uses the MQTT implementation and connection of OpenHAB, it does not connect to the broker itself.

And now the funny part: my development system works fine, so I need to find a way to debug this problem.

@Guillermo-Schimmel Did you configure broker and things in PaperUI or in textual files?

@waspie
I'm using rules to detect if a thing changes its status to offfline: https://www.openhab.org/docs/configuration/rules-dsl.html#thing-based-triggers

If my gateway changes its state to offline I receive a pushover notification.

@iostreamz314 The serial gateway is what you are looking for. But it's not a ready made dongle you are able to buy. You have to build it.

@jimmy-loyens I don't have rules specifically for mysensors or the gateways.

I've rules like: at dusk (Astro binding) close all covers (mysensors binding) and switch on the light in the garden (mysensors).
Or: if the door bell button (mysensors) is pushed play a sound (sonos) and send a notification to our mobiles (pushover).

@guillermo-schimmel Don't use the old jar.
Use the Eclipse marketplace to install the binding or use the one linked in the wiki. They both point to the same and current jar.

Don't forget to fulfill the dependencies either by installing the features in the karaf console or by installing the new mqtt binding and the serial binding.

https://github.com/tobof/openhab2-addons/wiki/Installation

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

@masmat I'm glad the first sensor is updating now. Please post the the thing and item definition of the light sensor and I'll look at it.
I only need the debug output from the binding so please use:

log:set DEBUG org.openhab.binding.mysensors

@masmat said in Getting MySensors MQTT Gateway working on OpenHAB 2.2 (Stable):

Number BoilerTemp "Lämminvesivaraaja [%.1f °C]" <heating> {channel="mysensors:temperature:mygateway1:temperature_1_15:temp"}

Needs to be changed to:

Number BoilerTemp "Lämminvesivaraaja [%.1f °C]" <heating> {channel="mysensors:temperature:mygateway1:BoilerTemp:temp"}

But there is something additionally amiss, because discovery is not working.
Please enable debug in the OH2 console and post the output of the initialization.
Don't spend time reinstalling, this looks like a configuration issue.

@masmat said in Getting MySensors MQTT Gateway working on OpenHAB 2.2 (Stable):

No autodiscovery, but this switches my sensors ONLINE (even ones that are not powered up ), but it's not updating the values.

Autodiscovery should work.
Does the temperature thing in OH2 get updates? Is it working?

The sensors will show up ONLINE if the connection to the broker is established, because the sensors are just a topic. There is at the moment no implementation to check if the sensors/things are really available. This could be done, but it is not implemented yet.

@jogant Good catch! I'm glad it's working now!

@jogant Indeed this looks like an error in your configuration. I suspect the MQTT configuration. Did you change the MQTT configuration according my posting above? I've also added a text to the Wiki. The name and content of the MQTT configuration differs between OpenHAB 2.2 and 2.3.

@jogant There already is a working version (2.4 SNAPSHOT) available on the marketplace and on my server. Please let me know if you expierence any problems.

@masmat please check your MQTT configuration. You're receiving an exception because it's trying to set "1883.0" for the value port.

@jogant Yeah. There are still some problems with 2.3 to fix. The binding works fine within the development IDE, but only there. I'm still looking into it.

@andre_m87 & @MasMat : I found a solution and indeed the MQTT implementation in OH2 (ESH) changed. This was a hard nut to crack, so it took me a while.

Here are the steps you need to do:

1. Rename: org.eclipse.smarthome.mqtt.cfg to org.eclipse.smarthome.mqttbroker.cfg
2. Change the content to:

name=mosquitto
host=192.168.2.3
secure=false
port=1883
username=USERNAME
password=PASSWORD
retain=false

If you're using a secure connection (SSL): change secure to true and use the correct port.

Another intersting feature in OpenHAB 2.3 is the embedded broker, so there is no need to have a separate MQTT server up and running.

@andre_m87 & @MasMat : I have the same problem here. Looks like a change in the OpenHAB MQTT implementation.
I'm working on it.

@julian-kröhl oh, you have found a really old thread.
I suggest you to go with the binding or with the MQTT gateway.

If you want to use the binding have a look here: https://github.com/tobof/openhab2-addons/wiki

@donny152 The version 2.2 / 2.3 in the binding name represents the code base the binding is developed to. The current code base is 2.3 so this is the way to go. If you're starting out, just use 2.3.

@dbagioni Is there an error message in the log to the time the gateway changes its state to offline?

Have you considered using the binding for OH2 and MySensors?

Please post (copy and paste) the exact error message from karaf console.

Is the Uno registered by Linux? dmesg, lsusb. Please check the spelling: is it ACM0 or AMC0?

@jogant please enable debug output with log:set DEBUG org.openhab.binding.mysensors and post the debug output here. I'll look at it.

@jjk Thank you for reporting back!

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

@masmat Just create the org.eclipse.smarthome.mqtt.cfg file. It's not created automatically. mqtt.cfg is not needed for the binding.

@cgrf Thank you for the hint! At the moment I don't have an explanation for that behaviour.

@masmat

1. /usr/share/openhab2/addons/
2. Thank you for the hint, I've pointed to the wrong directory, it's: /etc/openhab2/services
3. For additional Informations please have a look at the wiki: https://github.com/tobof/openhab2-addons/wiki

@jocke4u I'll try to document an example for using rules tomorrow. I'm not yet sure about the best final solution. Maybe I'll experiment with persistence within the binding.

@jocke4u & @NickBuilder :

Thank you! This will help me to find a solution. For reference, here is the corresponding issue on github: https://github.com/tobof/openhab2-addons/issues/69

@cgrf

Should OpenHAB be able to discover the sensors behind the gateway? Or do I need to configure them manually?

If you restart the node they should represent themself and will show up in the Inbox in PaperUI.

@cgrf said in openHAB 2.2 binding MQTT support:

Starting MQTT broker connection

You're using the mqtt1 (openhab1-addon) to connect to the broker. The OpenHAB2 binding is based on the current (/upcoming) mqtt-transport implementation of ESH.

My guess: the file org.eclipse.smarthome.mqtt.cfg is missing in /etc/openhab2/services and there only is a mqtt.cfg file. Just copy the mqtt.cfg file to org.eclipse.smarthome.mqtt.cfg (Same content, different name, different use).

mqtt.cfg: mqtt1 binding, mqtt-transport, owntracks ...

org.eclipse.smarthome.mqtt.cfg: ESH-MQTT and I'm only aware of my binding using it yet. But there are a few upcoming (mqtt generic, mqtt2 binding ..)

@cgrf

Is there a log entry in OpenHAB that looks like this?

[DEBUG] [.io.transport.mqtt.MqttService:155  ] - Starting MQTT Service...
[INFO ] [.i.t.mqtt.MqttBrokerConnection:576  ] - Starting MQTT broker connection 'mosquitto' to 'tcp://192.168.2.3:1883' with clientid paho6110733874326 and file store '/tmp/mosquitto'
[DEBUG] [.io.transport.mqtt.MqttService:155  ] - Starting MQTT Service...
[INFO ] [.i.t.mqtt.MqttBrokerConnection:576  ] - Starting MQTT broker connection 'mosquitto' to 'tcp://192.168.2.3:1883' with clientid paho6110762725063 and file store '/tmp/mosquitto'

Depending on your log level there only may be the INFO line.

This may be set in the gateway configuration either in PaperUI or via things-file:

PaperUI:

things-file:

Wiki

@jocke4u The request needs to be handled with rules because it is not allowed to access the value of an item via the binding API .

Please post the request (from the OpenHAB log, enable DEBUG with log:set DEBUG org.openhab.binding.mysensors if not already done in the karaf console) and we'll figure out the rule.

Hi @cgrf !

Please post the content of "org.eclipse.smarthome.mqtt.cfg".
My guess is: there is no connection between OpenHAB2 and Mosquitto. The binding is only using the connection, it is not in charge for establishment or reconnects.

Please check that in org.eclipse.smarthome.mqtt.cfg :

mosquitto.url=tcp://192.168.2.3:1883
mosquitto.user=user
mosquitto.pwd=secret
mosquitto.retain=false

and in the MQTT GW configuration (in OH2) the names are matching.

In your case it should look like (or similar to):

ineluki.url=tcp://172.19.0.5:1883
ineluki.user=user
ineluki.pwd=secret
ineluki.retain=false

@mythbai Thank you for reporting back! I'm glad it is working now.

The transport-mqtt feature is now needed because the support for MQTT GW is now part of the binding and the fix I've provided to you is based on the current code base.

The exception is completely unrelated to your problem and will do no harm. It only occures on startup and will soon be fixed!

@mythbai While the code for the serial connection in the binding was unchanged for a while it definatly issn't working now together with zwave binding.

Some time ago I've prepared a change of the serial library the binding is using. A few first tests looked promising but I didn't find the time to test it. So lets give it a new try: could you please test this binding: OH2 Binding with Serial Refactoring

Please remove the old binding with bundle:list, bundle:remove ID before installing the new one.

@siod

edit: Do I have to upload the ESP8266 Gateway Code to every ESP8266 Node?

Yes, you do have to. Just use seperate MQTT topics for every node/gateway.

I suppose you're looking for the MySensors / MQTT integration in general?

1. Is the ESP8266 flashed and working? Are you able to see the MQTT messages on the broker?
   (https://www.mysensors.org/build/mqtt_gateway)

2. You may connect the Mosquitto with OpenHAB via the (generic) MQTT binding (search the forum about how this could be achieved) or via the MySensors binding for OpenHAB2.

Hello @lesockz !

Well your node is sending V_RAIN instead of V_TEMP, so OpenHAB is not able to work with that.

Try:

MyMessage tempMsg(CHILD_ID_TEMP, V_TEMP);

For presentation S_TEMP (== 6) is used, while for set messages V_TEMP (==0) is used.

Hey @mythbai !

Could you please download and install the most recent version of the binding? I've not changed anything at the serial code, but while we're trying to figure out the problem, we should be on the same base of code.

I too have two serial devices connected to my OpenHAB box, one serial MySensors gateway and one Ebus-Adapter to Ebusd.

You may need to execute:

feature:install esh-io-transport-mqtt

Because the most current version of the binding now supports MQTT gateways.

Thank you @dakipro for your feedback!

I've updated the jar-file above. It is now possible to autodiscover a gateway if the corresponding broker is connected to OpenHab2.

At first glance the smarthome-mqtt and the (old) openhab-mqtt seem to work together, I've had no problem configuring both in the same instance. Of course this means we need mqtt.cfg AND org.eclipse.smarthome.mqtt.cfg.

Yeah, FOTA support would definatly be nice to have, but I'm not yet using it in my MySensors environment, so I first need to figure out how it works.

Finally I'm able to present a first alpha release of the MQTT support of the OpenHAB2 binding.
I've done some first tests with a RGB node and it looks good, but there is still some work to do.
So this version is for the category "Don't try this at home!".

Some important notes and things to test:

• The binding uses the upcoming MQTT support in smarthome/OpenHAB2, not the old version 1 binding! They may work together, but we need to test that. If you're willing to test that, please let me now.
• I've tested with OpenHAB2 snapshot #1099. I don't know how far it is compatible to old versions.
• There is a PR in the smarthome repository to add the functionality of a MQTT broker to OpenHAB2, so a separate broker won't be needed in the future. The binding will be compatible with this addition.
• I need to adjust logging.

Instructions:

1. Start OpenHAB2

2. In karaf console:
   feature:install esh-io-transport-mqtt

3. Download binding:
   wget http://www.oberfoell.com/openhab2/org.openhab.binding.mysensors-2.2.0-mqtt.jar

4. Place "org.eclipse.smarthome.mqtt.cfg" in the /etc/openhab2/services or conf/services directory. New filename! (Wassn't my idea!)

Example:

mosquitto.url=tcp://192.168.2.3:1883
mosquitto.user=user
mosquitto.pwd=secret
mosquitto.retain=false

(Use it like the old mqtt.cfg)

1. Configure MQTT broker via PaperUI
   
   or

via *.things file

Bridge mysensors:bridge-mqtt:gateway [  brokerName="mosquitto", 
                                        topicPublish="mygateway1-in",
                                        topicSubscribe="mygateway1-out",
                                        startupCheckEnabled=false ] {
                                        
}

1. Configure or discover things.

That's it!

@LastSamurai

The channel is not correct:

channel="mysensors:multimeter:gwSerial:voltageSensorWZ:volt"

It's confusing, but that's the way OpenHAB2 handles channels.

@gahlawathome I'm currently looking into the new MQTT implementation in smartphone. It should work without the PR above. The PR will bring us a new option to connect a MQTT binding with OpenHAB!

@LastSamurai Did you connect a channel / item for V_VOLTAGE? If the sensor is not represented by the sketch you need to connect it manually.

@andreground

I can't help you there, sorry.

Hi @andreground !

Have a look at expert mode in the OH2 binding:
https://github.com/tobof/openhab2-addons/wiki/Expert-mode-(rule-based)

This way you may send what you want.

@Nicklas-Starkel It happens, that MQTT support is sadly still on the to do list. There were some changes in the Smarthome MQTT library and we need to adopt them now.

Here's the Issue: https://github.com/tobof/openhab2-addons/issues/98

@gadgetman With the binding I'm only able to handle the things and the channels. The representation via items is not part of the bindings. After your description my first guess is, that this is a problem of OpenHAB itself, but I have no idea why it only happens with things using the MySensors binding. Is there something helpful in the logs?

Hi @rzylius !

There are two possible solutions:

1. Use ACK to track if a command is received by the node.

2. Send a heartbeat (it's a library function) to the controller / gateway and use a rule on the last update channel. If no update is received within a given time, send a push notification to your smartphone (or something like that).

Battery status is a special case in MySensors and in OpenHAB. You may define any thing type and only enable the battery channel. Every thing supports the battery channel. But you can't present a battery thing. Use another temp / humidity thing instead for example.