RS/YJ/Rule 6-10 (2022) #1845
RS/YJ/Rule 6-10 (2022) #1845
Conversation
| ltg_occupancy_control_type_match = True | ||
| ltg_daylighting_control_type_match = True | ||
| ltg_ltg_multiplier_schedule_match = True | ||
| for int_ltg_p in space_p["interior_lighting"]: |
There was a problem hiding this comment.
I think you need another one to make sure the length matched.
for example:
len(space_p["interior_lighting"]) == len(space_b["interior_lighting"])
There was a problem hiding this comment.
I'd like to double-check - My understanding is that we only compare the keys specified in the RDS (e.g., purpose_type, power_per_area, etc.) and do not need compare the keys not specified in the RDS (e.g., are_schedules_used_for_modeling_occupancy_control, are_schedules_used_for_modeling_daylighting_control) under the interior_lighting.
There was a problem hiding this comment.
And, thus do the lengths not need to be the same?
There was a problem hiding this comment.
The rule assertion is at space data group level. I think the first thing need to make sure is the proposed has the same number of lighting, equipment etc as baseline. This is not checked in the proposed-baseline. With this code:
for int_ltg_p in space_p["interior_lighting"]:
int_ltg_b = find_exactly_one_with_field_value(
"$.interior_lighting[*]", "id", int_ltg_p["id"], space_b
)I think it will still pass if baseline just add one more lighting object in its "interior_lighting", which should be incorrect.
| @@ -0,0 +1,347 @@ | |||
| from rct229.rule_engine.rule_base import RuleDefinitionBase | |||
There was a problem hiding this comment.
Should this rule also included in the 2019?
I haven't tested this rule yet. Thanks!