Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reintroducing the Concepts of Supply/Return Temperature Sensors and Setpoint for the Water Systems #628

Open
saiprasadbalaji opened this issue Mar 21, 2024 · 1 comment

Comments

@saiprasadbalaji
Copy link

For the water systems, I propose reintroducing the terms “supply” and “return” which were deprecated recently in favour of the terms “leaving” and “entering”. In the context of BMS, the distinction between "supply/return" and "entering/leaving" is crucial, especially when dealing with a common header. Therefore, I propose bringing back the terms "supply" and "return" due to the following reasons:
image

  1. Supply and Return Temperature Sensors are associated with the load side of the chilled water system.
  2. Entering and Leaving Temperature Sensors are associated with the evaporator side of the chilled water system.

For Hot water system,
image

  1. Supply and Return Temperature Sensors are associated with the load side of the hot water system.
  2. Entering and Leaving Temperature Sensors are associated with the boiler side of the hot water system.

Thanks,
Sai

@gtfierro
Copy link
Member

Hi there @saiprasadbalaji! Good to meet you and thanks for raising this issue.

We talked a little bit about this issues with @connorjcantrell today. My understanding from the description you gave is that the re-introduction of Supply/Return would allow you to more easily differentiate between points relating to the system vs points relating to individual equipment w/n the system; in the absence of other contextual information (i.e., having those entities modeled in the graph), the tendency would be to imbue the point classes with additional semantic meaning that differentiates between those cases.

I would like us to think more about how we could solve this w/o having to have points that insist on what kind of entity they are connected to. Could we have mock "stub" systems that are eventually resolved into a single "known" entity? Or some global "virtual" system that can own points before we know what instance they are associated with. Essentially, I think we can address this issue by figuring out a way that points can be associated with a TYPE of entity without having to know what INSTANCE of that entity happens to have that point. Do I understand this ok? @connorjcantrell please chip in with your thoughts too!

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

No branches or pull requests

2 participants