Load Shedding Priorities establish a deterministic hierarchy for power distribution during energy deficits within autonomous or grid-tied microgrids. The smart charge controller serves as the central orchestrator, monitoring battery state of charge (SOC), terminal voltage, and real-time generation metrics to manage circuit connectivity. This system addresses the critical problem of battery exhaustion and potential cell damage by systematically disconnecting non-essential loads. Integration occurs at the hardware abstraction layer where the controller interfaces with external power distribution units (PDUs) or dry contact relays via protocols like Modbus/TCP or MQTT. Operational dependencies include calibrated shunts for accurate current measurement and low-latency network paths for downstream relay triggers. If Load Shedding Priorities are misconfigured, the infrastructure risks a total system blackout, as high-current inductive loads might remain active during low-voltage states, causing a rapid voltage collapse. Thermal implications arise during these events as high-amperage switching generates heat at the relay contacts, while battery internal resistance increases during deep discharge cycles, further reducing throughput and system efficiency.
| Parameter | Value |
|—|—|
| Operating Voltage Range | 12V to 600V DC (System Bound) |
| Communication Protocols | Modbus/TCP, MQTT, RS-485, SNMP v3 |
| Shedding Tier Capacity | 8 Independent Priority Zones |
| Hysteresis Adjustment | 0.2V to 3.0V (0.1V increments) |
| Sampling Rate | 10Hz to 100Hz |
| Default Management Port | TCP 502 (Modbus), TCP 1883 (MQTT) |
| Environmental Tolerance | -20C to +60C Operating Ambient |
| Security Standards | TLS 1.2+ for API, AES-128 for Payload |
| CPU Requirement | ARM Cortex-M4 or x86 1.0 GHz+ |
| Memory Footprint | 256MB RAM Minimum |
Configuration Protocol
Environment Prerequisites
Successful implementation requires the charge controller to be running firmware version 2.4.0 or higher to support advanced Boolean logic for priority tiers. All external relays must be rated for the maximum peak inrush current of the attached loads to prevent contact welding. Network architecture must utilize a dedicated Management VLAN (802.1Q) to isolate control traffic from user data. For precision sensing, the system requires a calibrated 500A/50mV shunt or a Hall Effect sensor integrated into the primary DC bus. Root-level access via SSH or an authenticated Modbus Master session is necessary for modifying register values.
Implementation Logic
The engineering rationale for this architecture relies on a tiered state machine that prevents relay chattering through defined hysteresis windows. The priority logic is implemented as a descending stack where Priority 0 represents life safety or networking core devices that are never shed until the Hardware Cut-Off (HCO) is reached. Communication flows from the controller to the relay driver via a daemonized service that evaluates the battery state against the priority table every 100 milliseconds. This encapsulation ensures that transient voltage sags, caused by motor starts, do not trigger premature shedding. The system evaluates the rolling average of the terminal voltage rather than instantaneous peaks to account for ESR (Equivalent Series Resistance) voltage drop. Fault domains are isolated by utilizing independent GPIO headers for each load tier, ensuring that a single relay failure does not compromise the entire shedding logic.
Step By Step Execution
Defining Priority Thresholds in YAML Configuration
Access the controller configuration directory and define the priority tiers and their associated SOC percentages. This file dictates the behavior of the pwr-shed-daemon.
“`yaml
/etc/power-mgmt/priority_matrix.yaml
shards:
– id: 1
priority: 3
description: “Climate Control”
shed_soc: 65
reconnect_soc: 75
relay_pin: GPIO_04
– id: 2
priority: 2
description: “Peripheral Lighting”
shed_soc: 45
reconnect_soc: 60
relay_pin: GPIO_17
“`
System Note: Modifications to this file require a service reload. Use systemctl restart pwr-shed-daemon to apply changes. Ensure the reconnect_soc is always higher than the shed_soc to prevent rapid oscillation.
Mapping Modbus Registers for Remote Telemetry
Mapping specific registers allows external SCADA systems to monitor and override shedding states. The controller utilizes Modbus Function Code 06 for writing to registers and 03 for reading.
“`bash
Example using mbpoll to test relay state on register 40001
mbpoll -m tcp -a 1 -r 40001 -t 4:int 192.168.10.50 1
“`
System Note: Register 40001 typically maps to the manual override bit. Setting this to 1 forces the relay closed, while 0 returns control to the automated shedding logic.
Implementing Hysteresis via Controller Logic
To prevent signal noise from causing relay fatigue, configure the voltage hysteresis settings within the controller firmware. This dictates how much the voltage must rise above the cut-off before a load is reattached.
“`bash
Set Hysteresis to 1.5V above cut-off
controller-cli set battery_hysteresis 1.5
Verify settings
controller-cli get battery_thresholds
“`
System Note: High hysteresis values increase system stability but delay service restoration for lower-priority loads. This is a trade-off between battery health and service availability.
Configuring MQTT Payload for Real-time Monitoring
The controller should be configured to broadcast state changes via MQTT to a centralized broker for audit logging and dashboarding.
“`bash
Subscribe to the power shedding topic
mosquitto_sub -h 192.168.10.5 -t “grid/shedding/status” -v
“`
System Note: The payload is typically a JSON object containing current_soc, active_tiers, and voltage. Use jq to parse these values for automated alerts.
Dependency Fault Lines
Load Shedding Priorities are susceptible to several operational failures that can lead to system instability. Signal attenuation on RS-485 serial buses often occurs when termination resistors (120 Ohm) are omitted, resulting in corrupted Modbus packets and failed shedding commands. This manifests as a timeout error in the logs or relays failing to transition state.
Root cause: Incorrect bus impedance.
Verification: Use an oscilloscope to check for wave reflections on the data lines.
Remediation: Install 120-Ohm resistors at both physical ends of the bus.
Relay contact welding is another failure mode, usually caused by switching high-capacitive loads without inrush current limiters.
Symptoms: The controller reports a shed state (GPIO low), but the load remains powered.
Verification: Measure continuity across relay terminals while the control signal is inactive.
Remediation: Replace the relay and install a soft-start module for the load.
Shunt drift also poses a risk, where the reported SOC diverges from the actual battery state due to cumulative measurement errors.
Root cause: Thermal drift in the shunt resistor.
Verification: Compare the controller voltage reading with a calibrated Fluke multimeter.
Remediation: Perform a zero-point calibration and update the Peukert constant in the configuration.
Troubleshooting Matrix
| Error Message / Symptom | Likely Cause | Diagnostic Action | Remediation |
|—:|:—|:—|:—|
| MB_ERR_TIMEOUT | RS-485 Noise or ID mismatch | Run tail -f /var/log/modbus.log | Verify slave IDs and baud rate (default 9600/8N1) |
| Relay Chattering | Hysteresis window too narrow | Monitor voltage via journalctl -u pwr-shed | Increase reconnect_soc or battery_hysteresis |
| SOC Discrepancy | Shunt calibration drift | Use controller-cli get current_raw | Execute controller-cli calibrate 0 at no load |
| Shedding Logic Bypass | Manual override bit active | Inspect register 40001 via mbpoll | Reset override bit to 0 for auto-mode |
| Delayed Shedding | High controller CPU load | Run top or htop on controller | Optimize telemetry polling intervals |
Example Log Output (journalctl -u pwr-shed-daemon -f):
“`text
May 12 14:02:11 pwr-ctrl pwr-shed-daemon[842]: SOC at 44.9% – Threshold 45.0% reached
May 12 14:02:11 pwr-ctrl pwr-shed-daemon[842]: Shedding Tier 2 (Peripheral Lighting)
May 12 14:02:11 pwr-ctrl pwr-shed-daemon[842]: GPIO_17 set to LOW
May 12 14:02:15 pwr-ctrl pwr-shed-daemon[842]: WARNING: High voltage ripple detected on DC bus
“`
Optimization and Hardening
Performance Optimization
To reduce latency in shedding execution, adjust the polling interval for the battery monitor. Decreasing the interval from 1000ms to 250ms allows for faster response to sudden high-draw events. Further optimize the queue handling within the daemon by utilizing asynchronous I/O for MQTT broadcasts, ensuring that a slow network connection to the broker does not block the local relay switching logic. Implement a low-pass filter on the voltage sensing input to remove high-frequency noise from inverter switching, which prevents false triggers.
Security Hardening
Isolate the controller on a dedicated VLAN with strict iptables rules. Only allow Modbus/TCP traffic from the IP address of the authorized SCADA master. Disable unused services such as Telnet or HTTP, forcing all administrative traffic through SSH with public-key authentication. Encapsulate MQTT traffic within a TLS tunnel to prevent packet inspection of energy data.
“`bash
Example iptables rule to restrict Modbus traffic
iptables -A INPUT -p tcp -s 192.168.1.100 –dport 502 -j ACCEPT
iptables -A INPUT -p tcp –dport 502 -j DROP
“`
Scaling Strategy
For larger installations, employ a distributed shedding model where a master controller communicates with multiple remote terminal units (RTUs). This provides horizontal scaling and redundancy. If the master controller fails, the RTUs should be programmed with fail-safe logic to automatically shed all non-critical loads (Priority 2 and 3) if they lose heartbeat communication for more than 60 seconds.
Admin Desk
How can I verify if a load shed was triggered by SOC or Voltage?
Check the daemon logs using grep “reason” /var/log/pwr-shed.log. The logic engine appends the trigger variable (SOC or V) to every event entry, allowing you to differentiate between capacity-based at terminal-based shedding events.
What happens if the controller loses network connectivity?
If the controller utilizes network-attached relays (e.g., Shelly or Tasmota), the connection loss will prevent shedding. Hardwire critical relays to the controller GPIOs and configure a “fail-open” state to ensure loads are disconnected if the control signal vanishes.
Why is my priority 1 load shedding before priority 3?
This is typically caused by a misconfiguration in the YAML array or a register overlap. Verify that each tier has a unique id and relay_pin. Check for conflicting systemd timers that might be overriding the shedding daemon.
Can I manually override a shedding event during an emergency?
Yes, use the controller-cli set_override
How do I reduce the relay “clicking” during marginal power conditions?
Increase the hysteresis value. If a load sheds at 24.0V, set the reconnect at 25.5V. This ensures the battery has regained sufficient surface charge and stability before the load is reintroduced to the bus, preventing a cyclic loop.