You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if a user can overwrite the initial state of charge, they could do so with the wrong unit (ratio vs percent). to avoid this, we could add optional numeric range fields for these types, and use them during encode/decode operations as constraints which can cause StateError responses. for example:
pubenumCustomFeatureFormat{FloatingPoint{initial:OrderedFloat<f64>,min:Option<OrderedFloat<f64>>,max:Option<OrderedFloat<f64>>},
...
}implCustomFeatureFormat{pubfnencode_f64(&self,value:&f64) -> Result<StateVar,StateError>{matchself{CustomFeatureFormat::FloatingPoint{initial: _, min, max } => {let min_val = min.unwrap_or(OrderedFloat(f64::MIN));if value < min_val {Err(...)// also test vs max}else{Ok(StateVar(*value))}},
_ => Err(StateError::EncodeError(UnitCodecType::FloatingPoint.to_string(),self.name(),)),}}
...
}
testing this
The text was updated successfully, but these errors were encountered:
if a user can overwrite the initial state of charge, they could do so with the wrong unit (ratio vs percent). to avoid this, we could add optional numeric range fields for these types, and use them during encode/decode operations as constraints which can cause StateError responses. for example:
testing this
The text was updated successfully, but these errors were encountered: