Using the PAHO online MQTT over WebSocket test client
I connect and subscribe to sub/{user short identifier}/#.
Any message I publish to pub/{user short identifier}/{device short identifier}/{node short identifier}/{field name} using the Paho test client never appears in the "Last Messages" section. However if I use the android app and the "MQTT On/Off" widget the messages appear as expected.
I have confirmed that using the Paho client publish, the values do appear under "Last Values" on the field screen, therefore the publish is succeeding.
In the MQTT tutorial it states "We will route your published messages from pub/* topic to sub/* topic. " therefore I am expecting to see a subscribe message for every publish message sent through the Paho test client or am I misunderstanding?
Any message I publish to pub/{user short identifier}/{device short identifier}/{node short identifier}/{field name} using the Paho test client never appears in the "Last Messages" section. However if I use the android app and the "MQTT On/Off" widget the messages appear as expected.
The "historical" background of this behaviour is that a device send a lot of measurement data through the MQTT and most of the time you don't need to get what you sent a few moments earlier, so that what the cloud backend processed as data storage or something else is not returned to the MQTT.
I can add a flag to the device about the echo behaviour :
- NONE: no echo at all
- UNPROCESSED: echo only unprocessed messages (default behaviour)
- ALL: echo all messages
What do you think?
The "historical" background of this behaviour is that a device send a lot of measurement data through the MQTT and most of the time you don't need to get what you sent a few moments earlier, so that what the cloud backend processed as data storage or something else is not returned to the MQTT.
This makes perfect sense. Most of the time you would not want the broker to be sending back the data you just sent.
This would work but I think the flag should be at node level. You can have one device transmitting sensor data only for logging purposes and a second sensor that needs to be monitored by another device. I am unsure of what an unprocessed message is...
Use Case
You have a device e.g. An ESP with a temperature and humidity sensor attached, lets call this device ESP1 . You have a second device e.g Raspberry Pi (lets call this RPi1). ESP1 publishes temperature data every minute. RPi1 should be able to subscribe to topic /ESP1 (device short id) / Temperature (node short id) / value (field).
RPi1 receives a message that the temperature value is above 25 and performs some action e.g. activates a relay and turns on a fan.
In this case you would only want to echo the temperature node and not the humidity node.
For clarity and not to cause confusing...
Maybe echo is the wrong terminology to be using. In a standard MQTT broker setup a client publishes a message and all other clients subscribed to that topic should receive the message. This is not the behaviour I am experiencing with the IoT Guru broker as per my previous post when testing with the Paho test client. I would like to be able to subscribe from my MQTT client to a topic that is publishing my sensor data so that my I can perform some actions based of those values.
I hope I am making sense...
This makes perfect sense. Most of the time you would not want the broker to be sending back the data you just sent.
And the pub -> sub gateway counts the messages for quota.
This would work but I think the flag should be at node level. You can have one device transmitting sensor data only for logging purposes and a second sensor that needs to be monitored by another device. I am unsure of what an unprocessed message is...
Okay. 🙂
Maybe echo is the wrong terminology to be using. In a standard MQTT broker setup a client publishes a message and all other clients subscribed to that topic should receive the message. This is not the behaviour I am experiencing with the IoT Guru broker as per my previous post when testing with the Paho test client. I would like to be able to subscribe from my MQTT client to a topic that is publishing my sensor data so that my I can perform some actions based of those values.
It need some rework on the quota code base but it is possible. I will think about it.
Ah this makes a lot more sense now when thinking in terms of quota's for messages. One pub message could generate x number of sub messages depending on the number of clients subscribed...got it.
If you decide to make the change, I would then change my suggestion from having the indicator at node level to field level. Something like "Allow Subscriptions", if ticked clients can subscribe to that field. This seems to make more sense as the quotas work at field level.
This is not a bug and is working as designed, should I create a feature request and this topic can be closed or deleted?
If you decide to make the change, I would then change my suggestion from having the indicator at node level to field level. Something like "Allow Subscriptions", if ticked clients can subscribe to that field. This seems to make more sense as the quotas work at field level.
Okay, from now, you can subscribe to the "pub/{userShortId}/#". Please test it. 🙂
This is not a bug and is working as designed, should I create a feature request and this topic can be closed or deleted?
It's okay, I will add a [Solved] flag to the topic.
Please check my PM.
