Smart Solar Street Light: Making Better Decisions With Limited Energy

Before the smart solar street light can be considered an IoT device, it is an off-grid energy system. The controller has to be able to split the limited available stored energy between lighting and providing sensors and communications whilst ensuring the lights remain on the road at night before dawn.

The engineering question thus does not relate to how many smart functions can be added. The question is whether remote monitoring and auto dimming/battery protection contribute to having a functional system in terms of light through the long winter nights and multiple days of weak charging.

An effective dashboard is only beneficial when it facilitates improved energy decision making and quicker maintenance.

This week, the weakest of the winter starts.

Annual average sunshine based solar street light proposals may work well in summer and not work well in winter when it’s cloudy. The sizing process of the panels and batteries should begin with the month of poorest weather conditions – not the most sunny.

Check the local peak sun hours, longest night of winter, temperature range, rain/snow conditions, panel orientation, season shading and soiling conditions. These factors influence the amount of energy that is available for collection and storage.

The autonomy sought should be specified in terms of number of consecutive weak-light or rainy days. A statement like ‘works in bad weather’ is not sufficient to engineer or quote.

Ensure that before the system is sized, it is verified that:

• The weakest-month peak sun hours and project location are the two factors that influence PVNRE input.
• Longest winter night/lighting hours required
• Days of required consecutive cloudy or weak-light conditions
• Shading, dust and snow and access for cleaning of panels by seasons.
• Schedule of bright nights in the early evening, late night and morning
• Ageing margin and minimum reserve at sunrise of the battery.

These inputs are used to define the panel wattage, the battery capacity that can be used and the safe lighting profile. Their confirmation should be made prior to the selection of the product from the LED solar street light range.

Item	Project Data
1. Site & Winter Sun	Country/city or coordinates: by site; peak sun hours in the lowest-sun month: from local weather data; longest winter night: by site.
2. Road & Layout	Road type/width: municipal, residential, industrial park, rural, or parking area, by project; pole height/spacing: per lighting design; layout: single-side/both sides/staggered; target illuminance: local standard and project brief.
3. Autonomy	Low-sun autonomy: 5–7 days; daily operating hours: project setting; low-energy brightness: project setting.
4. Dimming & Sensors	Timed dimming: supported; sensor brightness and hold time: project settings; neighboring-light linkage: optional.
5. Battery Protection	Battery type/capacity: typically 60–120 Ah; type, permitted DOD, and temperature range: by model; low-charge threshold: controller setting.
6. Remote Monitoring	Pole count, communication/coverage, monitored items/alarms, and account permissions: project-specific.

With automatic dimming, there is a rule of thumb: The energy budget must be followed.

In fact there is no fixed load per night, if the solar street light does not remain at a constant light level during the night. Brightness is an energy schedule – it is the correct design.

A practical profile can include a high level of output during the evening traffic hour, a low level of output late at night and/or a temporary increase of output when a vehicle or pedestrian is detected. The transition down to the lower level should be smooth and not an abrupt transition.

The schedule should also be modified based on recent solar charging, battery level, and temperature and the number of hours until sunrise.

Road Lighting and Battery Reserve are Primary to Optional!

The energy stored in the batteries is used for cameras, environmental sensors, decorative indicators and frequent wireless reporting. They can be added after the load of road-lighting and winter reserve are secured.

It is important to have an operating priority in mind:

The order of importance should be: road lighting, battery protection, monitoring and communication, as options.

When it comes to remote control, there has to be a limit. In an operating mode an operator should not be able to leave a complete project at full output for several nights without a warning about the affect on battery reserve.

Good optics is energy saving, too. Focusing light outside of road (into windows and above the usable area) means that more light is being wasted and more glare caused, which is a drain on battery life.

If you are seeking a solar street light for small roads, after you have decided the brightness profile and the winter reserve, then compare all-in-one solar street lighting products.

On roads with occasional traffic, use Motion Boost.

Motion based control is suitable for rural streets and pathways, parking lots and campuses with intermittent traffic. Roads are typically heavily trafficked and typically require a steady light output rather than repeated high output activation.

The detector should be capable of detecting an approaching user early enough to provide the illumination of the route ahead; however, should not be triggered by public-road traffic, activity outside of the project boundary, branches or small animals, or rain.

Prior to planning a sensor, make sure the following is confirmed:

• Pedestrian detection, vehicle detection or combination of the two
• Main approach direction
• Spacing between poles and height of mounting of sensors
• This is the percentage of cases that are detected by both neighbouring poles.
• Temporary boost brightness
• Maintain position following a movement
• Smooth return-to-dim time
• Search in the direction of the lights to the right of the front light.

If a continuous route is desired, it may be necessary to use multiple poles for one detection event. Therefore, the solar street light which has sensor should be tested in the road layout and not as an individual sample.

Deep Discharge will not happen as long as Battery Protection is in place.

It is not possible to have all seasons or weather patterns in a fixed calendar.

Recent charging, energy used to date, battery status, temperature and time until sunrise should be considered for the decision making by an energy-aware controller. Following good charging, it can be charged by the normal profile and following several weak days it can be charged by conservative profile.

Battery voltage is not sufficient, as it varies according to load, temp, chemistry and rest time. State-of-charge trends, and charging history, provide a more effective basis for protection decisions.

If reserve is low, cut back on late night output and/or optional communication first, maintaining hours as determined by project as essential for safety.

Do not design for Day-One Capacity, do design for Battery Ageing!

There is more useable capacity in a new battery than in the same battery after being used every day for several years.

Service life is affected by temperature, depth of discharge, charging conditions and extended periods of time at a wrong state of charge.

Over-charge protection, over-discharge and temperature protection should be included in the project, and there should be some reserve to ensure that the lighting time is not shortened due to normal ageing.

Document battery protection thresholds, permitted depth of discharge and recovery rules rather than hiding those within the default of a controller.

Although smart control can help minimize unnecessary discharge, inspection and planned battery replacement needs to be part of the lifecycle plan.

The location of the panels determine the available energy in the winter months.

Even if a larger panel is installed in a poor location which is shaded during useful charging hours, it will not correct the location.

Input of solar energy can be diminished by trees, buildings, signs, new construction, dust and bird deposits. This problem tends to worsen over time, due to vegetation growth or changes in nearby conditions.

See where the sun is in the sky throughout the year – not just at midday on the day of installation.

On panels (direction and angle) should facilitate winter charging, cleaning and snow shedding (if applicable). An installation shall not cause the luminaire or pole accessories to cast unnecessary shade.

A semi-integrated solar street light could offer a more project flexible design and maintenance of the components if the panel directions and the luminaire directions require separate adjustment.

Maintenance Actions should be created by Remote Monitoring.

The information that should be reported for remote monitoring should be what a team need to make a decision: lamp status, Daily Solar charging, Battery Trend, Energy use, Controller temperature, Dimming level, Sensor events, Communication status and faults.

The first dashboard view should indicate as follows: Pole Affected, Alarm Priority, and Recent Operating History. Don’t assume a lamp failure, undervoltage of batteries and loss of communication are the same thing.

Trends in data are more helpful than individual data points. If the solar input drops, it could be due to dirt on the panels or the presence of vegetation or a panel fault; if the solar charging is normal and voltage drops off rapidly, it may be due to deterioration in the battery.

In the event of a failure of the gateway, cloud platform and/or Internet connection, the local controller is required to store the approved schedule, sensor response and battery-protection rules. You don’t want to have a single point of lighting failure when it comes to remote monitoring.

Settings and asset history should be restored to the controller after replacement or software update without having to rebuild the project manually. The solar street light provider should also specify what data format the street lights will export, user rights and what happens when the cloud service is discontinued.

Establish the System Across Several Nights

A successful night of operation is not a yardstick for a properly designed smart solar street light project.

Commissioning should confirm panel charging, dimming transients, motion response, battery protection and alarm and confirm local fall-back and re-connection after temporary loss of communications.

Do not stop monitoring due to cloudy weather and during the least reliable season. The project should be able to recover the battery reserve without compromising the important morning light period.

Check settings on a seasonal basis. What timing and reserve limits are necessary to make a profile work in summer may be different in longer winter nights.

Monitoring to Plan Whole Pole Maintenance

Replacement of the LED module is not enough to solve the maintenance.

The inspection of the panel, mount, battery, controller, sensor, luminaire, connectors, seals, fasteners and pole foundation may be required by technician.

Falling solar input, shorter battery run times, often being in low energy mode, dirty panels, loose wiring, water in compartments, misaligned sensors and vegetation blocking the sun from the panel are all useful warning trends.

Pole records should contain models of each component, date of installation, battery replacement, controller settings, firmware, and past alarms and completed repairs.

Conclusion

Smart solar street light with remote monitoring is a system for energy management, it is not just a lamp and an app.

A sound project begins with the poorest winter weather, features automatic dimming to regulate the daily load, safeguards the battery from deep discharge and turns the data from the remote into maintenance work.

Not the brightest every night is the best system. It supplies needed light at the needed time, saves sufficient energy to arrive in the morning and stays working when there is no communications.

FAQs

Q1. What data should be measured and reported from a solar street light remote monitoring?

It should provide lamp status, solar charging, battery status, energy utilization, dimming, temperature, sensor action, communications and top priority faults.

Q2. What if a smart solar street light is without Internet?

It should. Approved lighting schedule and motion response/battery-protection logic should continue to reside in the local controller.

Q3. What is the expected number of cloudy days that the battery will last?

The autonomy needs to be worked out based on the project location, the lowest sun month, the largest night, the lighting schedule, the maximum amount of batteries and the risk margin.

Q4. How does automatic dimming help to save the battery?

It cuts back production during times of low traffic volumes or following low quality charging and still maintains the priority lighting hours for the project.

Q5. Which information is needed prior to the quotation?

Enter the site of the project, winter solar data, road width, pole arrangement, desired illumination, night-time schedule, cloudy day requirement, battery constraints and remote monitoring requirements.