MQTT - 2 Messages per 1 publish on subscriber side

[geoxanadu]

If one sends (publish) 1 observation over MQTT on "v1.0/Datastreams(id)/Observations" I receive 2 messages (JSON Objects) on the subscriber side.

publish on "v1.0/Datastreams(id)/Observations":

{ „result“: 23.57 }

Subscription on "v1.0/Datastreams(id)/Observations" yields:

1. { „result“: 23.57 }

and 2. { "phenomenonTime" : "2017-04-24T11:59:26.079Z", "resultTime" : null, "result" : 23.57, "Datastream@iot.navigationLink" : "http://xx.xxx.xxx.xxx/SensorThingsService/v1.0/Observations(25460)/Datastream", "FeatureOfInterest@iot.navigationLink" : "http://xx.xxx.xxx.xxx /SensorThingsService/v1.0/Observations(25460)/FeatureOfInterest", "@iot.id" : 25460, "@iot.selfLink" : "http://xx.xxx.xxx.xxx /SensorThingsService/v1.0/Observations(25460)" }

So it seems that the message broker itself pushes the message to the subscriber and at the same time the SensorThingsServer sends a SensorThingsAPI compliant JSON object as well.

Following figure 4 on page 83 of the OGC specifiaction I would expect only on MQTT message. Is there a reason for this in your application?

Best regards

[hylkevds]

We agree it is not nice. This is a known issue with the standard itself, described on the issue tracker of the standard: https://github.com/opengeospatial/sensorthings/issues/5

Anything that is sent to a MQTT topic is distributed to all clients listening on that topic. So if a client listens on v1.0/Observations and a second client posts a new Observation using MQTT to v1.0/Observations then the listening client will receive that post. After the Observation is created, the server posts a new message to v1.0/Observations which is also received by the client.

We've proposed an update to the standard in the issue mentioned above. You could add your ideas there too.

A sort-of-workaround is to listen on v1.0/Datastreams(id)/Observations but publish on v1.0/Observations