I lean heavily on the Peripheral construct as I have many “dumb” devices I need to interact with. This requires me to write lots of middleware. I leverage Edge Workflows heavily for thus purpose. A major concern I have is I’m unable to intercept Device Commands intended for ALL downstream peripherals at their respective Edge Compute in a workflow. First I thought the Device: Command trigger node would pick up peripherals commands, but I was wrong. Then I thought I’d be tricky here and just use an MQTT block with a wildcard topic ala */command on that Edge Compute. I was saddened to come up against this little doozy in the docs though:
Single-level and multi-level wildcard topics such as custom/+/temperature or custom/# are valid when using the MQTT Trigger Node in Application Workflows, but are not able to be used when using the Losant Broker and MQTT Trigger Node on the Edge Agent. https://docs.losant.com/workflows/triggers/mqtt/
So…as far as I can tell, I’m stuck. I’d love to see EITHER:
The Device: Command trigger have inputs that would enable listing for all commands for assigned devices (perhaps via an advanced filter) OR
The MQTT Trigger node to enable wildcards at the edge using the Losant broker
I definitely understand your struggle here. Just so I completely understand your use case and what you’re looking for…
You have multiple peripherals that are connected to your Edge Agent. You’d like to be able to send a Device command down to all those peripherals, or rather a specific set of peripherals, based on which Edge Agent they’re connected/associated with. Is this correct?
So you’re looking for either the Device Command trigger to have a way to filter which devices get the command or you’re looking for multi-level wildcard topics at the edge?
I just want to be sure that I get this feature right for you.
1 Edge Compute has 10 Peripherals of different make/model etc.
If I send a command to 1 of those Peripherals via the Losant UI / API, I want to intercept that command in an Edge Workflow as a trigger. Then I can parse the command (knowing what device it was intended for…that’ll be important) and perform some steps to execute the command there at the edge.
Without something like this, I have to exit Edge Workflows and instead use the Python or Node.js SDKs to listen for the commands, then handle them. If forced, I could build a simple microservice in one of those languages that listens for any Peripheral commands and sends them back to the Edge Workflows via MQTT/HTTP triggers…but that seems like a pretty roundabout way to do it
Make sense? Of course this could apply to any number of commands sent to any number of devices. Just need a way to LISTEN for the commands as a workflow trigger (with the command name/payload &&& the target device ID).
Seems from the docs the preferred method as of right now is to NOT send messages to the peripherals, but instead send them to the Edge Compute directly, then handle them (send to correct device, etc) as referenced here:
I understand this point, but really don’t like it…adds another layer to the command process and renders the /command path for any peripheral basically useless without external programming / firmware development.
Commands can be received via the REST API.
So…you could theoretically Get Peripherals, loop through the Peripherals, and GET commands for each device via the API…here’s the path (GET https://api.losant.com/applications/APPLICATION_ID /devices/ DEVICE_ID /command).
That’s actually not a bad workaround. That gives you not just a method get commands, but to get specific commands by timestamp and in the quantity desired…it’s stream processing.
Honestly I like the idea of a Peripheral Command Trigger that is filterable the same way Get Peripherals is. Left un-scoped it would receive all commands destined for children of the Edge Compute. But you could filter it right there in the node for a specific DeviceId, tag/value, etc. That seems cleanest to me. MQTT wildcards have their own dangers…you’d need to artificially limit what commands you receive from the Losant broker at the edge as you don’t want commands from EVERY device in the tenant. Then you really don’t have any further way to scope without conditionals and such.
I’ve got it logged as a feature request to support receiving commands for peripherals in the edge agent. Thanks for the ideas.
There are some corner cases we need to figure out still - such as …
We only send down info on a limited number of an edge compute device’s peripherals, so what if the peripherals associated with an edge device exceed that number?
What do we do about floating peripheral devices, which behave as peripherals except any gateway / edge compute device may report on their behalf? Should all edge devices receive all commands for all floating peripherals?
I don’t think this will be a problem since it can be done by creating properly the access key for each gateway, where it is possible to define the allowed subscription and publish topics.
So, it is possible to create a pattern where each edge will pub/sub only it owns topics.
There are some corner cases we need to figure out still - such as …
We only send down info on a limited number of an edge compute device’s peripherals, so what if the peripherals associated with an edge device exceed that number?
What do we do about floating peripheral devices, which behave as peripherals except any gateway / edge compute device may report on their behalf? Should all edge devices receive all commands for all floating peripherals?
Follow whatever happens with the Peripheral: Get node? If we just don’t get anything after 1000 endpoints, then we need to be certain we get updates for the same 1000 devices. Honestly you’ve clearly stated a limitation…I’d expect things to get “wonky” once we exceed the limit (which we shouldn’t be doing). However, perhaps the bigger question is: Why is there a limit in the first place?" If there’s going to be a limit, I would think that should be enforced by the API & GUI. That way we avoid the issue altogether. However device limits seem a bit arbitraryif you have the resources, why place a limit?
Ideally you’d want to subscribe to for commands for given devices explicitly. This is fairly difficult to do in Losant Workflows. In Python, I would get all of the devices in startup, and pass all of the IDs into an MQTT client subscription explicitly…then perform events based on something happening on any of those subscriptions. Perhaps the more useful command intercept method would be a configurable command trigger node that allows for templated fields…or otherwise some kind of method to pipe explicit devices into it (which I know is not really how Losant triggers work). Or, of course wildcards could work there and would be simple enough to implement…but the question becomes how do you ensure your poor RPi4 doesn’t get commands for 15000 devices! Kelvin has an interesting take there on explicitly separating access keys per edge compute…I could see that strategy working (albeit a bit complicated when you start doing things like load-balancing peripherals across edge computes…that’s what I struggle with most. What I really want is to assign devices to a “cluster” of edge computes and have them distribute the load and commands based on resources, response time, etc).
)
