I'm wondering if there is a way to add the desired fw version into the spark/flash/status payload template? By default it passes the fw version that's running {{{PRODUCT_VERSION}}}. The whole idea of the flash/status would be to monitoring the flashing of a device to a new fw version, it would be nice to know which version it's attempting to flash while it's happening instead of waiting until the app-hash event.
@dillon How are you managing the versions of firmware on your devices. The console features working well for me - are you talking about pulling rather than pushing?
That is a reasonable request. However there are two potential issues that may make it less likely to happen, at least in the short term.
As with all of the unstructured (non-JSON) events that are generated, we have to weigh breaking everyone who's expecting the string to just be "success" by adding additional data after it.
The other is that there is a possibility that the service that generates that event doesn't know what version it is. I think that message is generated at a layer where it's just transmitting the binary data to the device, and doesn't know about firmware versions. That may not be the case, but it is a possibility that would weight against adding that to the message.
In general, it's best to rely on the spark/status/safe-mode event (if a Device OS upgrade is required) or the spark/status "online" event, which lists the product firmware version in the extra field version in the JSON data.
In these cases, I wonder if Logic could access some fleet information for the device, so one could get that info and add it to the event before it leaves the Particle cloud.
This can enable getting the group the device was on (in a product), or why not the notes of the device, or its name? All requests I have seen in the forum or asked by clients.
Do you think this could be possible one day?
Maybe I can also ask @Wraithan
I presume you mean making additional values available to mustache templates in web hooks so you can send other device parameters to external servers. One issue is that the way the mustache templates work, the webhook server doesn't know which template variables are used and instead it must retrieve every variable that's possible and make it available to the handlebars/mustache engine. This has a cost in database operations and time to process the webhook, which is why there isn't a kitchen sink of available variables right now.
1 Like
Also there's a new guide to firmware update events in the product event stream when updating firmware and Device OS OTA.
2 Likes