functional position/state?

[emiltin]

What is the purpose of the attributes fP and fS, and what values should be used?

The core documenation states: fP | functionalPosition | Functional position. Is null if no value is defined in SXL. fS | functionalState | Functional state. Is null if no value is defined in SXL.

And there is a bit in: https://github.com/rsmp-nordic/rsmp_core/blob/master/rst/rsmp.rst#definitions-2

But it doesn't make sense to me.

When I look in the SXL for traffic light spec, there is nothing except two empty cells here:

https://github.com/rsmp-nordic/rsmp_sxl_traffic_lights/blob/master/sxl_traffic_controller.md#aggregated-status-per-grouped-object

Are these attributes used, and what values should be used?

[otterdahl]

Functional position:

An object can be ordered to enter a predefined position. An object has at least one functional position and only one enter a single functional position at a time. Examples: Open/Closed, On/Off, Forward/Stop/Backwards

The term functional position is not specific to RSMP but is commonly used for control systems.

The fP and fS exists in the aggregated status and is always sent if it changes. It is a list of possible positions it can enter. It can be controlled using command M0001 (In the Excel version of the SXL, M0001 is in the section "Functional position").

The SXL for traffic controllers doesn't use functional positions since version 1.0.1, since we were unsure how to define it in a good way for traffic signals. It was replaced with individual statuses instead.

function state is no longer used in recent versions of the RSMP specification, but it left behind for backwards compatibility.

[emiltin]

Are there any examples of the use of fP (outside traffic light controllers)? I think we should clearly state in the spec that fS is deprecated. For TLCs, can fS and fP be left out? Or can they be null or must they be empty strings?

[otterdahl]

Yes, there are examples of other SXL's where fP being used. Examples include Rerouting system in Sundsvall and National system for DRIP signs. There most likely many more SXL's which use it.

The spec mention that fS is not used at section https://github.com/rsmp-nordic/rsmp_core/blob/master/rst/rsmp.rst#signal-exchange-list but perhaps it can be written more clearly.

The spec mention at https://github.com/rsmp-nordic/rsmp_core/blob/3.1.5-draft/rst/rsmp.rst#aggregated-status-message that they should be null if not used.

[emiltin]

can fS be left out, since it is not used?

[otterdahl]

I think fS still need to exist (according to https://github.com/rsmp-nordic/rsmp_core/blob/master/rst/rsmp.rst#basic-structure), but should be set to null (according to https://github.com/rsmp-nordic/rsmp_core/blob/3.1.5-draft/rst/rsmp.rst#aggregated-status-message)

[otterdahl]

I agree that the following section is not written in a very clear way: https://github.com/rsmp-nordic/rsmp_core/blob/master/rst/rsmp.rst#basic-structure I think it is due to poor translation from Swedish. We need to write this better.

[emiltin]

3.2 will be about clarification. removing fields (fS and perhaps also fP) will be for later

[emiltin]

all TLC implementations and also MobiMaestro uses an empty string, rather than null for fP. this is not according to spec. but we could choose to allow an empty string, so the implementations don't have to be changed.

[otterdahl]

I suggestion allowing both null or empty string. I've updated the draft.

[emiltin]

done