Sensor Management Web Platform (Thingsboard) - Case Study

The client required a highly cost-effective web platform designed to seamlessly manage a fleet of modular sensors and users with varying hierarchical levels of access. The solution needed to feature an intuitive user interface and a scalable device allocation framework while leveraging ThingsBoard PE for out-of-the-box IoT device management.
A core requirement was a dynamic system architecture, ensuring that both the entity relationships and custom dashboards were engineered to support easy scalability and the seamless addition of complex device combinations into the client’s expanding IoT ecosystem.

Project Context

To deliver on these commercial goals, the platform was developed to accurately monitor real-time connections, execute customized rule chains, and safely manage user permissions. Dynamic device profiling is the process of continuously tracking and updating the capabilities of connected “loggers” (main cloud-connected boards) and their physical add-on “sensors.”

A foundational requirement of the project was pushing the boundaries of the default ThingsBoard PE environment. While the initial development phases utilized out-of-the-box features to validate basic rule chains and access control, the platform framework was deliberately engineered to go far beyond the standard ThingsBoard schema to support highly customized asset and model hierarchies.
Extending the native ThingsBoard schema provides the flexibility essential for complex, multi-layered sensor fleet integration. The development process followed a phased lifecycle designed to de-risk system limitations and optimize platform constraints. It began with proof-of-concept functional validation using standard features before transitioning to a highly customized architectural design tailored to fit the modular nature of the physical devices.

Thingsboard Case Study WizzDev
Thingsboard Case Study WizzDev

Project Context

To deliver on these commercial goals, the platform was developed to accurately monitor real-time connections, execute customized rule chains, and safely manage user permissions. Dynamic device profiling is the process of continuously tracking and updating the capabilities of connected “loggers” (main cloud-connected boards) and their physical add-on “sensors.” A foundational requirement of the project was pushing the boundaries of the default ThingsBoard PE environment. While the initial development phases utilized out-of-the-box features to validate basic rule chains and access control, the platform framework was deliberately engineered to go far beyond the standard ThingsBoard schema to support highly customized asset and model hierarchies.
Extending the native ThingsBoard schema provides the flexibility essential for complex, multi-layered sensor fleet integration. The development process followed a phased lifecycle designed to de-risk system limitations and optimize platform constraints. It began with proof-of-concept functional validation using standard features before transitioning to a highly customized architectural design tailored to fit the modular nature of the physical devices.

Platform Stack with Custom Integrations

ThingsBoard PE Core

Primary IoT platform chosen for its out-of-the-box rule chains, telemetry routing capabilities, and built-in foundational management of the three primary entities: Assets, Devices, and Users.

Dynamic Asset Registry

Architectural workaround utilizing standard Asset entities to securely store comprehensive hardware models and their associated parameters in attribute lists, bypassing native device limits.

Custom UI Widget Engine

Purpose-built frontend component engineered because default ThingsBoard does not allow displaying tabular data from a list stored within a single asset’s attribute.

Role-Based Access Control

User group management module configured to provide segregated, secure access levels across different platform tenants and user tiers.

Software Architecture Stack

Automated Provisioning Layer

ThingsBoard rule chains managing local network authentication, device registration, and the automatic assignment of newly connected physical loggers.

Hierarchical Entity Engine

Mapping logic distinguishing between main cloud-connected “loggers” and modular add-on “sensors” (which alter device parameters upon installation).

State & Attribute Manager

Low-level custom actions deployed to seamlessly update parameters across devices and assets, ensuring real-time synchronization of hardware states.

Sub-Profile Emulation Core

Custom logic circumventing the lack of native “Sub Device Profiles” by dynamically tying connected devices to the model repositories stored within the Asset registry.

Scalability & Refactoring Engine

Autonomous architectural adaptation designed to manage the expanding scope of required changes and new device types as the physical hardware evolved.

System Implementation

The software development track completing the platform’s implementation followed a strict, standalone lifecycle designed to de-risk custom architectural changes and optimize standard ThingsBoard tools. The lifecycle commenced with an autonomous Proof-of-Concept (PoC) phase utilizing standard rule chains and simple custom actions to securely isolate and validate basic device assignments and user group permissions.


This allowed the platform framework to be built out quickly, ensuring the system operates as a self-sufficient management portal capable of independent execution as devices seamlessly appear (or are deleted by users) on the network.


The platform required a workflow focused on dynamic model assignment based on modular physical add-ons.


Because ThingsBoard does not support “Sub Device Profiles,” the system was engineered from the ground up to utilize a dedicated Asset entity to house all possible hardware models. Knowing the final scope of the project, early architectural choices for initial device types would have been approached differently, as later requirements completely exceeded initial expectations and required intensive structural workarounds.

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.