Guide: Setting up and testing MQTT Client Gateway

[gregl]

@DirkB19

Hi Dirk - did you change the MAC address ( these need to be unique too and it could have the same one "DEADBEEFFEED" as your existing GW )

[mbj]

@DirkB19 If you do not see anything in the serial monitor for the gateway then the problem must be with the gateway itself. Have you observed that there is a special #define MY_W5100_SPI_EN to uncomment when compiling for an Uno with the shield installed ? If not, you can try that.

[DirkB19]

@mbj said:

MY_W5100_SPI_EN

Sorry for this NOOB question, but where is this to be uncommented.
I don't see it in the gateway sketch ?
I use this sketch GatewayW5100MQTTClient.ino

[mbj]

@DirkB19

It is looking like this, just uncomment the #define - line:

// W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4

[DirkB19]

@mbj

Thanks for the help, but I'm still very confused because OK, I found the line to uncomment.
I uncommented, but still nothing on serial monitor.
So then I see lines below this in the sketch and I realize that my radio is wired as follows ;
SCK -- Pin 13
MISO -- Pin 12
MOSI -- Pin 11
CS -- Pin 6
CE -- Pin 5
?
But there's no Pins 14,15,16 to be found on my W5100/UNO ? So I'm very confused ...

#if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD)
#define MY_SOFTSPI
#define MY_SOFT_SPI_SCK_PIN 14
#define MY_SOFT_SPI_MISO_PIN 16
#define MY_SOFT_SPI_MOSI_PIN 15
#endif

// When W5100 is connected we have to move CE/CSN pins for NRF radio
#define MY_RF24_CE_PIN 5
#define MY_RF24_CS_PIN 6

[martinhjelmare]

@DirkB19

In this case I think pin 14-16 are meant to be aliases for analog pins A0-A2.

Read the build page for the Ethernet gateway. You have to wire the radio in a non standard way in combination with the 5100.

But it's optional when using the shield. You could enable the SPI for that instead, like you were talking about a few posts up.

[mbj]

@DirkB19 The Arduino pinouts are, to say the least, confusing and it helps to look at one of the pinout sketches you can find on the net, for example http://marcusjenkins.com/wp-content/uploads/2014/06/ARDUINO_V2.png. So the pins are, as Martin said, (A0-A2) which must be exactly as you had them wired before if you had a "previous version" working MQTT Ethernet gateway. I have such a gateway (nowadays used as a spare) but built with a nano and a W5100 unit and it compiled and worked right away using the GatewayW5100MQTTClient.ino sketch from the development branch.

As you see nothing in the serial monitor there must be something else. Even if you upload the sketch to a completely barebone UNO without radio or anything else attached you will get a message in the serial monitor, in this case:

0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0-beta)
0;255;3;0;9;Radio init failed. Check wiring.

So if you see nothing at all there is something really basic wrong.
Presumably your sketch compiles OK so I assume you have exchanged all Arduino libraries to the libraries which belong to the Mysensors development branch.

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