As discussed at the recent Haystack Connect conference, I would like to request a new Working Group be created for "Lighting Systems Working Group", and I volunteer to be the facilitator.

In addition, in a conversation with Keith Bishop, we think that for operational efficiency - it makes sense to roll working group #649 into the new working group mentioned above. That WG649 made great strides in accomplishing the primary objective, and now the subject can be incorporated as an ongoing item as part of Lighting Systems.

Thanks, Jeremy Yon

KICKOFF -> ANSI C137.6 and PH#705

Hi all - a small working group for ANSI C137.6 has started meeting. The group is targeting a first draft for a new standard "Data Tagging Vocabulary for Interoperability of Lighting Systems" in about 6 months, with regular meetings. The focus of that group is JUST THE VOCAB and will be platform independent (Haystack, Brick, ASHRAE 223P, etc.)...note ANSI is a consensus SDO -anyone can join, let me know if you need details)

My thoughts on THIS GROUP is to bridge that vocab development to the specifics of Project Haystack, particularly for Haystack 4. Since they are interwoven - we'd like to extend an invitation to this group to join some (about every-other) of the ANSI C137.6 calls to facilitate a fluid exchange of information. The next opportunity to join is Tuesday August 20th at 10AM Eastern US Time. If you'd like to attend, let me know and we'll get you on the list.

The specific Vocab categories that are planned to be addressed include: Units(phScience), Occupancy, Demand Response, Partitioning, Scenes/Presets, Energy Reporting, Dimming/Levels, and some miscellaneous terms that lighting may use differently from other industries.

The C137.6 group has decided to move serially, discussing these elements one at a time. The first topic is going to be Energy Reporting followed immediately by Occupancy.

I haven't been very active in a PH WG, so I very much welcome advice on the best way to proceed with this group. Would this group like to have discussions here in typed format, in some online meetings (I can host), or something else?

Thanks for showing interest in joining! Jeremy

Greetings again all. The first two chunks of content for everyone to pick apart if you would be so kind. The ANSI C137.6 working group is taking topics in a serial nature and iterating on the format for the future standard at the same time. We're striving to be very focused to only cover Key Points of interoperability...there are clearly many other possible tags which can be done adhoc and/or considered in future drafts.

The first bucket of items focused on Energy Reporting. The tags/terms which are presently on our master list include - any thoughts/concerns:

•	Active Power
•	Active Energy
•	Apparent Power
•	Apparent Energy
•	Baseline Power (NOTE - this is still being worked on, 
                        but it will be the maximum power of the 
                        device in order to use as a reference 
                        for lowered actual energy/power)

With the intention of this project being to create a referenceable American National Standard for all ontologies/platforms, the format of organizing the information is critical. Further - the result must be in conducive to displaying as text in a pdf to all users. Here is the first draft of how the information will be organized. Is this all good/useful information to drive commonality but avoid burdening any of the platforms? What should be added/removed/tweaked?

X.1 Active Power
Definition: Under periodic conditions, mean value, 
            taken over one period, of the instantaneous power 
            http://www.electropedia.org/)
Legal Tags:
	Project Haystack 4: active-power
	Brick: Active_Power
	ASHRAE 223P: TBD
Defaults/Alternates:
	Unit: kW (W x 1000)
		Alternate: Scale Factor (per DiiA part 252)
                       {PH:????, Brick:????, ASHAE 223P:???}
        Value type: cumulative since device initialization, non-resettable 
	        Alternate: Custom resetting accumulation
                        {PH:????, Brick:????, ASHAE 223P:???}
        Accuracy: per ANSI C137.5-xx class [[TBD]]
	        Alternate: Alternate ANSI C137.5-xx class
                         {PH:????, Brick:????, ASHAE 223P:???}
	        Alternate: Custom accuracy claim
                         {PH:????, Brick:????, ASHAE 223P:???}
Ontology Mapping:
	Project Haystack 4: https://project-haystack.dev/doc/lib-phIoT/active-power
		supertype: elec-power
	Brick: TBD
		subClassOf: Electric_Power
	rdfs: ????
	owl: ????
	owl:equivalentClass:Real_Power

References:
	DiiA Specification DALI Part 252-October 2018 {{note - standardize format}}

With the intention of this project being to create a referenceable American National Standard for all ontologies/platforms, the format of organizing the information is critical.

ANSI has a standard for this work, ANSI/NISO Z39.19-2005 (R2010) (1). Referencing 223P names is syntactically identical to Brick names, they are just from a different vocabulary, so the expanded names would have a different URI prefix (something like (2) for ASHRAE and (3) for Brick).

Joel

1. https://groups.niso.org/apps/group_public/download.php/12591/z39-19-2005r2010.pdf
2. https://data.ashrae.org/223/2019#
3. https://brickschema.org/schema/1.1.0/Brick#

I have a couple questions about what information is being stored in order to tie these efforts together. Specifically, concerning the fields in the example draft you attached:

• Legal Tags: are these the list of tags that are considered equivalent to the concept (e.g. the concept of "Active Power"), or tags that are permitted to be used with the concept?
• Ontology Mapping: the ontologies themselves should capture the class structure and any relevant properties, so it should be sufficient to just list the IRI here. That is usually considered the "canonical" pointer to the record in the ontology world. For Brick, the IRI would be https://brickschema.org/schema/1.1.0/Brick#Active_Power
• Defaults/alternatives: is the idea here to place requirements on how active power readings are gathered and treated, or to provide a list of data properties that should be communicated when talking about active power? (as an aside, how does one collect "cumulative" values for active power? My understanding is power is an instantaneous phenomenon)

@Joel -> Awesome reference. Thanks! -> Can you explain further the comment that 223P and Brick being syntactically identical? Apologies for still learning here - Are you referring to the section I called "ontology mapping?" The idea is that we expect a lot of people that will be looking at this standard will have no idea about the way that this will be used, so we were attempting to be helpful - perhaps if it is counter-helpful for those skilled in the art, should we be thinking more about some sort of an informative annex - am I catching your point?

@Gabe 1) Both. We're trying to stay platform agnostic, and as such it wouldn't make sense for us to pick one platform and offer the alternate as such - so my working starting point is to start with the concept and then point to how this must be captured if the system is using Project Haystack, Brick, or 223P. Put another way - using a different tag alone to identify this metric should be expected to be ignored. Obviously, nothing prevents additional tags, and this gets to your comment #3

2) Thanks...same response as above to Joel -> any suggestions/concerns from an education perspective?

3) Exactly. We're capturing only the aspects that are truly required to enable data combination in this version - each of the declarations cover known issues for our industry and would represent data mismatch if under-defined. Using what I've learned from listening in on your groups - I understand the desire to keep flexibility for the data engineers and scientists, so NOTHING PRECLUDES creating whatever data is desired - but we're declaring certain requirements if ONLY the primary tag is used (more data lake and less data swamp to steal the phrase from one of the speakers at Haystack Connect this year). Does that makes sense and it is compatible with the underlying principles of the platforms?

On cumulative energy reporting...after years of debate, we've settled in on cumulative energy as the best approach. Basically whatever is measuring the energy initiates the count when it is started up and then adds the energy it measures to the count. While there are various benefits - one that is probably most interesting is lost data points being understood. For lighting - energy from every device is often expected every 15 minutes to be accumulated, so we have to manage the exact timing of the data being received (is it 14:59, 15:01...counted in 2 different buckets) and inevitable lost points. Having it cumulative means that the accumulator can understand better judge what is going on in the system and respond appropriately. This is all being standardized right now in the drafting of ANSI C137.5. It's a big topic - I'm happy to add more if needed.

Can you explain further the comment that 223P and Brick being syntactically identical?

It's simply that the format of the name that both use to refer to a concept are IRIs and are expected to follow RFC7320 URI Design and Ownership rules, like the Active_Power example from Gabe.

We're trying to stay platform agnostic, and as such it wouldn't make sense for us to pick one platform and offer the alternate as such - so my working starting point is to start with the concept...

Absolutely focus on the vocabulary or glossary with any collaboration tools that you can collectively agree to use that will help you focus on the problem and stays out of your way. It could be a mind map, outline tool, wiki, or just a single Markdown file that you share. When you are ready to publish the content, then you dig around through the document types your audience is accustomed to consuming and automate the process of mapping the content.

NOTHING PRECLUDES creating whatever data is desired - but we're declaring certain requirements if ONLY the primary tag is used

That is specifically a Project Haystack modeling problem, you are essentially creating a namespace for yourself by using a tag. Other modeling systems use other techniques. If you are already thinking about how to represent your model in some form that is interoperable with some specific knowledge organization system you are probably jumping the gun.

A lot of really well designed systems have a data dictionary (you might remember that term from the 1970s) that isn't any more complicated than a spreadsheet.

Using what I've learned from listening in on your groups - I understand the desire to keep flexibility for the data engineers and scientists, so NOTHING PRECLUDES creating whatever data is desired - but we're declaring certain requirements if ONLY the primary tag is used

Flexibility is definitely important, but I would offer that in the context of a standard, it is crucial to regulate that flexibility with rules/methods that promote or enforce consistent usage. When there are no rules for how semantic information in a system should be communicated, then a system cannot guarantee that the same concept will be described by two different people in the same way. In the context of Project Haystack, there have been a few community efforts to address these kinds of issues (such as the Utah Tagging Reference document: https://project-haystack.org/forum/topic/682). For establishing a set of tags as equivalent to a concept, you usually have to be explicit about which tags can and cannot be included a set in order for it to be mapped to a concept. Otherwise, you can get into tricky scenarios where adding a tag can potentially change the interpretation of an entity entirely or invalidate other assumptions. Brick and other ontology-based information modeling systems use class hierarchies with properties as a framework for extending the set of concepts such that new concepts can be discovered and understood in the context of existing concepts. The OWL 2 Primer is a decent introduction to that kind of stuff.

I absolutely agree with Joel here that a data dictionary is the place to start. Defining rules for how to extend and annotate and grow the data dictionary -- whether this is by a human process or done through a formal knowledge representation system like OWL -- are important concerns as well, but are going to be more specific to how different systems implement knowledge representation. First and foremost, for any building metadata effort it is invaluable to have a concrete list of the things, types and relationships that the lighting community actually wants to be able to talk about. I also really like the data properties you are defining (e.g. when measuring active power we should care about modeling units, value type and accuracy).

---

It makes sense why one would want to use cumulative energy when gathering telemetry, but it feels inconsistent to define the instantaneous property of "power" as being cumulative. Why not "Active energy"?

Reported power and energy are not lighting specific; should they be defined for any device, at a higher level?

Reported power and energy are not lighting specific; should they be defined for any device, at a higher level?

In Haystack any equipment that measures electrical power should be tagged as elec meter and then contain the associated elec points. For example that is very typical with VFDs also.

Hi all - here is an updated list of terms, we're getting close to start fleshing out the expanded definition and defaults for each - but we welcome information now:

Energy Reporting

-Active Energy
-Apparent Power
-Apparent Energy

Occupancy

-Occupancy Indicator
-Occupant Count
-Occupancy Type {sensing method}
-Occupancy Method {sensing method}

Illuminance

-Color Temp {Direct Sensor Data of the color of the light on a particular scale}
-Luminaire Flux-Rated {Data-entry of maximum rating output - needed for other calcs}
-Luminaire Dim {real-time dimming level}
-Luminaire Dim Curve {Either linear or logarithmic response}
-Luminaire Flux {real-time value calculated from the previous 3 entries}

ALSO BEING IDENTIFIED are concepts that impact each of these groups and possibly other industries:

-Measurement Mounting Tag (type of mounting, location, and possibly other impacts)
-Individual sensor data vs space-zone accumulated representation
-Open and Closed loop sensing logic (do you sense what you are measuring & controlling or just what you are measuring)

Thanks for any input/questions. Jeremy

@Jeremy - Do we have a definition for apparent energy? Does it mean calculated energy?

May I suggest also looking into the BEDES Data Dictionary, with an implementation carried out in the BuildingSync Schema

I agree with @Michael, @Brian, and others: for electric power/energy, I recommend not reinventing the wheel but just going with the definitions already created for electric meters:

• https://project-haystack.org/doc/Energy#elecMeters (Final adopted tags)
• https://project-haystack.org/forum/topic/446 (Proposal, with links there-in to many other relevant threads)

We already have definitions for active power and apparent power; these can be extended into definitions for active energy and apparent energy if desired (although, in practice, I find those quantities to be less useful). active energy is the integral of active power with respect to time and is what we usually think of as "regular" energy consumption; apparent energy is the integral of apparent power with respect to time. (You can do the same with reactive power/energy as well.)

Hi all - regarding the energy. I really appreciate the dialog and thoughts - we definitely do not want to do any wheel-re-inventing. Our proposal is quite the opposite I believe, but fleshing this out is exactly why this workgroup exists.

My understanding (could be right or wrong) is that the referenced Haystack discussions about meters are really about something that is a device. What we're talking about with those specific energy terms is more of a phScience-type of discussion, the fundamental reporting regardless of the type of device. I adopted from this group a desire to use fundamental and reference-able definitions - and so we're not inventing anything - we're pointing at the IEC. Further, there are other lighting communication standards that are also headed in this way (DALI for example if you are familiar).

If I'm understanding correctly, the concepts of the elecMeter and the energy terms we've provided are complimentary, but I'd like to hear more about the risks/concerns if you would be open to sharing some practical examples to help me learn.

Thanks, Jeremy

We have added the following into Haystack 4 preview 3.9.8

• active-energy
• reactive-energy
• apparent-energy

And these points are also added to ac-elec-meter equipment

As the PoE based lighting getting more presence and acceptance in the lighting automation market. I feel we shall consider tags for lighting automation using PoE technology. There will be few specific tags will be coming in to picture with the PoE based lighting control/automation. Let me know your thoughts on this.