MQTT Setup - Client or Broker & Testing

[diggs]

Thanks for all help everyone. Finally getting everything up and running generally. I got the system running and talking to OpenHAB initially with the MQTTGateway (1.5) and the instructions here for setting up items etc in openhab. So I can now see Temp and Humidity readings.

http://forum.mysensors.org/topic/303/mqtt-broker-gateway

It ended up pretty straight forward. With that MQTTGateway broker running, I could actually subscribe to it with MQTTSpy and see the data. Only issue was that the MQTTGateway only seems to allow one client connection at a time, so once I had OpenHAB connected I could no longer connect with MQTTSpy, but at least it all worked and I can get reading in OpenHAB.

What I then tried was to bridge my Mosquitto Broker to the MQTTGateway broker to make broker access a little more flexible.

OpenHAB <> Mosquitto <> MQTTGateway

I got them talking/bridged and the data feed made it through to OpenHAB, so all good.

Only question I now have is about subscribing with the Mosquitto Broker in bridge mode.

If I connect MQTTSpy to the Mosquitto Broker and create a catch-all subscribed topic as "#" I see all the readings coming from the MQTTGateway to Mosquitto/OpenHAB, all good. However if I use MQTTSpy and subscribe to a specific topic such as "MyMQTT/20/0/V_HUM" nothing shows in the feed, though that topic is shown under the "#" topic and OpenHAB is picking up the feed data just fine.

This subscription matches how the item is setup and also what I see in the "#" feed.

{mqtt="<[mysensor:MyMQTT/20/0/V_HUM:state:default]"}

Anyone have any suggestions why the direct subscription does not pickup the feed?

Cheers

This is my bridge setting in Mosquitto config

connection MMQTTtoSensor
address 192.168.0.175:1883
clientid MyMQTT
cleansession true
notifications true
topic #

[John Connolly]

I've just built the MQTT gateway as I'm planning to replace the serial one I have in place currently, since I understand MQTT/IP comms a lot better than I do serial. I've built it but I can't connect to it with an MQTT client like MQTT Spy or the command line MQTT tools. I can ping it, but it won't let me connect in other ways.

I've built the gateway with a W5100 shield (which I just don't trust) and messed around with the pin assignments/SOFTSPI etc - I can see the gateway receiving the sensor updates if I open serial monitor. I had a similar issue with some basic webserver tests with that W5100 shield. I should throw it away.

I'm waiting for some new ethernet modules (ENC28J60-based) and will give it another go then. The next step will be to get it bridged to Mosquitto on my Pi. I'll be back...

[TD22057]

@John-Connolly You may want to the try the client gateway from this thread: http://forum.mysensors.org/topic/524/mqtt-client-gateway
It's a real MQTT client (point it at your Mosquitto broker) which I find easier to understand than the pseudo-broker that the MQTT gateway uses.

[tomkxy]

@John: You find the MQTTClientGateway in the MySensors Development branch. It has been merged recently.

[John]

I think this was meant for @John-Connolly ? ;)

[jkandasa]

I guess if create topic like mentioned below(Proposed Topic), we can achieve all the actions that we are doing with serial gateway or Ethernet gateway.

Proposed Topic: MyMQTT/node-id/child-sensor-id/message-type/sub-type
*Current Topic: * MyMQTT/node-id/child-sensor-id/sub-type

Is there any specific reason to skip 'message-type' from topic?

[tomkxy]

@jkandasa: I am not familiar with the Serial Gateway or the Ethernet gateway. What are the particular actions which cannot be done MQTTClientGateway?

With respect to your question whether there is any specific reason to not include the message-type, I have to admit that I am not aware right now of any particular reasons. However, I have to admit that I more or less just adapted the code created by other forum members to run with the new API version.

So in order to get it right you suggest to put the message type defined in the enum of MyMessage.h between the sensor-id and the sub-type?
For example: MyMQTT/node-id/child-sensor-id/0/sub-type -> for the presentation message

[jkandasa]

@tomkxy I guess you are also pointing this MQTT gateway: http://www.mysensors.org/build/mqtt_gateway

If we do not include 'message-type' we could not understand Set,Req,Presentation,Internal and Stream types. Right now we have added MQTT specific type which is not require if we use message-type

In the current design, we cannot do reboot, OTA request/response, get Sensor Name, req from sensor, etc.,

If we follow like we are receiving from Ethernet Gateway or Serial Gateway (node-id;child-sensor-id;message-type;ack;sub-type;payload), no need to maintain types separately in MQTT Gateway code same time we can do all the operations that is supported by MySensors. In MQTT topic will be MyMQTT/node-id/child-sensor-id/message-type/sub-type, we can add payload in mqtt payload and ignore ack bit(if it's 1) in MQTT Gateway itself.

[tomkxy]

@jkandasa No sorry I was referring to the MQTTClientGateway which as acting as a client to a MQTT broker. However, I see your point. The issue to be dealt with in the MQTTClientGateway is that it subscribes to the broker in order to receive messages from the controller and it needs some way to distinguish between inbound and outbound messages otherwise it would try to act on a message it just published on the broker.

One idea was to introduce two disjunct topic hierarchies which I would not like.
If the message types from send from the gateway to the controller and the message types send from the controller to the gateway would be disjoint I might be able to handle that in the MQTTClientGateway. Do you know whether the message types are disjoint?

[John Connolly]

@TD22057 said:

@John-Connolly You may want to the try the client gateway from this thread: http://forum.mysensors.org/topic/524/mqtt-client-gateway
It's a real MQTT client (point it at your Mosquitto broker) which I find easier to understand than the pseudo-broker that the MQTT gateway uses.

That's EXACTLY what I need/want! Thanks! I'll give it a shot the second the new kit arrives from AliExpress...which is taking its time.