1# events.json
2
3This file defines the events that dictate how fan control operates. Each event
4can contain groups, triggers, and actions.
5
6Actions are where fan targets are calculated and set, among other things.
7Triggers specify when an action should run. Groups specify which D-Bus objects
8the triggers and actions should operate on.
9
10Some actions have modifiers, which help calculate a value.
11
12- [Groups](#groups)
13- [Triggers](#triggers)
14- [Actions](#actions)
15- [Modifiers](#modifiers)
16
17## Example
18
19```
20[
21   {
22     "name": "fan(s) missing",
23     "groups": [
24       {
25         "name": "fan inventory",
26         "interface": "xyz.openbmc_project.Inventory.Item",
27         "property": { "name": "Present" }
28       }
29     ],
30     "triggers": [
31       {
32         "class": "init",
33         "method": "get_properties"
34       },
35       {
36         "class": "signal",
37         "signal": "properties_changed"
38       }
39     ],
40     "actions": [
41       {
42         "name": "count_state_before_target",
43         "count": 1,
44         "state": false,
45         "target": 15000
46       }
47     ]
48   }
49]
50```
51
52The above event is an example of a method to set the fan target to 15000 when
53one or more fans is missing. The basic behavior with this config is:
54
55The trigger `init.get_properties` will, on fan control startup, read the Present
56property on the `xyz.openbmc_project.Inventory.Item` interface from every D-Bus
57object in the 'fan inventory' group, update those values in the object cache,
58and then call the `count_state_before_target` action.
59
60The trigger `signal.properties_changed` will watch for changes on the Present
61property on each D-Bus object in the group, update the new value in the object
62cache, and call the `count_state_before_target` action when the value changes.
63
64The `count_state_before_target` action will look at the object cache value of
65the Present property on each member of the group and set the fan target hold to
6615000 when one or more of them is false. Otherwise, it will clear its fan target
67hold.
68
69## Groups
70
71```
72"groups": [
73    {
74        "name": "<name>",
75        "interface": "<interface>",
76        "property": { "name": "<name>" }
77    }
78    ...
79]
80```
81
82### name
83
84The name of a group that must be also be defined in [groups.json](groups.md).
85
86### interface
87
88The actions and triggers defined with this group will look at this D-Bus
89interface on the members of this group.
90
91### property: name
92
93The actions and triggers defined with this group will look at this D-Bus
94property on the members of this group.
95
96## Triggers
97
98There are several classes of triggers, and the JSON configuration is different
99for each.
100
101### init
102
103Init triggers run when fan control events are enabled on fan control startup.
104After invoking the configured method, any actions configured for this trigger
105will run.
106
107```
108{
109    "class": "init",
110    "method": "<method>"
111}
112```
113
114#### methods
115
1161. `get_properties` - Read the property configured for the group from every
117   member of the group, and store it in fan control's object cache.
118
1192. `name_has_owner` - Populates the service owned state from D-Bus for each
120   group member in fan control's D-Bus service cache map.
121
122### signal
123
124Signal triggers subscribe to certain D-Bus signals for each member of its
125configured group. After handling the signal, any configured actions are run.
126
127```
128{
129    "class": "signal",
130    "signal": "<signal>"
131}
132```
133
134#### signal types
135
1361. `properties_changed` - Subscribes to the PropertiesChanged signal for the
137   D-Bus interface and property specified in the group definition for each group
138   member. When the signal occurs, the new property value will be added to or
139   updated in the object cache.
140
1412. `interfaces_added` - Subscribes to the InterfacesAdded signal for the D-Bus
142   interface specified in the group definition for each group member. When the
143   signal occurs, the interface and its properties will be added to the object
144   cache.
145
1463. `interfaces_removed` - Subscribes to the InterfacesRemoved signal for the
147   D-Bus interface specified in the group definition for each group member. When
148   the signal occurs, the interface and properties will be removed from the
149   object cache.
150
1514. `name_owner_changed` - Subscribes to the NameOwnerChanged signal for the
152   services that host the D-bus interface specified in the group definition for
153   each group member. When the signal occurs, the service owned state will be
154   updated in the service cache map.
155
1565. `member` - Subscribes to the signal listed on each group member. No caches
157   are updated when the signal occurs.
158
159### timer
160
161Timer triggers run actions after the configured type of timer expires.
162
163```
164{
165    "class": "timer",
166    "type": "<type>",
167    "interval": "<interval>",
168    "preload_groups": "<true/false>"
169}
170```
171
172#### type
173
1741. `oneshot` - Starts a timer that runs once.
175
1762. `repeating` - Starts a repeating timer.
177
178#### interval
179
180The timer length in microseconds
181
182#### preload_groups
183
184Optional, if set to true, will update the D-Bus properties from the configured
185groups in the object cache after the timer expires but before any actions run.
186
187### parameter
188
189Parameter triggers run actions after a parameter changes.
190
191```
192{
193    "class": "parameter",
194    "parameter": "<parameter>"
195}
196```
197
198#### parameter
199
200The parameter value to watch.
201
202### poweron
203
204PowerOn triggers run when the power turns on. Functionally, they behave like an
205init trigger.
206
207```
208{
209    "class": "poweron",
210    "method": "<method>"
211}
212```
213
214#### method
215
216The methods are the same as with the init trigger.
217
218### poweroff
219
220PowerOff triggers run when the power turns off. Functionally, they behave like
221an init trigger.
222
223```
224{
225    "class": "poweroff",
226    "method": "<method>"
227}
228```
229
230#### method
231
232The methods are the same as with the init trigger.
233
234## Actions
235
236Actions can either operate on the groups listed with the event, or on the groups
237listed within the action's JSON config.
238
239Most actions set fan targets or floors. This can be done by requesting a target
240value explicitly, or by requesting an increase or decrease delta. Targets and
241floors can also be set with a hold, meaning another action can't set a
242floor/target below the one that is held.
243
244Some actions set or read a key/value pair called a parameter. These can be
245created, updated, and deleted as necessary. For example, one action may
246calculate and set a `floor_index` parameter, and another action may then read
247that parameter to help choose a fan floor.
248
249The available actions are:
250
251- [set_net_increase_target](#set_net_increase_target)
252- [set_net_decrease_target](#set_net_decrease_target)
253- [count_state_floor](#count_state_floor)
254- [count_state_before_target](#count_state_before_target)
255- [default_floor_on_missing_owner](#default_floor_on_missing_owner)
256- [mapped_floor](#mapped_floor)
257- [set_target_on_missing_owner](#set_target_on_missing_owner)
258- [override_fan_target](#override_fan_target)
259- [pcie_card_floors](#pcie_card_floors)
260- [set_request_target_base_with_max](#set_request_target_base_with_max)
261- [set_parameter_from_group_max](#set_parameter_from_group_max)
262- [target_from_group_max](#target_from_group_max)
263- [call_actions_based_on_timer](#call_actions_based_on_timer)
264- [get_managed_objects](#get_managed_objects)
265
266### set_net_increase_target
267
268Calculates the net target increase to be requested based on the value of each
269property given within a group. The net target increase is based on the maximum
270difference between the `delta` JSON value and all of the properties of the
271group. The final result is the increase change that's requested to the current
272target of a zone.
273
274The group values can be compared to either a value hardcoded in the JSON, or a
275parameter value.
276
277```
278{
279    "name": "set_net_increase_target",
280    "groups": [{
281        "name": "pcie temps",
282        "interface": "xyz.openbmc_project.Sensor.Value",
283        "property": { "name": "Value" }
284      }],
285    "state": 70.0,
286    "delta": 255
287}
288```
289
290The above config uses a hardcoded state value:
291
2921. For each member of the 'pcie temps' group:
293
294- Read its 'Value' D-Bus property.
295- If that property value is greater than the 'state' value of 70.0:
296- Subtracts 70.0 from the property value.
297- Multiplies that difference by the 'delta' value of 255.
298
2992. Requests an increase of the largest calculated delta value, if there is one.
300
301```
302{
303    "name": "set_net_increase_target",
304    "groups": [{
305        "name": "proc0 core temps",
306        "interface": "xyz.openbmc_project.Sensor.Value",
307        "property": { "name": "Value" }
308      }],
309    "state_parameter_name": "proc_0_core_dvfs_increase_temp",
310    "delta": 300
311}
312```
313
314The above config uses a parameter as the state value:
315
3161. For each member of the 'proc 0 core temps' group:
317
318- Read its 'Value' D-Bus property.
319- If that property value is greater than the value of the parameter listed in
320  the 'state_parameter_name' field, in this case
321  'proc_0_core_dvfs_increase_temp':
322- Subtracts that parameter value from the property value.
323- Multiplies that difference by the 'delta' value of 300.
324
3252. Requests an increase of the largest calculated delta value, if there is one.
326
327### set_net_decrease_target
328
329Calculates the net target decrease to be requested based on the value of each
330property given within a group. The net target decrease is based on the minimum
331difference between the `delta` JSON value and all properties in the group. The
332final result is the decrease change that's requested to the current target of a
333zone.
334
335The group values can be compared to either a value hardcoded in the JSON, or a
336parameter value.
337
338```
339{
340    "name": "set_net_decrease_target",
341    "groups": [{
342        "name": "pcie temps",
343        "interface": "xyz.openbmc_project.Sensor.Value",
344        "property": { "name": "Value" }
345      }],
346    "state": 65.0,
347    "delta": 80
348}
349
350```
351
352The above config uses a hardcoded state value:
353
3541. For each member of the 'pcie temps' group:
355
356- Read its 'Value' D-Bus property.
357- If that property value is less than the 'state' value of 65.0:
358- Subtracts the property value from 65.0.
359- Multiplies that difference by the 'delta' value of 80.
360
3612. Requests a decrease of the smallest calculated delta value, if there is one.
362
363```
364{
365    "name": "set_net_decrease_target",
366    "groups": [{
367        "name": "proc 0 core temps",
368        "interface": "xyz.openbmc_project.Sensor.Value",
369        "property": { "name": "Value" }
370      }],
371    "state_parameter_name": "proc_0_core_dvfs_decrease_temp",
372    "delta": 50
373}
374```
375
376The above config uses a parameter as the state value:
377
3781. For each member of the 'proc 0 core temps' group:
379
380- Read its 'Value' D-Bus property.
381- If that property value is less than the value of the parameter listed the
382  'state_parameter_name' field, in this case 'proc_0_core_dvfs_decrease_temp':
383- Subtracts the property value from the parameter value.
384- Multiplies that difference by the 'delta' value of 50.
385
3862. Requests a decrease of the smallest calculated delta value, if there is one.
387
388### count_state_floor
389
390Sets the fans to a configured floor when a number of members within the group
391are at a configured state. Once the number of members at the given state falls
392below the configured count, the floor hold is released.
393
394```
395{
396    "name": "count_state_floor",
397    "count": 2,
398    "state": false,
399    "floor": 18000,
400    "delay": 3
401}
402```
403
404The above config reads the configured D-Bus property on each group member
405configured for the action. If two or more members have a property value of false
406for 3 seconds, a floor hold will be requested with a value of 18000. Otherwise,
407the floor hold will be released (if it was previously requested).
408
409### count_state_before_target
410
411Sets the fans to a configured target when a number of members within the group
412are at a configured state. Once the number of members at the given state falls
413below the configured count, active fan target changes are allowed.
414
415```
416{
417    "name": "count_state_before_target",
418    "count": 1,
419    "state": false,
420    "target": 18000
421}
422```
423
424The above config reads the configured D-Bus property on each group member
425configured for the action. If one or more members have a property value of
426false, a target hold will be requested with a value of 18000. Otherwise, the
427hold will be released (if it was previously requested).
428
429### default_floor_on_missing_owner
430
431Sets the fan floor to the defined zone's default fan floor when a service
432associated to a given group has terminated. Once all services are functional and
433providing the sensors, the fan floor is allowed to be set normally again.
434
435There is no additional JSON config for this action.
436
437### mapped_floor
438
439This action can be used to set a floor value based on 2 or more groups having
440values within certain ranges, where the key group chooses the set of tables in
441which to check the remaining group values.
442
443```
444{
445  "name": "mapped_floor",
446  "key_group": "ambient temp",
447  "default_floor": 5555,
448  "fan_floors": [
449   {
450     "key": 25,
451     "default_floor": 4444,
452     "floor_offset_parameter": "ambient_25_altitude_offset",
453     "floors": [
454       {
455         "parameter": "pcie_floor_index",
456         "floors": [
457           { "value": 1, "floor": 2000 },
458           { "value": 2, "floor": 3000 },
459           { "value": 3, "floor": 4000 },
460           { "value": 4, "floor": 5000 },
461           { "value": 5, "floor": 6000 }
462         ]
463       },
464       {
465         "group": "power save",
466         "floors": [
467            { "value": true, "floor": 1000 }
468         ]
469       }
470     ]
471   }
472}
473```
474
475The above config will use the maximum value of the 'ambient temp' group as the
476key into the 'fan_floors' tables. There is one of those tables listed, and it
477will be used when the key group has a max value of less than 25.
478
479It will then traverse the contained floors arrays, keeping track of the highest
480valid floor value it finds. If it doesn't find any valid floor values, it will
481use the `default_floor` value of 4444, though that value is optional.
482
483If no valid tables were found given the key value, the `default_floor` value of
4845555 would be used, though that is optional and if not supplied the code would
485default to the default floor of the zone.
486
487At the end of the analysis, a floor hold will be set with the final floor value.
488
489This action can also have a condition specified where a group property must
490either match or not match a given value to determine if the action should run or
491not. This requires the following in the JSON:
492
493- "condition_group": The group name
494  - For now, this group must just have a single member.
495- "condition_op": Either "equal" or "not_equal"
496- "condition_value": The value to check against
497
498For example, the following says the single member of the 'cpu 0' group must have
499its Model property be equal to "1234" for the action to run:
500
501```
502    "groups": [{
503        "name": "cpu 0",
504        "interface": "xyz.openbmc_project.Inventory.Decorator.Asset",
505        "property": { "name": "Model" }
506      }
507      ...
508    ],
509    ...
510    "name": "mapped_floor",
511    "key_group": "ambient temp",
512    "condition_group": "cpu 0",
513    "condition_value": "1234",
514    "condition_op": "equal",
515    ...
516```
517
518### set_target_on_missing_owner
519
520Sets the fans to a configured target when any service owner associated to the
521group is missing. Once all services are functional and providing all the group
522data again, active fan target changes are allowed.
523
524```
525{
526    "name": "set_target_on_missing_owner",
527    "groups": [{
528        "name": "fan inventory",
529        "interface": "xyz.openbmc_project.Inventory.Item",
530        "property": { "name": "Present" }
531      }],
532    "target": 18000
533}
534```
535
536The above config will set a target hold of 18000 when the service associated
537with the 'fan inventory' group is lost.
538
539### override_fan_target
540
541This action locks fans at configured targets when the configured `count` amount
542of fans meet criterion for the particular condition. A locked fan maintains its
543override target until unlocked (or locked at a higher target). Upon unlocking,
544it will either revert to temperature control or activate the next-highest target
545remaining in its list of locks.
546
547```
548{
549    "name": "override_fan_target",
550    "count": 1,
551    "state": false,
552    "fans": [ "fan0", "fan1", "fan2", "fan3" ],
553    "target": 10000
554}
555```
556
557The above config will lock all fans in the fans array at a target of 10000 when
558one or more members in its configured group have a group property value of
559false.
560
561This could be used for example, to lock the rotors of a multirotor fan to a high
562target when one of its rotors has a functional property equal to false.
563
564### pcie_card_floors
565
566Sets the `pcie_floor_index` parameter based on the current configuration of
567plugged and powered on PCIe cards, using data from the `pcie_cards.json` file.
568
569It chooses the highest index from the active PCIe cards to set in the parameter.
570
571It must be configured with the following groups and properties:
572
573- The PCIe slots with the PowerState property
574- The PCIe cards with the following properties: Function0DeviceId,
575  Function0VendorId, Function0SubsystemId, Function0SubsystemVendorId
576
577```
578{
579    "name": "pcie_card_floors",
580    "use_config_specific_files": true,
581    "settle_time": 2
582}
583```
584
585The `use_config_specific_files` field tells the code to look for the
586'pcie_cards.json' files in the same system specific directories as
587'events.json'. If missing or false, looks in the base fan control directory.
588
589The `settle_time` field is the amount of time in seconds that needs to pass
590without a call to run() from a group property value changing. As the PCIeDevice
591attributes are written close together by the host, this allows the action to
592wait until the writes are done before selecting the index.
593
594Additional details are in the
595[header file](../../control/json/actions/pcie_card_floors.hpp)
596
597### set_request_target_base_with_max
598
599Determines the maximum value from the properties of the group of D-Bus objects
600and sets the requested target base to this value. Only positive integer or
601floating point types are supported as these are the only valid types for a fan
602target to be based off of.
603
604The `requested target base` value is the base value to apply a target delta to.
605By default, it's the current zone target unless modified by this action.
606
607```
608{
609    "name": "set_request_target_base_with_max",
610    "groups": [{
611        "name": "fan targets",
612        "interface": "xyz.openbmc_project.Fan.Target",
613        "property": { "name": "Target" }
614      }]
615}
616```
617
618The above config will set the requested target base to the maximum Target
619property value of all members of the 'fan targets' group.
620
621### set_parameter_from_group_max
622
623Sets a parameter value based on the maximum group property value. The property
624value can be modified before storing it if the JSON specifies a valid modifier
625expression.
626
627```
628{
629   "name": "set_parameter_from_group_max",
630   "parameter_name": "proc_0_throttle_temp",
631   "modifier": {
632     "expression": "minus",
633     "value": 4
634   }
635}
636```
637
638The above config will first find the max of its groups property values, subtract
6394, and then store the resulting value in the `proc_0_throttle_temp` parameter.
640
641### target_from_group_max
642
643The action sets target of Zone to a value corresponding to the maximum value
644from maximum group property value. The mapping is based on a provided table. If
645there are more than one event using this action, the maximum speed derived from
646the mapping of all groups will be set to the zone's target.
647
648... { "name": "target_from_group_max", "groups": [ { "name":
649"zone0_ambient", "interface": "xyz.openbmc_project.Sensor.Value", "property":
650{ "name": "Value" } } ], "neg_hysteresis": 1, "pos_hysteresis": 0, "map": [
651{ "value": 10.0, "target": 38.0 }, ... ] }
652
653The above JSON will cause the action to read the property specified in the group
654"zone0_ambient" from all members of the group. The change in the group's members
655value will be checked against "neg_hysteresis" and "pos_hysteresis" to decide if
656it is worth taking action. "pos_hysteresis" is for the increasing case and
657"neg_hysteresis" is for the decreasing case. The maximum property value in the
658group will be mapped to the "map" to get the output "target". Each configured
659event using this action will be provided with a key in a static map to store its
660mapping result. The static map will be shared across the events of this action.
661Therefore, the updated "target" value derived from "zone0_ambient" will be
662stored in that static map with its own key. Each time it calls this action
663running for each event, after the new value is updated to the static map, the
664maximum value from it will be used to set to the Zone's target.
665
666### call_actions_based_on_timer
667
668This action starts and stops a timer that runs a list of actions whenever the
669timer expires. A timer can be either `oneshot` or `repeating`.
670
671When all groups have a configured value to compare against, that will be
672compared against all members within each group to start/stop the timer. When all
673group members have a given value and it matches what's in the cache, the timer
674is started and if any do not match, the timer is stopped.
675
676When any group does not have a configured value to be compared against, the
677groups' service owned state is used to start/stop the timer. When any service
678providing a group member is not owned, the timer is started and if all members'
679services are owned, the timer is stopped.
680
681Consider the following action config:
682
683```
684{
685    "name": "call_actions_based_on_timer",
686    "timer": {
687        "interval": 5000000,
688        "type": "oneshot"
689    },
690    "actions": [{
691        "name": "test"
692    }]
693}
694
695```
696
697If its group configuration has a property value listed, like:
698
699```
700{
701    "name": "fan inventory",
702    "interface": "xyz.openbmc_project.Inventory.Item",
703    "property": { "name": "Present", "value": true }
704}
705```
706
707Then a oneshot timer of 5000000us will be started when every member of the fan
708inventory group has a value of true. Otherwise, the timer will be stopped if
709it's running.
710
711If the group configuration has no property value listed, like:
712
713```
714{
715    "name": "fan inventory",
716    "interface": "xyz.openbmc_project.Inventory.Item",
717    "property": { "name": "Present" }
718}
719```
720
721Then the timer will be started when any service providing a group member isn't
722owned (on D-Bus). Otherwise, it will stop the timer if it's running.
723
724### get_managed_objects
725
726This action adds the members of its groups to the object cache by using the
727GetManagedObjects D-Bus method to find and add the results. When that is done,
728it then runs any actions listed in the JSON.
729
730This allows an action to run with the latest values in the cache without having
731to subscribe to propertiesChanged for them all.
732
733```
734{
735   "name": "get_managed_objects",
736   "groups": [
737     {
738       "name": "proc temps",
739       "interface": "xyz.openbmc_project.Sensor.Value",
740       "property": { "name": "Value" }
741     }
742   ],
743   "actions": [
744     {
745       "name": "set_net_increase_target",
746       "state": 30,
747       "delta": 100
748     }
749   ]
750}
751```
752
753The above config will make the GetManagedObjects call on all services that own
754the configured groups and then add all resulting property values to the object
755cache. After that, it will call the `set_net_increase_target` action using the
756same groups.
757
758## Modifiers
759
760Modifiers are used by some actions to help calculate values.
761
762### minus
763
764Subtract the `value` field from the passed in value.
765
766```
767"modifier": {
768    "expression": "minus",
769    "value": 4
770}
771```
772
773The above config subtracts 4 from what is passed to it.
774
775### less_than
776
777Returns a value from a data table that is selected when the argument passed in
778is less than the `arg_value` entry in the table row. If there is a
779`default_value` field supplied, then that will be returned if the argument is
780greater than the `arg_value` of the last row.
781
782```
783"modifier": {
784  "operator": "less_than",
785  "default_value": 10000,
786  "value": [
787      { "arg_value": 500, "parameter_value": 1 },
788      { "arg_value": 1000, "parameter_value": 2 },
789      { "arg_value": 1500, "parameter_value": 3 }
790  ]
791}
792```
793
794The above config returns 1 if the arg passed is less than 500, 2 if less than
7951000, and 3 if less than 1500. Otherwise returns 10000, the default value.
796