Instructor guide

Answer keys, discussion points and common mistakes for the re-tuning workbook, modelled on the instructor notes that accompany the PNNL re-tuning training. Keep this page away from learners until they have tried each exercise.

Every figure here comes from a CAMBER run. Each exercise's key is pinned by the test suite (tests/workbook/): on a small synthetic stand-in for the dataset in every test run, and on the real catalog data with pytest -m network. When CAMBER's answer changes, those tests fail and name the exercise; the key and this page are then updated together. A figure quoted below is from the real data unless it says otherwise, with the CAMBER version and the commands on the exercise page.

Each exercise's section has the same parts: Answer key, Discussion points and Common mistakes.

Air side

`air-sat-reset`: Supply-air temperature reset

Figures from the real lbnl-sdahu, lbnl-ddahu and irish-ahu default subsets, CAMBER 0.98.0-dev (the dual-duct supply_air_reset reading 0.100.0-dev, after its cold-deck setpoint was mapped), with the commands on the exercise page.

Answer key

Is the single-duct unit's supply air reset? No. supply_air_reset is a warn on AHU__fault_free: "not reset (setpoint flat)". The rule reads the trended setpoint, which never moves (a range of 0.00 °F all year at 55.25 °F), so the shape of the supply air does not matter. Against the Guideline 36 outdoor-air target the supply air is colder in 71% of the occupied running hours, by a mean 6.0 °F (supply_air_reset_compliance, a warn). The faulted runs read the same: the sequence has no reset.
The dual-duct cold deck? Not reset either: supply_air_reset is a warn, "not reset (setpoint flat at ~55F)", and the supply air is below the Guideline 36 target in 66% of the hours. Since 0.100 the cold-deck setpoint is mapped, and the rule reads it: it never moves (a range of 0.00 °F all year at 55.0 °F). Before 0.100 no setpoint was mapped and the same warn came from the supply air itself ("SAT pinned low at ~55 F regardless of OAT"). The dataset's documentation describes a 60 °F cold-deck setpoint in economizer weather; the setpoint and the supply air hold 55 °F in every row (the data issue The 60 F economizer supply-air setpoint is not in the data). The published description and the published data disagree; CAMBER reads the data. The hot deck has its own setpoint (90 °F), which is not mapped: the answer is about the cold deck only.
The Irish unit? supply_air_reset is ok, "reset present": over the cooling hours its supply air falls as the outdoor air warms, by -0.14 °F per °F, and supply_air_reset_compliance is ok (it tracks the target). Falling with outdoor air is the right direction for a cooling supply-air reset: warm weather means more cooling load, so Guideline 36 lowers the supply air; cool weather lets it rise and saves reheat. The evidence is weak, though: the fit is loose and no setpoint is trended, so the finding carries a caveat asking for the setpoint. A negative slope can also be a fixed setpoint that the coil only just holds in hot weather.
Which run fails to hold its setpoint? AHU__damper_stuck_075: supply_air_control is a fault, too cold in 31% of its occupied running hours. With the damper stuck at 75 % the unit takes in cold outdoor air it cannot shut out, and it has no heating coil to warm it back up.
The fault-free unit's too-warm hours? supply_air_control is ok on AHU__fault_free: 3% of its occupied running hours are more than 2 °F above the setpoint (occupancy_gate: trended occupancy). Counting every fan-on hour instead, 78% of the too-warm hours are unoccupied: the fan cycling in the simulation's unoccupied mode, with the damper shut and warm return air. That is not an occupied-control fault, which is why the rule judges only occupied hours when the unit trends occupancy. With occupancy_gate: "off" the same unit reads a warn at 12%, the verdict CAMBER gave before 0.98.

Discussion points

Two different questions: is there a reset (shape), and is the supply air colder than it needs to be (target)? A unit can fail one and pass the other. Map both to the discharge-air temperature guide's questions on reset and on what drives it.
A trended setpoint beats inference. On the single-duct unit the setpoint settles it; on the Irish unit only the supply air is trended and CAMBER says so.
Documentation versus data (question 2): re-tuning starts from what the trends show, and a published sequence can be wrong.

Common mistakes

Reading a positive slope against outdoor air as a reset. A cooling supply-air reset moves the other way; supply air that rises with the weather is supply air losing to the load.
Treating the Guideline 36 gap as a fault. It is an energy opportunity, to weigh against zone comfort and humidity.
Blaming the controls for question 4. The controller is doing its best; the damper is the fault, and this unit cannot heat.

`air-static-pressure`: Static pressure reset and the damper census

Figures from the real lbnl-sdahu and ornl-frp-vav default subsets, CAMBER 0.98.0-dev, with the commands on the exercise page.

Answer key

Is the single-duct static setpoint reset? No. static_pressure_reset is a warn on AHU__fault_free: the setpoint never moves (a range of 0.00 in. w.c.), held at 1.607 in. w.c. all year: "flat (no trim-and-respond reset)".
Why no finding on the faulted runs? Their published setpoint is a placeholder (-400.25 in every faulted run), which the catalog masks to missing at ingest. With no setpoint the rule has nothing to judge, so it reports nothing rather than reading a negative setpoint. Only the fault-free run, and the fault-free part of the spliced onset run, carry the real setpoint.
What does the census say? damper_census is a fault: on the fault-free day all 10 boxes have a median damper opening below 50 % (a fleet median of 39%) over the hours the boxes' own trended occupancy marks occupied, none is near fully open: "static likely too high". The proposal is a trim-and-respond static reset: lower the setpoint while no box asks for more air, raise it when one does, so that the most-open box ends up nearly fully open.
What else could throttle every box? Light load on the test day (only the minimum airflow was needed); oversized boxes or minimum-airflow settings; a static sensor that reads low, so the fan makes more pressure than the trend shows; and the test design: the publisher says only the box under test was actively controlled. The census is a screening signal that tells you where to look.

Discussion points

The two halves need two datasets: the simulated unit trends a setpoint but no box dampers; the real building trends every damper but not the setpoint. Real projects face the same gaps; map the missing points against the static pressure guide's trend list.
A placeholder is not a setpoint (question 2): CAMBER masks what it can prove is not data, and says so in the data issues.
A flat setpoint on a simulation is the designer's choice; the re-tuning question is what resetting it would save.

Common mistakes

Reading "no finding" on the faulted runs as "no problem". The rule had nothing to judge.
Pooling boxes from different test days or different air handlers into one census.
Assuming the census judges an office schedule. Since 0.98 each box's occupied hours come from its own trended occupancy point, so a weekend test day gets a census too (the tests ran 07:00-22:00 every day); only a box with no occupancy trended falls back to CAMBER's assumed weekday 07:00-18:00 schedule, and the finding's occupancy_gate says which applied.

`air-heat-cool`: Simultaneous heating and cooling, and a leaking valve

Figures from the real lbnl-sdahu, lbnl-ddahu and irish-ahu default subsets, CAMBER 0.97.0-dev (the leak figures 0.98.0-dev), with the commands on the exercise page.

Answer key

Does CAMBER flag the leak? Yes. leaking_valve is a fault on AHU__coi_leakage_010: in 60.5% of its occupied, fan-on hours with the valve shut, the supply air sits below the mixed air. The fault-free run reads 2.4% (ok), and the label score gives leaking_valve TPR 100%, FPR 0 %.
Compare the two runs. With the valve commanded shut and the fan running, the fault-free unit's supply air sits a median +1.1 °F above its mixed air (the fan's heat, occupied hours); the leak run's sits at -0.1 °F. The leak takes about 1 °F out of the air, all day, in every hour the valve is meant to be shut. The rule's default only calls a cooling leak when the supply air is more than 3 °F below the mixed air, a margin meant to ride over sensor error, so with the defaults this leak is ok (CAMBER 0.97 missed it). The config credits the unit's own fan heat (measured_fan_heat_f 1.0 °F, cool_delta_thr_f 1.0 °F): a leak is now any supply air below the mixed air, and the caveat names the fan heat used. That 1.0 °F was measured on AHU__fault_free, the same run the score counts as a negative, so its clean verdict is partly by construction; the leak run, which the calibration never saw, is the evidence. A half-year split (calibrate on one half, judge the other) still reads the fault-free run ok and the leak a fault (VALIDATION.md).
Is the dual-duct unit fighting itself? simultaneous_heat_cool is a fault: both valves open in 27% of occupied hours. But the two coils sit in different air streams: the hot deck heats while the cold deck cools, by design. The energy question is the mixing at the terminal boxes, not coil fighting. The rule's caveat says it could not rule out dehumidification with reheat, because no cooling-coil leaving temperature or humidity is trended, and asks you to declare the sequence.
Dehumidification or fighting? Ask for the cooling coil's leaving-air temperature and a humidity (return or outdoor, to form a dew point). Dehumidification runs the coil below the entering air's dew point and reheats after it; a coil leaving above the dew point removes no moisture, so reheating after it is fighting. Also ask for the written sequence.
The Irish unit? simultaneous_heat_cool is ok: the coils are never open together (0.0 % of hours). leaking_valve is ok, judged on each coil's own leaving-air sensor rather than the supply air: a heating-leak signature in 9.8% of the hours with both valves shut, just under the rule's 10 % warn line.

Discussion points

A rule with a fixed margin misses small faults; a unit's own baseline catches them, at the price of a calibration that must not be judged on the data it came from. Ask where the class would put the margin, knowing the sensors' accuracy, and which period they would calibrate on. Map it to the AHU heating and cooling guide's question on valves that do not shut off.
"Both valves open" is a symptom, not a diagnosis: the system type (dual-duct) and the sequence (dehumidification) decide.
The Irish unit's valves were replaced in May 2022: the going-further step splits its record there.

Common mistakes

Quoting the fault-free run's FPR 0 % as proof the calibration works: that run set the 1.0 °F. The held-out half-year is the honest test.
Copying the 1.0 °F fan heat to another unit. Fan heat depends on the fan, its speed and the sensor positions; measure it on the unit's own known-good hours.
Calling the dual-duct unit's 27% a fault to fix at the coils.
Judging a heating leak on supply air downstream of the fan without allowing for fan heat.

`air-economizer`: a stuck outdoor-air damper and missed free cooling

Figures from the real lbnl-sdahu default subset, CAMBER 0.97.0-dev (the free_cooling_missed figures of questions 4 and 5, with the rule judging fan-on hours only (#120) and the low limit: 0.102.0-dev), with the commands on the exercise page.

Answer key

Which runs does CAMBER flag for too much outdoor air? AHU__damper_stuck_075 and AHU__damper_stuck_100_short: outdoor_air_fraction is a fault on both, and so is economizer_high_limit. The damper stuck at 75 % brings in a median 67.5% outdoor air in cooling weather; stuck at 100 %, all of it. Above the 60 °F high limit neither is ever locked out to minimum.
What does the fault-free unit do? It sits at its own design minimum, a 1.6 % OA fraction, in cooling weather: no OA-fraction or high-limit finding. Its annual median OA fraction is much higher (about 40 %), because it economizes whenever the outdoor air is below 60 °F. That is correct operation, and why the rule judges cooling weather against the unit's own minimum.
Which stuck dampers do the OA-fraction rules miss, and why? AHU__damper_stuck_010 and AHU__damper_stuck_025. Stuck near the minimum, they admit about as much outdoor air as a healthy unit in cooling weather (1.6 % and 4.4 %), so there is no excess to find.
Where do they show up instead? In free_cooling_missed: both are a fault, with mechanical cooling running in 100% of the free-cooling hours (outdoor air below 60 °F, supply fan running): the damper can't open to cool for free, so the coil does the work every hour. But the fault-free unit is a fault too, at 34.1%. A healthy unit reading as a full fault is the puzzle of question 5. The rule does not judge hours with the fan off (n_masked_fan_off): no air moves across the coil, so there is nothing to economize.
The fault-free unit's fault: the economizer low limit. Its missed_cause is economizer_not_commanded and missed_damper_cmd_median_pct is 10: on the missed hours the damper was commanded to its 10 % minimum, not open. The trends show when: on cold winter weekdays (December to February, most of them) the damper command sits at its minimum while the coil cools the mixed air; on mild days the damper opens, and when the coil runs it runs with the damper open (integrated economizer, which the rule does not count as missed). The dataset's inventory (section 1.2, in camber datasets info lbnl-sdahu) says the economizer runs only between 33.8 °F and 60 °F. Below 33.8 °F the sequence locks the economizer out, so those hours are not free-cooling weather. 899 of the fault-free unit's 965 missed hours, 93 %, are below the lockout. With "low_limit_f": 33.8 the rule sets aside 1,014 fan-on hours below it, judges the remaining 1,818 free-cooling hours, and the fault-free unit reads clean: ok at 3.63%. The stuck dampers stay caught: the 10 % and 25 % runs are still a fault, at 100%, with missed_cause: damper_not_delivering (the damper commanded open, the outside air not arriving). The low limit removes a design behaviour from the opportunity; it does not hide the fault, because a stuck damper misses free cooling above the low limit too.
Label score. Against the dataset's labels, outdoor_air_fraction finds 2 of the 4 stuck dampers with no false alarm: TPR 50%, FPR 0 %. Over all six scored runs (the four dampers, the leak and the fault-free run) the overall detection is TPR 40%, FPR 0 %: the exercise's config leaves out leaking_valve, so the leak run counts as missed.
The Irish unit (real irish-ahu data, whole record)? outdoor_air_fraction is a warn: in cooling weather (outdoor air above 70 °F) the outdoor-air fraction is above the unit's 4.1 % minimum in 42% of the hours. economizer_high_limit is a warn: above the 65 °F high limit, with the outdoor air no cooler than the return air, the damper is not back at minimum in 21% of the samples. free_cooling_missed is ok: mechanical cooling ran in 8.0% of the free-cooling hours. Raise the excess outdoor air in warm weather as a question for the site, with the dates; the free cooling is being used.
Is it the COVID-19 period? Not only. Splitting the record with source.start / .end: the years before it (2017-06 to 2020-02) show excess outdoor air in 53% of the cooling-weather hours, a fault on their own, against 45% in the documented 100 % outdoor-air period (2020-08 to 2021-11). Cooling weather is rare in Ireland, so each period has few such hours.

Discussion points

A stuck damper is two different faults depending on where it sticks: open wastes cooling in hot weather, closed wastes free cooling in cool weather. PNNL's economizer guide asks both questions; each CAMBER rule answers one of them.
free_cooling_missed is not one of the dataset's declared detector targets, so camber datasets score doesn't count it. Ask why: without the unit's low limit it also reports a fault on the fault-free unit (34.1%). A detector with a non-zero baseline has to be read against the unit's own fault-free run, which is what question 4 does; question 5 then finds where that baseline comes from.
"Favorable conditions" in the economizer guide's first question are what the unit's sequence says they are. The low limit is a setting of this sequence, not a CAMBER default: ask learners where they would find it on a real unit (the sequence of operations, the controller program, or a winter of known-good trends) and what the rule would read if it were set too high (stuck dampers lose their cold-weather evidence).
The design minimum matters. With a generic 20 % minimum the fault-free unit would look under-ventilated all summer; the config uses this unit's own measured minimum (1.6 %). Point to the _comment in the exercise config and to the minimum outdoor-air guide.
On a real unit (questions 6 and 7) the history matters: a documented decision explains part of the excess outdoor air, and the rest is a lead to take back to the site.

Common mistakes

Reading the annual median OA fraction (about 40 % on the fault-free unit) as excess outdoor air. Excess outdoor air is judged on cooling-weather samples only.
Concluding that the 10 % and 25 % runs are healthy because the OA-fraction rules are quiet.
Treating the fault on the fault-free unit's free_cooling_missed as a fault to fix, without comparing it with the faulted runs or checking when its missed hours happen.
Setting low_limit_f to make the fault go away rather than from the unit's sequence. The value is the documented 33.8 °F; a higher number would also set aside hours a stuck damper misses.
Running the dataset's default config (camber datasets config lbnl-sdahu without --exercise) for steps 2 to 5: it already sets the low limit on free_cooling_missed, so the fault-free fault of question 5 never appears, and it adds rules this exercise does not ask about.
Reading the Irish findings as scored detections. The data are unlabelled; a documented operating decision (100 % outdoor air) is not a fault, and a finding is a question for the site.

`air-scheduling`: Scheduling: 24/7 operation, setback and after-hours load

Figures from the real ornl-frp-ops default subset, CAMBER 0.97.0-dev, with the commands on the exercise page.

Answer key

The 24/7 baseline? night_weekend_setback is a fault on RTU__base_heating: the fan runs 100 % of the unoccupied hours, as in the occupied ones: "setback MISSING/weak". That is the test's design, and the finding a re-tuning visit would make on a real building.
Why is the setback effective? On RTU__sb_heating the fan still runs in 56% of the unoccupied minutes, which fails the runtime test. But it cycles: in the night hours it runs at all, its mean duty is 71%, and while it runs the return air reads 63.0 °F against 67.3 °F in occupied hours, close to the 60.1 °F setback. The rule's held-setback test decides: "setback effective (fan cycling to hold)", an ok. Runtime alone would have called it missing.
Night fan energy? 16.2 kWh in an average night (22:00-07:00) in the baseline, 3.2 kWh with the setback. The saving is larger than the runtime share suggests: the fan also draws much less power when it cycles at night than it does by day.
Compressor short-cycling? compressor_short_cycle is a fault in both tests: 178 starts a day in the baseline and 131 with the setback, against a 12-a-day threshold. Scheduling trims it (fewer running hours) but is not the fix: a DX compressor is cooling a building at minimum airflow in winter while the boxes reheat. Lock out mechanical cooling in cold weather, check the reheat, and give the compressor minimum on and off times.
Before promising the saving? The two tests ran in different weeks (March 2021 and January 2022), so the weather differs; the building was unoccupied; only the fan's power is counted; and a setback has to recover by the morning without starting the compressor and reheat harder. Normalize for weather and count the whole unit.

Discussion points

Runtime is not the whole story (question 2). The occupancy scheduling guide asks for unoccupied fan cycling to hold a setback, not continuous running; CAMBER's held-setback test reads the same distinction from the trends.
The schedule you judge against matters: the config uses the tests' own 07:00-22:00, every day. Try an office schedule and watch the verdicts move.
After-hours load is measured in energy, not hours.

Common mistakes

Calling the setback test "missing" because the fan runs half the night.
Comparing the two tests' energy as a saving without the weather.
Treating the short-cycling as a scheduling problem.

Terminal units and ventilation

`zone-reheat-overcooling`: the reheat penalty and overcooling at minimum airflow

Figures from the real lbnl-fpu default subset, CAMBER 0.97.0-dev (the valve-stuck-shut answer re-checked on 0.98.0-dev), with the commands on the exercise page.

Answer key

Does the fault-free box overcool its zone? Yes. overcooling_min_flow is a warn on PFPU__fault_free: in 85% of occupied hours the box sits at its minimum airflow with the zone already at or below its cooling setpoint. That minimum is 48% of the box's peak airflow. The box is sized for the summer peak, and its minimum is set high enough to overcool the zone most of the year.
How often does it reheat? The reheat valve is open in 11% of occupied hours, every one of them into centrally cooled air at minimum airflow (reheat_penalty warn; the valve averages about 21 % when open, on winter mornings). The zone needs the heat only because the minimum airflow keeps delivering cold air it does not need. That is the reheat penalty PNNL's zone guide sets out to reduce, and the fix is a lower minimum (within the ventilation requirement), not a repair.
The stuck-open box. airflow_tracking is a fault on PFPU__VAVDMPRStuck_100pct: the airflow is off its setpoint in every active hour, by 291% on average (always above it). The box reheats in 99% of occupied hours, and even so the zone is too cold in 10% of them (unmet_setpoint_hours warn). Half open, the airflow is off by 168 % and the box reheats in 67% of occupied hours, but the zone stays in band.
Why is overcooling_min_flow quiet on it? The rule looks for a box at its minimum that still overcools, which is a setting problem. The stuck box is never at its minimum: its airflow is far above its setpoint all the time. Its overcooling is a hardware fault, and airflow_tracking is the rule that names it.
The valve stuck shut. It is not wasting reheat: it delivers none. Both rules read the valve's measured position (valve_signal = position), which is 0 % all year, so reheat_penalty is ok (0 % open) and so is overcooling_min_flow (no overcooling with reheat). Each finding carries a caveat: the demand is at or above 90 % while the position reads at or below 5 % on 100 % of the occupied full-demand hours, a stuck or failed valve rather than a reheat penalty. With only the demand (as before 0.98), both rules rated it a fault: the demand sits near full (about 93 % when open) because the zone is cold, and the discharge still rose 6 °F at full demand, because the parallel box's fan mixes in warm plenum air, which passed the valve-versus-discharge cross-check. zone-reheat-saturated shows what it really is.
Which box is under test? The south-zone box (_S columns). Comparing each faulted run's columns with the fault-free run's shows that only the _S box's columns change. CAMBER's mapping (mappings/lbnl_fpu.json) documents this. It mapped the west box until 0.82 and scored a healthy box.
Label score. airflow_tracking, the dataset's only declared detector, finds both stuck dampers and never fires on the others: TPR 100%, FPR 0 %. The overall detection is TPR 50%, FPR 0 %: the stuck and the leaking reheat valve count as missed, because the dataset declares no detector for them.

Discussion points

Two causes, one symptom. A high minimum and a stuck damper both push cold air into a zone that must then be reheated. PNNL's zone guide asks about minimum airflow settings, and chapter 7 about boxes that do not respond. Draw out which rule answers which question.
The fault-free run is not "no findings". A simulated building designed with a conventional minimum still shows a small reheat penalty. That is the re-tuning opportunity, and it is why the rules warn rather than stay silent.
Demand versus position. The rules that judge heat delivered read the position; the rules that judge how hard the controller asks read the demand. Ask what a site that trends only one of the two can and cannot conclude, and what a series box (whose fan runs all the time) does to the discharge-air rise.
Minimums are also a ventilation question: lowering them needs the zone's 62.1 minimum. See zone-min-oa.

Common mistakes

Reading the stuck-shut valve's quiet reheat_penalty as "nothing wrong". It is quiet because no heat is delivered; the caveat names the stuck valve, and reheat_capacity_shortfall in zone-reheat-saturated grades it.
Expecting overcooling_min_flow to catch the stuck-open damper, and concluding the rule is broken when it is quiet.
Treating the half-open damper as harmless because the zone stays in band. It still reheats in two thirds of occupied hours.
Reading the fault-free box's warnings as faults to repair. They are settings to re-tune.
Scoring the leak and the stuck valve as airflow_tracking misses. They are outside what the dataset declares that detector for.

`zone-bad-box`: one bad box in a fleet

Figures from the real ornl-frp-vav default subset (test set 3), CAMBER 0.97.0-dev (the actuator_stuck figures and the label scores 0.98.0-dev), with the commands on the exercise page.

Answer key

Which box is under test? The box of room 205 (RTU_VAV_205__d3_<day>). On every faulted day its damper is a flat line at the test position (0, 20, 40, 60, 80 or 100 %) through the occupied hours. On the fault-free day it modulates like its nine neighbours, whose dampers all move through the day.
Airflow among the neighbours. On the 0 % day it delivers the least air of the ten boxes; on the 100 % day, the most. Compared with its own fault-free day, it starves in the first case and floods in the second. The raw airflows of the ten boxes differ widely, because the rooms differ in size, so rank and shape are the useful comparisons.
When does unmet_setpoint_hours flag it? On the 20 % day (a fault, unmet 53% of occupied hours, mostly too hot) and the 40 % day (a fault, too hot). It is quiet on the 0, 60, 80 and 100 % days. Stuck shut, the room still stayed in band that day: its load was small enough to do without the air. Stuck 60 % or more open, it got more cold air than it needed and still stayed in band. A stuck damper only upsets comfort when the day's load needs the airflow it can no longer give, so a one-day test catches it only on some days.
Flagged on the fault-free day too. Yes, a fault with the room too hot in 22% of occupied hours. Room 205 is the building's warm room: its afternoons run over the cooling setpoint even when its box works. That is a real finding, likely a load or a capacity limit, but it is not the fault under test.
The cohort rules. sat_rogue_zone_census is a warn. Grouping each day's ten boxes under that day's rooftop unit, it names box 205 as the zone dragging the supply-air reset on the fault-free, 20 % and 40 % days, and box 105 on the 80 % day. sat_cohort_starvation is ok: no day's cohort as a whole is starved, so the problem is one box, not the rooftop unit. The census says which zone is driving demand, not why. On the fault-free day it points at the warm room, not a fault.
The rooftop unit. As the stuck damper goes from shut to fully open, the unit's supply airflow rises at every step and its duct static pressure falls. A fixed-speed fan moves more air through a more open system. Each position is a different day, so the weather moves these numbers too, but the direction holds at every step.
actuator_stuck and the label score. It flags box 205 on all six stuck days and stays quiet on the fault-free day: TPR 100%, FPR 0 % (one negative day, so the interval is wide). Each stuck day's damper holds one position through all the occupied hours (100 % of active samples), and the rule says what contradicts it:
0 %: shut through occupied hours (a fault; no airflow setpoint is logged, so the caveat says it was judged against the occupied mode alone);
20 % and 40 %: part open while the room runs over its cooling setpoint (a fault; 6 °F and 3.8 °F over, median);
100 %: fully open while the room sits 5.2 °F below its cooling setpoint (a fault);
60 % and 80 %: nothing in the room contradicts the position, but it held all day while the room temperature moved, so it is a warn only. A mid-stroke position the room is happy with could be a healthy box holding its minimum.

The neighbours' dampers do sit still for hours (26-41 % open for 4-10.5 h), but at a minimum position in a room below its cooling setpoint: consistent with what the room asked for, and never for a whole day, so they stay quiet. unmet_setpoint_hours alone would catch 2 of the 6 stuck days and fire on the fault-free day too: TPR 33%, FPR 100 %. A comfort rule detects a stuck damper only on the days the stuck position hurts comfort, and it cannot tell a stuck box from a warm room. The dataset logs no airflow setpoint, so airflow_tracking, the rule that finds stuck dampers on lbnl-fpu, cannot run. 8. Room 102. No. Its box is not under test, and the room is too cold on every day, fault-free included (a fault each day). It is a cold room in this building. The reheat is electric and not trended as a valve, so CAMBER cannot say whether it was maxed out (see zone-reheat-saturated).

Discussion points

Chapter 7's advice to trend damper position and airflow for every box is the whole exercise. A box that does not move while its neighbours do is the cheapest fault signature there is. No comfort rule reproduces it, and neither does a plain "flat for four hours" test: the healthy boxes fail that one. actuator_stuck works because it asks whether the room wanted the damper somewhere else.
On the full subset actuator_stuck finds 17 of the 18 stuck days and none of the 13 fault-free and airflow-bias days. It misses set 1's 100 % day: the room ran warm, so a fully open damper looked like the right answer. A box stuck where a busy day would have put it anyway cannot be told from a working one.
The going-further cohort question: grouped per day, the raw mean airflow never singles out box 205 (robust z -1.5 to +2.0), and airflow as a share of each box's own peak flags six healthy box-days and scores the fault-free day at z -3.1. Evening out sizes does not isolate a stuck box. Its airflow against its own fault-free day does (all six days), and so, partly, does its damper's variability on the low tail (z -2.1 to -5.0; three of six past the default 3.5).
The zone cohort needs a common basis. Each day's boxes are compared under that day's rooftop unit (the naming topology), never across days. Ask what goes wrong when a census pools boxes from different days (the dataset config's _comment explains why cohort_airflow is left out of the default run, and its group_by_topology option fixes the pooling).
The labelled "fault-free" day is not a trouble-free building. Discuss room 205's warm afternoons and room 102's cold mornings as findings in their own right.

Common mistakes

Concluding that the 0 % and 60–100 % days are healthy because unmet_setpoint_hours is quiet.
Reading the 60 % and 80 % warnings as weaker evidence of a fault than the others. The damper is just as stuck; the room just did not contradict it that day.
Reading the rogue-zone census on the fault-free day as a false alarm. It correctly names the zone driving the reset, which happens to be a warm room, not a broken box.
Comparing raw airflows across rooms of different sizes and calling the smallest box the starved one.
Blaming the rooftop unit because its airflow and static change. They follow the stuck box; the cohort-starvation census says the cohort as a whole is fine.

`zone-reheat-saturated`: a zone below setpoint with its reheat maxed out

Figures from the real lbnl-fpu and ornl-frp-vav default subsets, CAMBER 0.97.0-dev (answers 4 and 5 re-checked on 0.98.0-dev), with the commands on the exercise page.

Answer key

Which run? PFPU__ReheatVLVStuck_0pct: reheat_capacity_shortfall is a fault. The zone sits more than 1.5 °F below its heating setpoint with the reheat demand at 90 % or more in 31.8% of occupied samples, 663 h over the year, a median of 4.5 °F below setpoint. It happens in the heating season, when the box needs heat and gets none.
Capacity or airflow? Capacity. In the shortfall samples the airflow is at 100 % of its setpoint, so the box delivers the air it asks for, and the discharge air is only 60.8 °F, barely above the supply air. The rule names capacity as the likely cause: look at the coil, the valve and the hot water, not the damper.
The other two rules. unmet_setpoint_hours is a fault, with the zone too cold in 37% of occupied hours. It counts the complaint but not the cause. overcooling_severity reports no overcooling (info). It sets the cold, reheat-saturated samples apart as a heating shortfall, graded fault on both depth and share: 30% of occupied samples, well over the 20 % a fault needs. "Overcooled" would send you to the cooling side (minimum airflow, supply-air temperature), when the zone is cold because heat cannot get in.
Which signal? reheat_capacity_shortfall reads the controller's reheat demand (heat_valve): the controller keeps asking for full heat because the zone stays cold, and the valve stuck shut cannot respond, so the reheat reads maxed out. reheat_penalty reads the valve's measured position (heat_valve_position, valve_signal = position), which is 0 % all year: it is ok, 0 % open, with a caveat that the demand is at or above 90 % while the position reads shut on 100 % of the full-demand hours, a stuck or failed valve rather than a reheat penalty. Before 0.98 it read the demand as reheat delivered in 51% of occupied hours and rated it a fault: the parallel box's fan mixes in warm plenum air, so the discharge rose a few degrees, enough to pass the valve-versus-discharge check (the config now allows for that lift with fan_heat_f = "auto"). On site: stroke the valve, check the discharge air at full demand, and check the hot-water supply to the coil.
Heat to spare. The fault-free run, the leaking valve and the half-open damper have no saturated shortfall at all. The fully open damper has a little (under 2 % of samples, ok): in a few cold hours its extra cold air outruns the reheat. overcooling_severity grades that shortfall info: it is deep enough for a fault, but only 0.8% of occupied samples, under the 5 % a warning needs. Before 0.98 it graded the depth alone and called it a fault.
ORNL, fault-free day. Several rooms are too cold on a normal day. Room 102 is below its heating setpoint in 33% of occupied hours (unmet_setpoint_hours fault), and rooms 104, 105, 106, 204 and 206 are too cold for part of the day too. overcooling_severity rates room 104 a fault, up to 4.6 °F below its heating setpoint, and room 102 info.
Why no reheat verdict? The boxes' reheat is electric and published only as energy per minute, not as a valve or a command, so it is not mapped. reheat_capacity_shortfall needs a reheat valve and produces no finding for any box. Without a reheat signal, overcooling_severity cannot set a heating shortfall apart from overcooling, so it calls room 104 "overcooled". Ask the operator to trend each box's reheat command (or stage), its discharge-air temperature and its airflow setpoint.

Discussion points

A saturated reheat valve is the end of the story that zone-reheat-overcooling begins. PNNL's zone guide asks whether zones hold their heating setpoints. This exercise adds "could the box have done more?"
The same cold room reads as three different problems (unmet hours, overcooling, a heating shortfall) depending on what the data carry. Missing data changes the diagnosis, not only the confidence.
Demand versus position: a controller's output tells you what it wanted, not what happened. Pair every demand with a response (discharge air, airflow) before trusting it.

Common mistakes

Calling the ORNL rooms "overcooled" and lowering their airflow. With no reheat signal CAMBER cannot tell, and the rooms may be short of heat.
Reading reheat_penalty's ok on the stuck-shut valve as "the reheat is fine". It is ok because no heat is delivered; read its caveat.
Treating unmet_setpoint_hours as a diagnosis. It measures a symptom.
Expecting a finding on every box. A rule that lacks its input stays silent. Check which rules produced findings, not only which fired.

`zone-dcv`: is outdoor air following occupancy?

Figures from the real finnish-dcv, b4b-windesheim and sdu-ou44 default subsets (each the whole published record), CAMBER 0.97.0-dev, with the commands on the exercise page.

Answer key

The Finnish ventilation test. Yes: "OA rises with demand (DCV functioning)". CO₂ is 332 ppm higher when the supply is raised than when it sits at its floor, compared within the same hour of day (correlation 0.82, a diagnostic only).
Why a warn? The finding also reports outdoor air held above the floor at low demand in 100 % of low-CO₂ samples. The config's floor is the documented base flow, 3 l/s (6.36 cfm), but the room's measured base is 4 l/s (a documented data issue). The rule is reporting the gap between the documented law and the trend. That is the point of checking a sequence against its data, not a malfunction.
The training records. Both read "OA modulates, but not with demand" (info). They were run under assorted ventilation strategies, not a DCV law, so outdoor air moved for other reasons. CAMBER describes what the data show and does not call a non-DCV strategy a broken DCV.
Which CO₂ sensor? Room 917810 reads "functioning" on both sensors (lifts of 139 ppm on the building-system sensor and 326 ppm on the desk sensor). Room 999169 depends on the sensor: on its desk sensor it functions (a 212 ppm lift), on the building-system sensor "OA modulates, but not with demand" (a 12 ppm lift). The valve opens on a morning clock and on CO₂. Within each hour the clock cancels, and the remaining lift is only as good as the sensor.
Room 925038. Its valve column is an assumed constant in the published data, not a measurement, so it is not mapped. With no outdoor-air signal the DCV rule does not evaluate the room: no finding at all.
Over-ventilated and functioning? No contradiction. The rooms are occupied only a small share of the time, and the valve's 20 % minimum keeps CO₂ near outdoor in 73 to 86% of occupied hours (co2_ventilation warn on all five). DCV responds to demand. Whether the minimum is higher than the rooms need is a separate, energy question.
The Danish rooms. ROOM1, the lecture room, functions: a 181 ppm lift, correlation 0.89. ROOM2 and ROOM3 are "DCV not judged -- CO₂ never reached the level where DCV should respond" (reason demand_below_engage). The study zones never got busy enough to test the DCV. That is neither good nor bad news about the controls, only an absence of evidence. ROOM2 is also over-ventilated (CO₂ near outdoor in 66% of occupied hours).
Which sensor to trust? Check each sensor against outdoor air when the room is empty (does it settle near 400–450 ppm?), against the other sensor when the room is busy, and for location (a desk sensor sees the occupants, a return-air or duct sensor sees a mix). Calibrate or replace before re-tuning the sequence on it.

Discussion points

The minimum outdoor-air guide asks whether outdoor air is reduced when spaces are lightly occupied. These three datasets give a yes, a "depends on the sensor" and a "can't tell". A verification tool that never says "can't tell" is guessing.
Clock versus demand: a valve on a time clock correlates with occupancy because people also follow the clock. Taking the lift within the hour of day is what separates the two. Ask the class to predict what a pooled comparison would say for room 999169.
Return-air CO₂ averages the zones an air handler serves and dilutes the critical one, so a DCV verdict judged on an air handler's CO₂ carries a caveat saying so. Here each "unit" is a room (equipment class VAV) with its own sensor, and CAMBER leaves the caveat off. Ask the class what would change if the same data were mapped to one air handler instead.

Common mistakes

Treating "not judged" as a failed DCV and recommending repairs.
Reading the Finnish test's warn as a DCV fault. It is the base flow above the documented floor.
Trusting whichever sensor gives the answer you expected.
Reading "over-ventilated" as unsafe. It is an energy observation. Under-ventilation is the safety question, and no room here is under-ventilated.

`zone-min-oa`: minimum outdoor air and 62.1 system ventilation

Figures from the real lbnl-b59 default subset, CAMBER 0.98.0-dev, with the commands on the exercise page. The 62.1 procedure follows the public sources listed in VENTILATION.md (the free 62.1-2016 Addendum f and secondary sources); no standard text is quoted here.

Answer key

The requirement. The same Vot for each unit: 1,421 cfm. By hand: the breathing-zone outdoor air is 5 cfm/person × 63 + 0.06 cfm/ft² × 12,513 ft² ≈ 1,066 cfm. With no system population, D = 1, so the uncorrected intake is also about 1,066 cfm, and the simplified system efficiency for D ≥ 0.60 is 0.75. That gives 1,066 / 0.75 ≈ 1,421 cfm.
Measured, and the verdict. The flow stations read 5,558 to 7,479 cfm of outdoor air (median over occupied, fan-on hours from April 2020), ratio 3.91 to 5.26 against Vot. Every unit is over-ventilated (a conditioning-energy penalty).
Why a warn? Over-ventilation is a warn (an energy penalty, not a safety problem), and the severity is capped at warn anyway, because every input is assumed. The finding's caveats say three things. The requirement rests on assumed area and population. There is no system population, so D = 1, the most conservative case. And the topology lists CO₂ zones under each unit that carry no ventilation inputs, so Vot covers the listed zones only. Here the lumped zone already stands for the unit's whole share of the floor.
The zones' CO₂. co2_ventilation_system flags all 11 zones as over-ventilated: CO₂ near outdoor in nearly every non-economizer occupied hour, with zone medians of 419 to 429 ppm. Two independent measurements, flow and CO₂, say the same thing.
DCV. "DCV not judged" on all four units: the zones' CO₂ never varies enough to test whether outdoor air follows it (reason no_demand_variation). This building has no DCV, and CAMBER does not call it functioning. The specificity lesson: a checker that never refuses would have given it a verdict. The finding also says "supply fan off while scheduled occupied", for 41, 82, 40 and 40 h by unit: the October and December 2020 days when the fans did not run although the schedule says occupied (speed feedback a few percent). Those hours are the whole 2.0–4.2 % below the 750 cfm floor, so below_floor_pct, the shortfall with the fan running, is 0.0–0.1 % and the grade stays info (since 0.98). The 2020 smoke-mode weeks are not among them.
How wrong would the inputs have to be? To read "adequate" (a ratio of 1.5 or less), Vot would have to be about 2.6 to 3.5 times larger. That means roughly three times the assumed population or floor area. Neither is plausible for this office. Giving a system population goes the other way: with Ps = 32 per unit, D ≈ 0.51, Ev ≈ 0.67 and Vot falls slightly, to 1,366 cfm. The ratios become 4.07 to 5.48, so the verdict does not change.
Before lowering the minimum. Ask for the design ventilation schedule (zone areas, populations, space types), confirmation of the flow stations' calibration, the unit's minimum damper setting and how it maps to flow, the minimum at part-load fan speed, and the wildfire-smoke and pandemic operating modes the owner wants to keep. Lower the setpoint in steps and verify with the zone CO₂.

Discussion points

The minimum outdoor-air guide's point, that a minimum set above what the building needs costs heating and cooling all year, shows clearly here. This is also where assumptions must be written down: the config's _comment and the finding's caveats are part of the answer.
System versus zone: judged against one zone's requirement, a multiple-zone unit looks over-ventilated too easily. The system procedure (Vou, D, Ev) is what applies to an air handler serving many zones. Walk through why D and Ev move in opposite directions.
2020 was not a normal year (shelter-in-place, wildfire smoke). Discuss whether the measured flows represent the building's normal minimum.

Common mistakes

Presenting the ratio as a compliance finding. The inputs are assumptions, and CAMBER caps the severity to say so.
Using the unit's 20,000 cfm design supply, or the descriptor's 5,000 cfm design minimum, as the 62.1 requirement.
Reading the DCV "not judged" as a DCV fault in a building that has no DCV.
Lowering the minimum on the strength of the CO₂ readings alone, without the design schedule.

Central plant

`plant-chiller-efficiency`: Chiller efficiency and fouling

Figures from the real lbnl-chiller full subset, CAMBER 0.97.0-dev, with the commands on the exercise page.

Answer key

Generic ceiling. chiller_efficiency is a fault on PLANT__fault_free: its median 1.44 kW/ton against the rule's generic 0.85 is 1.7 times the ceiling. Every run is flagged except the two chiller-sensor biases that read low. The score gives TPR 100% and FPR 85% (11 of the 13 negatives). A detector that fires on the healthy plant tells you nothing about the faulted ones: it catches everything by flagging everything.
Calibrated ceiling. The dataset template's 1.44 kW/ton is the fault-free run's own median, so the healthy chiller reads 1.44 kW/ton and is ok (17.7% of its loaded hours are more than 15 % above the ceiling). The simulated chiller's design curve is not published; its own healthy operation is the only honest reference, as a commissioning agent would set it.
Chiller fouling. The severe run (_065) reads 2.36 kW/ton, a fault (1.6 times the ceiling); the mild one (_095) reads 1.53, about 6 % above the ceiling, ok because the warn band starts at 1.2 times. The milder fouling still shows in pct_hours_inefficient: 33.3% of its loaded hours, against 17.7% for the fault-free chiller.
Other runs. All five tower-bypass runs are faults (2.47 to 3.02 kW/ton; the stuck-75 % run reads 3.02 at a median load of only 7 tons). The worst tower fouling barely moves the chiller: 1.47 kW/ton, ok. A controlled tower holds its leaving water by working its fan harder, so the chiller hardly notices: look at the tower's fan effort (plant-cooling-tower).
Label score. chiller_efficiency scores TPR 55% (6 of 11: the five bypass runs and the severe chiller fouling) and FPR 15% (2 of 13): the false alarms are PLANT__chiller_bias_1 (warn) and PLANT__chiller_bias_2 (fault), a chiller whose leaving-water sensor reads high. Missed: the milder chiller fouling, the three tower foulings and the tower PI mistuning.

Discussion points

Where does a design ceiling come from on a real plant? The chiller schedule gives kW/ton at design and part load; commissioning records give the healthy baseline. A generic number (0.85 kW/ton here) is a guess about a machine you have not looked at.
Calibrating on the fault-free run assumes it is healthy. On a real plant you rarely have a labelled healthy year; discuss how you would establish one (a post-commissioning period, a manufacturer's curve, a sister machine).
The PNNL cooling guide judges the plant by its controls, not by kW/ton. kW/ton tells you that energy is being lost; the control questions tell you where. Bring the reset and pumping exercise in here.

Common mistakes

Tuning the ceiling until the faulted runs light up and the healthy one does not, then quoting the score as if the ceiling had been set independently. The ceiling here is set from the fault-free run alone.
Reading the 6 % rise of the mild chiller fouling as "no fault". The severity is ok; the metrics are not.
Reading the chiller-bias alarms as detections. The chiller is healthy; the sensor lies (see plant-sensor-vs-equipment).
Concluding that tower fouling is harmless because the chiller's kW/ton barely moves: the cost moved to the tower fan.

`plant-cooling-tower`: Cooling tower: approach and fan effort

Figures from the real lbnl-chiller full subset, CAMBER 0.97.0-dev (the fan-effort drift: CAMBER 0.98.0-dev), with the commands on the exercise page.

Answer key

The healthy tower. A median approach of 8.1 °F over the 483 hours its fan ran at 90 % or more: ok. That is the calibration point of the dataset template's 8.1 °F design approach, so it is ok by construction; 0.2% of those hours are more than 3 °F above it.
The 65 % fouled tower is not flagged. Its approach at high fan is 9.4 °F, 1.16 times the design approach, below the 1.3 times where a warn starts. The fouling does show in the share of high-approach hours: 20.4% against 0.2%.
Fan effort. The fouled tower's fan ran at 90 % or more for 1,617 hours, against 483 for the healthy one: about 3.3 times as long. A tower controlled to a leaving-water setpoint keeps its approach and pays for fouling in fan energy. The milder foulings follow the same order (the 80 % run: 8.4 °F, 1,169 hours; the 95 % run: 8.2 °F, 577 hours).
Condenser-water reset. Yes: condenser_water_reset is ok with a slope of 0.93 °F of condenser-water supply per °F of wet-bulb over the operating hours. The simulated controller holds the tower's water at the wet-bulb plus a fixed offset, with a 60 °F floor.
The stuck bypass. condenser_bypass_leak is a fault on all five bypass runs, attributed to the valve: with the bypass commanded shut, the water entering the chillers is +62.2 °F warmer than the water leaving the tower (median, stuck-75 % run). The approach rule declines (info) on the bypass runs because the tower fan never reaches 90 % (a peak of 51 % in the stuck-75 % run): with the water going around it, the tower has little heat to reject. The chiller pays instead (plant-chiller-efficiency).
Label score and fan effort. cooling_tower_approach scores TPR 0% and FPR 0 %: it finds none of its four targets (the three tower foulings and the PI mistuning, on which it declines because the fan never reaches 90 %). cooling_tower_fan_effort_drift measures what answer 3 read by hand: the fan speed at matched condenser range and wet-bulb, here against the declared reference PLANT__fault_free. It is a fault on the 65 % and 80 % foulings (+17.8 and +10.9 fan %-points) and ok on the 95 % one (+3.3, under its 5-point floor): TPR 67% on its target, tower fouling, and FPR 0 %, with no alarm on the other 20 runs. The fault-free run declines as is_reference (it is the yardstick; the scorer still counts it as a correct negative, so the false-positive count reads 0 of 21). The +1 and +2 °F tower-sensor biases also push the fans harder (+29 and +48 points), but the tower's leaving-water reading moved with them (+1.6 and +3.5 °F), so the rule reports a sensor offset (info), not fouling.

Discussion points

"The approach looks fine" is not "the tower is fine". Ask what the controller holds constant; the fault shows in whatever it spends to do so.
Why judge the approach only at high fan? In mild weather the controller chooses to leave warmer water (the 60 °F floor), and a high approach then is correct control.
The bypass is a textbook case of a fault invisible to the equipment's own controls: the tower holds its setpoint, the valve reads shut, and the chillers get the hot water. Only a sensor downstream of the mixing point sees it.
The simulated bypass runs drive the condenser loop to temperatures a real chiller would trip on (the catalog's data issue). Discuss what a real plant would show instead (high-pressure trips, alarms).
On the bypass runs cooling_tower_fan_effort_drift reads hundreds of fan %-points below the reference (about -390 to -470), which no fan can do. The bypassed loop runs condenser ranges the reference never saw, so the matched-load model extrapolates: read it as "not comparable", not as a healthier tower. condenser_bypass_leak is the rule for those runs.

Common mistakes

Reading the fouled tower's ok as healthy without comparing its metrics with the fault-free run's.
Reading info (declined) on the bypass runs as ok.
Treating the bypassed-fraction estimate as the leak size: in these runs it does not follow the severities in the file names (it is fixed at 0.92, 0.97 and 0.99 for the 25, 50 and 75 % runs).
Counting the two 75 % runs as two detections: in both the valve command reads zero all year and the condenser side is the same data, so they are one case.
Lowering the design approach until the fouled tower is flagged, and not checking what else gets flagged with it.
Reading the reference's info decline as a missing result, or comparing a real plant's tower with another tower that was never shown to be healthy: a reference is only as good as the evidence that it is clean.

`plant-chw-reset-pumping`: Chilled-water reset and pumping

Figures from the real lbnl-chiller default subset, CAMBER 0.98.0-dev, with the commands on the exercise page.

Answer key

Reset. Yes: chwst_reset_present is true and chwst_reset_direction is expected, with a slope of -0.38 °F of supply per °F of outdoor dry-bulb (median supply 47.6 °F over the running, occupied hours). The supply gets warmer in cool weather and colder in hot weather, which is the direction the rule expects (expected_reset_sign: negative). A slope the other way would not count as a reset.
Low delta-T. Chiller 1's loop delta-T has a median of 6.4 °F, and 80.1% of its running hours are below the rule's 8 °F minimum. Yet chw_plant_reset is ok on the healthy plant: the rule reads the chiller's flow, finds it constant (flow_mode: constant, a coefficient of variation of about 0.1 %), and reports the delta-T without judging it, with a caveat. A constant primary flow does not follow the load, so the chiller's delta-T is low at part load by design: a property of this plant, and a design question (variable primary flow, a higher supply setpoint in mild weather), not a broken component. On a variable-flow plant the same figures would count, against design_deltaT_min_f (8 °F unless set from the loop's design).
DP reset and pumping. No: the DP setpoint is flat (dp_sp_reset_present false, the same value all year). The secondary pump runs at a median 84.9% and at 90 % or more in 38.0% of its hours: a warn for riding the curve.
VFD minimum. The pump's floor is 34.5%: the rule learns it from the speeds (vfd_floor_pct, near_min_source: learned) and counts 31.3% of the fault-free run's hours at or near it (the band is the floor plus a point, 35.5 %). The pump also runs all year, with no cooling load in winter. On the chiller-bias run the pump idles at its floor (a median of 34.5%) for 68.6% of its hours, a warn for sitting at the minimum.
Stuck bypass. The plant cannot make chilled water: the supply median is 65.0 °F and the delta-T 0.7 °F, and the pump runs at a median 100%. The supply warms as the weather warms, a slope of +0.76 °F per °F, the reverse of a reset: chw_plant_reset is a warn with chwst_reset_direction: reverse (its low delta-T is not judged on this constant-flow plant). That warn and chw_pump_dp_reset (a warn) are both symptoms; the cause is the tower bypass, which only condenser_bypass_leak names (plant-cooling-tower).

Discussion points

Map the three answers onto the PNNL cooling guide's three questions. The guide's low-delta-T test uses the same 8 °F line; discuss why it does not fit a constant-flow primary loop, and what the rule does instead.
Why does a flat DP setpoint cost energy? Pump power goes roughly with the cube of speed, so the hours near full speed dominate the bill.
A plant whose pump idles at a floor all winter is a scheduling question: can the loop be shut down, or the floor lowered?
The stuck bypass shows how one fault fans out into symptoms on every loop. Ask which finding a technician should act on first.

Common mistakes

Fixing the low delta-T by chasing a broken part: nothing is broken; the plant is designed that way.
Reading the ok on the healthy plant as "the delta-T is fine": it is low, and the rule says why it does not judge it.
Reading the bypassed plant's positive slope as a working reset: it is the plant losing its chilled water in hot weather.
Blaming the pump for the bypassed plant: it runs flat out because the chilled water is warm.

`plant-boiler`: Boiler plant

Figures from the real lbnl-boiler full subset, CAMBER 0.97.0-dev (the firing rules and the boiler efficiency drift: CAMBER 0.98.0-dev), with the commands on the exercise page.

Answer key

Which rules run. All four point-in-time rules, on every run: 68 findings, 17 per rule, all ok (the boiler drift family's findings come on top; see answer 4). boiler_summer_lockout, boiler_short_cycle and hw_plant_deltat need to know when the boiler fired. The plant's status point is the boiler enable, on all year even while the boiler burns no gas, so the catalog leaves it unmapped. The three rules accept either a run status or the boiler's gas input, and here they read firing from boiler 1's gas input (above 5 % of its own 95th percentile): each of their findings carries run_source gas and a caveat that says so. The fault-free boiler fires in 37.8% of the hours, with 0.92 starts a day; the hourly trend hides any firing shorter than an hour, so the start count is a floor. Before CAMBER 0.98 the three rules printed nothing here, and the RCx report listed them under "Checks not evaluated"; that table is now gone.
Reset and summer lockout. The lockout is judged: the fault-free boiler spends 0% of its firing hours above the 65 °F lockout (0.35% on PLANT__boiler_PI; occupied hours), so ok. The reset is judged too, from the supply temperature against the outdoor temperature over firing hours: hws_reset_present is false on every run (a flat supply), which the rule reports in its summary without raising the severity. There is no supply-temperature setpoint to compare with. The trend viewer shows the same: the loop supply flat all year, and boiler 1's gas input falling to nearly zero in warm weather while the plant stays enabled and pump 1 keeps running.
Pumping. hw_pump_dp_reset is ok: a median speed of 29.0%, almost no hours near full speed, none near the 25 % minimum band, so neither riding the curve nor pinned at minimum. What the ok leaves out: the DP setpoint is flat (dp_sp_reset_present false), and the pump ran in 8,759 hours, every hour of the year, summer included.
Fouling. No point-in-time rule fires on PLANT__boiler_foul_065: the pump and the three gas-read firing rules are all ok. The loop delta-T holds its 36.0 °F median; only 12.2% of firing hours fall below the 20 °F design floor, under the 20 % warn line. Fouling shows as more gas for the same heat, and no point-in-time rule here compares the two. boiler_efficiency_drift does, against the declared reference PLANT__fault_free: gas input per unit of heat delivered is +53.7% on the 65 % fouling and +24.9% on the 80 % one (both fault), and +5.1% on the 95 % one (warn; it clears the 5 % warn floor by 0.1 point, so a slightly different reference period could miss it). The +2 and +4 °F hot-water temperature biases raise the ratio too (+11 % and +25 %), but the gas at matched outdoor temperature did not rise: the rule reports a heat-metering problem (info), not fouling. The fault-free run declines as is_reference.
DP sensor bias. A DP sensor reading 20 % high makes the pump slow to a median 26.4%, and one reading 20 % low speeds it up to 32.4% (29.0% healthy), while the DP reading itself stays at its setpoint: the controller holds the lying reading there. The rule stays ok on both. The label score for boiler_efficiency_drift is TPR 100% (3 of 3 foulings) and FPR 0 %: none of the other 13 runs fire (the scorer still counts the reference as a correct negative, so the false-positive count reads 0 of 14). Nothing else in this config detects any of the 16 faults.

Discussion points

The heating guide asks the same three questions as the cooling guide (reset, delta-T, DP reset), plus a summer shutdown. Which could a technician answer from this plant's trends, and which need a point it does not have?
An enable is not a run status. The gas input stands in for one here; ask what trend you would add on a real plant (burner firing, flame signal, gas valve) to count short firings the hourly gas trend cannot see.
A pump that runs all summer for a boiler that does not fire is a scheduling opportunity even though every rule says ok.

Common mistakes

Reading a short-cycle ok from the gas input as proof of long firings: sub-hour cycles are invisible on an hourly trend.
Mapping the enable point as the boiler status to make the rules run: every idle hour would then count as firing.
Reading the pump's ok as "nothing to re-tune": the flat DP setpoint and the all-year running are both opportunities.
Expecting a temperature rule to see boiler fouling: the supply temperature is held at setpoint whatever the boiler's condition.

`plant-lockout`: Heating plant lockout

Figures from the synthetic synthetic-hw-plant-lockout entry (generated by CAMBER, so every copy gives the same numbers), CAMBER 0.103.0-dev, with the commands on the exercise page. How the four plants were built: one weather series (eight weeks from early May, a warm spell in late May and early June) drives four plants whose outdoor-air enable switches off above their lockout and back on 3 °F below it. While enabled, the boiler fires when the building needs heat (below 55 °F, a morning warm-up, and zones reheating in occupied hours) and the pump runs. PLANT__locked_out locks out at 65 °F; PLANT__warm_spell does too, but its lockout is overridden through the warm spell; PLANT__pump_left_on locks the boiler out at 65 °F but its pump runs every hour; PLANT__low_lockout locks out at 58 °F.

Answer key

At 65 °F. PLANT__locked_out and PLANT__low_lockout pass both rules (ok, 0 % of their running hours above the lockout). PLANT__warm_spell faults on both: the boiler fires in 34.62% of its occupied firing hours above 65 °F, the pump runs in 39.53% of its running hours above it. PLANT__pump_left_on passes boiler_summer_lockout and faults on hw_pump_summer_lockout (70.45%).
The pump on its own. On PLANT__pump_left_on the pump runs in every occupied hour, and the boiler is off in 100% of the pump's hours above the lockout (boiler_off_pct): the pump was left running (in hand, overridden, or on a schedule) after the boiler was locked out. The boiler's check reads firing only, so it cannot see a pump. On the warm-spell plant the boiler was off in 36.47% of the pump's warm hours: the plant was enabled, the pump ran with it, and the boiler fired only when something called for heat. The RCx report groups that plant's two findings into one issue, the boiler first, since one lockout fixes both.
Score. Both rules score TPR 100% and FPR 0 % on the four plants: the boiler rule catches the one plant labelled boiler_not_locked_out and passes the other three (the pump-left-on plant is not a boiler fault); the pump rule catches both labelled plants (the warm spell counts for the pump too) and passes the two healthy ones. Four plants is a tiny sample: the 95 % intervals are wide.
At 58 °F. Set on boiler_summer_lockout only; the pump rule judges at 58 °F too (its lockout_oat_f is 58, its param_basis says "inherited from boiler_summer_lockout in this config"). Now the two plants that lock out at 65 °F fail the boiler rule: PLANT__locked_out fires in 65.22% of its firing hours above 58 °F, a fault, though it behaves exactly as its own sequence says. PLANT__low_lockout still passes both rules: it stops firing at 58.0 °F, so its own lockout is about 58 °F.
At 75 °F and where each plant stops. The warm-spell boiler drops to a warn (17.95%): a higher lockout hides most of the warm spell. The pump still faults on the warm-spell and the pump-left-on plants. The warmest firing hour (max_oat_running_f on the boiler finding) is 64.7 °F on PLANT__locked_out, 64.8 °F on PLANT__pump_left_on, 58.0 °F on PLANT__low_lockout and 79.9 °F on PLANT__warm_spell. Choose the lockout from the site's own sequence of operations, or from the outdoor temperature above which no zone called for heat in a known-good season, never from the default; then set it once on boiler_summer_lockout.

Discussion points

The same plant passes or fails depending on one number. Who owns that number on a real site, and where is it written down?
Is a pump running all summer always a fault? Discuss dehumidification reheat, domestic hot water and freeze protection, and what each would do to the lockout.
Both rules judge occupied hours only. What would a pump running every night add, and how would you see it?

Common mistakes

Reading the boiler's ok on PLANT__pump_left_on as "the plant is locked out".
Lowering the lockout until a plant fails and calling it a fault: at 58 °F the plant that locks out at 65 °F "fails" while doing what its sequence says.
Citing these figures as evidence about real plants: the data are synthetic.

`plant-sensor-vs-equipment`: Plant sensor faults vs equipment faults

Figures from the real lbnl-chiller full subset, CAMBER 0.97.0-dev, with the commands on the exercise page.

Answer key

The chiller's leaving-water sensor. Reading 2 °C high, the chiller reads 3.19 kW/ton, a fault (1 °C high: 2.13, a warn). Reading 2 °C low it reads 0.67 kW/ton, far better than the healthy chiller's 1.44, ok. Neither chiller changed. The controller holds the lying sensor at setpoint, so the real water is colder (or warmer) than it reads; the chiller works harder (or less), and the tons CAMBER computes from the biased temperature are wrong as well. A kW/ton better than the healthy machine's is itself a clue.
Where the low-reading sensor also shows. In the secondary pump: chw_pump_dp_reset is a fault on the 2 °C-low run, with the pump at 90 % or more in 82.1% of its hours (a median of 100 %). The real chilled water is warmer, so the air handlers' valves open wider and the pump works harder to hold the loop DP. The high-reading runs do the opposite: the pump idles at its 34.5 % VFD floor for most of its hours, a warn for sitting at the minimum (0.98 learns the floor; before, the rule's 25 % band missed it).
Tower sensor vs bypass. condenser_bypass_leak reports both ±2 °C tower-sensor biases as info with attribution: sensor_offset: the water entering the chillers reads -3.1 °F and +3.6 °F from the tower's leaving water, and the difference stays the same at every load. Warm return water leaking through a bypass would grow with the condenser range, as it does on PLANT__bypass_stuck_075, a fault attributed to the valve. (Reading colder than the tower's leaving water is impossible for mixing, which settles the -3.1 °F case.) The ±1 °C biases stay under the rule's 2 °F threshold (ok).
The loop DP sensor. Not in the DP reading, which the controller holds at setpoint. It shows in the pump speed: a sensor reading 20 % high lets the pump slow to a median 74.4% (ok), one reading 20 % low drives it to 97.0% (a warn), against 84.9 % healthy.
Score. chiller_efficiency scores FPR 15% (the 1 °C- and 2 °C-high chiller-sensor runs, 2 of 13 negatives); cooling_tower_approach scores FPR 0%. The labels are right to count these as false alarms: the chiller is healthy, and a technician sent to it would find nothing wrong. The right work order is "calibrate the sensor", and a detector that cannot tell the two apart sends the wrong trade.

Discussion points

"Treat a sensor bias as a negative" is a statement about the equipment rule, not about the sensor. The sensor fault is real and worth finding; it needs its own detector (a comparison with an independent reference), and condenser_bypass_leak shows one way to separate the two.
Controlled variables hide their own sensor's bias: the reading sits at setpoint, and the error moves to whatever the controller drives (the chiller's lift, the pump speed).
Ask which PNNL-guide conclusions from the other exercises would flip if one sensor were off by 2 °C.

Common mistakes

Counting the chiller-bias alarms as detections because "something was wrong".
Trusting a suspiciously good kW/ton (0.67 here) as good news.
Reading the tower-bias info as ok: it names a problem, just not the valve.
Looking for a DP sensor bias in the DP trend, which looks perfect.

Data quality, energy charting, M&V and the capstone

`data-trend-quality`: are the trends good enough?

Figures from the real nuig-ahu101, lbnl-b59 and irish-ahu default subsets, CAMBER 0.97.0-dev (the clipped, schedule, stray-row and per-mode figures 0.98.0-dev), with the commands on the exercise page. Trust scores are the RCx reports' (hourly, gated on the unit's fan signal; for a unit with no fan point, read per its inferred operating mode).

Answer key

Which core points does each unit not trend? AHU101__ahu101 has no mixed-air temperature and no outdoor-air damper (it is a 100 % outdoor-air unit: nothing to mix) and no duct static or static setpoint. RTU01 has no cooling or heating valve and no duct static or setpoint; its fan point is a speed, not a status. AHU__ahu has no supply-air setpoint, no duct static or setpoint and no fan point at all, so its trust table is ungated. B59's outdoor-air flow is flagged late_start: it starts on 2020-04-10. Earlier values were the publisher's gap fill, which the ingest masks.
The copy. RTU04's return air carries its supply-air data (copied_signal). CAMBER blames the point that jumps across the gap to the other's level at the stretch's edges: the return air suddenly reads supply-air temperatures, while the supply air keeps measuring supply air. The return air drops to suspect at 0.56; the supply air keeps its score.
Mixing balance. RTU01 and RTU02's mixed-air sensors fail the flow-weighted balance and are capped at suspect 0.75; RTU03 and RTU04 pass. The balance rests on flow stations of unknown accuracy and cannot say which of mixed, outdoor or return is wrong, so it is screening-grade: it can make a point suspect, never untrusted on its own.
The ceiling. The room CO2 tops out at the sensor's full scale, just under 2000 ppm; 532 stored 15-minute samples read it, and every one has the supply fan off. It is a clipped reading, a lower bound, not a measurement. The trust table names it: the CO2 point carries the clipped flag, and SensorTrust.clipped gives the limit (2,000 ppm, high side) and the share of those samples with the fan off (1.0). The flag carries no trust penalty; the ingest's quirk note and the dataset's data issues say the same.
The held meter. ELE_lig_S holds one value for 32.25 h and 36.5 h, both runs starting on a Saturday. A lighting load parked at its base over a weekend is plausible; a logger holding its last value is too. The flag says "look", and the trend viewer (does anything else move in those hours?) or the site settles it.
Filled or not. RTU01_zone_022's CO2 has two 30-day windows of continuous values (every value unique) from 2020-04-26, between windows that repeat the sensor's resolution: a filled stretch, which the publisher's README says exists (gaps filled by interpolation and other methods). The nuig fan status repeats whole days too, and the screen now says why: passed the role (or seeing a series on two levels), it reports that 191 days follow a fixed schedule (whole days sharing a pattern with two or more others) instead of calling them fills. Three repeats that no shared pattern explains still warn (two weekend pairs in March and May 2018, and two weekdays in May 2018): look at them in the trend viewer, but a schedule override that ran twice is the likely story.
The irish supply air. Two things used to make it untrusted (0.19 in CAMBER 0.97), and both are now handled. A few stray rows logged years before the rest, then a long gap, made its coverage over its own span low: CAMBER now flags stray_lead and judges the point from the first sample after the gap (2017-06-23), leaving the 4 stray rows out. And a supply air held tightly at setpoint made every hour spent idle look like a robust outlier: the unit has no fan point, so the RCx table infers an off-mode (OA damper and coil valves closed) and reads the outliers per mode. The RCx gated column reads trusted at 0.89 (stray_lead, no outliers). The plain one-population read, sensor_trust on the series alone, still reads untrusted at 0.27 with outliers: it does not know the operating modes. The sensor is fine; the plain verdict described the control, not a fault.

Discussion points

The trending guide's question is "can the data answer the re-tuning questions?", not "is every point perfect?". A unit with no fan point (irish-ahu) can still be analysed, but every gated check runs ungated, and the report says so.
Tie each flag to a physical story before acting: a copy is a mapping or programming error (fix the BAS), a failed balance is a sensor location or calibration issue (a walk-down item), a clipped reading is a sensor range limit (change the sensor or accept a lower bound).
CAMBER already corrected some data at ingest; show camber datasets info irish-ahu and the --no-corrections option, and discuss why corrections must be recorded, not silent.

Common mistakes

Reading suspect as "broken": it means "verify before relying on it".
Treating the nuig fan status's repeated days as fabricated data, or the 3 unexplained repeats as proof of a fill.
Concluding the irish supply-air sensor must be replaced because its plain sensor_trust score is 0.27: read it per operating mode first.
Running gapfill_signature on an hourly resample: the means erase the granularity signature.
Counting a fan speed as missing: CAMBER uses it as the fan-on gate when no status exists.

`data-energy-charting`: energy charting

Figures from the real bdg2 (site Fox) and valladolid-uva default subsets, calendar 2016, CAMBER 0.97.0-dev, with the commands on the exercise page.

Answer key

Weekends. Both university buildings drop: UVA_A's weekend peak (mean load by hour of day) is only 0.45 of its weekday peak, and UVA_B's falls further. The assembly building Fox_assembly_Audrey__electricity does not drop: its weekend profile matches its weekday one.
Out-of-hours load. baseload_anomaly calls the assembly building (0.90) and the lodging building (1.04) a fault, and both Valladolid buildings ok (UVA_A 0.56). The lodging's ratio above 1 is right: people sleep there, so its "unoccupied" hours are occupied, and the default weekday 07:00-18:00 window does not fit it. The assembly building's is the one to question: a building that runs its night and weekend load at nearly its daytime level is the first thing PNNL's scheduling guide asks about.
Flatness. The lodging building: load factor 0.59 against UVA_B's 0.31, and a base load (5th percentile) of 0.41 of its peak against 0.085. A flat, high base is normal for lodging and a warning sign for an office or classroom building.
Weather. The lodging's chilled water picks a cooling-only change point (3PC) and the weather explains most of its daily variation (R² 0.86); it meets the G14 tier. The same building's electricity barely follows the weather (R² 0.32) and fails it.
UVA_A's all-days model. R² 0.12, CV(RMSE) 26.1%. Its profile shows why: weekdays and weekends (and holidays and academic breaks) are different loads at the same temperature, so a temperature-only model scatters. A day-type driver is missing, which mv-baselines adds.

Discussion points

The metrics are only as good as the occupied window: ask each group to set start_hour / end_hour to what they believe for each building and rerun baseload_anomaly.
An "ok" out-of-hours ratio of 0.56 still means more than half the daytime load runs all night; compare it with what should be on at 03:00.
Weather dependence says which meters a weather-normalized M&V baseline suits: chilled water here, not the lodging's electricity.

Common mistakes

Calling the lodging's ratio above 1 a scheduling fault.
Reading a high R² as "a good model" without the CV(RMSE), or a low R² as "a bad meter".
Comparing peaks across buildings without normalizing (each ratio is within one building).
Using the hour of the peak from a meter whose clock is in doubt; check the data issues first.

`mv-baselines`: change-point baselines and M&V

Figures from the real cofactor-drammen, valladolid-uva and bdg2 default subsets, CAMBER 0.97.0-dev, with the commands on the exercise page. The bills are synthetic, cut from the open BDG2 meters.

Answer key

The 2018 baselines. b6400_ElImp (school) and b6410_ElImp (nursing home) meet CAMBER's G14 gate. b6404_ElImp does not: its CV(RMSE) of 22.5% is within the daily tier, but its R² of 0.72 is under the 0.75 CAMBER requires. SEP §6.4.1 rejects the same model for another reason: its cooling slope has the wrong sign (the logical-sign test), so its SEnPI is not reportable under validity: both.
The unexplained saving. The school b6400_ElImp uses 5.8% less in 2019 than its 2018 model predicts, with a 90 % band of 24,051 on the saving: outside the band. The backcast agrees (5.1%). No measure is documented, so before reporting it, find the cause: an operating change, a sub-meter moved, an occupancy change. A saving nobody can explain is a non-routine question, not a result.
The nursing home. 0.8%, well inside its band: no change.
The chain. UVA_B (the faculty whose publisher describes an equipment replacement) shows a chained saving of 12.6% over 2016-2018; UVA_A, -0.1%, none. Neither 2016 baseline meets the G14 gate (R² 0.66 and 0.55, under 0.75), though both pass SEP's R² test (0.50 or more), so the savings are "for information only". The chain leaves the academic breaks (July and August, Christmas, Easter) unmodelled: the occupied-day driver knows public holidays only.
The closure. Unadjusted, b6400_ElImp's 2020 chained saving is -0.9%, which looks like "no change". The closure indicator is material and negative: the school used much less while it was shut, which hid the rest of the year. Adjusted, the saving is -8.1%: outside the closure the school used more than the model expects (plausibly, more ventilation after reopening). The unadjusted figure misleads because two opposite effects cancel.
Chilled-water bills. 10 bills make the 2016 baseline (a bill straddling New Year belongs to neither year, and a bill with a missing day is dropped), and the bills choose a 63 F cooling base. R² 0.90, but CV(RMSE) 22.7% fails the monthly 15 % tier: a high R² on a load that swings from almost nothing in winter to a large summer load says the shape is right, while the monthly scatter is still too large for a savings claim. The caveats add that the base is poorly determined and the baseline covers less than a year.
Electricity bills. R² 0.48: under SEP's 0.50, so weather explains little of the variation (the lodging's load follows its occupancy); the model is not SEP-valid, and the forecast band spans zero. Bills alone cannot measure a saving on this meter.

Discussion points

The order matters: method first, then adjustments, then the result (see the M&V page). Ask which method each group would declare before they saw any saving.
G14 acceptance and SEP validity answer different questions (can this model support a savings claim? is this model statistically valid?), and they can disagree in both directions.
Non-routine events need evidence and approval under SEP §5.3.2; point to the ledger entry's evidence and approved_by fields, and to IPMVP's caution on meter-derived adjustments.
Bills are the only data many buildings have. Discuss what a sub-meter or trend data would add.

Common mistakes

Reporting the 5.8% as a re-tuning saving.
Reading the unadjusted -0.9% as "the school did not change".
Treating R² as the only acceptance criterion, or ignoring CV(RMSE) because R² is high.
Forgetting that the bills are synthetic, or presenting them as real utility bills.
Comparing forecast and backcast percentages without their bands.

`capstone`: RCx report, walk-down, re-tuning plan and verification

Figures from the real lbnl-sdahu and ornl-frp-ops default subsets, CAMBER 0.97.0-dev (the damper issue's cause, the M&V data need and the Verify on site section: 0.98.0-dev; the free-cooling figures, the ranking and the walk-down rows with the economizer low limit in the config, uncosted issues ranked by confidence, and free_cooling_missed judging fan-on hours only (#120): 0.102.0-dev), with the commands on the exercise page. The RCx report is the one written before the drift baselines are frozen. The config sets free_cooling_missed's economizer low-limit lockout at the documented 33.8 °F, as learners did in step 5 of air-economizer, so neither unit's cold-weather hours at the damper minimum count as missed free cooling.

Answer key

The top issue. Rank 1 is headed "Outdoor-air damper not modulating (stuck low)", on AHU__onset_damper_stuck_025, a fault with confidence H: the only fault and the only high-confidence issue in the report. No issue here has a cost (the config gives no equipment sizing), so no dollars separate them. The report ranks by severity first, so the damper fault leads the warns. Within one severity it puts unconditional issues before conditional ones and costed before uncosted, by cost; uncosted issues then rank by confidence, H before M before L, and only then by the issue key, a fixed tie-break. That is why the onset unit's supply-air reset and the control's static-pressure reset, uncosted warns at confidence M, follow. Rank here is not a measure of size: the drift check of question 5 is what confirms the damper. The heading names the cause; the recommended action is "Repair the outdoor-air damper or actuator": stroke the damper from the BAS and watch the blades, the linkage and the actuator before changing any economizer logic. The finding tells the two causes apart by setting the command against the temperatures. On 90% of the missed free-cooling hours with a usable temperature balance (640 h), the damper was commanded at least 90 % open, yet the outdoor-air fraction from the mixed-air temperature stayed near 4 % (missed_cause: damper_not_delivering, commanded_open_pct 90.3). On the fault-free control, the damper was commanded low on its few missed hours (economizer_not_commanded, 0 %), and the control has no economizer issue at all. "Stuck low" is inferred from the mixed-air temperature, and a badly placed mixed-air sensor reads the same way. That is why the walk-down confirms it.
Missed free cooling. With the 33.8 °F low limit, the onset unit ran mechanical cooling in 42% of the free-cooling hours (outdoor air between 33.8 °F and 60 °F, supply fan running), a fault, against 3.6% for the fault-free control (ok). The rule judges only hours with the fan on: with the fan off nothing moves across the coil and there is nothing to economize. The share is over the whole year, and the damper stuck only from 1 July, so six healthy months still dilute it; it is a fault all the same. A damper stuck at 25 % admits about as much outdoor air in cooling weather as the unit's small design minimum, so the outdoor-air-fraction rules see nothing to object to. Before 0.102 the rule also counted the fan-off nights and weekends, which diluted both shares to about half: 21 % (a warn) and 2.0 %. Without the low limit the figures are 61 % and 34 %, a fault on both units: most of the control's missed hours are cold-weather hours at the damper minimum, by design.
The conditional issue. The onset unit's static-pressure reset issue is conditional on duct_static_sp (trust 0.40): in the faulted half of the splice the published setpoint is a placeholder that the ingest masks, so half the year has no setpoint. Walk-down item: read the static setpoint at the controller and confirm what the trend is mapped to.
Walk-down checklist and re-tuning plan (a model answer; accept any that covers the evidence). The report's Verify on site section is the generated version: its sensor table leads with the onset unit's duct_static_sp (trust 0.40, untrusted), then the equipment table lists each issue's item in rank order: first, on issue 1, the onset unit's damper (look at the blades, linkage and actuator while the BAS strokes it; confirms if the blades stay near one position at a 100 % command; refutes if they travel fully, and then the mixed-air sensor is the suspect), then the supply-air and static-reset logic of both units. With the low limit the control has no economizer item. It lists no design values: the economizer's minimum outdoor air (1.6 %), 60 °F high limit and 33.8 °F low limit are site parameters in this config, not rule defaults. The "rule defaults" confidence lines belong to supply_air_reset and static_pressure_reset, whose parameters are detection thresholds, not site facts. A student's list should match the generated one and add what a template cannot know:
Outdoor-air damper on the onset unit: stroke it from the BAS through its range, watch the blades and the linkage, and compare the mixed-air temperature with the command. Expect: the blades stay near a quarter open. Confirm the economizer enable logic, the 60 °F high limit and the 33.8 °F low-limit lockout in the program.
Static-pressure setpoint point: confirm the trend mapping and the value at the controller.
Design values worth confirming anyway, from the drawings or the controller: the minimum outdoor-air position, the supply-air setpoint and the static setpoint.
The plan, sensors first: fix the static-setpoint trend; repair the damper actuator or linkage; then consider the sequence changes the report suggests (supply-air reset, static-pressure reset) as separate measures with their own verification. Verification: the frozen drift baseline for the damper (the economizer signal should return to steady), and free_cooling_missed back to the control's level.
Drift. The onset unit reads fault, locus outdoor-air: at matched damper command it delivers 83 percentage points less outdoor air than in the first half (a drift of -83). The control reads ok, steady. After the repair, keep the same frozen first-half baseline and score a post-repair window: the economizer signal should return to steady. Only if the repair changes the design (a new minimum, say) would the baseline be moved, and then with camber drift accept and a recorded reason.
The scheduling measure. Before, the baseline test's setback is missing (a fault: the fan runs every unoccupied hour); after, the setback test's is ok, a held setback with the fan cycling at night. The measure did not fix the short cycling: 178 compressor starts a day before and 131 after, both far above the rule's limit. A second issue for the plan.
M&V. CAMBER refuses: an hourly baseline needs at least 1440 hours and the baseline test has
The refusal says what is missing: its need puts the gap at 1,272 more hours (about 53 days of data). A defensible measurement needs a longer baseline covering the reporting weather (months, not a week), or an IPMVP Option B isolation measurement of the unit's own energy, set up before the change.

Discussion points

The RCx report ranks issues and names the likely cause from the trends; it does not prove it. Map each item on the checklist to the walk-down chapter's advice on what to observe, and to the economizer guide's two questions.
Verification is planned before the change: decide the check, the window and the pass mark in the re-tuning plan, then run it.
Drift and M&V answer different questions: "did the equipment go back to how it was?" and "how much energy did the change save?". The capstone shows one working and one refused, honestly.

Common mistakes

Freezing the drift baselines before writing the RCx report, so the report already contains the drift verdict.
Reading the rank of uncosted issues of one severity as a measure of size. It orders them by confidence; add report.loads sizing to cost them and rank them by dollars.
Dropping the low limit from cap.json. The damper stays a fault, and the control becomes one too (34 %), for hours its sequence locks the economizer out by design.
Reprogramming the economizer on a damper-cause issue: the command already opens, so the fix is mechanical.
Ordering a new actuator on the heading alone: "stuck low" comes from the mixed-air temperature, so stroke the damper and check the mixed-air sensor first.
Treating the conditional static-reset issue as a confirmed fault.
Comparing the two RTU tests' energy directly as a saving: different winters, a week each, no weather normalization.
Moving the drift baseline to "clear" an alarm without a recorded reason.

Instructor guide

Air side

air-sat-reset: Supply-air temperature reset

air-static-pressure: Static pressure reset and the damper census

air-heat-cool: Simultaneous heating and cooling, and a leaking valve

air-economizer: a stuck outdoor-air damper and missed free cooling

air-scheduling: Scheduling: 24/7 operation, setback and after-hours load

Terminal units and ventilation

zone-reheat-overcooling: the reheat penalty and overcooling at minimum airflow

zone-bad-box: one bad box in a fleet

zone-reheat-saturated: a zone below setpoint with its reheat maxed out

zone-dcv: is outdoor air following occupancy?

zone-min-oa: minimum outdoor air and 62.1 system ventilation

Central plant

plant-chiller-efficiency: Chiller efficiency and fouling

plant-cooling-tower: Cooling tower: approach and fan effort

plant-chw-reset-pumping: Chilled-water reset and pumping

plant-boiler: Boiler plant

plant-lockout: Heating plant lockout

plant-sensor-vs-equipment: Plant sensor faults vs equipment faults

Data quality, energy charting, M&V and the capstone

data-trend-quality: are the trends good enough?

data-energy-charting: energy charting

mv-baselines: change-point baselines and M&V

capstone: RCx report, walk-down, re-tuning plan and verification

`air-sat-reset`: Supply-air temperature reset

`air-static-pressure`: Static pressure reset and the damper census

`air-heat-cool`: Simultaneous heating and cooling, and a leaking valve

`air-economizer`: a stuck outdoor-air damper and missed free cooling

`air-scheduling`: Scheduling: 24/7 operation, setback and after-hours load

`zone-reheat-overcooling`: the reheat penalty and overcooling at minimum airflow

`zone-bad-box`: one bad box in a fleet

`zone-reheat-saturated`: a zone below setpoint with its reheat maxed out

`zone-dcv`: is outdoor air following occupancy?

`zone-min-oa`: minimum outdoor air and 62.1 system ventilation

`plant-chiller-efficiency`: Chiller efficiency and fouling

`plant-cooling-tower`: Cooling tower: approach and fan effort

`plant-chw-reset-pumping`: Chilled-water reset and pumping

`plant-boiler`: Boiler plant

`plant-lockout`: Heating plant lockout

`plant-sensor-vs-equipment`: Plant sensor faults vs equipment faults

`data-trend-quality`: are the trends good enough?

`data-energy-charting`: energy charting

`mv-baselines`: change-point baselines and M&V

`capstone`: RCx report, walk-down, re-tuning plan and verification