Guide: Setting up and testing MQTT Client Gateway

[DirkB19]

@mbj

Aha !! Finally, it WORKS :)
mbj gave me the right hint about using the development libraries !!!

So for others to learn from my mistakes, to get a UNO&W5100 shield to work with this MQTT Client Gateway sketch, you need your nRF24 radio connected to these pins nrs. on the W5100 shield ;
SCK -- Pin 13
MISO -- Pin 12
MOSI -- Pin 11
CS -- Pin 6
CE -- Pin 5

AND (!) you need to install the libraries from the development branch.
(I first removed the 1.5 libraries)

I just hope that installing the libraries from development branch will not get me into trouble with my the rest of my nodes (upladed with 1.5).

Is there an easy way to switch between 1.5 & development branch libraries when uploading sketches ?

Anyway, thanks to all those who responded and special thanks to mbj.

Some things are so obvious, but for newbies (like me) it can be a struggle ...

[martinhjelmare]

@DirkB19

You can use git to easily change between different branches with libraries and sketches.

The take home message from the first sentence in the top post of this thread, is that dev branch libs are required with this sketch.

You should take care not to mix old style sketches with dev branch library and vice versa. Node to node to gateway comm should be OK as long as all nodes and gateway know the message types being used.

[moskovskiy82]

In most examples for the openhab i see the examples being put like

Dimmer Light_R {mqtt=">[server:/mySensors/118/0/V_DIMMER:state:*:default]"}

Is there a way with the MQTT client gateway to have the messages defined as
V_DIMMER e.t.c?

[27maximilian]

@moskovskiy82

I believe these examples are mostly referring to the older MQTT (Broker) Gateway. As @hek said in post #1 the client gateway resembles the serial protocol. The difference between the two is on the one hand a slightly modified topic structure and on the other hand that instead of names the topics make use of the number representation of the message types (see the Serial API).

In your example you would have to use 3 instead of V_DIMMER as CMD-TYPE in your topic-configuration.

If you are wondering whether there is a library which you can included in your items-file in openhab such that you can use the name representation instead of the values for the message type, then I am afraid I don't have a solution for you. I am, moreover, pretty sure that this won't be possible with the mqtt-binding but would require a specific mysensors binding for openhab.

[moskovskiy82]

And for the better understanding - why were the inbound and outbound topics separated? Are there any drawbacks in unifiing when using openhab as a controller?

[hek]

If they weren't separated all outgoing messages would be looped back to the gateway.

[27maximilian]

Update: I guess I was answering while @hek also posted his answer.

I didn't do it, so I can only guess. But I believe this was done because otherwise the MQTT-topic would not include any information who the recipient is. This would on the one hand (1) make the GW send every message from a sensor back to the sensor and on the other hand (2) could cause infinite loops with controllers such as openhab.

Regarding (1), imagine the topic-strucutre would be like:

mysensors/6/1/1/0/0

for a temperature sensors with node id 6 and child id 1 without the in/out separation. If the sensor now sends a message with the temperature, e.g. 23, to the GW, then the GW posts a message with the payload 23 to the topic. However, because there is no in/out separation, the GW listens to all messages on the topic

mysensors/#

and hence receives it own message, which it then sends back to the originating sensor. Not only would this double the traffic in your radio network, it might also be problematic for bidirectional sensors, such as a relay, because it would also cause an infinite loop.

Regarding the infinite loop, I will use (2) as an example but the same would happen for a bidirectional sensor. Consider you would have a relay sensors, that can be locally or remotely trigged, as for example a lights relay with switch. In openhab this relay could be defined like this:

Switch LIGHT_test {mqtt=">[mosqMQTT:mysensors/2/1/1/0/2:command:*:default],>[mosqMQTT:mysensors/2/1/1/0/2:command:default]"}

Imagine the local switch is trigged on the relay, then the sensor sends a message to the GW, which posts this message on the mqtt-topic:

mysensors/2/1/1/0/2

The OH receives this message, updates the state of this item but also posts a message on the topic because of the item configuration, which would generate an infinite loop. If the sensor would do the same then we would have an infinite loop, in which the number of messages would double each iteration.

[moskovskiy82]

@27maximilian
Ok got the point. But in your example with the local button on the relay. How would one define the item in openhab?
Seems two items need to be defined - buton with the gateway-in topic and a relay with gateway-out topic? And than implement a rule to update the relay status when the button state was changed? As otherwise the controller wouldn't know the state of the relay?

Seems i will face exact same problem as in this topic when i finish the code MQTT Dimmer

[27maximilian]

I am not sure because I never did this myself but I would try to not only use the command class but also the state class in OH.

Something like this could work:

Switch LIGHT_test {mqtt=">[mosqMQTT:mysensors-in/2/1/1/0/2:command:*:default],<[mosqMQTT:mysensors-out/2/1/1/0/2:state:default]"}

Please be aware that this is just an idea. I never implemented this so far, neither did I test the code. The syntax could be wrong or it might conceptually not work.

[Martin Tellblom]

I use this gateway 2.0 and I'm very pleased with it, but...... I would like to be able to use it as a network gateway as well.
Is this possible?

[Samuel235]

Sorry if i shouldn't be bringing an old thread back to life, however it is a sticky and therefor I assume you guys would be okay with this being brought up to date.

I have a pretty simple question really;

My W5100GatewayMQTTClient is in a loop, as shown below on the serial monitor, it seems to be reconnecting to the MQTT server every 8-10 seconds. Is this normal behaviour or not? I'm by no means asking for a solution (if i get one i will be sure to post here for others to revert back to if needed), but if you would like to suggest something, then it would be appreciated. I'm looking more for just a confirmation of if this is normal behaviour as of MySensors 2.1 or not.

I used to run this client gateway back when MySensors V1.6 was in the development branch back in late 2015 and It didn't do anything like this back then.