Skip to content

Conversation

@gtfierro
Copy link
Member

No description provided.


## Migration Notes

- Existing models where controllers hosted individual points should introduce Point Groups and shift the `brick:hosts` relationship to target the group. Equipment such as VAV boxes can continue to reference their points through `brick:hasPoint`.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since brick:hosts wasn't merged yet, I think we can remove this point.

@fennibay
Copy link

Looks good for me, just have a minor comment. Thank you @gtfierro!

Clarify the role of Point Groups in modeling and emphasize their relationship with `brick:hasPoint`.
Avoid inferring semantics from group membership alone. For example, adding a setpoint and its min/max limits to the same Point Group does *not* mean those limits constrain that setpoint. Model explicit relationships if you need to express functional ties.
```

This is *not* a replacement for `brick:hasPoint`! You should still use `brick:hasPoint`/`brick:isPointOf` to relate points to their equipment. This modeling construct focuses on the networking/instrumentation of the system.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it help to give a few examples?

  • a VAV could have a Supply_Air_Flow_Sensor, but this point is hosted by a Controller
  • a Controller could have an On_Off_Status, which is hosted also on the same Controller

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants