I am keen to trigger some action when a device is first seen by golioth (provisioned with a certificate). This can be used to trigger a couple of actions. I can get the device to send a one off message to say hello but would prefer to do in golioth if possible.
Steps to Reproduce
NA
Expected Behavior
When a device is created there is the possiblity to generate a pipeline to generate further actions
Hey Clive, interesting idea that inspired some conversation on our end. I think the simplest way to do this in the short term is to have a script or agent talking to the REST API and watching the devices endpoint. Since we have moved away from using WebSockets, this would be a polling interval, but would be configurable via your own logic. I think something like a 1-5 minute polling interval would be realistic for most device fleets. Here’s some steps I’d normally take in this scenario using something like n8n
Poll on the devices endpoint
Check if the total number of devices has changed
If no, no action
If yes, start a comparison
Parse the list of all device IDs and produce a list of those added/subtracted
Pull each item out as a workflow item and kick off downstream actions (other API interfaces)
The 3rd item is interesting as well because there is a use case where you could have branching logic for devices that have been decommissioned. Those tasks would be separate from the onboarding tasks.
I don’t believe this will be pulled into the console as a standard offering, but I have really enjoyed using tools like n8n to supercharge my capabilities working with APIs. I use a lot of the LLM tools out there today to guide my setup of workflow tools but then they run without any API access to LLMs (though you could also do this)
I kind of settled on adding a “provisioned” flag to a stateful process in a telemetry process that is set to false by default. First time it sees a new device it fires off a message and then changes the flag to true. This can then initiate any number of downstream actions. I wanted to check however if I was working around something that existed already.
That was another solution we discussed. The only potential downside was that the device might continue to send this over the life of the product, unless you use a bootstrap/test firmware that later gets updated with the latest version using the OTA firmware update capability.