Definition
Peak and valley scheduling (peak and valley load adjustment) refers to using scheduling strategies to shift electricity load from peak periods to off-peak periods, or to discharge energy storage and distributed power during peak periods and charge during off-peak periods, achieving peak shaving and valley filling, reducing pressure on the grid during peak hours, improving power supply reliability, and lowering grid investment and user electricity costs. Peak and valley scheduling is an important component of demand-side management.
Peak-valley scheduling combined with time-of-use electricity pricing guides user behavior through price signals; combined with demand-side response, it can participate in the ancillary services market; in coordination with energy storage and electric vehicles, it can form a virtual power plant (VPP).
Technical Features
Peak-valley scheduling relies on real-time communication and remote control of controllable load devices. EV charging stations, energy storage systems, adjustable air conditioners, and industrial and commercial loads receive power adjustment or time-based control instructions from the scheduling platform via IoT SIM cards. Optimization scheduling requires considering load forecasts, electricity prices, and user preferences.
Use Cases
Peak-valley scheduling is widely used in scenarios such as orderly charging, energy storage, demand-side response, industrial and commercial air conditioning, and ice storage cooling. EV charging stations, energy storage systems, and adjustable load devices receive scheduling instructions via IoT SIM cards. SimtoLink provides stable networking and dedicated APNs for various controllable load devices involved in peak-valley scheduling, ensuring the real-time execution of scheduling instructions.
What flexible load needs before it can shift
In peak-valley dispatch, the IoT SIM carries a power target to equipment that can give way, and brings the result back. Giving way means charging can wait, storage can change between charge and discharge, and some air conditioning or cool storage can move inside the comfort or process range. It does not mean every electrical load can be rewritten remotely. Load that cannot stop on a production line, and fire and safety supplies, must not appear on the dispatch list even if their SIM is online. The device needs a local measurement, must be able to change power after the target arrives, and must refuse clearly when it cannot, rather than stay silent. Load forecasting only says how high a future peak may be. It does not decide whether the site is allowed to move.
Storage and flexible load move in opposite directions, and they are easy to put under one "reduce power" command. On the peak, storage should discharge, chargers should charge less, and a cool-storage chiller should unload. Those are three actions. The command must name the object, the direction, the target power, and a deadline. After the deadline the device returns to its local policy. A command with no deadline occupies the device indefinitely, and the next peak-valley flip still runs the old target. Cellular only delivers the command and the receipt. The reason a change failed (protection lockout, local manual control, not enough capacity) belongs in the receipt.
A local calendar overrides cloud power
A common mistake is a device whose local clock already forces full power in the off-peak period. The cloud power cap arrives and the local logic drops it, yet the platform marks success because it received a transport acknowledgement. Transport success and a change in power are not the same thing. The receipt should include the setpoint after the change, and preferably the direction in which the meter reading then moves. Another mistake is a keep-powered switch the user has turned on. Dispatch keeps sending, the failure log floods the screen, and other devices that really can shift are buried. During keep-powered, mark that object as not adjustable. Do not keep retrying it.
Clock error moves an off-peak action into a time that is still on peak. A batch of devices starting early means the dispatch itself creates a new peak. Device clocks should be checkable. If the error exceeds the allowed range, refuse the shift. The default after a link loss should also differ by device type: storage may stay in its current state, and charging load should fall to a lower power, not hold the highest power from before the peak. Acceptance compares three numbers: the command target, the device receipt, and how the meter changes over the following interval. A receipt with a meter that does not move means the local calendar or a protection circuit is still sitting on top of the cloud command.
Keep-powered devices should leave the adjustable list
After the user turns keep-powered on, that device should leave the adjustable set for the time being, and dispatch should stop retrying it. Further commands only pile up failure records and bury devices that can still shift. If a local calendar writes the off-peak period as full power, a cloud power cap must be visible in the receipt as refused or rewritten. Do not mark success from delivery alone. The command needs a deadline. After it, the device returns to its own policy, so it does not keep an old target after the peak and valley swap.
Storage discharge, less charging, and cool-storage unload are three directions. They cannot share one sentence that says "reduce power." A device whose clock is far off should refuse a new shift plan, so a whole batch of load does not enter the peak early. When the link drops, charging load falls to a lower power and storage holds its current state. Do not write both defaults as the same full power. The target, the receipt, and the meter direction agree only when peak-valley dispatch has got past the local logic.