With what granularity should HiveMQ credentials be assigned? #237
sgbaird
started this conversation in
Data and access management
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
For example, let's say I have the digital pipette and the motorized turntable.
I lean towards yes for both of the above questions. For example, digital pipette would have its own credentials and only be allowed to subscribe and publish on the
digital-pipette#
(note the#
wildcard), the motorized turntable would have it's own credentials and only be allowed to subscribe and publish on theturntable/#
topic. Then the orchestrator would be able to publish on any topic.Naming scheme
What should I use for the topic naming schema?
It's worth mentioning that I should probably be using MQTT topic trees. For example, if there are multiple devices within a single experiment, then package those topics under a topic level. For example,
clslab-solid/wax-lamp
,clslab-solid/turntable
, etc. However, it's also quite possible that devices will move to different experiments. For example, while a certain version of CLSLab:Solid implies use of a wax lamp, use of a wax lamp does not explicitly mean CLSLab:Solid. It makes it pretty easy to see which devices are connected to which experiments, but it becomes more difficult to swap things out. Configuration files are one alternative, but then these have to be manually updated, and could easily get out-of-sync. In that case, maybe it's worth the effort of enforcing a more rigorous topic naming schema. Additionally, typically I'd prefer to create copies of components rather than disassemble devices and refactor into new devices, at least where resources (time and money) permit.As an example, my instantiation of the digital pipette includes two components that support communication: the L16-R actuator and the Pico W. The credentials reside on the Pico W and the commands are actually sent to the L16-R actuator, but the device as a whole is a specific instance of the "Digital Pipette". Likewise, it's not guaranteed that the
L16-R
is the only one I use, that theDigital Pipette
is the only one in the ecosystem, and almost certainly it won't be the case that the Pico W is the only one. I suppose I could do something like:Is the digital pipette just the hardware, or is it the microcontroller, too? It's just a name anyways, but good to be consistent. The format above shows the flow of things. The device type named
digital-pipette
uses a particular Pico W microcontroller that has its own (mostly unique) ID.In terms of controlling the device, I think I prefer the idea of messages being in JSON format rather than trying to embed the parameters in the MQTT topic itself, even if there's only a single parameter being passed. I think it's worth the effort to use
json.loads(...)
to be able to have a more standardized framework. This also makes it more amenable to passing info back (e.g., success message). Open to feedback here.I'm not sure if it would make sense to track the
PICO_ID
-s associated with each Pico W and have that in the topic, too.See also:
Beta Was this translation helpful? Give feedback.
All reactions