Create a point list that another technician can interpret, trace to its source and verify. Apply a consistent project naming rule while preserving the distinction between commands, measured values, feedback and software values.
This lesson uses an original fictional building-control example. It does not rename live points, edit controller logic, change device addresses or issue commands. The naming syntax is a classroom convention, not a nationwide requirement or a prescribed BACnet, Modbus, Haystack or Brick identifier format.
A point list is more than a list of display labels. Each record should tell a reader what the value means, where it comes from and how to interpret it.
For this exercise, use these fields: Stable point identifier. Display name and full description. Site/building and equipment association. Point function and data type. Engineering units or enumerated state meanings. Source device and exact object, register or terminal mapping. Scale and applicable range. Read/write capability and authorized access context. Alarm/trend requirements, where specified. Verification status, evidence and document revision.
Some fields may be not applicable. Mark that explicitly rather than filling them with invented data. A software calculation has no physical sensor terminal of its own, for example.
The poster uses: Building.Equipment.Quantity.Function
Its dictionary is: B01 = Building01. AHU01 = Air-handling unit01. SAT = Supply-air temperature. DMP = Damper position. SENSOR = Measured quantity. CMD = Commanded quantity. FBK = Reported position feedback.
Thus B01.AHU01.SAT.SENSOR identifies a measured supply-air temperature associated with AHU01 in Building01. It does not encode the controller's network address or establish the measurement's accuracy.
Choose the actual project's permitted characters, case, separators and length limits before importing names. This exercise uses uppercase and periods for clarity. Other approved systems may require different syntax.
Original record P-0101: Name B01.AHU01.SAT.SENSOR. Description AHU01 measured supply-air temperature. Function measurement; numeric value; units°C. Source mapping and scaling must be populated from the actual documents before verification is complete.
Original record P-0102: Name B01.AHU01.DMP.CMD. Description AHU01 requested damper position. Function command; numeric value; units%. Its request is not evidence of actual movement. Write capability and operating permission are separate questions.
Original record P-0103: Name B01.AHU01.DMP.FBK. Description AHU01 reported damper position. Function feedback measurement; numeric value; units%. Identify whether it represents actuator position, driven shaft position or another documented source. Do not silently treat it as measured airflow.
The P-identifiers are stable classroom record keys. They are not BACnet device instances, object instances or Modbus addresses.
A controller can expose points describing another piece of equipment. Brick's controller documentation explicitly distinguishes the hosting relationship from the equipment-point relationship. Its page marks the controller-specific relationships as additions in version1.5. That is useful context for record design, not a requirement to use that schema version on every project.
A temperature can belong semantically to AHU01 while being hosted by ControllerC07. If C07 is replaced, the equipment relationship and point purpose may remain the same even though the source mapping changes. Separate fields make that change reviewable.
Project Haystack's published Points summary distinguishes sensor, command and setpoint functions and relates points to their site and equipment. These are examples of structured metadata practices. A custom string containing SENSOR is not automatically a complete Haystack model.
Numerical units are only part of interpretation. A binary point needs definitions for both states. A multistate point needs its documented state table. A status named RUN does not explain whether it comes from a command, an auxiliary contact, a current switch or software logic.
For a fictional Boolean feedback point, record false=not proven and true=proven only if that is the actual documented meaning. Do not assume false means safely stopped. Preserve unavailable, stale or fault quality separately from a normal false value.
For a derived point, document the expression and source points. For a setpoint, record its purpose and approved range where applicable. Do not label a setpoint as measured temperature merely because both use degrees.
The poster's saved example has command60% and feedback40%. The arithmetic difference is60−40=20percentage points. The relative difference measured against the60%command would be20/60, about33.3%, but that is a different metric and is not what the poster reports.
The two values need timestamps and quality to be comparable. A moving actuator may temporarily differ from its target. Wrong scaling, stale data, source-mapping issues or mechanical conditions may also require investigation. The point list should preserve the observation without claiming a cause from subtraction alone.
Check the complete names and stable identifiers across the project scope. Two rooms may both contain a TEMP point, but the full convention should distinguish their equipment or location. A unique label still needs a verified source mapping.
Before renaming a live point, review graphics, alarms, histories, schedules, external integrations and other references. Preserve the original name and a cross-reference to the new one. A display rename should not silently destroy the continuity of historical data or create a duplicate point.
This lesson does not perform such a rename. Its example is a drafting exercise that should be reviewed before any import.
Brick Ontology Documentation, Controllers: https://docs.brickschema.org/modeling/controllers.html Opened successfully; supports separating hosting from equipment association. Project Haystack, Points: https://project-haystack.org/doc/docHaystack/Points Official search excerpt provided point-function and containment information; direct page retrieval timed out twice. Only those visible introductory concepts were used, not unreviewed details.
The names, three records, dictionary, comparison and exercises are original teaching examples.
Mistake: Creating a feedback name while mapping it to the command object. Correction: Verify the source mapping and identify whether it provides independent feedback or only an echoed command.
Mistake: Replacing an equipment association with the controller that hosts the point. Correction: Keep host mapping separate from the equipment and physical quantity the point describes.
Mistake: Calling unique names verified points. Correction: Retain pending status until mapping, units, scale, quality and required evidence are checked.
Texas journeyman, 15 questions, scored by topic against the 70% mark. No card, and no account needed to start.
Free study material for low-voltage apprentices. This is a national foundation course: requirements differ by state and by local jurisdiction, and a practice that is common in one place is not a rule everywhere. Nothing here is a licence, a certification, or authority to work unsupervised, and completing it does not count as apprenticeship hours or continuing-education credit. Check the codes adopted where you are working, the licensing authority for that work, and your employer's safety programme. VoltMark is not affiliated with, endorsed by, or sponsored by NFPA, OSHA, NICET, BICSI, FOA, or any state or local licensing authority.
Electrician licensing exam prep: practice questions, timed exam simulations, and step-by-step help finding every answer in the NEC.