Is it possible to use the losant API inside of a custom html dashboard block?
We have a need for a button that triggers a workflow to send a command to a device.
I know there is this API:
The other way we’re thinking off is to use an endpoint workflow and trigger that from the block but the reset api seems to be a cleaner method as everything can be within the block.
Hello. I would also be interested in knowing if it is possible to implement the solution that Wesley comments, since so far the solution that I have implemented working with HTML Custom Blocks to trigger workflows has been to use Endpoints. These Endpoints are configured as Public, and from the Workflow some kind of user control is implemented so that not everyone can trigger the workflow.
It would be interesting to know if the Losant API can be called from the blocks, although researching the documentation a little, I see that it is necessary to enter the authorization token and I do not know how feasible that is from the HTML block.
We look forward to hearing from you, greetings.
Starting with the short answer: Yes, it is possible, but no, do not do this.
The Losant API is a public, documented, RESTful HTTP API, therefore it is absolutely possible to make calls to API endpoints using JavaScript’s Fetch API. However, virtually all of the API’s endpoints require some level of authorization in the form of a token delivered in the request headers.
Your personal user token is stored as a cookie in the browser, and that token is sent with every request you make as you navigate the Losant web interface (fetching a list of your application’s devices, saving a workflow, etc.) However, that token is not exposed to the scope of the Custom HTML Block, thus the request cannot be authenticated against whichever Losant user is viewing that dashboard.
Thus, in order to utilize the Losant API in a Custom HTML Block, you would also have to include a token within the configuration of the block, and that token would be visible to anybody who had access to the dashboard. Even if you lock that token down as much as possible - by generating an Application API Token and limiting its scope to just the Flow: Press Virtual Button method - somebody could use that token to press any Virtual Button within your application if they can get their hands on a flow ID / Virtual Button ID.
Therefore, my recommendation would be exactly as @IoT_Hub suggested: I’d use a public Experience Endpoint (or a Webhook), use that to trigger a workflow, and take whatever action you intend to take within that dashboard block within that workflow.
@Wesley_Manning I should also ask …
Using an Input Controls Block, you can either press a Virtual Button or send a command to a device. Is there a reason you are trying to do this in a Custom HTML Block instead? Is there something lacking from the Input Controls Block that does not allow for your use case?
@Dylan_Schuster I don’t know the full details but we need gather other configuration settings to set range limits on inputs and populate labels and that can’t be done in the regular input control block. User friendly stuff.
OK, experience endpoint was the first thought. We’ll do that. It’s just more components spread out through the Losant app so that’s why I asked about the API method. Thanks for the details.
Hello Dylan. Since you have asked Wesley for feedback on the Input Control blocks, I leave you a post I created a couple of days ago where I talk precisely about the need to use a HTML Custom Block, since you do not have for example a calendar element with which to pass dates to a Workflow.
Thanks, best regards.
@IoT_Hub I did file a feature request for a datepicker input based on that feedback from a couple days ago.
@Wesley_Manning let me know if you can provide specifics and I’ll see if we can revise the Input Controls Block to handle your use case.
Hi Dylan,
I can provide more details for Wesley.
We have the need for an input block with a slider and a button to submit the slider change.
This slider allows a user to update a transducer control value, where that transducer has specific configuration (units, min/max values, etc).
The main limitation is that the min/max values, units label for the slider can’t be based on these device attributes.
So as it stand the current workaround is to use a Custom HTML block and its queries to appropriately display that slider control.
Then once the user makes the change and pressed a button, we do an API call to an experience workflow to trigger an application workflow to send that command to the device.
I suppose a Losant solution would require either
@Chris_Perry thanks for the info. I have some questions that, based on the answers to, we may be able to support your use case …
As for some of the other information you provided …
we do an API call to an experience workflow to trigger an application workflow to send that command to the device.
FYI, you can trigger an application workflow from an experience endpoint, and you can send a device command from an experience workflow, so there shouldn’t be any need to jump from one workflow to another.
Allow Input Block slider control parameters to be dynamically populated
They are dynamically controllable to a degree using dashboard context, hence my questions above. Depending on your responses, I can put together a proof of concept if I think what I have in mind will work for your use case.
Add ability to trigger workflows via some method exposed to the Custom HTML block
This is a fair ask, but I’ll have to dig a little deeper on this to see what this would look like from a feature perspective - and if it is even possible to achieve from a security perspective.
Thanks again for the details so far.
@Dylan_Schuster thanks for the help so far!
To answer your questions:
More info:
The device has 6 physical transducers, only one can be configured to be the main control transducer.
The Control block in question needs to
Currently we ingest all this data as its stored on the device, just integers.
Originally, I figured we could just get the attribute values(trans config) and figure out what strings to display.
The alternate, which I think you’re alluding to, would require us to populate new attributes that hold the data in a manner that is ready to just be printed on a block, with no processing required.
This technically could work, but would require a change on how we ingest those parameters.
Yes, this is what I had in mind, storing the min, max, and unit as tags either on the device object or as tags on the device’s attributes. When it comes to data such as this, tags usually suffice for our users because these are typically static values - or at least values that do not change based on the current state of the device.
So with that said, I don’t have a good answer for how to achieve what you’re looking for (setting properties other than the value of an input element in an input controls block through state data). Allowing this would probably involve returning a context device’s composite state (last values for all attributes) along with the configuration information. But I’ll log the feature request and will let you know if this is something we select for development.
Thanks for the feedback, and let us know if you have any other questions or suggestions.