Open emiltin opened 5 years ago
Several commands and statuses (e.g. M0001, S0007-13, 20) has 'intersection' as an argument/return value. These are not perfectly designed since it requires all intersections of the controller to be sent comma separated. For instance S0007 "Controller switched on" can return intersection:"1,2", status: "True, False" which means that intersection 1 is turned on and intersection 2 is turned off. This is currently poorly documented in the SXL.
Currently no alarms has the ability to send info about intersection in the SXL.
A better way of doing it would be to use each intersection as an ObjectType.
You mean each intersection should have it's own component, which you then query?
Yes
Should this be described in core? Or is this SXL specific?
It is SXL specific
OK. So multiple intersections in a single controller is supported, but needs to be documented (in this SXL)?
Yes, it is supported, but there are limitations. Alarms and aggregated status is missing information about intersection.
We should require this to be supported by having multiple components. Return values like "True,True" when you have two intersections is error-prone and messy to implement.
Do we plan to change this in the next version of the SXL? In any case, I guess we need to support the current model in the schema?
Not sure. I think feedback from the manufacturers would be good. As far as I know, only one manufacturer supports the ability to send multiple intersections comma separated.
But we need to decide whether we allow comma separated lists in the current schema.
I think the current model needs to be supported in the current schema.
I'll add comma-separated lists to the current schema
Milestome set to 2.0, since this is breaking change.
To sum up: some commands and statuses support multiple interections, using the intersection
attribute to indicate what intersections data relate to, e.g. https://rsmp-nordic.github.io/rsmp_sxl_traffic_lights/1.2.1/sxl_traffic_light_controller.html#s0020
But it's not a very elegant solution; moving forward we would like to have a component for each intersection.
Some intersections have multiple signal rings (intersections) connected to the controller. Should status and alarms indicate what ring/intersections issues relate to?