Clarification of intent and extent of CONTROLS connection

[duncangreene]

From the documentation.

The Controls connection should be used when one entity impacts the behavior of another.

The example discusses an LCM and a luminaire, but what is the precise intent and exact extent of the CONTROLS connection?

Is it approached from a 'technical/topological' point of view, or an 'ergonomic/human' point of view? Taking the luminaire and LCM, lets also consider a light switch and occupancy detector wired into the LCM. These two devices would provide 'inputs' to the LCM, and the LCM would coordinate/arbitrate these various inputs to command the 'outputs' (the luminaires).

Should we say:

1. switch CONTROLS LCM (which technically/topologically might be considered the case)?
2. switch CONTROLS luminaire (which ergonomically/from a user PoV might be considered the case)?

I imagine we wouldn't be advocating to do both, as the above two CONTROLS connections have quite different interpretations?

If we did do option 2, what differentiates the semantic nature of this CONTROLS connection from LCM CONTROLS luminaire as shown in the example?

This example could be expanded very quickly when we begin to consider the other potential sources of influence to the state of a luminaire (time schedules in controllers, last man out switches, DSR, constant light control, head ends, etc.). Are these (potential) methods of control all intended to be captured by CONTROLS? If so, to what end?

[duncangreene]

Taking it to a completely separate discipline, if a pyranometer on the façade of a building is providing a signal that is ultimately used to influence of the position of 1,000 blinds on that façade, do all 1,000 blinds have a CONTROLS connection back to that one pyranometer (which ergonomically might be considered the case)? Or do they have 'cascaded' CONTROLS connections 'upwards' through the topological chain that makes up the blind control system for that façade (which technically might be considered the case)?

[duncangreene]

Apologies and thanks in advance, just tagging folks I've seen active on here! @tasodorff @shambergoldstein @charbull, any ideas/thoughts on this one?

[shambersafai]

I believe the most appropriate way to model these types of relationships would be:

1. the control module (LCM/shade control module) CONTROLS the individual luminaires/blinds. Meaning all of the luminaire/shade entities onboarded that you have this information for would have this CONTROLS connection on them.
2. the control module (LCM/shade control module) HAS_PART with the occupancy sensors/pyranometer/switches, essentially viewing the sensors/switches as inputs/components of the control loop for that module.

Let me know if that answers all of your questions/makes sense.

[duncangreene]

I am not sure I follow your question about basing it on the communication prototcols; what do you mean by abstracted away?

Apologies, I've maybe conflated the notion of 'communication protocols' with the physical/topological layout of a system in the above. Will try to illustrate a bit further below.

Imagine elsewhere in the same building that we're using inline KNX blind actuators instead, connected to non-digital blind motors, again connected to external venetian blinds. Under DBO convention I believe we would 'draw the box' around a given single blind, motor, and actuator all together (from a physicals PoV they would quite likely be all be regarded as part of the same 'unit', which I believe is the approach taken when 'drawing the box').

In this scenario there is no KNX/SMI gateway (because no protocol translation was required), and thus potentially nothing to which we would attribute a CONTROLS connection to in this case (that is, all the KNX arbitration that was carried out within the KNX/SMI gateway previously is now carried out within the inline KNX blind actuator), but we've 'drawn the box' around the actuator in this instance, and so we'd have nothing to attribute the CONTROLS connection from/to.

Where it seemed peculiar is that for some blinds in the building we would have CONTROLS connections (because of the circumstantial presence of KNX/SMI gateways), but for some other blinds in the building, we wouldn't have CONTROLS connections (unless we broke down 'the box' maybe and decided to model the individual blind actuators separately from their respective blind motors*?).

*If we did this, presumably we'd be doing it just so that we could attribute a CONTROLS connection, but do users need to? How do users work out where to draw the line? Is there an implication if a piece of equipment doesn't/can't have a CONTROLS connection because all elements of control are realised within the piece of equipment itself?).

[shambersafai]

I see. To clarify a bit on the difference between the gateway and the inline actuator, other than the use of a protocol and being wired/wireless, does/can the gateways send positions to multiple blind motors or is it always 1:1?

[duncangreene]

Specifically on the subject of the aforementioned KNX/SMI gateways, they could arbitrate the same 'command' to multiple SMI blind motors if configured that way (which is not uncommon/unreasonable).

By comparison just for context, if instead of inline KNX blind actuators (which are usually, but not always 1-to-1 to a blind motor), we could quite reasonably have 'remotely located' 4 or 8 or 16 or * way KNX blind actuator devices controlling 4 or 8 or 16 or * blind motors each, if the installation/project requirements happened to warrant it that way.

P.S. Very happy to jump onto a call to delve into this further if wanted?

[shambersafai]

If both the gateways and inline actuators can be setup to control multiple blind motors then I think it only makes sense to model them both as standalone entities, outside the box of the blind & motor. In the case that they are controlling multiple then you cannot box them in with a single blind/motor and it would be best to model them consistenly in every scenario. Therefore I would stick with the layout I suggested in my above comment, replacing the gateway with the inline actuator when applicable.