emiltin
commented
1 week ago One thought on this subject, if the recipient's name is not in the topic name: as an IOT device, is it a network / cpu overhead for me if I'm subscribed to the same topic as the other devices for receiving commands? (I think it is).
The recepient is in the topic path of commands and alarm reactions:
command/<module>/<code>/<receiver>/<component>
reaction/<module>/<code>/<receiver>/<component>A device will typically subscribe to a topic path that includes its own node id, so it only receives relevant commands, for example, assuming a TLC with the node id 4d2f:
subscribe:
command/tlc/+/4d2f/#
reaction/tlc/+/4d2f/#On the other hand, a status is not send to one specific receiver, and it therefore has the sender in the topic path, instead of the receiver:
status/<module>/<code>/<sender>/<component>
alarm/<module>/<code>/<sender>/<component>A supervisor system would typically want status messages from any device, and would therefore subscribe using a wildcard for the node id part, and in fact typically accepting any module/code as well:
subscribe:
status/#
alarm/#If I had to audit this kind of action, I would put in the payload the name of the system that sent the command (the name of the business application) and the name of the operator for commands concerning user security would be logged in my business application with confidentiality management and data purging.
Yes we could consider putting the sender node id, and possibly also an operator id, in the payload of commands. But note that for auditing, the sender id is always known to the broker and would typically be logged there. Would that be enough? Or is there are need for logging this also on the device?
One thought on this subject, if the recipient's name is not in the topic name: as an IOT device, is it a network / cpu overhead for me if I'm subscribed to the same topic as the other devices for receiving commands? (I think it is).
On the other hand, having the sender's name in the topic name doesn't enable the same kind of optimization as having the recipient's name. For auditing reasons, this could be an optional field in the payload (everyone can decide whether or not to put it in, depending on their supervisor's possibilities, or for RGPD legal reasons if the operator's name is put in there).
If I had to audit this kind of action, I would put in the payload the name of the system that sent the command (the name of the business application) and the name of the operator for commands concerning user security would be logged in my business application with confidentiality management and data purging.
What do you think of this?