You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the ideas of MQTT is that clients don't have to know anything about each other. They just need the address of the broker, and some topic to publish/subscribe to. This means that a sensor, e.g. a thermometer, starts publishing data as soon as it connects to the broker, regardless of whether anyone is listening.
A benefit of this is that the broker can be set up to persists data to a database, regardless of which clients (supervisors) are connected.
But if the data has a significant size, a downside might be that you spend bandwidth for no reason, in case nobody is listening.
This could also be an issue if the device can deliver the data in several formats, aggregation intervals, etc. Instead of having to publish in all formats, only what's asked by supervisor should be send.
In RSMP 3 you can set the status interval, either a fixed interval, or send on change. Some settings might result if high data bandwidth, like signal group status for all groups every second, or some traffic sensor that has a lot of very frequent changes.
How could this be handled in MQTT?
Timed
Supervisors could also inform a device that it would like data to be send for some interval. A supervisor would have to ask for more before the current interval times out. If the supervisor dies, the device will then stop sending data at some point.
Update intervals
If we want a supervisor to be able to subscribe to data at arbitrary intervals, device could publish to topics that include the update interval in the topic name e.g an interval of once per minute: status/12d9/traffic/volume/1m
A device could perhaps offer some fixed interval that you can use, e.g. 1s, 10s, 1m, 10m, 1h, 24h
Subscriptions
If we need to provide different data stream to each supervisor, another approach would be for each supervisor to subscribe to a topic that include the id of the supervisor. The supervisor informs the device about what data it wants, and the device then starts publishing to a topic that includes the id of the supervisor, which only that particular supervisor reads.
Aggregation
A question is whether a device should be able to provide data in several different aggregations at the same time (to different supervisor) or just one.
Or whether we want to move to model where devices send just raw data, and aggregation is handled later in the chain.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Copied from a file in the repo:
Is anyone listening?
One of the ideas of MQTT is that clients don't have to know anything about each other. They just need the address of the broker, and some topic to publish/subscribe to. This means that a sensor, e.g. a thermometer, starts publishing data as soon as it connects to the broker, regardless of whether anyone is listening.
A benefit of this is that the broker can be set up to persists data to a database, regardless of which clients (supervisors) are connected.
But if the data has a significant size, a downside might be that you spend bandwidth for no reason, in case nobody is listening.
This could also be an issue if the device can deliver the data in several formats, aggregation intervals, etc. Instead of having to publish in all formats, only what's asked by supervisor should be send.
In RSMP 3 you can set the status interval, either a fixed interval, or send on change. Some settings might result if high data bandwidth, like signal group status for all groups every second, or some traffic sensor that has a lot of very frequent changes.
How could this be handled in MQTT?
Timed
Supervisors could also inform a device that it would like data to be send for some interval. A supervisor would have to ask for more before the current interval times out. If the supervisor dies, the device will then stop sending data at some point.
Update intervals
If we want a supervisor to be able to subscribe to data at arbitrary intervals, device could publish to topics that include the update interval in the topic name e.g an interval of once per minute:
status/12d9/traffic/volume/1m
A device could perhaps offer some fixed interval that you can use, e.g. 1s, 10s, 1m, 10m, 1h, 24h
Subscriptions
If we need to provide different data stream to each supervisor, another approach would be for each supervisor to subscribe to a topic that include the id of the supervisor. The supervisor informs the device about what data it wants, and the device then starts publishing to a topic that includes the id of the supervisor, which only that particular supervisor reads.
Aggregation
A question is whether a device should be able to provide data in several different aggregations at the same time (to different supervisor) or just one.
Or whether we want to move to model where devices send just raw data, and aggregation is handled later in the chain.
Beta Was this translation helpful? Give feedback.
All reactions