Device identifying data, custom inheritance, luminance, and real time data

62 views
Skip to first unread message

Nikos Andronikos

unread,
May 2, 2022, 7:12:52 AMMay 2
to Brick User Forum (Unified Building Metadata Schema)
Hi Brick folks,

Since this is my first post here, I'll introduce myself so my questions have some context. I'm a Software Engineer at an Australian company called Cognian. Our product, Syncromesh, is a wireless smart canopy (i.e. a mesh network) for commercial IoT. The canopy has various functions, being both a wireless lighting control system, as well as transport layer for third party building infrastructure. Our protocol is open (meaning we use existing or published standards) at both ends. To achieve this, our wireless nodes have various interfaces (i.e. BLE, DALI, etc) for connecting to third party devices and our gateway connects upstream via MQTT and Azure IoT Hub to on premise systems such as the BMS, in addition to cloud based platforms.

In Brick, we need to model the hardware that comprises Syncromesh, as well as the connected devices and express the multitude of settings, alarms, faults, collected telemetry, etc.

In mapping our native protocol into Brick, I've compiled the following list of questions as a start, and I was hoping for some guidance on best practices.

1. Capturing device identification information.
All devices have various identifying information and it's important to expose
this to external systems. What is the recommended way of noting information, such
as a device's:
* manufacturer
* model name
* serial number
* gtin

2. Is it advisable to sub-class Brick classes to describe more specific types than
Brick exposes?  E.g. Gateway and Node as a subclass of Electrical Equipment.
Or is it better to use less specific classes pending additions to the spec?

3. I'm not clear on the difference between Luminance Setpoint and Luminance Command.
I have also seen reference to a Luminance Status but can't find it in the spec.
It's possible, due to ballast settings that the actual luminance reported by a
device may be different to the value set, so Luminance Status seems to have merit.

6. Real time data references. Has there been any discussion on methods of linking
a Point to a real time data stream? e.g. an MQTT topic?
Would marking up Points with rdfs:comment be the best method for adding this
sort of custom metadata in the short term?

Thanks in advance. Looking forward to interacting further.

Gabe Fierro

unread,
May 25, 2022, 12:46:17 PMMay 25
to Brick User Forum (Unified Building Metadata Schema)
Hi there! 

Sorry for the delay in reply -- for some reason google groups hasn't been forwarding me these emails...

1. Capturing device identification information.
All devices have various identifying information and it's important to expose
this to external systems. What is the recommended way of noting information, such
as a device's:
* manufacturer
* model name
* serial number
* gtin

The right mechanism for these is to model them as Entity Properties: https://docs.brickschema.org/metadata/entity-properties.html
If you send me a list of these concepts, I can make sure they are added to Brick soon.

2. Is it advisable to sub-class Brick classes to describe more specific types than
Brick exposes?  E.g. Gateway and Node as a subclass of Electrical Equipment.
Or is it better to use less specific classes pending additions to the spec?


We have docs on extending Brick here: https://docs.brickschema.org/extra/extending.html . For networking-centric items, I would advise putting those in your own extension for now, and we can have a conversation about how they might be more formally incorporated into Brick in the future.

3. I'm not clear on the difference between Luminance Setpoint and Luminance Command.
I have also seen reference to a Luminance Status but can't find it in the spec.
It's possible, due to ballast settings that the actual luminance reported by a
device may be different to the value set, so Luminance Status seems to have merit.


If there's a missing class, e.g. Luminance Status, please do file an issue on the GitHub page so that we can add it! The difference between command and setpoint would be a direct action vs a control target, respectively. I don't think you would find a Luminance Setpoint many places unless you are, for example, actuating shades to achieve a daylighting luminance setpoint -- I think Luminance Command would be more common.

4. Real time data references. Has there been any discussion on methods of linking

a Point to a real time data stream? e.g. an MQTT topic?
Would marking up Points with rdfs:comment be the best method for adding this
sort of custom metadata in the short term?


There has been some discussion of this! There are a couple issues on the Brick GitHub discussing some ideas. More concretely, we have External Representations (https://docs.brickschema.org/metadata/external-representations.html) whose structure is informed by the Ref Schema (https://github.com/gtfierro/ref-schema). We would love to add MQTT topics to this -- one outstanding question is how to properly describe the schema of those messages in the MQTT topics. Maybe it's enough to just link to a schema description, but we aren't quite sure yet.

If you have time and would like to discuss this synchronously, we have weekly Working Group meetings (https://brickschema.org/blog/working-groups/) which I attend. We would be happy to spend time discussing any and all of the above! Just show up to whatever time listed works for you.

Best,
Gabe

Nikos Andronikos

unread,
Jun 14, 2022, 4:05:13 AMJun 14
to Brick User Forum (Unified Building Metadata Schema)
Thanks for the answers,

Regarding device identification, for us, the following are important:

GTIN (Global trade item number): 48 bit integer, from DALI IEC-62386-102,
Serial number: 64 bit integer, from DALI IEC-62386-102,
Manufacturer name,
Device model/type,
MAC address: Typically I will use the mac address as the unique identifier within the name of the device instances, but I think it would be worth including this as a specific property for network equipment,


Regarding real time data references, I was primarily considering this as a means of cross referencing to an external specification containing the schema or payload descriptions.
I can see great value in using Brick as a discovery mechanism to understand the structure of an output stream, even without going into the contents of each payload, since it allows users to apply their existing knowledge of Brick to quickly understand a new custom protocol.
Doing both would be nice though. In our Syncromesh MQTT protocol spec, I describe all the payloads using JSON schema. Specific sensors also include JSON schema descriptions of the telemetry they support in the device discovery payloads.
We publish telemetry payloads as both JSON and simple numeric values to suit the capabilities of different consumers.


Finally, thanks for the invite to the working group meetings, the "A" sessions suit my timetable and I will try to join the 29th June and 14th July calls (dates in AU timezone).
I would be happy to show some details of our system and the source data that is used to generate the Brick model if you are interested.

You may also be interested to see a brick model I've generated - this represents one of our sites here in Sydney. The site uses Syncromesh for lighting control as well as capturing indoor air quality and occupancy data. The data from this site is going to a number of sources (via MQTT) for analysis, including a Willow digital twin.
The Brick model is auto generated after querying the gateway to discover the devices on the network and their configuration. It is not a complete representation of our network (i.e. not a one to one mapping of hardware on site and Brick entities), but it is relatively complete in representing the published data points.
Reply all
Reply to author
Forward
0 new messages