Remote dimming works through a chain: the management platform sends a command over a network, a field controller receives it, and a compatible driver changes LED output. Reliable operation requires agreement across every layer, together with local behaviour when communications fail.
Define the command path
| Layer | Required definition |
|---|---|
| Driver | Supported control interface, operating range and measured input at settings |
| Field node | Driver compatibility, addressing, schedule storage and local logic |
| Network | Protocol, site coverage, gateway or carrier and connectivity cost |
| Platform | Device support, user roles, commands, logs and data export |
| Feedback | Acknowledgement, actual measurements and alarm definitions |
Separate socket and connector arrangements from electrical dimming interfaces and network protocols. A physically matching node does not prove software interoperability. Request the compatible models and versions and demonstrate the proposed combination.
Distinguish a command from measured performance
A 50% command may not equal half the electrical input or half the delivered light. Check the driver’s dimming curve and measure the assembled luminaire at the required stages. Then verify that the lighting layout meets the project brief at those stages.
Define what the platform actually reports. Input energy, temperature, battery state and component faults require suitable sensing and supported reporting. An inferred value should be identified as an estimate. Test alarms against known conditions rather than relying on dashboard labels.
Specify offline and recovery behaviour
Identify where schedules are stored, how clocks are maintained and what happens after network, gateway, platform or power loss. The local fallback must deliver the agreed lighting service. Define how manual overrides expire and how normal operation resumes.
For solar nodes, include controller and communications consumption in the daily energy calculation. Remote commands must respect the configured battery protections and service plan. A network connection cannot compensate for inadequate generation or storage.
Commission the complete system
Test individual and group commands, stage input power, acknowledgement, scheduling, coverage and offline operation. Verify alarm delivery and the operator’s response workflow. Record firmware, device identity, settings and results.
Agree who owns administrator access and operational data, how data can be exported and what happens when subscriptions or equipment support end. Include connectivity fees, software maintenance and replacement compatibility in procurement. Demonstrated end-to-end operation is stronger evidence than a generic claim of remote-control capability.
Frequently asked questions
Does receiving a command prove the light reached the intended output?
No. Distinguish acknowledgement from measured power or output, and verify the relevant feedback and lighting performance.
Will a matching socket guarantee controller compatibility?
No. Connector, electrical interface, protocol and software support must all match the proposed combination.
What is the essential network-loss test?
Verify that the light follows its agreed local schedule or fallback and returns to normal operation correctly after communications are restored.
Related reading
- How Can Campus Smart Lighting Use Time-Based Dimming?
- Smart vs Conventional Street Lights: Functions and Controls
Prepare your project enquiry
Send the location, layout, required lighting schedule and documentation needs to sales@mclsolar.com. The proposed models, available evidence and commercial terms should be confirmed in the quotation.