Mock Sources

Mock sources simulate live and trend data without a physical device. Each mock point is assigned a simulation pattern that generates realistic values on the fly. The patterns are modeled on real commercial-building schedules and typical weather, so trends show believable weekday/weekend operation, morning warmup, seasonal variation, and day-to-day differences — no two days are identical. They’re ideal for demos, dashboards, testing rules and alarms, and mocking up an integration before hardware is available.

Sources

The address format for Mock sources is:

mock:<suffix>

Where suffix is an opaque identifier. Mock sources are not bound to a node.

Examples:

mock:88502
mock:10.0.1.5
mock:ahu-1

Points

The point address selects which simulation pattern to generate, with an optional variant and an optional condition:

<prefix> "." <pattern> [ "." <variant> ] [ "." <condition> ]

Examples:

av.temp          # zone temperature
av.temp.2        # zone temperature, variant 2
bv.run           # fan / equipment run status
ai.temp.stuck    # a temperature sensor with a "stuck" condition

prefix is the standard point type prefix (ai, av, bv, …) and sets the point kind, so match it to the reading (ai/av for analog, bi/bv for binary). The optional variant is an integer that de-correlates identical patterns so points don’t move in lockstep. For example, you can give each of several zone temperatures a different variant and they’ll each read slightly differently.

Simulation patterns

Temperatures

Pattern	Simulates	Example points
temp	Zone/space air temperature — held near setpoint when occupied, drifts to setback overnight	Zone Temp, Space Temp, Return Air Temp, Mixed Air Temp
dat	Discharge/supply air temperature — warm during morning warmup, cold supply while cooling	Discharge Air Temp, Supply Air Temp
oat	Outdoor air temperature — realistic diurnal and seasonal weather	Outside Air Temp

Setpoints

Pattern	Simulates	Example points
sp	Cooling setpoint on an optimum-start schedule	Zone Cooling Setpoint, Supply Air Temp Setpoint
htgsp	Heating setpoint on an optimum-start schedule	Zone Heating Setpoint

Air quality & humidity

Pattern	Simulates	Example points
co2	Zone CO₂ — rises with occupancy, decays overnight	Zone CO₂, Space CO₂
humidity	Indoor relative humidity	Space Humidity, Zone Humidity
oarh	Outdoor relative humidity (seasonal)	Outdoor Humidity
pm	Particulate / air quality	PM2.5, PM10, TVOC

Airflow & pressure

Pattern	Simulates	Example points
flow	Supply air flow — minimum flow plus cooling demand	Supply Air Flow, Discharge Air Flow, Air Flow Setpoint
pressure	Duct static pressure	Discharge Air Pressure, Duct Static Pressure

Equipment

Pattern	Simulates	Example points
run	Binary on/off following the equipment schedule (warmup start, weekend operation)	Fan Status, Enable Command
pct	Modulating output driven by cooling demand (0–100%)	Cooling %, Cooling Valve, Damper Position
heat	Heating output — weather driven, opposite of cooling (active in winter, off in summer)	Heating %, Reheat
econ	Economizer / outside-air damper — minimum outside air plus free cooling when mild	Outside Air Damper Position

Energy

Pattern	Simulates	Example points
power	Whole-building electrical power — lighting + plug + fan + cooling, higher in summer	Real Power, kW Demand
energy	Cumulative electrical energy	kWh Consumption

Other

Pattern	Simulates	Example points
occ	Occupancy fraction (0–1) with a lunch dip; never fully empty	Occupancy Sensor
steady	A constant baseline (0); pair with a condition to model a status point	Alarm/Leak/Tamper status (with a condition)
sine	A clean sine wave with no noise	Reference / test signal

Most patterns include a small amount of natural variation so trended data looks realistic; setpoints and sine are clean by design.

Conditions

Append a condition to a point address to have it produce a specific abnormal pattern — a sensor fault or a real event — in a repeatable way. Conditions are passive — there’s nothing to trigger. Each condition occurs once a day at a time that varies from day to day, not pinned to the same clock time (it lands somewhere in business hours). The schedule is deterministic for any given day — so it’s fully repeatable and shows up identically in both live and trend data — but across days the timing moves around, which is what you want when exercising fault-detection rules, alarms, and device-health handling end to end.

Condition	Behavior	Example use
stuck	Value flatlines for the whole day	Failed / frozen sensor
oor	Value pushed outside its normal range for a window	Out-of-range / threshold breach
drift	Value slowly drifts out of range through the day	Calibration drift, low battery
spike	Brief transient excursions a few times a day	Air-quality / VOC spikes
event	Momentarily trips on for a window, then clears	Momentary alarm — smoke, tamper
latch	Trips on and stays on for the rest of the day	Sustained alarm — a leak
dropout	Value drops out (no data) for a window	Comms loss / device offline
shortcycle	Binary output toggles rapidly during operation	Equipment short-cycling

Examples:

ai.temp.stuck      # a zone temperature sensor that flatlines
ai.temp.oor        # a zone temperature that goes out of range
ai.co2.drift       # a CO₂ sensor drifting out of calibration
bi.steady.event    # a momentary alarm that trips then clears
bi.steady.latch    # a leak that trips and stays on all day
ai.temp.dropout    # a sensor that goes offline for a window
bv.run.shortcycle  # a fan that short-cycles

The analog conditions (stuck, oor, drift, spike) work on any sensor pattern — swap temp for co2, humidity, flow, and so on. event and dropout work on any point; use steady as the base pattern for status/alarm points.