mtconnect
mqtt2 MTConnect/Probe/ topic name for agent
agent device probe topic is prefixed with Agent.
is that intentional? what is Agent. in this case? is that unique to the 'agent' device type?
If it is device name - why dont the other devices have topics with the same [name].[uuid] format?
It is the type of Device. It is the same as the node below the Devices collection in the Devices model. BestW(Sent from mobile)On Dec 22, 2023, at 00:55, robot-ranger @.***> wrote: agent device probe topic is prefixed with Agent. image.png (view on web) is that intentional? what is Agent. in this case? is that unique to the 'agent' device type? If it is device name - why dont the other devices have topics with the same [name].[uuid] format?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
ok, right. i was expecting to be able to walk the json to Current/Agent by path instead of by name. if that makes any sense.
since the name is Agent.[uuid] , and uuid is unknown to the client until connect, in order to find the agent, i have to subscribe to MTConnect/Current/# and iteratively inspect each published message for a DeviceStream with name == Agent
...but the owner/operator of the agent COULD have changed the name in agent.cfg...
is the expectation that we do some logical if topic.startsWith('MTConnect/Current/Agent')?
Admittedly this would be abusive on behalf of the owner/operator of the agent, but what if one of the devices' uuid started with 'Agent'? (then the if statement above would be true for more than one device)
Ex: if a device just happens to have a uuid Agent-but-not-agent, then its topic would be MTConnect/Current/Agent-but-not-agent (again; i realize that would ultimately be operator error, im just trying to illustrate the use case for having a name-agnostic path to agent)
TLDR - imo, the agent probe and current should be accessible by name-agnostic path to improve the flexibility of client apps.
ETA: it would be nice to be able to subscribe to the agent topics without knowing the name, and be guaranteed i am getting the agent exclusively
I cant exclusively subscribe to the agent because my client app may not know the agent uuid and therefore does not know the topic string to subscribe to. The only way to "find" the agent is to subscribe to the entire /Probe/+ or /Current/+ topic and inspect each topic. The client apps may not care about ALL of the devices, maybe only wants data from some adapters, but also has a need to reference the agent.
for maximum inter-operability between client apps and cppagent - I propose that the agent should have fixed and common topic strings without uuid, so that any app or adapter can locate and query the agent without knowing uuid
something like MTConnect/Current/Agent/ and MTConnect/Probe/Agent/
Any app or data consumer that wants to further verify the agent by uuid, it still can.
What would you suggest in the case where there is more than one agent per broker?Do we introduce a “node id” concept like SpB where we add the agent id as a prefix for all devices including the agent? (Sent from mobile)On Dec 24, 2023, at 01:31, robot-ranger @.***> wrote: i suppose i could unsubscribe... 🤔
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
well... i hadnt thought of that; not something we envisioned in our use cases. But that is a good point..