implement color temperature and lighting level

[jbkoh]

This addresses #445 and #439. The following changes are made

• Add
  • Lighting_Color_Temperature_Sensor
  • Lighting_Color_Temperature_Command
  • Lighting_Correlated_Color_Temperature_Sensor
  • Lighting_Correlated_Color_Temperature_Command
  • Light (Substance)
• Change
  • Light_Command to Lighting_Level_Command

Several things to discuss further within this PR.

• Color_Temperature vs Correlated_Color_Temperature. They are slightly different as defined here and here while many of other articles equate them as well. Not sure about the industrial practice and I'm happy to introduce only one of them (probably Correlated_Color_Temperature only).
  • QUDT QK only define Correlated_Color_Temperature only but not the other one. Thus, we have to introduce a new QK if we want to have Color_Temperature.
• Light vs Lighting as substance. We already have Lighting as an Equipment class, while Light and Lighting are interchangeably used in cases. Some English experts need to make a decision here. To me it seems Lighting as Equipment is more of a collection of Lights, but not entirely sure. I'm happy with the current form of Light as Substance and Lighting as Equipment too.
• After checking Add ColorTemperatureLightingCommand #445 (comment), even Lighting_Level may not be specific enough. Is "Lighting_Brightness_Command" preferred over "Lighting_Level_Command"? (I'd agree so, and will change it if I hear preferences.)

@nikosandronikos @cbupp @OskarNSE please check this and let me know your thoughts!

[steveraysteveray]

QUDT used CCT based on input from a lighting expert. Note that quantitykind:DUV was also added to indicate the distance from the Planckian locus.

[jbkoh]

Thanks for the input, Steve! I was curious if Color_Temperature is a valid concept or not in the lighting industry, but from your sharing, maybe not. I'll wait a bit more to learn others experiences and remove Color_Temperature if desired. Thanks!

[jbkoh]

Just noticed that we already have Luminance_Command, which is functionally same as Lighting_Level_Command.

Controls the amount of luminance delivered by a lighting system

I'm happy with reusing the existing one (Luminance_Command) instead of introducing (Lighting_Level_Command), but want to hear others' opinions. Any preference? nikosandronikos

[nikosandronikos]

Light as substance, Lighting as equipment seems correct to me.

Regarding Lighting_Brightness vs Lighting_Level - I don't have a strong preference for one over the other. Luminance doesn't seem correct to me as a general light level descriptor, as it relates to measurement contexts more than command contexts. A luminance command is something I would give to a system that includes a sensor and a light, where the light output is adjusted based on the measured luminance (e.g. daylight harvesting). Or perhaps to some sort of calibrated lighting device (I haven't seen any of these) where the light level is described as something other than just a relative value of the total possible output power.

It's also important to have corresponding Status points for each of the added commands, as the actual value used by the device may be different than the commanded value. E.g. I set a group to 100% brightness, but some of the devices within the group have a maximum of 80% set on the ballast - I'll want to know the actual status of each LED in addition to the commanded level.

[gtfierro]

@jbkoh I would take a look at recent QUDT changes to make sure the units/quantity kinds are aligned

[jbkoh]

@gtfierro what was our decision to directly use QUDT quantity kinds? Do we need to still define in our quantities or not?

[gtfierro]

Use QUDT kinds directly wherever you can! If you need something that's not in there, let me know and we can define it in Brick

[steveraysteveray]

...or even better, submit new quantity kinds to QUDT!