Direct answer

Not necessarily. The current product documentation does not require electrical-fire monitoring to go to the cloud: the device side itself has local capability, since the electrical fire monitoring and control device provides an OLED display and a relay output, allowing display and interlocking locally; at the same time, the four-layer monitoring-system architecture provides a path for data uplink, through which the perception layer can reach the platform layer via the edge layer. What can be confirmed, then, is that local capability and the cloud path coexist rather than being mutually exclusive, and that going to the cloud is not a mandatory requirement. The documentation gives the platform layer as the FEXCloud IoT cloud platform, and the edge layer as including the lightning-protection smart gateway, the intelligent edge-computing gateway, and the industrial gateway, which handle protocol conversion, edge computing, and local caching. Whether a specific project needs to go to the cloud is not specified in the documentation, and this article accordingly draws no inference about mandatory or non-mandatory status.

1. Within the four-layer architecture, data already has two destinations

To judge whether going to the cloud is mandatory, one first looks at which paths the system architecture provides. The current product documentation describes the monitoring system in four layers: the perception layer, the edge layer, the platform layer, and the application layer. The perception layer handles collection; the edge layer handles protocol conversion, edge computing, and local caching; the platform layer handles device access, time-series database, and AI inference engine; and the application layer faces specific applications. This layering shows that after data leaves the perception layer, it can either stop at the edge layer for local processing and caching, or continue up to the platform layer. In other words, the architecture itself accommodates both local processing and cloud aggregation, and whether to take the cloud route depends on project needs rather than being forced by the architecture.

2. The device side already has local capability

Whether to go to the cloud first depends on whether the device must rely on the cloud to work. The electrical fire monitoring and control devices listed in the current product documentation (ESF-22110-R and ESF-12110-R) both carry an OLED display, provide one channel of residual-current monitoring, four channels of temperature monitoring, and one relay output, and communicate over RS485; the difference is that the former is powered by AC220V and provides two digital inputs, while the latter is powered by DC5V and has no digital input. The OLED display means data can be read directly on site, and the relay output means interlocking can be triggered locally. It can be seen that, without any cloud platform involved, the device still has local display and local action capability.

3. The edge layer handles protocol conversion and local caching

If data must enter a larger system, the edge layer is the first stop. The current product documentation describes the edge layer as containing the lightning-protection smart gateway, the intelligent edge-computing gateway, and the industrial gateway, as well as the industrial wearable and the cloud PLC, whose duties include protocol conversion, edge computing, and local caching. These three duties show that the edge layer is not merely forwarding: protocol conversion unifies data from different devices into a format that can be aggregated, edge computing performs processing locally first, and local caching retains data when the network or platform is unavailable. For electrical-fire monitoring, this means that even without connecting to the cloud platform, data can be organised and temporarily stored at the edge layer rather than being usable only through the cloud.

4. The platform layer provides aggregation and analysis

The value of the cloud path is understood from the capabilities of the platform layer. The current product documentation records the platform layer as the FEXCloud IoT cloud platform, whose capabilities include device access, time-series database, and AI inference engine. These three correspond respectively to multi-device aggregation, time-based storage, and intelligent analysis. That is, going to the cloud mainly brings centralised access, historical data storage, and upper-layer analysis capability, rather than being a precondition for whether the device can work locally. If a project needs cross-site aggregation or platform-side analysis, the cloud path has value; if only local display and local interlocking are needed, the device side and the edge layer already suffice. The documentation describes platform and device capabilities separately, which itself shows they serve different roles.

5. The communication protocol matrix shows how the cloud path runs

Whether the cloud path can run depends on whether the protocols support it. In the communication protocol matrix given by the current product documentation, the device downlink includes Modbus RTU (RS485), Zigbee (Modbus), and LoRa; the device uplink includes Modbus TCP and MQTT (Ethernet, 4G), as well as gateway-level IEC 61850 (optional). This set of protocols shows that data has a clear channel from device to platform: the downlink connects devices to the edge layer, and the uplink carries edge-layer data to the platform. The documentation marks IEC 61850 as gateway-level and optional, which also reflects that cloud-related capability exists at an optional level rather than as an all-or-nothing requirement.

6. Typical scenarios give a combination

In its typical-application section, the current product documentation lists low-voltage distribution-cabinet electrical-fire early warning as a recommended combination, with a recommended configuration of the electrical fire monitoring and control device (ESF-22110), the multi-channel leakage-current monitoring and control device (such as the multi-channel leakage products of the ESC series), and the multi-channel temperature intelligent controller, together with an IoTBox. What is worth noting here is that the documentation gives a set of sensing and control combinations and does not write the cloud platform as a precondition for the scenario. In addition, the multi-channel leakage-current monitoring and control device provides one or three channels of leakage monitoring, a leakage range of 10 to 3000 mA, accuracy class 1, and RS485 communication, which further shows that local collection and control are the basis of the scenario. Going to the cloud in such scenarios is an add-on capability, not a mandatory action specified by the documentation.

7. Breaking "must go to the cloud" into a check

For ease of review, the question can be broken into four steps. First, confirm whether the project needs local display and interlocking, or cross-site aggregation and analysis; the former can be met by the device side and the edge layer. Second, check whether the device has local capability, such as display and relay output, and whether the power supply and digital-input configuration match the site. Third, if the cloud is needed, check whether the edge layer has protocol conversion and caching, and whether the uplink protocols cover channels such as Ethernet or 4G. Fourth, check whether there is a mandatory basis for "must go to the cloud"; if so, it should be marked explicitly as a matter not listed in the current documentation and left to design documents and standards. This breakdown answers under what conditions the cloud is needed, rather than whether it is always required.

Scope and limitations

First, this article restates only what the current product documentation lists, and its factual boundary is limited to the four-layer monitoring-system architecture and the duties of each layer, the model configuration and key parameters of the electrical fire monitoring and control device, the models and leakage range of the multi-channel leakage-current monitoring and control device, the communication protocol matrix, the typical-application combination, and the fact that going to the cloud is not specified as mandatory.

Second, a mandatory requirement to go to the cloud is a matter not listed in the documentation, and this article draws no inference about mandatory or non-mandatory status.

Third, the display, channel, and power-supply configuration of the electrical fire monitoring and control device are cited as listed, and this article draws no conclusion about specific engineering wiring or settings.

Fourth, the leakage range and accuracy of the multi-channel leakage-current monitoring and control device are cited as listed, and this article makes no judgement about their field suitability.

Fifth, the communication protocol matrix is cited as listed, and this article makes no inference about network selection or bandwidth requirements of specific projects.

Sixth, the typical-application combination is used only to explain the direction of configuration, and no commitment is made about the monitoring outcome of any specific project; the latest product documentation and project scheme prevail.