A sunlight simulation management method, a sunlight simulation system, a device, and a medium

Abstract

The application relates to the technical field of intelligent building lighting control, and discloses a sunlight simulation management method, a sunlight simulation system, equipment and a medium.The method comprises the following steps: receiving a first control instruction sent by a sensor and a second control instruction sent by a terminal device respectively within a preset time period; performing priority sorting on the first control instruction and the second control instruction according to a preset instruction priority rule; and issuing the control instruction with the highest priority to a light environment control module to allow the light environment control module to drive a light source to enter a target working state.The application can effectively solve the problem of logical confusion caused by conflicts among multiple control source instructions, ensure the determinacy and consistency of system response, and thus avoid the decline of user experience caused by unpredictable final states.

Description

Technical Field

[0001] This application relates to the field of intelligent building lighting control technology, and in particular to a method, system, device and medium for managing sunlight simulation. Background Technology

[0002] Existing intelligent lighting sunlight simulation systems typically allow for control in multiple ways, such as automatic sensor control, manual control via local touchscreen, and remote control via an app. However, these control sources operate independently and lack a unified coordination mechanism. When different control sources issue conflicting commands simultaneously (e.g., a sensor wants to turn off the lights, while the user wants to turn them on via the app), the system's final state may depend on the last command received, leading to chaotic control logic, failure to meet user expectations, and a poor user experience. Summary of the Invention

[0003] This application provides a method, system, device, and medium for managing sunlight simulation, in order to solve the problem that existing sunlight simulation systems suffer from chaotic control logic when receiving conflicting control commands, thereby reducing the user experience.

[0004] The first aspect of this application provides a method for managing simulated sunlight, applied to a sunlight simulation system, wherein the sunlight simulation system includes: a sensor, a terminal device, a light source, and a light environment control module, and the method includes: receiving a first control command sent from the sensor and a second control command sent from the terminal device within a preset time period; prioritizing the first control command and the second control command according to a preset command priority rule; and sending the control command with the highest priority to the light environment control module to allow the light environment control module to drive the light source into a target working state.

[0005] In some embodiments of this application, the instruction priority rule includes: the priority of the first control instruction is lower than the priority of the second control instruction.

[0006] In some embodiments of this application, the step of sending the highest priority control command to the light environment control module to allow the light environment control module to drive the light source into the target working state includes: sending the second control command to the light environment control module to allow the light environment control module to drive the light source to change the lighting parameters and enter the first working state.

[0007] In some embodiments of this application, the terminal device includes a smart screen and / or an app, and / or a visual management platform. The second control command includes: a local control command, a remote control command, and a monitoring control command. The command priority rule further includes: the priority of the local control command is higher than the priority of the remote control command, and the priority of the remote control command is higher than the priority of the monitoring control command.

[0008] In some embodiments of this application, the step of sending the highest priority control command to the light environment control module to allow the light environment control module to drive the light source into a target working state includes: sending the local control command to the light environment control module to allow the light environment control module to drive the light source to change the lighting parameters and enter a second working state.

[0009] In some embodiments of this application, the method further includes: acquiring the target working state and its corresponding lighting parameters and sending them to the terminal device, so as to allow the terminal device to update the currently displayed working state and lighting parameters of the light source.

[0010] A second aspect of this application provides a solar simulation system, the system comprising: a sensor, a terminal device, a light source, and a light environment control module, wherein: the sensor is configured to: detect outdoor illuminance in real time and generate a first control command based on the illuminance; the terminal device is configured to: generate a second control command based on user operation; and the central management module is configured to execute the solar simulation management method as described in any one of claims 1-6, so as to allow the light environment control module to drive the light source into a target working state.

[0011] In some embodiments of this application, the central management module includes a multi-functional gateway configured to execute the sunlight simulation management method described in any of the first aspects, so as to allow the light environment control module to drive the light source into the target working state.

[0012] A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the solar simulation management method described in any of the first aspects of the above embodiments.

[0013] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the solar simulation management method described in any of the first aspects of the above embodiments.

[0014] This application offers the following advantages: By introducing a preset instruction priority rule, when the system simultaneously receives conflicting instructions from different control sources such as sensors and terminal devices, it can automatically sort the instructions according to this rule and always send the highest priority instruction to the lighting environment control module to drive the light source. This mechanism effectively solves the logical confusion problem caused by conflicting instructions from multiple control sources, ensuring the determinism and consistency of the system response, thereby avoiding a decline in user experience due to unpredictable final states. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0016] Figure 1 This is a flowchart illustrating an embodiment of the solar simulation management method provided in this application; Figure 2 This is a schematic diagram of the framework of an embodiment of the sunlight simulation system provided in this application; Figure 3 This is a schematic diagram of the framework of an embodiment of the electronic device provided in this application; Figure 4 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium provided in this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures, interfaces, and technologies are presented for illustrative purposes rather than for limiting purposes, in order to provide a thorough understanding of this application.

[0018] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this document means two or more. Moreover, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0019] As described in the background section, existing solar simulation systems suffer from chaotic control logic when receiving conflict control commands, which reduces the user experience.

[0020] For example, the instruction execution process of a solar simulation system (also known as a KNX system) is as follows: it executes the last instruction sequentially, without the function of logically judging the instruction priority, which leads to chaotic control logic and does not meet user expectations.

[0021] To address the aforementioned issues, this application proposes a method capable of intelligently arbitrating instruction priorities and executing the highest-priority instruction from different control sources based on the instruction priority.

[0022] This application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0023] According to one embodiment of this application, a solar simulation management method is proposed and applied to a solar simulation system. The solar simulation system includes: sensors, terminal equipment, a light source, and a light environment control module, and as follows: Figure 1 As shown, this application performs the following steps S1-S3 to respond to different commands generated by different control sources: S1, receiving a first control command sent from a sensor and a second control command sent from a terminal device within a preset time period; S2, prioritizing the first control command and the second control command according to a preset command priority rule; S3, sending the control command with the highest priority to the light environment control module, so as to allow the light environment control module to drive the light source into the target working state.

[0024] Therefore, the above embodiments, by introducing a preset instruction priority rule, can automatically sort the instructions according to this rule when the system simultaneously receives conflicting instructions from different control sources such as sensors and terminal devices, and always send the instruction with the highest priority to the light environment control module to drive the light source. This mechanism effectively solves the logical confusion problem caused by conflicting instructions from multiple control sources, ensures the determinism and consistency of the system response, and thus avoids a decline in user experience caused by unpredictable final states.

[0025] In this embodiment, as Figure 2 As shown, the solar simulation system includes: an illuminance sensor as a sensing and automatic control source, a smart control terminal as a local manual control source, a user personal terminal application as a remote control source, a light environment control module and a multi-functional gateway as the core coordination and execution unit, and a visual management platform as a centralized monitoring and configuration platform.

[0026] The inventors discovered that existing KNX systems currently lack multi-command priority arbitration functionality. This application addresses this deficiency by embedding a priority arbitration logic within the central management module. The rule is defined as: "Local manual control (smart control terminal) > Remote manual control (mobile APP) > Automatic control (illuminance sensor)". When the central management module receives multiple potentially conflicting commands within a short period, it determines which command to execute based on this rule, ignoring or temporarily storing lower-priority commands. The arbitrated valid command is then sent to the actuator via the KNX gateway. For example, when the sensor determines that the lights should be turned off based on brightness, if the user is operating the system via the smart control terminal, the system prioritizes the user's operation and maintains the lighting status.

[0027] Therefore, in this embodiment, the instruction priority rule includes: the priority of the first control instruction is lower than the priority of the second control instruction. In this embodiment, the terminal device includes a smart screen and / or an app, and / or a visual management platform. The second control instruction includes: local control instructions, remote control instructions, and monitoring control instructions. Furthermore, the instruction priority rule also includes: the priority of the local control instruction is higher than the priority of the remote control instruction, and the priority of the remote control instruction is higher than the priority of the monitoring control instruction.

[0028] In this embodiment, a second control command is sent to the light environment control module to allow the light environment control module to drive the light source to change the lighting parameters and enter the first working state.

[0029] In this embodiment, a local control command is sent to the lighting environment control module to allow the lighting environment control module to drive the light source to change the lighting parameters and enter a second working state. The target working state includes a first working state and a second working state.

[0030] Therefore, the above embodiments establish a clear and stable arbitration mechanism for the system by embedding the explicit priority rule of "local manual control > remote manual control > automatic control" into the central management module, thereby effectively solving the problem of command conflict. Specifically, the system can intelligently judge and always execute the highest priority user intent (especially immediate manual operation), ensuring the determinism of control response and meeting user expectations. At the same time, by ignoring or temporarily storing low-priority instructions, it avoids logical confusion and significantly improves the reliability of the system and user experience.

[0031] In addition, the inventors' research also found that when a control terminal (such as a touch screen) changes the lighting status, other terminals (such as mobile apps and central control software) often cannot update the current status in real time, resulting in "inconsistent views," poor user experience, and an increased possibility of misoperation.

[0032] Therefore, in this embodiment, the target working state and its corresponding lighting parameters are obtained and sent to the terminal device so that the terminal device can update the working state and lighting parameters of the currently displayed light source.

[0033] Specifically, in another embodiment of this application, the valid instruction after priority arbitration is sent to the lighting environment control module to drive the DALI dimming and color tuning terminal to change the lighting parameters. In the KNX system, instruction execution and status synchronization can be updated in real time via KNX bus communication, but this status synchronization is mainly limited to devices on the KNX bus and cannot be actively pushed to application layer terminals such as mobile APP and central control software. To this end, after the instruction is executed, the central management module of this invention captures the execution result (i.e., the new system status, including the currently active mode, brightness value, and color temperature value) and sends it as a "status update broadcast message" to all online terminal devices in real time and actively through the KNX / IP network, including: the terminal that initiated the control, other smart control terminals, all logged-in user mobile APPs, and the visual management platform software interface.

[0034] In this embodiment, the system's central management module (which can be deployed on a multi-functional gateway or a visual management platform server) continuously receives control commands from various channels. These commands include: automatic on / off / dimming commands from illuminance sensors (based on ambient illuminance), manual scene invocation commands from smart control terminals (such as triggering "morning light mode"), and remote control commands from mobile apps. The central management module converts these heterogeneous commands into a unified internal data object.

[0035] Therefore, the above embodiments demonstrate that, after command arbitration is executed, the central management module actively captures the system status and generates a "status update broadcast message," which is then pushed to all online terminal devices in real time via the KNX / IP network. This effectively solves the problem that traditional KNX system status synchronization is limited to the bus itself and cannot actively notify application layer terminals. This ensures a high degree of consistency between the status of various terminal interfaces, such as mobile apps and central control software, and the actual status of field devices, greatly improving the real-time performance and user experience of multi-terminal collaborative control. Simultaneously, heterogeneous commands from different channels, such as illuminance sensors, smart control terminals, and mobile apps, are uniformly converted into standardized internal data objects within the central management module. This effectively solves the processing complexity caused by differences in multi-source command formats and protocols, providing a unified and reliable data foundation for subsequent priority arbitration, logical judgment, and command issuance. This significantly improves the efficiency and stability of the system in processing heterogeneous control signals and enhances the scalability and maintainability of the entire intelligent control system.

[0036] Specifically, in this embodiment, upon receiving a "status update broadcast message," each terminal device immediately updates its local interface display. For example, when a user adjusts the lighting to "sunset mode" via a mobile app, the scene icons on the smart control terminal screens in the office and the device status icons on the central control room's visual management platform will be simultaneously updated to display the "sunset mode" identifier and the current brightness and color temperature values. It should be noted that the color temperature values ​​may need to be converted on the central management module due to different data formats. After conversion, all data can be synchronized and consistent, ensuring that the status views presented by all terminal devices are completely consistent.

[0037] Take a conference room as an example: 1. System Composition: The conference room is equipped with illuminance sensors (for automatic sensing), smart control terminals (for local control) mounted on the walls, personal terminal applications installed on users' mobile phones (for remote control), and a multi-functional gateway (running central management logic) and a visual management platform (for monitoring) deployed in the computer room. All lighting is controlled by the lighting environment control module via DALI.

[0038] 2. Conflict Arbitration Example: In the afternoon, the illuminance sensor detects sufficient brightness and issues an automatic command to "turn off the main light." Almost simultaneously, a user in the conference room manually selects the "Conference Mode" scene via the smart control terminal. The management software in the multi-functional gateway receives both commands at the same time. According to the rule of "local manual > automatic," it executes the "Conference Mode" command and ignores the automatic light-off command. The lights are then adjusted to the preset brightness and color temperature for conference mode. The existing KNX bus itself does not have this arbitration capability; the central management software of this invention implements this logic before issuing commands through the KNX gateway.

[0039] 3. Status Synchronization Example: After the "Meeting Mode" command is executed, the multi-functional gateway immediately generates a status message with the following content: "Area - Meeting Room, Mode - Meeting, Brightness -80%, Color Temperature -4000K". This message is simultaneously sent to: the smart control terminal in the meeting room (updating its interface display), all online mobile apps (synchronously updating the status of the meeting room controls), and the visual management platform (updating the status of the meeting room icon on the floor plan). Due to the data format differences between the KNX bus and the central management module, the color temperature value needs to be converted by the central management module before being sent out to ensure that all terminals display the same information. Afterward, anyone viewing the meeting room lights on any terminal will see completely consistent information.

[0040] In summary, the central management module of the above embodiments of this application receives heterogeneous control commands from sensors, local touch screens, and remote applications, and arbitrates concurrent conflicting commands according to a preset command priority rule (local manual > remote manual > automatic) to determine the final execution command. This function is independent of the underlying KNX system (the KNX system itself does not have this function) and is implemented through the newly added central management module / gateway module. Moreover, after any valid control command is executed, the system actively encapsulates the generated complete new state into a broadcast message and sends it to all online control and monitoring terminal devices in the system, driving the interface of each terminal device to update immediately to ensure the global consistency of the status display. For parameters such as color temperature that have different data formats, the central management module performs format conversion before synchronization. Therefore, the above embodiments of this application have the following beneficial effects: (1) It solves the conflict of multiple control source commands and realizes deterministic system behavior: When facing multiple concurrent or near-concurrent commands such as sensor automatic control, local manual control, and remote control, traditional systems often rely on the simple "last command is valid" principle and do not have priority arbitration function. This application adds a central management module to the KNX system to independently implement a clear dynamic priority arbitration logic (such as local manual > remote manual > automatic), intelligently adjudicate conflicting instructions, and ensure that the system behavior always conforms to the highest priority control intention. (2) It ensures the consistency of the entire system state and improves the user experience: In the existing system, the KNX bus can realize the state synchronization between devices, but it cannot actively push the state to application layer terminals such as mobile APP and central control software. This invention realizes cross-terminal (including KNX devices and application layer terminals) visual communication by having the central management software actively broadcast the complete system state to all online terminals after the instruction is executed. Figure 1 To reduce misoperation. (3) Ensure the consistency of the entire system status and improve the user experience: In the existing system, the KNX bus can realize the status synchronization between devices, but it cannot actively push the status to application layer terminals such as mobile APP and central control software. This invention realizes cross-terminal (including KNX devices and application layer terminals) visual communication by having the central management module actively broadcast the complete system status to all online terminals after the instruction is executed. Figure 1(4) Enhanced system scalability and integration capabilities: This application takes a multi-functional gateway and a central management module as its core, adopts standard communication interfaces (KNX, Modbus, BACnet / IP, etc.) and a unified internal data model, which makes it easy to connect to new devices or third-party systems, and does not rely on the native functional expansion capabilities of the underlying bus (such as KNX). (5) Improved system stability and maintainability: Centralized arbitration and status management reduce the complexity of interaction logic in the distributed system. All operations are recorded, which facilitates fault diagnosis and system operation analysis. When it is necessary to modify the control strategy or priority rules, only adjustments need to be made at the central node, without configuring each KNX terminal individually, which significantly reduces the operation and maintenance costs.

[0041] Based on the inventive concept of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method described in the above embodiments. The following is in conjunction with... Figure 3 Please provide a detailed explanation.

[0042] like Figure 3 As shown, it illustrates the electronic device 100 of this application, which may specifically include a processor 110 and a memory 120. The memory 120 is coupled to the processor 110.

[0043] Processor 110 is used to control the operation of electronic devices. Processor 110 may also be referred to as a CPU (Central Processing Unit). Processor 110 may be an integrated circuit chip with signal processing capabilities. Processor 110 may also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. The general-purpose processor may be a microprocessor, or processor 110 may be any conventional processor.

[0044] The memory 120 is used to store computer programs and may be RAM, ROM, or other types of storage terminals. Specifically, the memory 120 may include one or more computer-readable storage media, which may be non-transitory or transient. The memory 120 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage terminals or flash memory terminals. In some embodiments, the non-transitory computer-readable storage media in the memory 120 is used to store at least one line of program code.

[0045] The processor 110 is used to execute computer programs stored in the memory 120 to implement the methods described in the various method embodiments of this application.

[0046] In some embodiments, the electronic device may further include a peripheral terminal interface 130 and at least one peripheral terminal. The processor 110, memory 120, and peripheral terminal interface 130 may be connected via a bus or signal line. Each peripheral terminal may be connected to the peripheral terminal interface 130 via a bus, signal line, or circuit board. Specifically, the peripheral terminal includes at least one of a radio frequency circuit 140, a display screen 150, an audio circuit 160, and a power supply 170.

[0047] The peripheral terminal interface 130 can be used to connect at least one I / O (Input / Output) related peripheral terminal to the processor 110 and the memory 120. In some embodiments, the processor 110, memory 120 and peripheral terminal interface 130 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 110, memory 120 and peripheral terminal interface 130 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0048] The radio frequency (RF) circuit 140 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 140 communicates with communication networks and other IoT devices via electromagnetic signals; it is the communication circuit of the electronic device. The RF circuit 140 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 140 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, an operator identification module card, etc. The RF circuit 140 can communicate with other terminals through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 140 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0049] Display screen 150 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 150 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 110 for processing. In this case, display screen 150 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 150, located on the front panel of the electronic device; in other embodiments, there may be at least two display screens, located on different surfaces of the electronic device or in a folded design; in still other embodiments, display screen 150 may be a flexible display screen, located on a curved or folded surface of the electronic device. Furthermore, display screen 150 may be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. Display screen 150 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0050] The audio circuit 160 may include a microphone and a speaker. The microphone is used to collect sound waves from the operator and the environment, converting the sound waves into electrical signals that are input to the processor 110 for processing, or input to the radio frequency circuit 140 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each positioned in a different part of the electronic device. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 110 or the radio frequency circuit 140 into sound waves. The speaker may be a conventional film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 160 may also include a headphone jack.

[0051] Power supply 170 is used to supply power to various components in an electronic device. Power supply 170 can be alternating current, direct current, a disposable battery, or a rechargeable battery. When power supply 170 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery that is charged via a wired line, while a wireless rechargeable battery is a battery that is charged via a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0052] For a detailed description of the functions and execution processes of each functional module or component in the electronic device embodiments of this application, please refer to the descriptions in the above-described method embodiments of this application, which will not be repeated here.

[0053] In the embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the embodiments of the electronic devices described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some data may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0054] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0055] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0056] Based on the inventive concept of the above embodiments, this application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the steps of the method described in any of the above embodiments. The following is in conjunction with... Figure 4 This describes the execution process of the above embodiments on a computer-readable storage medium.

[0057] like Figure 4As shown, it illustrates the computer-readable storage medium of this application. The integrated units described above, if implemented as software functional units and sold or used as independent products, can be stored in the computer-readable storage medium 200. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions / computer programs to cause an Internet of Things device (which may be a personal computer, server, or network terminal, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, as well as electronic terminals such as computers, mobile phones, laptops, tablets, and cameras that have the aforementioned storage media.

[0058] The execution process of program data in a computer-readable storage medium can be described with reference to the above-described method embodiments of this application, and will not be repeated here.

[0059] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0060] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

Claims

1. A method for simulating sunlight management, characterized in that, The method is applied to a solar simulation system, wherein the solar simulation system includes: a sensor, a terminal device, a light source, and a light environment control module, and the method includes: Within a preset time period, a first control command sent from the sensor and a second control command sent from the terminal device are received respectively. The first control instruction and the second control instruction are prioritized according to a preset instruction priority rule. The highest priority control command is sent to the light environment control module to allow the light environment control module to drive the light source into the target working state.

2. The solar simulation management method according to claim 1, characterized in that, The instruction priority rule includes: the priority of the first control instruction is lower than the priority of the second control instruction.

3. The solar simulation management method according to claim 2, characterized in that, The step of issuing the highest priority control command to the light environment control module to allow the light environment control module to drive the light source into the target working state includes: The second control command is sent to the light environment control module to allow the light environment control module to drive the light source to change the lighting parameters and enter the first working state.

4. The solar simulation management method according to claim 2, characterized in that, The terminal device includes a smart screen and / or an app, and / or a visual management platform. The second control command includes: a local control command, a remote control command, and a monitoring control command. The command priority rule also includes: the local control command has a higher priority than the remote control command, and the remote control command has a higher priority than the monitoring control command.

5. The solar simulation management method according to claim 4, characterized in that, The step of issuing the highest priority control command to the light environment control module to allow the light environment control module to drive the light source into the target working state includes: The local control command is sent to the light environment control module to allow the light environment control module to drive the light source to change the lighting parameters and enter the second working state.

6. The solar simulation management method according to claim 1, characterized in that, The method further includes: The target operating state and its corresponding lighting parameters are acquired and sent to the terminal device, allowing the terminal device to update the currently displayed operating state and lighting parameters of the light source.

7. A sunlight simulation system, characterized in that, The system includes: sensors, terminal equipment, a light source, and a light environment control module, and: The sensor is configured to: detect outdoor illuminance in real time and generate a first control command based on the illuminance; The terminal device is configured to generate a second control command based on the user's operation; The central management module is configured to execute the solar simulation management method as described in any one of claims 1-6, so as to allow the light environment control module to drive the light source into the target working state.

8. The sunlight simulation system according to claim 7, characterized in that, The central management module includes a multi-functional gateway configured to execute the sunlight simulation management method as described in any one of claims 1-6, so as to allow the light environment control module to drive the light source into the target working state.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the rental and sales business payment integration method as described in any one of claims 1-6.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the rental and sales business payment integration method according to any one of claims 1-6.

Images