One device map
HVAC, lighting, access and lab instruments share one status and alert view.
One system for campus devices, labs, energy and inspections.
Campus gear usually sits in separate ledgers. This plan puts devices, lab bookings, energy and inspections in one place, with a record for every check and repair.
HVAC, access and lab instruments are tracked separately
Lab bookings collide because they live in chats and spreadsheets
Energy waste shows up only when the bill arrives
Paper inspections cannot be matched to repair tickets
Keep the equipment you have, connect the data first, then split the views by role. The connection layer takes the most work, and it is where most of our effort goes.
PLCs, meters, access control, cameras and sensors already on site. Read what is readable, add a module where it is not, and leave the existing control system alone.
Modbus · OPC UA · MQTT · HTTP · GB28181 · SDK
Common protocols connect directly. The gateway handles protocol mapping, local buffering and backfill, so the data does not break.
Device registry, time-series data, alert rules, work orders, roles and audit in one back end that serves several scenarios.
Data is collected once and reused by every scenario added later, which is why the connection layer has to be done properly the first time.
HVAC, lighting, access and lab instruments share one status and alert view.
Schedules, approvals and usage stay online, so clashes and idle gear are visible.
Water and power by building and use, with a notice when usage jumps.
QR or NFC check-ins keep the route, photos and tickets together.
Instruments are booked online and only power on after a card or QR check-in, so clashes and idle gear are visible by user and project.
Schedules follow the timetable and drop to holiday mode automatically. Left-on units are listed instead of found by walking the building.
Power-on, over-temperature and abnormal stops are logged, so pre-class checks become one screen instead of opening every bench.
Water and power split by building and use; the circuit that jumped is named the same day, not at the end of the month.
Not a feature list: what actually happens in a day. These four steps are the common shape of such projects.
A third-floor classroom is still cooling. The timetable shows no evening class.
The rule "no class + no people + unit running" raises one notice tied to that floor and unit.
The notice reaches the duty phone; the operator confirms and shuts it down remotely, and the record keeps who did it.
The weekly report shows the entry and how often it recurred, which decides whether the schedule needs changing.
Every stage has a checkable output. No six-month build followed by a single review.
Walk the site, list devices, available ports and current systems, and mark what reads directly versus what needs a module.
Rank the ideas by impact, feasibility and dependencies, then choose one that proves value without dragging in every department.
Gateways connect devices, data lands on the platform, and alert rules, roles and recipients are configured for a small internal group.
One team or one building uses it for real; rules and screens change with feedback until false and missed alarms settle.
Check every acceptance item, finish documentation and training, then decide which buildings, lines or sites come next.
The three items below come from projects of this kind and go into the acceptance sheet, instead of relying on a general impression.
Device status is visible on the spot
Inspections and repairs share one record
Energy spikes show up before the bill
Scattered plant devices and protocols, brought into one platform for inventory, boards and alerts—less ad-hoc ops handoff.
Device onboarding and inventory in one place
Learn More →GeneralDuty and reports relied on last-minute sheets; configurable rotating boards replace screenshot-and-verbal numbers.
Key metrics on one screen
Learn More →EducationLab instrument booking and management system
Bookings and occupancy are visible
Learn More →We add a gateway: Modbus and similar where a port exists, current transformers, IR or dry contacts where it does not. The existing control system stays untouched, and a site survey comes before any list.
No. The platform reads from what you have and can use the campus single sign-on, so nobody keeps another password.
Either public cloud or on-premise in the campus data room. On-premise follows your network policy and data does not leave the campus.
One scenario first, such as lab booking or one building’s energy. Usually four to eight weeks, then repeat for other buildings.
By number of scenarios and device connection points. A site survey produces the list, then a quote and a schedule follow.
Leave one contact. We send how similar projects were handled plus a scenario list. If it is not worth doing, we say so.
Phones are answered 9:00-18:00 on weekdays, or scan the WeChat code.