Perhaps an example of how hardware normally uses the LD1/2/3 information will clarify things. SwitchLinc A is the controller, SwitchLinc B is the responder. When the link was established between A and B, SwitchLinc B as the responder stores the currently locked in values for bright level and ramp rate in the LD1 and LD2 fields in the responder link record in B.
When A sends an ON command to B, B searches through its link records and when a match is found, B responds by turning on to the bright level, and using the ramp rate that is stored in LD1 and LD2 respectively.
Now replace responder SwitchLinc B with EZSrve as a responder. When EZSrve receives the ON command from A, EZSrve does not “turn on” like a conventional responder so the LD1/LD2 values have no meaning.
When SwitchLinc A sends a command to a responder, the responder has no information regarding the state of SwitchLinc A. If SwitchLinc A had local bright level and ramp rate set it could be half bright and taking many seconds to get there. The responder has no way of knowing any of this information. Even if the responder is intelligent (like EZSrve), querying the controller may not tell the whole story as is the case of a slow ramp rate. A query of the controller will tell you what the current bright level is but if a slow ramp rate is in progress the controller will produce a different bright level on the next query.