You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/b83af5c3-b65b-452f-9727-37127240f609n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/2C0966E6-A546-4854-A925-CD32ACA8984C%40yahoo.com.
Hey Gabe and Ambuj,thanks for the example! This is exactly what I needed. As Ambuj said, there is still the problem that there is no 1:1 matching between meters and sensors. For electricity, I could also use a energy usage sensor , right? This might be more consistent with gas and water meters, as I could also use a energy usage sensor for gas and a water usage sensor for water.I would be very happy to participate in your discussions about this topic.Best,Malte
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/43360aa1-8fe7-4455-98b4-ae1dae65aa39n%40googlegroups.com.
We do have a basic building meter example that is on the Brick repository: https://github.com/BrickSchema/Brick/blob/master/examples/building_meter/building_meter.ttl . Properties like the power phase are captured as entity properties rather than as subclasses. We have quantities for voltage/current imbalance defined, but not yet the Points for them (though I've created an issue to track their creation: https://github.com/BrickSchema/Brick/issues/292).
Let me know if the example makes sense and if there's any
additional information I can provide. I would be happy to augment
the example Building Meter on the Brick GitHub with more
attributes/points/properties if you can describe what you'd like
I am also a new guy to Brick and also trying to build up data model for digital electrical power meter in our building.
There are a lot of data, such as power factory A, power factory B, power factory C, Active Power Total, Reactive Power Total, ..., .etc, in an electrical power meter. how can I put them into brick model? do I need to create another class for those?
For example,1. create class Active_Power_A_Sensor nuder brick:Active_Power_Sensor2. create class Voltage_Unbalance_Sensor under brick:Voltage_Sensor3. create class Voltage_Unbalance_Sensor under brick:Voltage_Unbalance_Sensor...
or any other way to build up those data points into brick?
P.S. here(http://www.toyotech.com.tw/upload/pdf/Sch-PM5350rs485.pdf) is pdf for Schneider power meter
Morrisgt.f...@berkeley.edu 在 2021年5月4日 星期二上午6:23:14 [UTC+8] 的信中寫道：
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/86383621-3202-4250-9592-77a642d52d33n%40googlegroups.com.
This has been discussed in other places but not sure if there is a consensus:
1. How do you associate a meter with what is consuming/producing the energy (e.g. a chiller, a floor or a domestic hot water system)?
2. Is there a way to model submetering hierarchies?
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/31a7526a-3a96-470b-8d73-376c752c2df3n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/CAFJ%2Bac%3Dn9jh6usCXpW3X%2BuT%3DWH-CfJ65%3DHBnzTgJQEiOKWk5-w%40mail.gmail.com.
Thanks for the pointer, Steve! I think alignment with 201 would
be a great feature.
I am reading through 201 and as far as I can tell the submeter hierarchy is modeled with a "partOf" relationship between the meter devices --- do I have this right? I am trying to figure out what software I can use to open the UML diagrams on LInux, but I'm curious if there are any reference models or examples that might elucidate how 201 models meters and submeter hierarchies?
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/8ce4b69a-dee0-7198-ff09-b0861aa49957%40cs.berkeley.edu.
A thought about energy usage. It’s good that one can capture what loads are associated with a meter using relations but for energy reporting purposes it may be beneficial to also somehow expand the meter subclasses with usages. Usages such as: air conditioning, heating, ventilation, domestic hot water, office equipment, etc. Or is there a better way to capture this consistently?