It's common to think of IoT, especially in the industrial space, as a way to understand your own environment and processes in order to improve efficiency or reduce costs. While these kinds of insights are valuable, there's an entirely new category of customer-facing IoT applications emerging. Manufacturers are now implementing IoT, not for themselves, but for their customers. These customers can log into custom and branded experiences, from anywhere in the world, to view the health and details about the equipment they've purchased. The manufacturer benefits by collecting valuable usage data from fielded equipment and by introducing subscription-based revenue opportunities for the remote monitoring service.
With Losant's launch of Experiences just over two years ago, we've emerged as one of the best, and very few, IoT platforms that enable this new category of applications. A significant requirement for these applications is multi-tenancy. Every customer should be able to log into the same experience, but only view the devices associated with them. Today's release of nested Experience Groups with built-in Device Associations provides a way to easily create and utilize a custom multi-tenancy model within your Losant applications.
Nested Experience Groups
Let's start with an example that describes the type of multi-tenant application commonly being developed on our platform. Here's a diagram that demonstrates the tenancy model:
In this scenario, Kanarra Technologies is the manufacturer of industrial power generators. They sell those generators to large enterprises. In this example, those enterprises are hospital chains. Those hospital chains are made up of geographic regions with each region having multiple facilities. Each facility has 2-4 generators, which are represented in Losant as individual Devices.
In an experience like this, you want users to be able to log in at different levels of this hierarchy and view their devices plus any devices beneath them. For example, you may assign a regional facility manager to the "California - Northern" group. That user should be able to view the details of every generator at every facility in that region, but they shouldn't be able to see generators from other regions, and especially not generators from other customers. Likewise, a user assigned to a specific facility should only see generators at that facility.
For this example, the groups represent customers, regions, and facilities. In your application, however, the groups can represent pretty much anything, and the same concept of device association applies. With the introduction of nested Experience Groups, this hierarchy can now be directly modeled within Losant.
Along with this update, we've combined the separate Users and Groups application menu items to make it easier to work with these resources from a single view. The new menu item is called, unsurprisingly, Users & Groups. The screenshot above shows the full implementation of the Kanarra Technology group hierarchy as pictured in the diagram.
Device To Group Association
A major part of creating a tenancy model is associating devices to each tenant. With this release, we've added first-class device association to experience groups to facilitate this functionality. We also made it easy to utilize this association in dashboards and our workflow engine.
Parent groups automatically adopt all device associations from their child groups. In the example above, if you were to query which devices were associated with a member of the "California - Northern" group, you'd receive the devices directly associated with that group and the devices associated with any of that group's children. This makes it easy to allow someone like a regional facilities manager to view the details of all devices at any facility under that region.
Experience User Dashboard Context Variable
One of the ways we exposed the device to group association is through a new Experience User Dashboard Context Variable. This is particularly useful when using a Dashboard Experience Page. You can use this context variable anywhere devices can be selected in a dashboard. We'll automatically convert that context variable into the list of all associated devices based on your group hierarchy.
The screenshot above is showing a Device List Block using an experience user context variable to select which devices should be in the list. When using an experience user as a filter, it's automatically being expanded to all of the individual device associations from that user's group and all child groups. Because that user represents potentially many separate filters being applied at once, we added a special note about using the "match all" option since it's unlikely that devices will match all of those individual filters at the same time.
Since the logged in user is automatically available at experience.user, you can quickly supply the user's ID using the following template in dashboard pages.
New Experience User and Group Workflow Nodes
Along with the context variable, which brings the device association to dashboards, we've also added and expanded a number of workflow nodes to expose the group hierarchy and device associations to your business logic. Some of the more important nodes are outlined below.
Device: Get Node
We've expanded the Device: Get Node to support querying the device association by experience group or experience user. This is helpful if you'd like to render a list of devices associated with a user in a custom experience page.
Device: Verify Node
The new Device: Verify Node makes it easy to confirm that a user is associated with a device based on your group hierarchy. Remember that parent groups adopt associations from their children, so this node will automatically traverse your nested groups to see if the user is associated with the device from its current group or any child group.
Group: Summary Node
The new Group: Summary Node provides a way to query your experience group hierarchy. This is useful if you'd like to present this information to your end users. For example, if a regional facilities manager is logged in, it can be useful for them to see all of the facility child groups beneath them.
Based on our Kanarra Technologies example at the beginning of this article, below is how a group hierarchy can be rendered to someone assigned to the top-level "Kanarra Technologies" group.
The tree view on the left is rendered from the result of the Group: Summary Node. The node's configuration starts the summary with the group the user is assigned to and returns it and all of its children. The updated Device: Get Node is then used to query each individual group's devices for the display on the right. Whereas creating this experience prior to this release was possible, the new nested groups and device association drastically reduces the complexity of this application.
Other Updates
- Added OPC UA: Call Node for Edge Workflows.
- Added OPC UA Trigger for Edge Workflows.
- Added Group: Verify Node for Experience and Application Workflows.
- Added Group: Get Node for Experience and Application Workflows.
- Redis Node now supports SSL connections.
- Modbus: Read and Modbus: Write Nodes now support configurations from payload paths.
- Data Table Queries now support partial matches.
- HTTP Node now supports changing the body encoding.
- Modbus: Write Node now supports Preset Multiple Registers (FC=16) writes.
- Table: Get Rows Node now supports filtering the Data Table columns returned.
What's Next?
With every new release, we really listen to your feedback. By combining your suggestions with our roadmap, we can continue to make the platform easy for you. Let us know what you think in the Losant Forums.