config.yml

# The description and configuration of the hardware
Hardware:
  # The frequency in Hz the SPI bus is run. You can't get dramatically
  # higher in the Raspi as it seems 
  SPIFrequency: 2097152
  # Here we describe aspects of how exactly the display is being set up
  Display:
    # This number gives how often the LED stripes are forcefully set
    # new even when no changes happen from any producer. The reason is
    # that sometimes electrical noise or interference may randomly
    # change around the status of some LEDs (lit/unlit, color). So we
    # make sure to set the whole stripes back to the desired values
    # every short interval
    ForceUpdateDelay: 500ms
    # How many "internal LEDs"" in total are there for the producers
    # to work with. These are not necessarily the number of LEDs on
    # the stripes (see below)
    LedsTotal: 165
    # My LED stripes used are unfortunately very much on the bluish
    # side of things when evenly lit. Internally, we simply calculate
    # with RGB {255, 255, 255} being the desired full white. When
    # translating to what the real LEDs should display, we apply these
    # correction factors (you can see how extremely heavy I need to
    # dampen the blue and green component to arrive at a desired nice,
    # warm white color). This is a very crude way to do so, but enough
    # for my needs for now. The goal for me is to ensure that a white
    # color setting for the sensorled (see below) is pleasant to my
    # eyes.
    ColorCorrection: [1, 0.175, 0.05]
    # Here comes the mapping of the internal representation of the
    # "LedsTotal" LEDs to groups of real world segments of LED
    # stripes. Note: The segments in one group MUST NOT overlap. LEDs
    # not covered by a segment in a group become "virtual" segments in
    # that group. Using multiple groups becomes necessary when you
    # e.g.  want to illuminate a hallway with stripes on the walls
    # left and right of the hallway. Then you will need segments that
    # overlap or in other words: The same internal LED will be part of
    # multiple segments (one on the left wall of the hallway, one on
    # the right). Using groups you can have that, as the non
    # overlapping rule only applies to segments belonging to the same
    # group.
    LedSegments:
      # The index of the LED from the internal stripe that is the
      # first LED of the segment
      GroupA:
        - FirstLed: 0
          # and the same for the last one
          LastLed: 69
          # which SPI multiplex configuration should be used to address
          # that stripe (see below). If "Visible" is false this is
          # ignored
          SpiMultiplex: L1
          # If the segments low index starts at the end where the
          # connector is or the other way around
          Reverse: false
        - FirstLed: 111
          LastLed: 164
          SpiMultiplex: L2
          Reverse: false
      # NOTE: This example "GroupB" will NOT WORK on real hardware, as
      # I am using "XXX", "YYY" and "ZZZ" for SpiMultiplex here, which are not
      # a defined SpiMultiplex definition (see below). When running it
      # in the simulation mode it will still work. Every real segment
      # on the real hardware needs a valid mapping to a SPiMultiplex
      # definition!
      
      # GroupB:
      #   - FirstLed: 30
      #     LastLed: 60
      #     SpiMultiplex: XXX
      #   - FirstLed: 75
      #     LastLed: 100
      #     SpiMultiplex: YYY
      #   - FirstLed: 120
      #     LastLed: 150
      #     SpiMultiplex: ZZZ
  # This section describes the placement and other properties of the
  # IR sensors being attached to the system.
  Sensors:
    # how many reading of the sensor should be combined into a mean
    # value for further processing. Helps to reduce random spikes and
    # false positive triggers
    SmoothingSize: 3
    # hove often the sensors should be read. Small delay -> more
    # frequent readout
    LoopDelay: 20ms
    # Here comes the configuration of each single sensor
    SensorCfg:
      # We give it a uid, that is also used to create an associated
      # instance of a SensorLed producer
      S0:
        # Where on the LED strip the sensor sits
        LedIndex: 0
        # Like for the display - which SPI multiplex configuration to
        # use to access the ADC that handles this sensor
        SpiMultiplex: ADC1
        # The channel (0-7) on this ADC where the sensor is attached to
        AdcChannel: 0
        # The sensor needs to read a value > TriggerValue for the
        # program to register a trigger event. This is set via try and
        # error to be low enough that people passing by are always
        # registered, but noise and IR cross talk is not randomly
        # triggering
        TriggerValue: 130
      S1:
        LedIndex: 69
        SpiMultiplex: ADC1
        AdcChannel: 7
        TriggerValue: 120
      S2:
        LedIndex: 111
        SpiMultiplex: ADC2
        AdcChannel: 0
        TriggerValue: 130
      S3:
        LedIndex: 164
        SpiMultiplex: ADC2
        AdcChannel: 5
        TriggerValue: 120
  # Here we define which settings on what GPIO pin will result in the
  # multiplexer to select a certain device to be accessible via SPI
  SpiMultiplexGPIO:
    # This is the "SpiMultiplex" being referred to above in SensorCfg
    # and LedSegment  
    L1:
      # All pins that must be set low 
      Low: [17]
      # All pins that must be set high
      High: [22,23,24]
    L2:
      Low: [22]
      High: [17,23,24]
    ADC1:
      Low: [17,22,23]
      High: [24]
    ADC2:
      Low: [17,22,24]
      High: [23]

# Here come all the different producer configurations that are
# currently available in the system

# The central SensorLedProducer - for each sensor, one instance of
# this will be set up. Here is the shared config, while the index of
# the sensor determines where the zero point on the stripe is for the
# grow -> stay -> shrink effect
SensorLED:
  # well, you could potentially just not enable the whole thing but
  # that would effectively turn off the core functionality of the
  # whole system
  Enabled: true
  # How fast it grows one LED at a time in both directions
  RunUpDelay: 5ms
  # How fast it shrinks down again
  RunDownDelay: 20ms
  # How long it stays in the fully lit state
  HoldTime: 10s
  # the color and intensity of the lit LEDs. See also the description
  # of the ColorCorrection parameter above
  LedRGB: [70, 70, 70]

# A producer that generates a continuous light between sunset and
# sunrise identical for all LEDs
NightLED:
  Enabled: true
  # Sunrise and sunset depend on the geographical place where the
  # system is installed
  Latitude: 49.014
  Longitude: 8.4043
  # an array of color definitions to use during the night. The
  # duration between sunset and sunrise is evenly divided between the
  # different definitions. 
  LedRGB:
    - [1, 0, 0]
    # Repeating the same color multiple times
    # essentially makes the time the color is shown proportionally
    # longer (here: 2/3 of the night a red glow, 1/3 a blue glow)
    - [1, 0, 0]
    # There is a 20 instead of a 1 here because of the ColorCorrection
    # explained above. Setting the blue component to 1 would otherwise
    # reduce the light to not be visible at all. So 20 * 0.05 = 1 is
    # the lowest visible setting for blue.
    - [0, 0, 20]

# A producer that reacts to getting continuous trigger events from one
# sensor for a minimum time of TriggerDelay and of a Value greater
# than TriggerValue. This will light the full stripe for maximum
# HoldTime with the color and intensity given in LedRGB. In other
# words: you can hold your hand very close to one sensor for longer
# than TriggerDelay, and the whole stripe will light up for a certain
# time. You can alternatively stop the producer when running by
# holding your hand very close for the same time again (toggling
# between on and off)
HoldLED:
  Enabled: true
  HoldTime: 5m
  TriggerDelay: 3s
  TriggerValue: 200
  LedRGB: [140, 140, 140]

# A cute little effect of colored blobs moving around on the stripe,
# bouncing and reflecting of each other, and having their color
# components mixed. It will be triggered by the end of the sensorled
# effect (that means: when all LEDs are dark again after a
# sensorledproducer has done its grow-stay-shrink cycle)  
MultiBlobLED:
  Enabled: true
  # How long to stay active after starting
  Duration: 120s
  # How much delay between moving the blobs around one step. Smaller
  # delay -> faster movement
  Delay: 120ms
  # All the blobs that should be visible
  BlobCfg:
    BlobRed:
      # How much to move with each step
      DeltaX: 0.3
      # Where to start on the stripe
      X: 20
      # A measure that influences the width of the blob. Just play
      # around with the numbers here
      Width: 512
      # The color and intensity of the blob
      LedRGB: [30, 0, 0]
    BlobGreen:
      # negative means: start to move to the left
      DeltaX: -0.5
      X: 40
      Width: 512
      LedRGB: [0, 30, 0]
    BlobBlue:
      DeltaX: 0.4
      X: 130
      Width: 768 
      LedRGB: [0, 0, 40]
    BlobRed2:
      DeltaX: -0.2
      X: 150
      Width: 512 
      LedRGB: [30, 0, 0]

# This is an example of a very simple producer. It produces a (default
# red) dot that is moving rapidly from left to right and back (a bit
# like the cylons from Battlestar Galactica... hence the name).  Look
# into the source code of cylonproducer.go to see how to set up a
# minimal producer.
CylonLED:
  Enabled: false
  # How long to be active before shutting down again
  Duration: 20s
  # Delay between moving 1 Step to left or right. 
  Delay: 30ms
  # How far to move per step (in LEDs). Can be a float.
  Step: 1.7
  # Width of the dot moving around
  Width: 7
  # Color of the dot.
  LedRGB: [255, 0, 0]