Add first round of explanations

Provide more explanation for:

alarms
statuses
commands

Initially we will collect descriptions separately, until we decide on the format flow from e.g. yaml -> markdown/pdf.

Descriptions can now be placed in the new yaml.sxl

Suggestion of description of traffic situation:
Traffic situation is a concept used to divide multiple TLC's into technical areas and sub-areas. The traffic situation gives the possibility to change the TLC sub-area dynamically depending on the time of day and the traffic flow. Depending on the traffic situation the TLC selects the time plan dynamically.

Thanks. I'll soon commit an initial verison of the sxl.yaml, which we can then update via commits or pull requests.

I've written explanations for all alarms, statuses and commands. They will be included in the upcoming 1.0.15.
The SXL in yaml format below is updated. Perhaps we should place the sxl.yaml in the rsmp_sxl_traffic_lights repo.
The only thing blocking right now is this issue.
---
objects:
  Traffic Light Controller:
    description:
    aggregated_status:
      1:
        title: Local mode
        description: Traffic Light Controller is in local mode. NTS has no control.
      2:
        title: No Communications
      3:
        title: High Priority Fault
        description: Traffic Light Controller is in fail safe mode; e.g. yellow flash
          or dark mode
      4:
        title: Medium Priority Fault
        description: |-
          Traffic Light Controller has a medium priority fault, but not in fail safe mode.
          E.g. several lamp faults or detector fault
      5:
        title: Low Priority Fault
        description: Traffic Light Controller has a low priority fault. E.g. Detector
          fault
      6:
        title: Connected / Normal - In Use
      7:
        title: Connected / Normal - Idle
        description: |-
          Traffic Light Controller dark according to configuration.
          NOTE! When dark according to configuration the controller is considered to be in use
      8:
        title: Not Connected
    alarms:
      A0001:
        description: |-
          Serious hardware error

          Used for hardware errors

          Is a "major fault" defined according to 3.8 i EN12675 which causes the controller to switch to a "failure mode" according to 3.6 in EN12675
        priority: 2
        category: D
      A0002:
        description: |-
          Less serious hardware error

          Used for hardware errors

          Is a "minor fault" defined according to 3.8 in EN12675.
        priority: 3
        category: D
      A0003:
        description: |-
          Serious configuration error

          Used for configuration errors

          Is a "major fault" defined according to 3.8 in EN12675 which causes the controller to switch to a "failure mode" according to 3.6 in EN12675
        priority: 2
        category: D
      A0004:
        description: |-
          Less serious configuration error

          Used for configuration errors

          Is a "major fault" defined according to 3.8 in EN12675 which causes the controller to switch to a "failure mode" according to 3.6 in EN12675
        priority: 3
        category: D
      A0005:
        description: |-
          Communication error between traffic light controllers / synchronisation error

          Used for communication errors with other controllers during coordination.

          Is a "minor fault" defined according to 3.8 in EN12675.
        priority: 3
        category: D
      A0006:
        description: |-
          Safety error

          Used for safety errors

          Is a "major fault" defined according to 3.8 in EN12675 which causes the controller to switch to a "failure mode" according to 3.6 in EN12675
        priority: 2
        category: D
      A0007:
        description: |-
          Communication error between one or multiple traffic light controllers and central control system.

          Used for communiucation errors with the central system. Includes NTP connection loss if the TLC is configured to use NTP

          Is a "minor fault" defined according to 3.8 in EN12675.
        priority: 3
        category: D
      A0009:
        description: |-
          Other error

          Used for other errors not covered by any other alarm type

          Is a "minor fault" defined according to 3.8 in EN12675.
        priority: 3
        category: D
      A0010:
        description: |-
          Door open

          Used for open door/cabinet
        priority: 3
        category: D
    statuses:
      S0001:
        description: |-
          Signal group status

          Provides the status of each signal group, including basic information such as green, yellow and red. But also detailed technical information

          Can be used to draw a live signal group diagram as well provide diagnostic information about the performance of the controller. In combination with S0025 it can also be used to construct a SPaT message according to J2735
        arguments:
          signalgroupstatus:
            type: string
            description: Signal group status as text field
          cyclecounter:
            type: integer
            description: Cycle counter
          basecyclecounter:
            type: integer
            description: Base cycle counter
          stage:
            type: integer
            description: Current stage (isolated)
      S0002:
        description: |-
          Detector logic status

          Provides the status of all detector logics of the controller

          Can be used to draw a live signal group diagram as well provide diagnostic information about the performance of the controller. Can also be used for bus priority, external control systems, and much more
        arguments:
          detectorlogicstatus:
            type: string
            description: Detector logic status as text field
      S0003:
        description: |-
          Input status

          Input (1-255) of the controllers general purpose I/O.

          Input is used where the traffic light controller must react to external control. It could be external detectors, bus priority, and much more.
        arguments:
          inputstatus:
            type: string
            description: Input status as text field
          extendedinputstatus:
            type: string
            description: Extended input status as text field
      S0004:
        description: |-
          Output status

          Output (1-255) of the controllers general purpose I/O.

          Can be used for all types of output where the traffic light controller needs to control other equipment. Can be used for bus priority, coordination between traffic controllers, external control systems, and much more
        arguments:
          outputstatus:
            type: string
            description: Output status as text field
          extendedoutputstatus:
            type: string
            description: Extended output status as text field
      S0005:
        description: |-
          Traffic Light Controller starting

          The traffic signal is starting, e.g. it is in startup mode and has not begun working normally yet.

          During startup mode the traffic controller shows dark, red, yellow flash or using the predetermined start cycle (minimum times)
        arguments:
          status:
            type: boolean
            description: |-
              False: Controller is not in start up mode
              True: Controller is currently in start up mode
      S0006:
        description: |-
          Emergency stage

          The status is active during emergency prioritization.

          Used in situations where full priority is given in the emergency vehicle program.
        arguments:
          status:
            type: boolean
            description: |-
              False: Emergency stage inactive
              True: Emergency stage active
          emergencystage:
            type: integer
            description: Number of emergency stage
      S0007:
        description: |
          Controller switched on

          The controller is active and is not in dark mode.

          Used to determine if the controller is operating, e.g. it shows red, green or yellow to the vehicles.

          During maintenance work the controller might be using dark mode (no output to the signal heads)
        arguments:
          intersection:
            type: integer
            description: |-
              0: Not applicable (only one intersection exists or applicable for all intersection of the traffic light controller)
              Other value: Intersection number
          status:
            type: boolean
            description: |-
              False: Traffic Light Controller in dark mode
              True: Traffic Light Controller not in dark mode
      S0008:
        description: |-
          Manual control

          Traffic control deactivated in controller

          Signal timings is controlled manually by service personnel using the operating panel of the controller.
        arguments:
          intersection:
            type: integer
            description: |-
              0: Not applicable (only one intersection exists or applicable for all intersection of the traffic light controller)
              Other value: Intersection number
          status:
            type: boolean
            description: |-
              False: Manual control inactive
              True: Manual control active
      S0009:
        description: |-
          Fixed time control

          Traffic actuated control deactivated and a pre-timed control is used

          Usually only used in case normal detectors can't be used, e.g. during maintenance work.
        arguments:
          intersection:
            type: integer
            description: |-
              0: Not applicable (only one intersection exists or applicable for all intersection of the traffic light controller)
              Other value: Intersection number
          status:
            type: boolean
            description: |-
              False:  Fixed time control inactive
              True:  Fixed time control active
      S0010:
        description: |-
          Isolated control

          Isolated control mode indicates the controller operates independently of any other traffic light controller. This may different depending on traffic program (time plan).

          Used to determine if the controller is operating independently or operating with other controllers (coordination)
        arguments:
          intersection:
            type: integer
            description: |-
              0: Not applicable (only one intersection exists or applicable for all intersection of the traffic light controller)
              Other value: Intersection number
          status:
            type: boolean
            description: |-
              False: Isolated control disabled
              True: Isolated control enabled (Vehicle actuated control or Fixed time control)
      S0011:
        description: |-
          Yellow flash

          The controller shows yellow flash

          Yellow flash may be used during a serious fault (depending on configuration) or maintenance work. It can also be manually set using M0001
        arguments:
          intersection:
            type: integer
            description: |-
              0: Not applicable (only one intersection exists or applicable for all intersection of the traffic light controller)
              Other value: Intersection number
          status:
            type: boolean
            description: |-
              False: Yellow flash disabled
              True: Yellow flash enabled
      S0012:
        description: |-
          All red

          The controller show all red

          All red can be manually set using the controllers operating panel during maintenance work.
        arguments:
          intersection:
            type: integer
            description: |-
              0: Not applicable (only one intersection exists or applicable for all intersection of the traffic light controller)
              Other value: Intersection number
          status:
            type: boolean
            description: |-
              False: All red disabled
              True: All red enabled
      S0013:
        description: |-
          Police key

          The controller is forced to dark mode or yellow flash.

          The "police key" is a external control switch present in some controllers that manually switches the controller to either dark mode or yellow flash.
        arguments:
          intersection:
            type: integer
            description: |-
              0: Not applicable (only one intersection exists or applicable for all intersection of the traffic light controller)
              Other value: Intersection number
          status:
            type: integer
            description: |-
              0: disabled
              1: dark mode
              2: yellow flash
            values:
            - '0'
            - '1'
            - '2'
      S0014:
        description: |-
          Current time plan

          The current time plan (signal program) used in the controller. There may be 1-255 predefined time plans

          The time plan (signal program) may change signal timings, cycle time, control strategy and much more. Typical usage is is scenario based control where change of program is used to change priority etc.
        arguments:
          status:
            type: integer
            description: Current time plan
      S0015:
        description: |-
          Current traffic situation

          The current traffic situation used in the controller

          Used for area-based control where a command can be sent to a master traffic light controller about which predefined traffic situation to use (1-255).

          Traffic situation is a concept used to divide multiple TLC's into areas and sub-areas. The traffic situation gives the possibility to change the TLC sub-area dynamically depending on the time of day and the traffic flow. Depending on the traffic situation each TLC selects the time plan dynamically.

          This status is not a requirement unless the TLC already support this feature and is usually not a function used today.
        arguments:
          status:
            type: integer
            description: Current traffic situation
      S0016:
        description: |-
          Number of detector logics

          Can be used for the management system to check the number of detector logics configured in the controller
        arguments:
          number:
            type: long
            description: Number of detector logics
      S0017:
        description: |-
          Number of signal groups

          Can be used for the management system to check the number of signal groups configured in the controller
        arguments:
          number:
            type: long
            description: Number of signal groups
      S0018:
        description: |-
          Number of time plans

          Can be used for the management system to check the number of time plans configured in the controller
        arguments:
          number:
            type: long
            description: Number of time plans (depreciated)
      S0019:
        description: |-
          Number of traffic situations

          Can be used for the management system to check the number of traffic situations configured in the controller
        arguments:
          number:
            type: long
            description: Number of traffic situations
      S0020:
        description: |-
          Control mode

          Can be used for the management system to check the current control mode (startup, normal, standby, failure, test)
        arguments:
          intersection:
            type: integer
            description: |-
              0: Not applicable (only one intersection exists or applicable for all intersection of the traffic light controller)
              Other value: Intersection number
          controlmode:
            type: string
            description: |-
              -Startup mode
              -Normal control
              -Standby mode
              -Failure mode
              -Test mode
            values:
            - startup
            - control
            - standby
            - failure
            - test
      S0021:
        description: |-
          Manually set detector logic

          Provides status of detector logic (1-255) regarding if they are either forced to true or false.

          Can be used to connect RSMP compatible detection equipment to the traffic light controller. Can also be used for prioritization.
        arguments:
          detectorlogics:
            type: string
            description: Manually set detector logics (1/0) as text field
      S0022:
        description: |-
          List of time plans

          Provies a list of the configured time plans which is possible to use. This status was added due to status S0018 only provides the total number of time plans and not which were possible to use with M0002.

          Can be used for the management system to check the number of time plans configured in the controller
        arguments:
          status:
            type: string
            description: Comma separated list of configured time plans. E.g. "1,2,3,5"
      S0023:
        description: |-
          Dynamic bands

          Provides a list of all defined dynamic bands. Dynamic bands moves start of signal groups in the cycle and changes the signal timings.

          A typical usage of dynamic bands is scenario based control where changing of signal timings is used for optimal traffic flow.
        arguments:
          status:
            type: string
            description: |-
              Dynamic bands.
              Each dynamic band are written as pp-dd-ee where:
              pp=Time plan
              dd=Dynamic band number (from 1-10)
              ee=Extension in seconds in this band

              Each dynamic band is separated with a comma.

              E.g.
              pp-dd-ee,pp-dd-ee
      S0024:
        description: |-
          Offset time

          Offset time is used to define an offset between intersections in coordinated control. It is based on the expected travel time between intersections

          Can be used by the management system to check to fine tune the coordination for optimal traffic flow
        arguments:
          status:
            type: string
            description: |-
              Offset table
              Each offset time is written as pp-tt where:
              pp=time plan
              tt=offset time in seconds

              Each offset time is separated with a comma

              E.g.
              pp-tt,pp-tt
      S0026:
        description: |-
          Week time table

          Week time table for signal programs (time plan) to use for each day during a week

          The week time table determine which predefined signal timings (time plan) to use during the week for optimal traffic flow.
        arguments:
          status:
            type: string
            description: |-
              Week time table. Defines time table to use for each week day
              Each day is written as d-t where:
              d=day of week
              t=time table nr

              Day of week legend:
              0=Monday
              1=Tuesday
              2=Wednesday
              3=Thursday
              4=Friday
              5=Saturday
              6=Sunday

              Each segment is separated with a comma
              E.g.
              d-t,d-t
      S0027:
        description: |-
          Time tables

          Time of day for when to switch signal program (time plan).

          The signal timings (time plan) to use during time of day for optimal traffic flow.
        arguments:
          status:
            type: string
            description: |
              Time Table. Defines time tables.
              Each time definition is written as t-o-h-m where:
              t=time table nr (1-12)
              o=function
              h=hour - switching time
              m=minute - switching minute

              Function legend:
              0=no plan is selected by time table
              1=set plan 1
              …
              16= set plan 16

              hour and minute is using local time (not UTC)

              Each time definition is separated with a comma

              E.g.
              t-o-h-m,t-o-h-m
      S0028:
        description: |-
          Cycle time

          Cycle time (or cycle length) is the sum of all phases in a time plan (traffic program). This time is fixed when using fixed time control or coordination (except "local coordination"). When the cycle counter reaches this length it is reset back to zero.

          Changing the cycle time can be used as part of scenario based control
        arguments:
          status:
            type: string
            description: |-
              Cycle time table
              Each cycle time is written as pp-tt where:
              pp=time plan
              tt=cycle time in seconds

              Each cycle time is separated with a comma

              E.g.
              pp-tt,pp-tt
      S0029:
        description: |-
          Forced input status

          Provide status of input (1-255) regarding if they are forced or not. Can be used for all types of input where the traffic light controller must react to external control.

          Can be used for bus priority, coordination between traffic controllers, external control systems, and much more
        arguments:
          status:
            type: string
            description: Forced input status as text field
      S0030:
        description: |-
          Forced output status

          Provide status of output (1-255) regarding if they are forced or not. Can be used for all types of output where the traffic light controller needs to control other equipment

          Can be used for bus priority, coordination between traffic controllers, external control systems, and much more
        arguments:
          status:
            type: string
            description: Forced output status as text field
      S0031:
        description: |-
          Trigger level sensitivity for loop detector

          The trigger level sensitivity determines at what level the loop detector should trigger. If it set too low then then traffic will not be detected as intended. If it is set too high the detector might give false positives.

          Can be used to make sure that the detectors detect traffic as intended
        arguments:
          status:
            type: string
            description: |-
              Loop detector trigger level sensitivity is written as dd-ss where:
              dd=loop detector number
              ss=sensitivity value
              Each loop detector is separated with a comma. E.g.dd-ss,dd-ss.
      S0091:
        description: |-
          Operator logged in/out OP-panel

          Provides information if maintenance personnel is currently working on site
        arguments:
          user:
            type: string
            description: |-
              username: User currently logged in
              nobody: No one logged in
            values:
            - "[username]"
            - "[nobody]"
          status:
            type: string
            description: |-
              -login: Somebody currently logged in
              -logout: Nobody currently logged in
            values:
            - login
            - logout
      S0092:
        description: |-
          Operator logged in/out web-interface

          Provides information if maintenance personnel is currently working with the controller
        arguments:
          user:
            type: string
            description: |-
              username: User currently logged in
              nobody: No one logged in
            values:
            - "[username]"
            - "[nobody]"
          status:
            type: string
            description: |-
              -login: Somebody currently logged in
              -logout: Nobody currently logged in
            values:
            - login
            - logout
      S0095:
        description: |-
          Version of Traffic Light Controller

          Provides diagnostic version information
        arguments:
          status:
            type: string
            description: Manufacturer, product name and version of traffic light controller
      S0096:
        description: |-
          Current date and time

          Provides diagnostic information about the current date and time set in the controller
        arguments:
          year:
            type: integer
            description: 'Year according to format YYYY. NOTE: UTC is used'
          month:
            type: integer
            description: 'Month (01-12) according to format MM. Note: UTC is used'
          day:
            type: integer
            description: 'Day of month (01-31) according to format DD.  Note: UTC
              is used'
          hour:
            type: integer
            description: 'Hour of day (00-23) according to format DD. Note: UTC is
              used'
          minute:
            type: integer
            description: 'Minute (00-59) according to format MM. Note: UTC is used'
          second:
            type: integer
            description: 'Second (00-59) according to format SS. Note: UTC is used'
      S0097:
        description: |-
          Checksum of traffic parameters

          Can be used to check if any traffic parameter has been changed.

          For instance, depending on controller, maintenance personnel can modify traffic parameters on site to optimize traffic flow. This status provides the ability to monitor if any traffic parameter has been changed. The traffic parameters may be downloaded with S0098.
        arguments:
          checksum:
            type: string
            description: |
              Checksum of the traffic parameters
              Uses SHA-2 as hashing algorithm
              Includes
              - all signal programs, including program versions
              - signal group settings
              - time plans
              - safety matrix
              - intergreen times
              - detector settings

              It should NOT include:
              - network settings
              - log files
              - software
              - other device settings that are not part of the signal program

              Note:
              - The checksum should be calculated using the same data as used in S0098
          timestamp:
            type: string
            description: Time stamp of the checksum. Format according to W3C XML dateTime
              with a resolution of 3 decimal places. All time stamps in UTC. E.g.
              2009-10-02T14:34:34.341Z
      S0098:
        description: |-
          Configuration of traffic parameters

          Can be used to download all traffic parameters from the controller.

          For instance, depending on controller, maintenance personnel can modify traffic parameters on site to optimize traffic flow. This status provides the ability to downloaded them.
        arguments:
          config:
            type: base64
            description: |-
              Traffic parameters
              Includes
              - all signal programs, including program versions
              - signal group settings
              - time plans
              - safety matrix
              - intergreen times
              - detector setting

              It should NOT include:
              - network settings
              - log files
              - software
              - other device settings that are not part of the signal program

              Note:
              - There is no way to upload this binary file to the TLC using RSMP
              - The format of the binary file is not specified and is not expected to be compatible between suppliers
          timestamp:
            type: string
            description: Time stamp of the config. Format according to W3C XML dateTime
              with a resolution of 3 decimal places. All time stamps in UTC. E.g.
              2009-10-02T14:34:34.341Z
          version:
            type: string
            description: Version information of the configuration. Contains basic
              information such as controller id, changes to config and other information.
              The format is not specified in detail.
      S0205:
        description: |-
          Traffic Counting: Number of vehicles

          This status was introduced to improve performance in case traffic counting is done on all all detectors
        arguments:
          start:
            type: string
            description: Time stamp for start of measuring. Format according to W3C
              XML dateTime with a resolution of 3 decimal places. All time stamps
              in UTC. E.g. 2009-10-02T14:34:34.341Z
          vehicles:
            type: string
            description: |
              Number of vehicles
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
      S0206:
        description: |-
          Traffic Counting: Vehicle speed

          This status was introduced to improve performance in case traffic counting is done on all all detectors
        arguments:
          start:
            type: string
            description: Time stamp for start of measuring. Format according to W3C
              XML dateTime with a resolution of 3 decimal places. All time stamps
              in UTC. E.g. 2009-10-02T14:34:34.341Z
          speed:
            type: string
            description: |
              Average speed in km/h (integer)
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
      S0207:
        description: |-
          Traffic Counting: Occupancy

          This status was introduced to improve performance in case traffic counting is done on all all detectors
        arguments:
          start:
            type: string
            description: Time stamp for start of measuring. Format according to W3C
              XML dateTime with a resolution of 3 decimal places. All time stamps
              in UTC. E.g. 2009-10-02T14:34:34.341Z
          occupancy:
            type: string
            description: |
              Occupancy in percent (%) (0-100)
              - Value expressed as an integer with a range of 0-100.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
      S0208:
        description: |-
          Traffic Counting: Number of vehicles of given classification

          This status was introduced to improve performance in case traffic counting is done on all all detectors
        arguments:
          start:
            type: string
            description: Time stamp for start of measuring. Format according to W3C
              XML dateTime with a resolution of 3 decimal places. All time stamps
              in UTC. E.g. 2009-10-02T14:34:34.341Z
          P:
            type: string
            description: |
              Number of cars
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
          PS:
            type: string
            description: |
              Number of cars with trailers
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
          L:
            type: string
            description: |
              Number of trucks
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
          LS:
            type: string
            description: |
              Number of trucks with trailers
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
          B:
            type: string
            description: |
              Number of busses
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
          SP:
            type: string
            description: |
              Number of trams
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
          MC:
            type: string
            description: |
              Number of motor cycles
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
          C:
            type: string
            description: |
              Number of bicycles
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
          F:
            type: string
            description: |
              Number of pedestrians
              - Value expressed as an integer with a range of 0-65535.
              - Contains data from all detector logics. Each detector logic is separated with a comma.
              - The value is set to “-1” if no data could be measured (e.g. detector fault)
    commands:
      M0001:
        description: |-
          Sets functional position

          Sets the controller to yellow flash, dark mode or normal control

          Requires security code 2
        arguments:
          status:
            type: string
            description: |-
              NormalControl: Normal Control
              YellowFlash: Enables yellow flash
              Dark: Enables dark mode
            values:
            - NormalControl
            - YellowFlash
            - Dark
          securityCode:
            type: string
            description: 'Security code 2 '
          timeout:
            type: integer
            description: |-
              Time in minutes until controller automatically reverts to previous functional position.
              0=no automatic return
          intersection:
            type: integer
            description: Intersection number
        command: setValue
      M0002:
        description: |-
          Sets current time plan

          Change of traffic program of the traffic light controller.

          Typical usages is scenario based control where change of program is used to change signal timings etc.

          This command changes the signal timings for optimal traffic flow.

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: Controller uses time plan according to programming
              True: Controller uses time plan according to command
          securityCode:
            type: string
            description: Security code 2
          timeplan:
            type: integer
            description: designation of time plan
        command: setPlan
      M0003:
        description: |-
          Sets traffic situation the controller uses.

          Used for area-based control where a command can be sent to a master traffic light controller about which predefined traffic situation to use (1-255).

          Traffic situation is a concept used to divide multiple TLC's into areas and sub-areas. The traffic situation gives the possibility to change the TLC sub-area dynamically depending on the time of day and the traffic flow. Depending on the traffic situation each TLC selects the time plan dynamically.

          Associates to a setup with Trats where a master/slave concept is used.

          This command is not a requirement unless the TLC already support this feature and is usually not a function used today.

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: Controller uses traffic situation according to own programming
              True: Controller uses traffic situation according to command
          securityCode:
            type: string
            description: Security code 2
          traficsituation:
            type: integer
            description: designation of traficsituation
        command: setTrafficSituation
      M0004:
        description: |-
          Restarts Traffic Light Controller

          Used in the event of serious faults in the device where a restart is considered to be able to remedy a problem.

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: 'True: Restart controller'
          securityCode:
            type: string
            description: Security code 2
        command: setRestart
      M0005:
        description: |-
          Activate emergency route

          The function is made for emergency prioritization. Works in the same way as the M0006 and M0008 where the traffic light controller responds to an input.

          Should be used in situations where full priority is given in the emergency vehicle program.

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: Activate emergency route
              True: Deactivate emergency route
          securityCode:
            type: string
            description: Security code 2
          emergencyroute:
            type: integer
            description: Number of emergency route
        command: setEmergency
      M0006:
        description: |-
          Activate input

          Set given input (1-255) of the controllers general purpose I/O to either true or false.

          The function can provide an input to the traffic light controller on which a predefined action can be taken

          Can be used for all types of input where the traffic light controller must react to external control.

          Typical usages are bus priority, coordination between traffic controllers, external control systems, and much more

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: Deactivate input
              True: Activate input
          securityCode:
            type: string
            description: Security code 2
          input:
            type: integer
            description: Number of Input
        command: setInput
      M0007:
        description: |-
          Activate fixed time control

          Deactivates the traffic actuated control using detectors and activates pre-timed control.

          Can be used in case normal detectors can't be used, e.g. during maintenance work.

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: Deactivate fixed time control
              True: Activate fixed time control
          securityCode:
            type: string
            description: Security code 2
        command: setFixedTime
      M0012:
        description: |-
          Request start or stop of a series of signal groups.

          Starts or stops several signal groups.

          This command was introduced due to coordination requirements needing to set many signal groups to green and red at the same time and M0010 and M0012 being to slow to send a message for each signal group individually

          Although this command is intended to be used with coordination it is not actually specified to be used for this yet. It is reserved in the SXL for possible future use.

          Intended for use with coordination of signaling systems where a traffic light controller communicates with neighboring controllers.

          Only used when a primary controller orders signal group of other controller to green or red (Coordination with external control bits.)

          May also include purposes for adaptive control where a UTC system or a local traffic light controller takes over the phase control (stage control).

          Requires security code 2
        arguments:
          status:
            type: string
            description: |-
              Orders signal groups to green or red. Sets a block of 16 signal groups at a time. Can be repeated to set several blocks of 16 signal groups. Values are separated with comma. Blocks are separated with semicolon. Since semicolon breaks the SXL csv-format, colon is used in example below.

              1=Order signal group to green
              0=Order signal group to red

              Format: [Offset],[Bits to set],[Bits to unset]:…

              Offset sets where the 16 inputs starts from followed by two 16 bit values telling which bit to set and unset in binary format, i.e. first bit have value 1 and last bit have value 32768.

              Example 1:
              "5, 4134, 65" sets input 6,7,10,17 = on and 5,11 = off
              (Input starts from no. 5 and bit 1,2,5,12 = 1 and bit 0,6 = 0)

              Example 2:
              "22, 1, 4" sets input 22 = on and 24 = off
              (Input starts from no. 22 and bit 0 = 1 and bit 2 = 0)

              And both these examples could be sent in the same message as:
              "5,4143,65:22,1,4"

              Such a message would order signal group 6,7,10,17,22 to green and signal group 5,11,24 to red
          securityCode:
            type: string
            description: Security code 2
        command: setStart
      M0013:
        description: |-
          Activate a series of inputs

          Set given inputs (1-255) of the controllers general purpose I/O to either true or false.

          This command was introduced due to coordination requirements needing to set many inputs to true/false at the same time and M0006 being to slow to send a message for each input individually. With this command many inputs can be set to true/false at the same time using a single RSMP message

          Can be used for all types of input where the traffic light controller must react to external control. Typical usages are bus priority, coordination between traffic controllers, external control systems, and much more

          Requires security code 2
        arguments:
          status:
            type: string
            description: |-
              Sets/Unsets a block of 16 inputs at a time. Can be repeated to set several blocks of 16 inputs. Values are separated with comma. Blocks are separated with semicolon. Since semicolon breaks the SXL csv-format,  colon, ":" is used in example below.

              Format: [Offset],[Bits to set],[Bits to unset]:…

              Offset sets where the 16 inputs starts from followed by two 16 bit values telling which bit to set and unset in binary format, i.e. first bit have value 1 and last bit have value 32768.

              Example 1:
              "5, 4134, 65" sets input 6,7,10,17 = on and 5,11 = off
              (Input starts from no. 5 and bit 1,2,5,12 = 1 and bit 0,6 = 0)

              Example 2:
              "22, 1, 4" sets input 22 = on and 24 = off
              (Input starts from no. 22 and bit 0 = 1 and bit 2 = 0)

              And both thease examples could be sent in the same message as:
              "5,4143:65:22,1,4"

              Such a message would activate input 6,7,10,17,22 and deactivate input 5,11,24
          securityCode:
            type: string
            description: Security code 2
        command: setInput
      M0014:
        description: |-
          Set dynamic bands

          Can be used to change between predefined signal timings. Moves the start of signal groups in the cycle.

          This command can be used to change the split of green time during the cycle. A typical usage is scenario based control where changing of signal timings is used for optimal traffic flow.

          Requires security code 2
        arguments:
          plan:
            type: integer
            description: Plan to be changed
          status:
            type: string
            description: |-
              Dynamic bands.
              Each dynamic band are written as dd-ee where:
              dd=Dynamic band number (from 1-10)
              ee=Extension in seconds in this band

              Each dynamic band is separated with a comma.

              E.g.
              dd-ee,dd-ee
          securityCode:
            type: string
            description: Security code 2
        command: setCommands
      M0015:
        description: |-
          Set Offset time

          Offset time is used to define an offset between intersections in coordinated control. It is based on the expected travel time between intersections

          This command can be used to fine tune the coordination for optimal traffic flow.

          Requires security code 2
        arguments:
          status:
            type: integer
            description: Set offset time in seconds
          plan:
            type: integer
            description: Time plan nr
          securityCode:
            type: string
            description: Security code 2
        command: setOffset
      M0016:
        description: |-
          Set week time table

          Set which time table for signal programs to use for each day during a week

          This command changes the signal timings during the week for optimal traffic flow.

          Requires security code 2
        arguments:
          status:
            type: string
            description: |-
              Week time table. Defines time table to use for each week day
              Each segment is written as d-t where:
              d=day of week
              t=time table nr

              Day of week legend:
              0=Monday
              1=Tuesday
              2=Wednesday
              3=Thursday
              4=Friday
              5=Saturday
              6=Sunday

              Each segment is separated with a comma

              E.g.
              d-t,d-t
          securityCode:
            type: string
            description: Security code 2
        command: setWeekTable
      M0017:
        description: |-
          Set time tables

          Set time of day for when to automatically switch signal program (time plan).

          This command changes the signal timings according to time of day for optimal traffic flow.

          Requires security code 2
        arguments:
          status:
            type: string
            description: |
              Time Table. Defines time tables.
              Each time definition is written as t-o-h-m where:
              t=time table nr (1-12)
              o=function
              h=hour - switching time
              m=minute - switching minute

              Function legend:
              0=no plan is selected by time table
              1=set plan 1
              …
              16= set plan 16

              hour and minute is using local time (not UTC)

              Each time definition is separated with a comma.

              E.g.
              t-o-h-m,t-o-h-m
          securityCode:
            type: string
            description: Security code 2
        command: setTimeTable
      M0018:
        description: |-
          Set Cycle time

          Cycle time (or cycle length) is the sum of all phases in a time plan (traffic program). This time is fixed when using fixed time control or coordination (except "local coordination"). When the cycle counter reaches this length it is reset back to zero.

          This command provides the ability to change the cycle time when using coordinated or fixed time control. It changes the timings for optimal traffic flow. Can be used with scenario based control.

          Requires security code 2
        arguments:
          status:
            type: integer
            description: Set cycle time in seconds
          plan:
            type: integer
            description: Time plan nr
          securityCode:
            type: string
            description: Security code 2
        command: setCycleTime
      M0019:
        description: |-
          Force input

          Force a given input (1-255) of the controllers general purpose I/O to either True or False. Can be used for all types of input where the traffic light controller must react to external control.

          Can be used for bus priority, coordination between traffic controllers, external control systems, and much more

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: Force input
              True: Release input
          securityCode:
            type: string
            description: Security code 2
          input:
            type: integer
            description: Number of Input
          inputValue:
            type: boolean
            description: |-
              False: input forced to False
              True: input forced to True
        command: setInput
      M0020:
        description: |-
          Force output

          Force a given output (1-255) of the controllers general purpose I/O to either True of False. Can be used for all types of output where the traffic light controller needs to control other equipment

          Can be used for bus priority, coordination between traffic controllers, external control systems, and much more

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: Force output
              True: Release output
          securityCode:
            type: string
            description: Security code 2
          output:
            type: integer
            description: Number of Output
          outputValue:
            type: boolean
            description: |-
              False: output forced to False
              True: output forced to True
        command: setOutput
      M0021:
        description: |-
          Set trigger level sensitivity for loop detector

          The trigger level sensitivity determines at what level a loop detector should trigger. If it set too low then then traffic will not be detected as intended. If it is set too high the detector might give false positives.

          This command provides the ability to fine tune loop detectors to make sure they detect traffic as intended

          Requires security code 2
        arguments:
          status:
            type: string
            description: |-
              Loop detector trigger level sensitivity is written as dd-ss where:
              dd=loop detector number
              ss=sensitivity value
          securityCode:
            type: string
            description: Security code 2
        command: setLevel
      M0103:
        description: |-
          Set security code

          Change the security code to use when sending commands

          Security codes are used as an extra layer of security in many commands. They need to match between the supervision system and the traffic light controller in order for the commands to be executed.
        arguments:
          status:
            type: string
            description: |-
              Level1: Change security code 1
              Level2: Change security code 2
            values:
            - Level1
            - Level2
          oldSecurityCode:
            type: string
            description: Previous security code
          newSecurityCode:
            type: string
            description: New security code
        command: setSecurityCode
      M0104:
        description: |-
          Set clock

          Can be used to manually set the clock of the traffic light controller if automatic  time synchronization (NTP or watchdog sync) is not available. For instance, during maintenance work

          Requires security code 1
        arguments:
          securityCode:
            type: string
            description: Security code 1
          year:
            type: integer
            description: |-
              Changes internal clock. Note: UTC is used
              Year according to YYYY
          month:
            type: integer
            description: |-
              Changes internal clock. Note: UTC is used
              Month according to MM (01-12)
          day:
            type: integer
            description: |-
              Changes internal clock. Note: UTC is used
              Day in month according to DD (01-31)
          hour:
            type: integer
            description: |-
              Changes internal clock. Note: UTC is used
              Hour according to HH (00-23)
          minute:
            type: integer
            description: |-
              Changes internal clock. Note: UTC is used
              Minute according to MM (00-23)
          second:
            type: integer
            description: |-
              Changes internal clock. Note: UTC is used
              Second according to SS (00-59)
        command: setDate
  Signal group:
    description:
    alarms:
      A0008:
        description: |
          Dead lock error

          Used for dead lock errors.

          E.g. a signal group has requested green but is unable to switch due to a conflicting signal group for an extended period of time. At some point the request times out and the controller goes failure mode. This can caused by configuration errors or external sources.

          Is a "major fault" defined according to 3.8 in EN12675 which causes the controller to switch to a "failure mode" according to 3.6 in EN12675
        priority: 2
        category: D
        arguments:
          timeplan:
            type: integer
            description: Current time plan
      A0101:
        description: |-
          Pushbutton error

          Used for push buttons
        priority: 3
        category: D
      A0201:
        description: |-
          Serious lamp error

          Used for lamp errors

          Is a "major fault" defined according to 3.8 in EN12675 which causes the controller to switch to a "failure mode" according to 3.6 in EN12675
        priority: 2
        category: D
        arguments:
          color:
            type: string
            description: Color of lamp
            values:
            - red
            - yellow
            - green
      A0202:
        description: |-
          Less serious lamp error

          Used for lamp errors

          Is a "minor fault" defined according to 3.8 in EN12675.
        priority: 3
        category: D
        arguments:
          color:
            type: string
            description: Color of lamp
            values:
            - red
            - yellow
            - green
    statuses:
      S0025:
        description: |-
          Time-of-Green / Time-of-Red

          Provides predicted signal timings of green and red for each signal group. Max, min and likley time to green and red

          Can be used with S0001 to construct a SPaT message according to J2735. Provides the necessary data for TTR (Time to green) and GLOSA (Green Light Optimal Speed Advisory)
        arguments:
          minToGEstimate   :
            type: string
            description: |-
              Time stamp for the minimum time for the signal group to go to green. If the signal group is green, it is the minimum time for the next green.
              Format according to W3C XML dateTime with a resolution of 3 decimal places. All time stamps in UTC. E.g. 2009-10-02T14:34:34.341Z
          maxToGEstimate   :
            type: string
            description: |-
              Time stamp for the maximum time for the signal group to go to green. If the signal group is green, it is the maximum time for the next green.
              Format according to W3C XML dateTime with a resolution of 3 decimal places. All time stamps in UTC. E.g. 2009-10-02T14:34:34.341Z
          likelyToGEstimate   :
            type: string
            description: |-
              Time stamp for the most likely time for the signal group to go to green. If the signal group is green, it is the most likely time for the next green.
              Format according to W3C XML dateTime with a resolution of 3 decimal places. All time stamps in UTC. E.g. 2009-10-02T14:34:34.341Z
          ToGConfidence:
            type: integer
            description: Confidence of the likelyToGEstimate. 0-100%
          minToREstimate   :
            type: string
            description: |-
              Time stamp for the minimum time for the signal group to go to red. If the signal group is red, it is the minimum time for the next red.
              Format according to W3C XML dateTime with a resolution of 3 decimal places. All time stamps in UTC. E.g. 2009-10-02T14:34:34.341Z
          maxToREstimate:
            type: string
            description: |-
              Time stamp for the maximum time for the signal group to go to red. If the signal group is red, it is the maximum time for the next red.
              Format according to W3C XML dateTime with a resolution of 3 decimal places. All time stamps in UTC. E.g. 2009-10-02T14:34:34.341Z
          likelyToREstimate   :
            type: string
            description: |-
              Time stamp for the most likely time for the signal group to go to red. If the signal group is red, it is the most likely time for the next red.
              Format according to W3C XML dateTime with a resolution of 3 decimal places. All time stamps in UTC. E.g. 2009-10-02T14:34:34.341Z
          ToRConfidence:
            type: integer
            description: Confidence of the likelyToREstimate. 0-100%
    commands:
      M0010:
        description: |-
          Start of signal group. Orders a signal group to green.

          Although this command is intended to be used with coordination it is not actually specified to be used for this yet. It is reserved in the SXL for possible future use.

          Intended for use with coordination of signaling systems where a traffic light controller communicates with neighboring controllers. Only used when a primary controller orders signal group of other controller to green or red (Coordination with external control bits.)

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: No command (default)
              True: Order a signal group to green
          securityCode:
            type: string
            description: Security code 2
        command: setStart
      M0011:
        description: |-
          Stop of signal group. Orders a signal group to red.

          Although this command is intended to be used with coordination it is not actually specified to be used for this yet. It is reserved in the SXL for possible future use.

          Intended for use with coordination of signaling systems where a traffic light controller communicates with neighboring controllers. Only used when a primary controller orders signal group of other controller to green or red (Coordination with external control bits.)

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: No command (default)
              True: Order a signal group to red
          securityCode:
            type: string
            description: Security code 2
        command: setStop
  Detector logic:
    description:
    alarms:
      A0301:
        description: |-
          Detector error (hardware)

          Used for detector errors in hardware

          Is a "minor fault" defined according to 3.8 in EN12675.
        priority: 3
        category: D
        arguments:
          detector:
            type: string
            description: Designation of the detector (hardware)
          type:
            type: string
            description: |-
              Type of detector.
              loop: Inductive detector loop
              input: External input
            values:
            - loop
            - input
          errormode:
            type: string
            description: Detector forced on/off while detector error
            values:
            - 'on'
            - 'off'
          manual:
            type: boolean
            description: Manually controlled detector logic (True/False)
      A0302:
        description: |-
          Detector error (logic error)

          Used for detector errors (logic).

          For instance; detector continuously on or off during an extended time.

          Is a "minor fault" defined according to 3.8 in EN12675.
        priority: 3
        category: D
        arguments:
          detector:
            type: string
            description: Designation of the detector (hardware)
          type:
            type: string
            description: |-
              Type of detector.
              loop: Inductive detector loop
              input: External input
            values:
            - loop
            - input
          errormode:
            type: string
            description: Detector forced on/off while detector error
            values:
            - 'on'
            - 'off'
          manual:
            type: boolean
            description: Manually controlled detector logic (True/False)
          logicerror:
            type: string
            description: |-
              Type of logic error
              always_off: no detection during predefined max time
              always on: detection constantly on during predefined max time
              intermittent: intermittent logic fault (flutter)
            values:
            - always_off
            - always_on
            - intermittent
    statuses:
      S0201:
        description: |-
          Traffic Counting: Number of vehicles

          Used for Traffic counting
        arguments:
          starttime:
            type: string
            description: Time stamp for start of measuring. Format according to W3C
              XML dateTime with a resolution of 3 decimal places. All time stamps
              in UTC. E.g. 2009-10-02T14:34:34.341Z
          vehicles:
            type: long
            description: Number of vehicles on a given detector logic (since last
              update)
      S0202:
        description: |-
          Traffic Counting: Vehicle speed

          Used for Traffic counting
        arguments:
          starttime:
            type: string
            description: Time stamp for start of measuring. Format according to W3C
              XML dateTime with a resolution of 3 decimal places. All time stamps
              in UTC. E.g. 2009-10-02T14:34:34.341Z
          speed:
            type: integer
            description: Average speed in km/h
      S0203:
        description: |-
          Traffic Counting: Occupancy

          Used for Traffic counting
        arguments:
          starttime:
            type: string
            description: Time stamp for start of measuring. Format according to W3C
              XML dateTime with a resolution of 3 decimal places. All time stamps
              in UTC. E.g. 2009-10-02T14:34:34.341Z
          occupancy:
            type: integer
            description: Occupancy in percent (0-100%)
      S0204:
        description: |-
          Traffic Counting: Number of vehicles of given classification

          Used for Traffic counting
        arguments:
          starttime:
            type: string
            description: Time stamp for start of measuring. Format according to W3C
              XML dateTime with a resolution of 3 decimal places. All time stamps
              in UTC. E.g. 2009-10-02T14:34:34.341Z
          P:
            type: long
            description: Number of cars
          PS:
            type: long
            description: Number of cars with trailers
          L:
            type: long
            description: Number of trucks
          LS:
            type: long
            description: Number of trucks with trailers
          B:
            type: long
            description: Number of busses
          SP:
            type: long
            description: Number of trams
          MC:
            type: long
            description: Number of motor cycles
          C:
            type: long
            description: Number of bicycles
          F:
            type: long
            description: Number of pedestrians
    commands:
      M0008:
        description: |-
          Sets manual activation of detector logic

          Set given detector logic (1-255) to either true or false.

          Can e.g. be used to connect RSMP compatible detection equipment to the traffic light controller. Can also be used for prioritization.

          Requires security code 2
        arguments:
          status:
            type: boolean
            description: |-
              False: Deactivate manual control of detector logic
              True: Activate manual control of detector logic
          securityCode:
            type: string
            description: Security code 2
          mode:
            type: boolean
            description: |-
              False: Deactivate detector logic
              True: Activate detector logic
        command: setForceDetectorLogic


Project System: Stop opening component designer by default

From @davkean on May 11, 2016 1:57
Today if you double-click on a type that implements IComponent in Solution Explorer, we open the component designer.
While that's useful for forms, and user controls, it's not very useful for controls, or other components that contain just code and nothing "designable".
We should consider open code view by default. Let's pull the telemetry on whom double-click on a component, only to immediately close it and choose View Code.
Copied from original issue: dotnet/roslyn#11236

From @paul1956 on May 11, 2016 2:4
That will make working with Forms (and user controls) more difficult. Can you have two defaults, one for things what make sense (at least forms) and one where code view would be better.

As part of this - this would cover the automatically adding of <SubType>Component</SubType> to components.

Sorry - I didn't make it clear in the original issue, "Forms" and "UserControls" should continue to open in the designer by default, I'm only talking about things that get the "component designer" not the user control/winforms designer


New Utility for Postgres to be used as a local 'warehouse'

Added a 'postgres' variant of a utility in /_data/meltano/utilities/postgres/
Checklist

[ ] Add/update the file in the appropriate folder (/taps or /targets). The name of the file should match the name of the tap. If there is already one, add a descriptor to the name such as -search.
[ ] Add/update the PNG logo image in /assets/logos/<taps or targets>. The image name must match the YAML file name.
[ ] Tag @tayloramurphy or @pnadolny13 to flag it for review. Or post to the #hub channel on Meltano slack.

Reviewer Checklist

[ ] Validate file against JSON Schema. https://www.jsonschema.net/home is an option.
[ ] Build website locally and validate everything works.

Hi @tayloramurphy @pnadolny13 please take a look at this new utility.  Thanks!

@tayloramurphy this looks good to me, if you wanted to give a final review and merge.

Legends.  Thanks for accepting it and improving it!


How would you go about using django ORM and django-generate-series to get 1 table with 1 item per (date, id) combination ?

Hello !
Let's say I have a table on one side and a date sequence on the other. I don't know how to generate a table containing each (date, item_id) combination, in 1 SQL query and using Django ORM.
I would like to be able to do that using Django ORM because I have a lot of post processing after that, i.e. annotations and aggregations.
I found a very similar question with a pure SQL answer:
https://dba.stackexchange.com/questions/133406/postgresql-generate-a-series-of-dates-for-each-group-in-a-table

@lionelwust I am very sorry to have missed your question for so many months. I know it's probably far too late to be useful to your project, but I've updated the package to product the cartesian product of an input QuerySet or iterable.
Fixed in d404ebf3e2e026135a4052576d39673a38e63343
Thank you for pointing out a useful feature.
Released as a beta while I clean up the code and tests a bit more.

That's nice, will try to use it !
Have a good day, Lionel


Add option to specific custom npm registry

eg: updtr --registry https://registry.npm.taobao.org

@egoist are you interested in specifying a different registry than the one set in npm config?

@rbartoli Yes, I use the default registry to do things like npm publish, but use npm --registry http://registry.in.china to make installing faster in my area. And lots of people do like so here.
However this is not a high priority issue 😅

So you are installing your packages with npm install --registry http://your.registry packageName right? I think you forgot the word install, or i think about something else :)

Published as v0.1.13

Wow, thanks! 😁


Add google cloud sdk

Testing steps performed:

pushed to my private docker repository
ran docker run --it --entrypoint=/bin/bash myrepository/test-kube-tools
`which gcloud
/google-cloud-sdk/bin/gcloud
gcloud auth login <prints out "Go to the following link in your browser > ..."  (e.g. didn't actually login, but it seems to work).

Forgot to do:

forgot to update the readme to list google cloud sdk. If you're happy with this change I'd be happy to update the readme accordingly. Note it is also currently missing azure cli.


Q: How shall zcl_abapgit_convert=>language_sap2_to_sap1 work?

The METH zcl_abapgit_convert=>language_sap2_to_sap1 doesn't convert 6N (aka en-GB aka 둮) as it selects form I_LANGUAGE, which in my system contains entries

Method even raises and does not call statement of Line 325, which would returns the  expected value 둮

Why is that and is the current behaviour right?

The first part is intended for ABAP Cloud, where cl_i18n_languages is not released. So the answer needs to come from SAP how to handle the missing languages in cloud.

Ok, what I understand is that abapGit cannot convert languages in ABAP Cloud based on cl_i18n_languages. I learned that
data(converter) = xco_cp_language=>format->iso_639.
data(spras) = converter->to_language( 'EN' )->value. " is 'E'

would be an ABAP Cloud alternative. However, it raises when converting non-installed languages, e.g. 6N.
So my question is: What is the expected behaviour in abapGit (in ABAP Cloud scenario) when converting non-installed languages?

The result of importing objects with AG should be the same as importing them via transport.
AFAIK, a transport with texts in several languages would import all of them no matter if the language is installed in the system or not.
If AG ignored some languages that are not installed, there would be diffs as well. Assuming a complete repo is translated that would mean diffs on all objects.
It's best to import all languages. But then we need some kind of fallback for that ABAP cloud conversion method.

Thanks for clarification.

Maybe provide a table within abapGit as for bcp47 introduced in #6915
Supported Languages Supportedlanguages.xls as of SAP Note 73606

We could but then AG become responsible for maintaining a list that actually exists in ABAP Cloud. How about your colleagues provide a method for xco_cp_language...to_language that does not raise an exception?

via XCO Library only the installed languages are exposed, which makes it a bad choice for general conversion routine 😬

We don't want persisted tables. It will have to be in coding. Add it to the local section.

Will try to go with local section, as done in #6915 for bcp47 to SAP conversion.


HSEARCH-2473 Get test naming practices straight

https://hibernate.atlassian.net//browse/HSEARCH-2473
I tested the new JQAssistant rules locally by adding tests with the wrong suffix: it worked.

Pull Request Test Coverage Report for Build 1

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.306%

Totals

Change from base Build 295:
0.0%

Covered Lines:
18657

Relevant Lines:
20891

💛  - Coveralls

Merged thanks!


Added Rock-paper-scissors game

Please fill all the details and checkbox, so we can merge PR faster.
Pull Request Template
Rock-paper-scissors -
What have you Changed
what you changed in the codebase. write here
Issue no.(must) -
Self Check(Tick After Making pull Request)

[x] This issue was assigned to me.
[x] One Change in one Pull Request
[x] My file is in the proper folder
[x] I am following clean code and Documentation and my code is well-linted with flake8.
[x] I have added README.md and requirements.txt with my script

If the issue was not assigned to you Please don't make a PR. It will mark as invalid.
Join Us on Discord:- https://discord.gg/JfbK3bS
acknowledgment

[x] I have tested the script and distributed it under an MIT license.

.


API is down

I don't think a description is needed but seriously the API is down and I can't embed daily quote in my daily note.

Seems to be something wrong with the DNS config.


Patch devise gem to handle invitations to share plans properly

Related issue #397
Scenario:

User shares a plan with an email address that does not have an account.
The person that the plan was shared with does not get or see the email
The person that the plan was shared with registers their account directly without following the link in the email
The person enters their new account and does not find the shared plan because the link to it has been deleted (a brand new account overwrites the stem account w/link to plan)

The desired behavior is to preserve the link to the shared plan regardless of the path the user follows to create an account. Otherwise the user has to request that the original plan owner re-invite them to the plan. Devise gem should be patched to support this use case as it is probably common and desired by others.

the devise and devise_invitable gems are separate projects. The devise_invitable gem creates the user record when the plan is shared. If the user creates an account before accepting the invitation it looks like the devise gem overwrites the record created by devise_invitable.
We may have to send one of them a PR to patch this behavior, or monkey patch it on our end.

@briri I've coded this behaviour in the registrations controller (destroy stem account - this also gets rid of the role (plan sharing)). The gems' default behaviour is to not let the user register (because their email is known to the system - there is a stem acccount with it) and this is what was annoying our users.

Ideally we'd have the position @stephaniesimms outlines i.e. user can still create account (an unfollowed token invite / stem account shouldn't prevent this) AND they'd have access to shared plan. I don't think it's possible to have the two though, so we opted for being able to register as being more important

@vyruss fixed this. I just confirmed.


[BUG] FastAPI App lifespan hook doesn't get run

Checklist

[✓] I checked the FAQ section of the documentation
[✓] I looked for similar issues in the issue tracker

Describe the bug
It seems that if I use a lifespan with my schemathesis test, it doesn't get called, which results in my tests failing. I think this would also be the case with the deprecated startup / shutdown event hooks (I admittedly didn't check).
To Reproduce
Steps to reproduce the behavior:
Use the "Python tests" example from the README:
import schemathesis

schema = schemathesis.from_uri("https://example.schemathesis.io/openapi.json")

@schema.parametrize()
def test_api(case):
    case.call_and_validate()

If possible, please post a minimal version of your API schema that cause this behavior:
N/A
Expected behavior
App lifespan hook is run. Or maybe more test setup is required? I see various related discussion, and a package called asgi-lifespan which seems vaguely related, but it's not obvious to me how I might get this working, or even if it's possible.
Environment (please complete the following information):

OS: Ubuntu Linux
Python version: 3.9
Schemathesis version: 3.19.0
Spec version: OpenAPI 3.0.2

Additional context
Trying to test a FastAPI app that has TiMVT mounted.

This is indeed an issue with the current approach to ASGI, I am going to rework our ASGI documentation and sort all related issues out for Schemathesis 3.21


RFC 5280 compliance with SAN extension

From RFC 5280:
   If the subjectAltName extension is present, the sequence MUST contain
   at least one entry.  Unlike the subject field, conforming CAs MUST
   NOT issue certificates with subjectAltNames containing empty
   GeneralName fields.  For example, an rfc822Name is represented as an
   IA5String.  While an empty string is a valid IA5String, such an
   rfc822Name is not permitted by this profile.  The behavior of clients
   that encounter such a certificate when processing a certification
   path is not defined by this profile.

Certificates created with Lemur without any SANs are created with an empty list of SANs in the SubjectAlternativeName extension. See here these spots where that's essentially a hard-coded default:

https://github.com/Netflix/lemur/blob/master/lemur/common/fields.py#L396
https://github.com/Netflix/lemur/blob/master/lemur/certificates/models.py#L244

I find these work in most places, but I have a suspicion they do not work in OpenJDK 7+ keystores. I am working on confirming this now, but it at least violates the RFC.

The cryptography plugin is probably most affected by this. External CAs (Digicert, Symantec, etc.) will enforce this behavior by adding whatever is in the common name as a subAltName entry I would assume we could do same.

Here's some proof:

CA certificate with no SAN component: https://gist.github.com/neilschelly/1f22eef17e88fb589954b1ccf785424d
CA certificate with an empty list of SANs: https://gist.github.com/neilschelly/eb51cc6ecb3adc48b16101e59ddbdbd7

The following is the command output of using the Java keytool to parse the empty SAN certificate:
$ keytool -printcert -v -file ca-emptysan.crt
keytool error: java.lang.Exception: Failed to parse input
java.lang.Exception: Failed to parse input
        at sun.security.tools.keytool.Main.printCertFromStream(Main.java:2208)
        at sun.security.tools.keytool.Main.doPrintCert(Main.java:2337)
        at sun.security.tools.keytool.Main.doCommands(Main.java:1052)
        at sun.security.tools.keytool.Main.run(Main.java:337)
        at sun.security.tools.keytool.Main.main(Main.java:330)
Caused by: java.security.cert.CertificateParsingException: java.io.IOException: No data available in passed DER encoded value.
        at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:168)
        at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1779)
        at sun.security.x509.X509CertImpl.<init>(X509CertImpl.java:196)
        at sun.security.provider.X509Factory.parseX509orPKCS7Cert(X509Factory.java:466)
        at sun.security.provider.X509Factory.engineGenerateCertificates(X509Factory.java:352)
        at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462)
        at sun.security.tools.keytool.Main.printCertFromStream(Main.java:2206)
        ... 4 more
Caused by: java.io.IOException: No data available in passed DER encoded value.
        at sun.security.x509.GeneralNames.<init>(GeneralNames.java:61)
        at sun.security.x509.SubjectAlternativeNameExtension.<init>(SubjectAlternativeNameExtension.java:141)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at sun.security.x509.CertificateExtensions.parseExtension(CertificateExtensions.java:112)
        at sun.security.x509.CertificateExtensions.init(CertificateExtensions.java:88)
        at sun.security.x509.CertificateExtensions.<init>(CertificateExtensions.java:78)
        at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:734)
        at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:166)
        ... 10 more

And for the one lacking the SAN extension entirely:
$ keytool -printcert -v -file ca-nosan.crt
Owner<EMAIL_ADDRESS>L=Manchester, ST=NH, C=US, OU=Dyn Engineering, O="Oracle + Dyn, Inc", CN=CA-nosans
Issuer<EMAIL_ADDRESS>L=Manchester, ST=NH, C=US, OU=Dyn Engineering, O="Oracle + Dyn, Inc", CN=CA-nosans
Serial number: 5b08eccca24a46b89260c38bce156a72
Valid from: Fri Mar 03 16:21:03 UTC 2017 until: Sun Mar 03 16:21:03 UTC 2024
Certificate fingerprints:
         MD5:  96:FA:DB:28:F4:E0:BC:DD:46:18:74:61:92:2F:59:28
         SHA1: 86:41:DC:B5:CA:C8:D0:41:16:7C:80:B3:A8:33:FB:50:90:D7:17:ED
         SHA256: 15:1F:8D:C7:F6:33:5C:98:D3:EF:8A:6B:A8:D4:52:47:24:A4:C7:CB:C0:D2:1E:DA:F5:C5:1A:34:01:81:84:D1
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: <IP_ADDRESS> Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 2F B0 39 64 93 55 D9 70   C9 35 CA 3E AB 6F 17 DB  /.9d.U.p.5.>.o..
0010: 11 6D BC A8                                        .m..
]
<EMAIL_ADDRESS>L=Manchester, ST=NH, C=US, OU=Dyn Engineering, O="Oracle + Dyn, Inc", CN=CA-nosans]
SerialNumber: [    01]
]

#2: ObjectId: <IP_ADDRESS> Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#3: ObjectId: <IP_ADDRESS> Criticality=false
ExtendedKeyUsages [
  OCSPSigning
]

#4: ObjectId: <IP_ADDRESS> Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#5: ObjectId: <IP_ADDRESS> Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 2F B0 39 64 93 55 D9 70   C9 35 CA 3E AB 6F 17 DB  /.9d.U.p.5.>.o..
0010: 11 6D BC A8                                        .m..
]
]

I think you're probably right. Here's a couple options for a fix. I can do any of them:

Adjust the models/schemas so that you can create a certificate with no SubjectAlternativeName extension. If the list of GeneralNames is empty, it will just skip adding that extension.
Adjust the lemur_cryptography plugin code so that if there is a SubjectAlternativeName extension with no GeneralNames in it, it will create a GeneralName from the Subject CN and add that to the SAN extension.
Adjust the models/schemas so that there will always be a SubjectAlternativeName extension. Unless it is already present in the list of SAN GeneralNames, it will add the CN from the Subject to the SAN extension.

The first option allows for a certificate without a SubjectAlternativeName extension. That's perhaps not practically useful for typical uses of certificates to protect websites, but could satisfy someone's edge case where they want certificates without that extension defined.
The second option lets the plugins handle an empty SAN extension all by themselves, however they see fit. Most third-party ones will handle this gracefully and put the Subject CN into the SAN extension. We could fix the cryptography plugin to match this behavior.
The third option ensures that all CSRs that are created by the Lemur can become RFC-compliant certificates once they are signed, without depending on the plugin or third party to do it for them.
I'm a fan of the second option myself, which seems easiest to implement and matches your comment. I'll try making that happen with a PR soon.

I think option 2 is okay for now as it aligns cryptography with the other issuers.


Corridor doesn't always guard against room corners

This probably shouldn't happen:

Generated with seed 7953 on the interactive manual.
As far as I can tell, there are actually two ways this can happen. Corners are marked as "expandable" walls, but are usually not eligible for expansion since they have no empty space around them.
E - wall that could expand now
X - wall that won't expand now

XEEEX
E...E
E...E
E...E
XEEEX

But if a wall is removed next to them, they can be expanded, and you can end up with this:
XEEEX
E...E
E...E
E....
XEEE.

Once doors are added, this ends up looking pretty awkward.
The other reason it can happen (it looks like it happened here) is because doors don't really exist in the regular map data, and corridors will happily tunnel into existing doors, thinking they are just normal floors. See also the other odd "double-door" just to the left of the highlighted area in the image.
It looks like both cases could be fixed by actually including the doors in the map data, and treating them as a separate type of cell from walls and floors.
One idea could be treating the cell value as a bitfield, so 2 would mean an open door and 3 would mean a closed door. You could just check the low bit when you don't care about doors and just want to know if the cell is "open" or "closed."

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Well, IIRC, door placement has no relation to actual map (room/corridor/wall) generation. So this issue is more specific to the door placement algorithm. Adding a condition "do not place doors next to an existing door" sounds like a straightforward modification.

Well, IIRC, door placement has no relation to actual map (room/corridor/wall) generation.

Right, it doesn't, they're just added after the fact. I guess what I'm suggesting is to add them to the _map data as part of the digging process, so you can check for them when determining whether a feature is valid.

Adding a condition "do not place doors next to an existing door" sounds like a straightforward modification.

That might work. Removing one of the doors in the highlighted example would result in one of these:
#####          #####
#...#          #...#
#...#####      #...#####
#.......#      #...+...#
####+##.#      ####.##.#
   #.##.#         #.##.#
   #....#         #....#
   ######         ######

The left-hand example sort of makes sense, but the right-hand example looks like a door missing a wall next to it. Choosing which door to remove might involve looking at neighboring cells.
If both of the offending doors are removed, it doesn't look too bad but it might break the "every room has at least one door" test.

I guess what I'm suggesting is to add them to the _map data as part of the digging process, so you can check for them when determining whether a feature is valid.

Makes sense. Also probably makes the whole algo a lot more complex. Perhaps this approach can be used as a basis for a completely new map generating algorithm?
My own aesthetic criteria are probably not that strict: in my view, these maps correspond to hundred-years-old dungeons with many crumpled walls, damaged interiors and so on. Two doors next to each other do not pose a real issue.

If both of the offending doors are removed, it doesn't look too bad but it might break the "every room has at least one door" test.

I am okay with this as well. Door-less rooms are nothing special. In fact, I am not sure why the algorithm does place doors at all; perhaps doors should have been completely omitted and moved upwards to application-level?

Two doors next to each other do not pose a real issue.

Good point. DCSS does this occasionally and calls them "big doors." Opening a door opens all doors adjacent to it, and all doors adjacent to those, and so on, all at once. But I've never seen them in sequence in a tunnel; they usually appear like this:
#####
#...#####
#...+...#
#...+...#
#...#####
#####

It does seem reasonable to say that doors belong at application level, and just leave everything as-is, with the existing doors being more of a suggestion about where you might want to place doors if you feel like it. So I guess we can close this as "works as intended." :+1:


Release 0.1.0

Initial release

Coverage remained the same at 100.0% when pulling 4fc2a651325d14b2e1e406fe74a774446dd310f0 on develop into c5628589d54cf7a3fe05ccdf39ec35b6a397bb78 on master.


Unpublishing does not reindex

It needs to reindex so it no longer displays in explore.

It needs to delete the submission from solr, not reindex.


Unity does't recognize NN Model file

I have done everithing step by step but NN Model file MiDaS_model-small.onnx is not recognized in Unity 2021.3.18f

Hi @tomihr, what happens when you select the model and look at the Inspector ? Does it show anything?
I'm going to test in Unity 2022 today

@tomihr I can confirm it works on Unity 2021.2.17 with Barracuda 3.0.0

It seems that model file is corupted, when I used other one it worked.On Mar 10, 2023 13:58, George Adamopoulos @.***> wrote:
Hi @tomihr, what happens when you select the model and look at the Inspector ? Does it show anything?
I'm going to test in Unity 2022 today
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

This happened to me once, for no apparent reason, and downloading the model again did the trick!
FYI, I just tested succesfully with 2022.2.7 with all the latest packages, and I will push a new version shotly.


Updating radiator CSS to match that of the main CSS.

Changed wording for Pending to Noop. Fixing #365

Coverage remained the same at 80.417% when pulling ecf94ef6faa7cd1177d38a6fbcf8d37a5ce9c9af on mterzo:radiator_color_scheme into f4d751060ad9f555acb66be112e135a794b0e67f on voxpupuli:master.

Old Radiator

New Radiator


Looking for documentation for the effects/load of using the Kubernetes resource lock

Hey all,
This project looks really neat and conceptually, I love the idea of just making a ConfigMap or similar as my locked resource.
Has there been any testing/verification on the scalability of an approach like this? How long does it take to acquire a lock? How does the control plane behave when you have multiple services trying to ask for the same lock?
Has the feature been extensively tested?
Thanks!

Hi!
The basic mechanics behind distributed lockgate locker (whether it is kubernetes or http) is that it uses some key-value storage with optimistic locking. Key-value storage with optimistic locking means that one process that tries to update some value by some key:

Should first read current value by this key and handle its value.
May receive an error like "this key has been changed" on update operation by this key if value has been changed since first read. In this case process should reread current value again and handle this new value appropriately.

In the case of kubernetes-locker all locks info stored in such storage with optimistic locking support — resource annotations. Kubernetes itself uses etcd to implement such locks.
We are using this library in the werf project: https://github.com/werf/werf. Which is a cli tool to perform CI/CD operations. It needs distributed locks to implement distributed caching of built images. This library is good enough for such short lived build processes and does it job well.
Note that a client that makes use of lockgate distributed locking should implement a procedure to recover from exceptional situation when a lock lease has been lost. A client which holds a lock should renew given lease periodically or this lock will be overtaken by another client. A client that lost lease due to network problems or smth else will receive exception response from server and should handle this situation. In the werf we crash current image build process immediately when such exception has been detected.

If I'm understanding correctly, you wouldn't recommend using the Kubernetes locker to do a long term lock that would be used for a case like leader election. Is that right?

I think for such task it is better to use etcd itself, rather than lockgate.

Understood! Thank you.


%checks type refinement function for opaque alias types

I'm using opaque alias types described here: https://flow.org/en/docs/types/opaque-types/
I'm also using the undocumented checks% hack to define type refinement functions, for example
declare function isHash(x: mixed): boolean %checks(typeof x === "string");

and the actual function is defined as
function isHash (thing: mixed): boolean {
    return typeof thing === 'string' && StorageBaseCommon.CRYPTO_HASH_RE.test(thing);
}

(I have a reason for using a separate declare statement to have the %checks on instead of putting it right on the actual function, but that's not important now.)
My problem is that I don't seem to have a way to write a type refinement function for an opaque alias type?
For example, I use SHA-256 hashes in my code, which are strings, but very special strings (obviously). So I'm using an alias
export opaque type SHA256Hash: string = string;

It's very unfortunate that I can't just tell Flow that a function checks a given type, that I can only use typeof and instanceof. That only works for "fake OOP" class-based programming where instanceof works. It doesn't work for a functional style when I have just different kinds of plain objects and no inheritance and nothing is constructed using new. And plain types cannot be aliased if only typeof is allowed for refinement.

There are some limitations with refinements on opaque types:

Opaque types can be refined based on their type body in the same file. try-Flow
Opaque types can not be refined based on the defined super-type. try-Flow

This issue is not really related to the %checks functionality, though the limitations apply there as well.


[core] Support commit metrics

Purpose

Linked issue: close #1468

Remove total- metrics, which is more suitable to query system files table.


Broken download link for matcaps

The download links for all the matcaps I checked link to "/material/undefined" which returns an error 500
Example: https://market.pmnd.rs/material/basic-1 https://market.pmnd.rs/material/clay-white

I was beaten to it https://github.com/pmndrs/market/issues/25