Most street light complaints are not really about a lamp. They are about a promise: a resident reports a dark corner, hears nothing back, and reports it again next week. Smart-node alerts, an accurate GIS layer, and a 311 queue can end that cycle only when they feed one work order process instead of three separate lists. This free 2026 playbook lays out a practical workflow for IoT fault detection, asset accuracy, and 311 loop closure. It also shows how Oxmaint CMMS software can follow each outage from first signal to verified repair.
Street Light 2026 Playbook: IoT + 311 CMMS Template
A free playbook for public works, lighting, and 311 teams. Detect faults from smart nodes, match every ticket to the right pole in GIS, dispatch by priority, and close the loop with the resident, using a CMMS template that records each step.
Where the Street Light Workflow Breaks
Cities that add smart nodes often end up with three lists that never meet: a node dashboard, a 311 queue, and a crew spreadsheet. Each list knows something the others do not.
Root causes worth fixing first
- Pole tags, GIS points, and node IDs entered by different teams at different times
- Alarms that fire on every event, so crews learn to ignore the dashboard
- Utility-owned poles mixed with city-owned poles and no ownership field
- Repairs closed without a night check or node confirmation
- Repeat failures treated as new outages with no cause code
- No report showing which signals were found by the system and which by residents
The Signal Triage Matrix
Before dispatching anyone, ask two questions: did a node alarm, and did a resident report? The answer decides the response.
Alarm and resident report
Confirmed outageCreate one work order and attach both signals. Dispatch by priority and tell the resident the ticket is being worked.
Alarm, no resident report
Proactive repairSchedule the fix before complaints arrive and log it as found by the system. This is the payoff of IoT.
Resident report, no alarm
Verify firstCheck node communications, pole location, ownership, photocell state, and neighboring fixtures. Not every fixture has a node.
No alarm, no report
Normal operationCover with scheduled patrols and preventive checks so silent failures are still found.
Fault Library: What the Node Is Telling You
A shared fault library turns raw alarms into consistent work orders. Adjust the actions to your equipment and your electrical safety procedures.
| Signal | Probable Cause | First Check | Work Order Type |
|---|---|---|---|
| Lamp out, zero power reading | Driver failure, fuse, wiring, or circuit issue | Review power and voltage history, then inspect the pole fuse and connections | Corrective, electrical |
| Day burning | Photocell or controller fault, or fixture stuck on | Check schedule, dimming profile, and photocell state | Corrective, controls |
| On/off cycling | Failing driver, loose connection, or thermal protection | Trend the cycle count and inspect at the pole | Corrective, raise priority on repeat |
| Several fixtures out on one circuit | Cable fault, breaker, contactor, or upstream utility outage | Check the feed point and utility outage status before sending multiple crews | Circuit investigation |
| Node offline, fixture lit | Communications problem, not a lighting fault | Check node power, antenna, and network coverage | Controls maintenance |
| Low or fluctuating voltage | Corroded splice, poor connection, or voltage drop | Inspect connectors and measure at the pole | Preventive or corrective |
| Knocked-down or damaged pole | Vehicle impact | Make safe, isolate power, notify risk management | Emergency |
| Missing fixture or cable | Theft or vandalism | Make safe and record the police report reference | Emergency, then repair |
GIS Accuracy: The Record IoT Depends On
An alarm is only useful if it points at the right pole. Treat the asset record as the foundation, and verify it in the field instead of trusting address geocoding.
Asset Record Checklist
How GIS Drift Happens
Give Every Outage One Record From Alarm to Verified Repair
Link poles, fixtures, and nodes in a single asset register, then turn alarms and resident reports into work orders with owners and closing evidence.
311 Loop Closure: Five Handoffs
A ticket stays open because a handoff is missing. Give each handoff an owner and a record.
Intake
The agent captures the location, the pole tag number if visible, and a short description. The system checks for duplicates.
Match
The ticket links to a GIS asset. Duplicates merge, and the node status is checked.
Dispatch
A work order is created with a priority. Utility-owned poles are referred out with a tracked reference number.
Repair
The crew records the cause code, parts used, time on site, and an after photo.
Verify and notify
A night check or node confirmation proves the fix. The resident is told, and the ticket closes with the work order number.
Example priority tiers
| Priority | Condition | Response Target |
|---|---|---|
| P1 Emergency | Downed pole, exposed wiring, or damaged fixture | Make safe immediately |
| P2 Safety-critical | Outage at a crosswalk, school zone, intersection, or several adjacent fixtures | Example: within 1 to 2 days |
| P3 Standard | Single fixture out | Example: within one working week |
| P4 Planned | Dimming profile, node offline with lit fixture, or cosmetic issue | Scheduled batch |
These targets are examples only. Set actual response times through your council or agency policy.
Recurring Checklists
Daily and Weekly Triage
Monthly Review
Node Commissioning
Quarterly and Annual Care
Smart-Node Technology Notes for 2026
LED conversion and adaptive dimming have made connected control a common part of lighting programs. Choices made at procurement shape maintenance for years.
| Topic | Where It Fits | Watch For |
|---|---|---|
| Cellular IoT nodes | Scattered fixtures and areas without a private network | Recurring data fees and coverage gaps |
| RF mesh | Dense urban grids with many nearby fixtures | Gateway placement and dead zones after construction |
| LoRaWAN | Low-data alerts across wide areas | Limited data volume for rich diagnostics |
| ANSI C136.41 receptacle | Nodes and photocontrols that can be swapped without rewiring | Confirm the luminaire specification supports it |
| Driver interface standards | Luminaires that expose diagnostic data to the node | Compatibility between node and luminaire vendors |
| Cybersecurity | Any networked lighting control system | Default credentials, firmware updates, and access logs |
Warmer color temperatures and shielded optics are common design goals for dark-sky and neighborhood concerns. Record the fixture specification so replacements match the design.
One Outage, Two Workflows
This illustrative comparison shows how the same outage moves through an open-loop process and a closed-loop process.
Open-loop process
Closed-loop process
CMMS Template: Mapping the Playbook to Oxmaint
Oxmaint acts as the maintenance system of record. Ask during a demo how your node platform and 311 system can feed it, whether through staff entry or integration.
| Playbook Need | Oxmaint Capability | Record Left Behind |
|---|---|---|
| Pole, fixture, node, and cabinet register | Asset management | Hierarchy from cabinet to circuit to pole to fixture to node |
| Fault to repair | Work orders and corrective maintenance | Signal source, cause code, parts, and photos |
| Night patrols and audits | Mobile inspection workflows and scheduling | Patrol results and outages found |
| Cabinet and pole care | Preventive maintenance | Inspection history per asset |
| Driver and photocell stock | Inventory | Parts used per repair and reorder levels |
| Council and 311 reporting | Dashboards and reports | Open outages, repeat failures, and closure times |
KPI Scorecard
| KPI | How to Calculate | How to Read It |
|---|---|---|
| Median time to repair | Ticket open to verified closure | Rising values point to dispatch or parts delays |
| Repeat outage rate | Fixtures with a second outage in a set window, divided by fixtures repaired | High values suggest the wrong root cause was fixed |
| Found-by-system share | Outages detected by nodes before a report, divided by all outages | Rising values show IoT is working |
| Ticket-to-asset match rate | 311 tickets linked to the correct asset on the first try | Low values point to GIS drift |
| Node health | Nodes reporting, divided by nodes installed | Drops signal network or power problems |
| Utility referral turnaround | Days from referral to confirmed repair | Shows where the city depends on outside crews |
Four Gates for Rollout
Frequently Asked Questions
How does a CMMS use IoT street light alerts?
Alerts open or attach to work orders linked to the pole ID, so cause, parts, and verification are recorded. Start building your asset register.
Why does GIS accuracy matter for 311 requests?
Crews repair what they can find. A wrong pole ID or coordinate sends them to the wrong location and leaves the ticket open.
Should every node alarm create a work order?
Not always. Tune thresholds first, and keep low-priority events such as a node offline with a lit fixture in a separate queue.
Who repairs a utility-owned pole?
The utility does, but the city should track the referral and keep the resident ticket open until the fix is verified.
Do we need a smart node on every fixture?
No. Mixed networks are common, and non-networked fixtures rely on patrols and 311. Book a demo to plan a mixed setup.
Close the Loop on Every Dark Street Before the Second Call
Bring node alarms, GIS assets, crew work, and 311 tickets into one maintenance record, and show residents and council exactly what was fixed and when.
