A smart lightning-protection platform does not lack features. What makes operations teams "install it and stop looking" is usually not that the product cannot do the job, but a break somewhere in the operating chain. This article breaks the phenomenon into three verifiable dimensions — alarm usability, data credibility, and response closure — and checks each against the platform and alarm-grading capabilities described in the knowledge base. One clarification up front: this three-dimension framework is the article's own analytical lens for organising the topic, and the knowledge base does not state it as a direct proposition. Every factual description below is linked back to a knowledge-base entry, and boundaries and metrics are set out separately at the end.

Alarm Usability: Can Alarms Be Understood and Trusted?

Smart lightning protection relies on a fixed vocabulary. The platform is named FEXCloud; the central system is the Taiyi Intelligent Control Hub System; the engine layer comprises the Qianzhi, Wanxiang and Tianyan engines; alarm levels are fixed as YJ1 / YJ2 / BJ1 / BJ2; SPD means surge protective device; and the red lines are five non-bypassable red lines. Consistent terminology has direct value: the customer sees the same semantics across different interfaces and documents, reducing the distrust that comes from things not matching up.

Whether an alarm can be used depends first on whether the grading is clear. The knowledge base gives a six-level alarm system: Normal (85–100), Watch (70–84), YJ1 (55–69), YJ2 (40–54), BJ1 (20–39, action within 48 hours), and BJ2 (0–19, immediate shutdown). The six levels cover the 0–100 range continuously from high to low, each with an explicit numerical boundary. A level conveys not only how high the risk is but also the response deadline built into the rule itself, so an operator knows what pace to follow on receiving an alarm. Without such grading, every anomaly arrives with the same face, and the dashboard is soon ignored.

Beyond grading, whether the alarm content is readable is equally important. The knowledge base stipulates that each alarm carries a standard-clause citation, four-dimension impact labels (safety / efficiency / lifespan / carbon, scored 0–100), a confidence value, and a scenario label. Together these four kinds of information turn an alarm from an isolated number into a judgement that can answer "on what basis, with what impact, at what confidence, and in what scenario". The red lines act as a non-bypassable guard and form the floor of this usability: when a red line triggers, it is not diluted by the ordinary weighting logic.

Data Credibility: The Chain from Perception Layer to Cleaning Layer

A more hidden reason operators stop looking is untrustworthy data. Data credibility is not a single-point capability; it depends on the whole chain. The knowledge base describes the monitoring system's general four-layer architecture — perception, edge, platform and application layers — where the application layer includes Web / App visualization, alarm management, analytical reports and mobile inspection. The application layer faces the user directly, but whether what it displays holds up depends on the preceding perception and transmission stages.

In the front-end layers, access and cleaning determine the quality of the data that reaches analysis. The knowledge base states that the L1 access layer supports 40+ protocol parsers (Modbus / MQTT / OPC-UA / 104 / BACnet and others), unifying data from devices of different vendors and protocols. The L2 cleaning layer performs G5 four-stage data cleaning: denoising, de-duplication, anomaly flagging, and interpolation completion. Incomplete access leaves blind spots; insufficient cleaning admits noise and duplicates; either distorts the higher-level assessment. For operations teams, once the platform's data is found to disagree with the actual site, trust is consumed faster than it would be by missing features.

Above that sits the stability of the analysis chain. The knowledge base describes the Taiyi Intelligent Control Hub System's seven-stage pipeline: L1 access → L2 cleaning → L3 standard validation → L4 Qianzhi analysis → L5 Wanxiang assessment → L6 fusion decision → L7 persistence, with L4 Qianzhi analysis running 50 sub-models in parallel; L6 fusion decision applies a weighted composite health score to the Qianzhi and Wanxiang assessments, and L7 persistence handles dual-database storage, real-time push and triggering of Tianyan prediction. On localization granularity, the Wanxiang engine defines an 18-level scenario localization tree (L1–L18), in which L17 is terminal-block level and L18 is contact-point level. The finer the localization, the more likely an alarm lands on a specific object rather than a vague "something is abnormal somewhere"; insufficient localization precision is itself one reason users abandon a dashboard.

Response Closure: Handing Off from Alarm to Responsibility

Even with clear alarms and trustworthy data, a platform still degenerates into a screen that only watches and never acts if the response stage is missing. Closure means an alarm must reach a person and a process. The knowledge base describes the Taiyi front end (decision interface) as including an integrated cockpit, a 3D digital twin (locating alarms to devices) and a mobile H5. The integrated cockpit serves overview, the 3D digital twin maps alarms to specific devices, and the mobile end lets response actions be completed on site. The closer the tool-level entry points are to the actual response situation, the easier it is to form a continuous action from "seeing" to "handling".

The rule level also reserves a handle for closure. The six-level alarm system above sets BJ1's response deadline at 48 hours and BJ2 at immediate shutdown, essentially requiring the operations side to define who does what within what time. The platform can deliver the alarm, the location and the deadline to a person, but whether someone claims it, whether it flows according to level, and whether the outcome is fed back depend on the customer's own operations roles and process design. This layer cannot be replaced unilaterally by the product, and it is the real gap behind many "installed but unused" projects.

Boundaries

First, breaking "installed but unused" into alarm usability, data credibility and response closure is this article's operations-methodology framework; the knowledge base does not state this three-dimension framework directly, and this article uses it only as a lens for organising the topic, not as a verified product fact.

Second, the quantified metrics appearing in the knowledge base — for example alarm compression of 80%, root-cause accuracy of 85%+, scenario localization precision L17–L18, cascade risk coverage of 100%, electrical hazard identification rate of 95%+, and MTTR shortened by 60% — are supplier-stated claims in the knowledge base and have not been independently verified. This article does not cite them as verified facts, nor does it infer any parameter, case, certification or effect for which no source is provided; readers and buyers should evaluate them independently against their own scenarios.

Taken together, "install it and stop looking" is closer to an operations problem than a purely product one. Alarm usability determines whether the platform is worth looking at, data credibility determines whether what is seen can be trusted, and response closure determines whether anyone acts on it afterwards. If any one of the three is missing, a smart lightning-protection platform will gradually be set aside after deployment. Returning to the capabilities described in the knowledge base, the six-level alarm system and four-dimension impact labels provide the basis for readability, the four-layer architecture and the L1/L2 chain provide the basis for credibility, and the Taiyi front end with graded response deadlines provides the entry to closure; connecting these capabilities into the customer's existing operations roles and processes is the key to keeping the platform in continuous use.