Good folks, tell me if not true (and forgive if redundant);
Basic process to manage device state:
Data comes thru web to a Device in Losant
Hits a Trigger (input) node in a Workflow, which puts new data on the payload
** Can manipulate data within payload (ex, Math node)
** Can even use a Device Command (output) node to further trigger an Edge Device (Workflow in deployed Edge Agent)
Beyond this, you can ‘mass update’ data in Workflow using Device State node, means choose ‘individual fields’,
or perhaps more appropriately, can include key-value JSON data in an API call to said Workflow trigger, and then mass update payload using handlebars (as shown),
Again may sound, basic just confirming these are the best starting points for a larger / full-scale app.
Regarding the basics of setting device state using an application workflow – yes, what you’ve have laid out is correct.
Regarding your question about device state data in your Debug output…
In your Device: State Node, you’re using a JSON template with a hard-coded value, rather than referencing a payload value. The node is simply queueing the request and moving forward without adding or modifying the current payload. You can specify a result path that will add an object to the payload indicating if the request was queued successfully, but it will not contain any details about the command (or the associated device) itself.
There are a number of nodes that add to or modify the payload. You can use the Virtual Button Trigger to simulate an initial payload, which is very helpful for testing. For example, if you placed the JSON template that you currently have in your Device: State Node into a Virtual Button, you would be able to reference those values in other nodes. It would also appear in the Debug output.
Hopefully this helps to get you on the right track. Please let us know if you have any further questions!
Copy that, sounds like it was behaving kind of ‘headless’ or ‘parallel’ to the payload;
Means even though the JSON snippet specified “data.battery_voltage”, it wasn’t explicitly attached to the payload.
So seems best place to do said ‘attaching’ of data (ex, incoming API w/ data) to Payload is in the Device state trigger node (green), means better done more upstream in the Workflow.
Then shortly thereafter, handlebars, etc. would come in handy to manipulate and use any attached data in the Device state node (orange), means manage device Attributes more downstream.