I searched for this issue and found this thread, although it looks to be a few years old, and abandoned.
I am storing Threshold values in attribute tags.
For example, I have an attribute named rms_x, which is a measure of vibration on the x axis.
I then have three tags:
static_alert_enabled = true
static_warning_threshold = 2000
static_warning_num = 3
The first turns the alert on/off, the second is the value to be breached, and the third is the number of times it must be aboved that threshold before an alert is fired.
I would like to give the ability to users (maybe only certain ones, but that is future), to see and modify the attribute tag for the static_warning_threshold.
Input Controls seemt o be the way to do that. I seem to be able to do that with a raw attribute like a text field, but once you go that one level deeper into an attribute tag, it doesnt seem to want to show that.
How would I get this behavior? The only way I can think of to do it is to revert back to setting an attribute and using that for my threshold, That means creating minimum of 3 new attributes, per axis (3 axis) for each alert value. We are intending to have a few alert values, a warning, a danger, and then a future dynamically determined one, that would be then 3 Attributes x 3 Axis, x 3 Alert Values, for a total of 27 new attributes to maintain?
Great question, in order to update attribute tags via an input control block, you will need to use the button trigger to trigger a workflow to run that will update your device attributes based on the text input in the input control block.
You will need to provide a payload to send to the workflow via your input control block:
We are using the virtual button trigger, associated with your input control block, to send a payload with updated attribute levels, and using the Device: Update node to modify the warning threshold level.
It’s important to note that when using this process, you’ll need to provide all of the attributes in the payload along with the updated values, otherwise if you only sent an updated value for your threshold, it would remove the alert_enabled and warning_number attributes.
That was a great call to search through the forums for older threads, you just didn’t happen to hit on ones that were as relevant:
Following up from this morning, you mentioned wanting the ability to display the current value set as the threshold in the input block for your users.
You’ll need to use the Static Value within the Input Control Block, in combination with context variables for the device.
In the static value field I’ve placed the following: {{ctx.deviceId-0.attributes.vibration_xaxis.tags.static_warning_threshold}}
This will display the current value set for the static_warning_threshold attribute tag in the input control box.
Thinking about how this would be used by your users potentially, the one concern I had was that upon entering a new value to set a new threshold, there’s no positive indication that the value has been correctly set, other than going into your device configuration page to confirm.
So to help address this, I would recommend that you also place a Device List block on your dashboard that has a Custom column that contains the same ctx variable string as above. When the dashboard updates this table will refresh with the most recent value for that attribute tag displayed.
I would like to also point you to a new tool we have within the docs at Losant, our Template Tester Tool, this tool is great for understanding how a particular template will render within your application, and is exactly how I identified the path to reach the attribute tag value above.
Thank you Aidan, this looks to do exactly what I need to do.
When I am working with Workflows I can of course see the payload and see what is available for me to work with. On Dashboards, it is sometimes not obvious what elements I have access to (like attributes).
I am learning that it seems like the device model is pretty consistent and availabe everywhere, but is there a spot where I could see the payload available to a dashboard block?
One other related question too: I was hoping to use a Toggle on the Input block for a True/False attribute tag I have that turns the given alert off or on. However it looks like I cannot programatically set the initial state of the Toggle, only default to True or False, not pull it from a query or template.
It looks like I could maybe do this via an attribute though (and selecting Dynamic Value), and then the user could click a Save button on the input block to kickoff a workflow to report state to set the value to True or False AND go set the attribute tag to True or False (I have workflows already pointing towards that attribute tag).
Is there a more elegant way to use that toggle button?
Currently what you are experiencing with the Toggle Buttons on the Input Control Block is indeed how it works. I do think, though, there could be a better way for the Toggles to default to a specific value. I’ll raise a Feature Request for this and be sure to follow up with you as I learn more!
Thank you Heath, yes, having that Toggle button be able to programatically default to a specific value would be useful. We came upon another use case for it.
A user can ‘subscribe’ to Event notifications against a device.
When events are active against a device, and updates are added, we keep track of the updates added since the last time we check, and send them to the people who are subscribed to that device.
The Subscribers to a device are kept in a Losant Data Table.
Putting the button onto the Dashboard, to allow them to subscribe is where I would love to have it toggle to whatever the current Experience Users Subscription Status is (as determined by a query against the data Table), such that they are informed of their current subscription status simply by looking at the Toggle button.
