1# phosphor-led-manager 2 3This project manages LED groups on dbus. Sometimes many LEDs must be driven 4together to indicate some system state. 5 6For example, there can be multiple identify LEDs. When the user wants to 7identify the system, they should all light up together. 8 9## Configuration 10 11The configuration can happen via json or yaml. 12 13### Configuration: LED Priority 14 15Each LED can have "Priority" as "Blink", "Off" or "On". If this property is 16defined, it should be defined on each instance of the LED in the config. 17 18When multiple LED groups are asserted and contain the same LED, "Priority" 19determines the state of the LED. 20 21For example, Group 1 says LED1 should be "Blink", and Group 2 says it should be 22"On". LED1 will then have the state declared in "Priority". 23 24## Configuration: LED Group Priority 25 26Using LED Priority is fine for simple configurations, but when group state needs 27to always be consistent, Group Priority can be used to enforce the consistent 28representation. 29 30The Group `Priority` is optional and a higher priority means that when 2 groups 31are asserted, the one with highest `Priority` will be represented consistently. 32Meaning all its LEDs will have the state as per the configuration. 33 34## Configuration Example with Group Priorities (JSON) 35 36Here we prioritize the locating group above the fault group since locating may 37be required to fix the fault. 38 39So independent of the order that these groups are asserted, if both are 40asserted, "sys_id" should be in "Blink" state. 41 42The "unrelated" group will have the default group priority of 0. 43 44```json 45{ 46 "leds": [ 47 { 48 "group": "enclosure_identify", 49 "Priority": 2, 50 "members": [ 51 { 52 "Name": "sys_id", 53 "Action": "Blink" 54 }, 55 { 56 "Name": "rear_id", 57 "Action": "Blink" 58 } 59 ] 60 }, 61 { 62 "group": "fault", 63 "Priority": 1, 64 "members": [ 65 { 66 "Name": "sys_id", 67 "Action": "On" 68 }, 69 { 70 "Name": "fault", 71 "Action": "On" 72 } 73 ] 74 }, 75 { 76 "group": "unrelated", 77 "members": [ 78 { 79 "Name": "rear_id", 80 "Action": "On" 81 } 82 ] 83 } 84 ] 85} 86``` 87 88### Configuration Example (JSON) 89 90This is our configuration file. It describes 2 LEDs for the 91'_enclosure_identify_' group, with their respective states and duty cycles. 92 93```json 94{ 95 "leds": [ 96 { 97 "group": "enclosure_identify", 98 "members": [ 99 { 100 "Name": "pca955x_front_sys_id0", 101 "Action": "On", 102 "DutyOn": 50, 103 "Period": 0, 104 "Priority": "Blink" 105 }, 106 { 107 "Name": "led_rear_enc_id0", 108 "Action": "On", 109 "DutyOn": 50, 110 "Period": 0, 111 "Priority": "Blink" 112 } 113 ] 114 } 115 ] 116} 117``` 118 119Then start the program with 120 121```text 122~# ./phosphor-led-manager --config example.json 123``` 124 125## Dbus interface 126 127When starting the program, our LED group shows up on dbus. Usually there will be 128many more groups. 129 130```text 131$ busctl tree xyz.openbmc_project.LED.GroupManager 132`- /xyz 133 `- /xyz/openbmc_project 134 `- /xyz/openbmc_project/led 135 `- /xyz/openbmc_project/led/groups 136 `- /xyz/openbmc_project/led/groups/enclosure_identify 137 138 139$ busctl introspect xyz.openbmc_project.LED.GroupManager /xyz/openbmc_project/led/groups/enclosure_identify 140NAME TYPE SIGNATURE RESULT/VALUE FLAGS 141... 142xyz.openbmc_project.Led.Group interface - - - 143.Asserted property b false emits-change writable 144``` 145 146In the above output, the usual org.freedesktop.\* interfaces have been removed 147to keep it readable. 148 149We can now drive the entire group by setting it's 'Asserted' property on dbus. 150 151```text 152$ busctl set-property \ 153xyz.openbmc_project.LED.GroupManager \ 154/xyz/openbmc_project/led/groups/enclosure_identify \ 155xyz.openbmc_project.Led.Group Asserted b true 156``` 157 158The program can then use the _xyz.openbmc_project.Led.Physical_ dbus interface 159exposed by _phosphor-led-sysfs_ to set each LED state. 160 161## How to Build 162 163```text 164meson setup build 165cd build 166ninja 167``` 168