Tenant controls
Status and resource limits were linked to the behavior of the shared platform.
Manufacturing · Electrical equipment IoT
Connecting IoT tenant operations with device data continuity
An electrical-equipment business extended an IoT platform to connect tenant administration, usage limits, device replacement, and data operations, while improving a slow monitoring-screen experience.
The business context
A device platform also needs an operating model.
An equipment platform can receive readings successfully and still be difficult to run as a shared service. Each customer tenant needs an appropriate scope of access and consumption. Devices may be replaced, while the business still needs continuity in the readings associated with them.
The customer needed both a management platform and a mobile application within a constrained delivery window. Shinetech worked from an established IoT foundation, extending it to cover platform administration, tenant operations, product services, and the lifecycle of device data.
System view
Make tenant settings and device replacement part of daily operations.
Fictional tenant settings and example quotas illustrate the documented operating decisions. This is an original reconstruction, not a screenshot or a statement of customer capacity. View full-size interface (new tab)
The operating challenge
Administrative changes had consequences for live data.
Tenant status could not be treated as a label alone. Freezing a tenant needed to affect data collection, and usage limits needed to apply to resources such as device points, telemetry, and notifications. Device replacement introduced a different problem: changing the hardware should not discard the context of its earlier readings.
The team also faced a major scope change during delivery and monitoring screens that took too long to render. Both issues required specific choices about what to reuse, what to change, and where to spend development effort.
The delivery decisions
Extend the platform where operations required it.
Set reuse boundaries before implementation
The team evaluated which capabilities could remain on the existing ThingsBoard foundation, which needed adaptation, and which required new development. Device connectivity and rules could be reused while the surrounding product and operating workflows were extended.
Tie tenant controls to collection and consumption
Tenant administration was connected to data collection and resource limits. The implementation linked a frozen tenant to stopped collection and applied quota checks to the defined resources, giving administrative actions a concrete effect on platform use.
Keep device history through replacement
Replacement handling allowed a new device to inherit the old device's data history. Data operations also covered collection, scheduled cleanup, and archival work, with separate handling for basic platform information and time-series readings.
Resolve display bottlenecks and manage scope
Local caching and resource compression helped address slow monitoring screens. When requirements changed substantially, the team and customer revised the feature scope, replacing more complex work to keep the delivery plan manageable.
The working detail
A replacement device should not create a disconnected history.
Data continuity
A piece of equipment and the physical device reporting on it do not necessarily have the same lifetime. Preserving historical readings through a device replacement keeps past data useful after the hardware identity changes.
That operational concern sat alongside collection and retention controls. Together they made the platform easier to administer as a continuing service, rather than only as a collection of connected devices.
The delivered result
The implementation connected device data with tenant operations.
Continuous history
Device replacement preserved access to the previous readings.
Faster screens
The project team reported that monitoring-screen rendering improved from minutes to seconds after optimization.
The reported rendering improvement is a project observation, not an independently reproduced benchmark. The source also records reusable display themes; it does not establish a service-level guarantee or deployment scale.
Case taxonomy
Searchable by industry, technology, product, and business need.
Industry and product
- Manufacturing
- Electrical equipment IoT
Technology and delivery
- Java
- Angular
- ThingsBoard
- Flutter
Business need
- IoT
- Tenant management
- Data continuity
- Device lifecycle
- Time-series data
- Data retention
- Quota management
Discuss your project
Does your IoT platform handle the life of a customer as well as the life of a device?
Tell us how your business works and where your software needs to change.
Get in touch
Ready to build software that fits your business?
Tell us what you need to build, modernize, automate, or augment with AI. We can start with a focused discussion or a no-risk 1-week trial.
“A fantastic company to work with.” After the initial rapid development project, American Shipping Co. kept two Shinetech developers embedded for nearly four years, supporting internal and external tools and new AI initiatives.
CEO, American Shipping Co. - 5-star Google Review