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
We've found a bug with the current implementation of discharge events for some appliances. Some appliances are used in close succession such as the use of a KitchenTap during morning and evening use by multiple users. In a situation where the sampled discharge_flow_rate is slower than the consumption flow rate, the discharge time will extend past the consumption event time - this is correct. The problem arises if the next consumption event begins before the discharge event for the previous consumption event has finished. Currently the discharge event will overwrite the data from the previous discharge event -> therefore resulting in water volume vanishing from the system.
The proposed solution is to add a check for each discharge event to check that if there is a non-zero discharge_flow_rate at the expected discharge start time, to delay this discharge start time to the next timestamp with a zero discharge_flow_rate. This would allow the full remaining water from the previous consumption event to be fully discharged before discharging the volume added by the latest consumption.
The text was updated successfully, but these errors were encountered:
We've found a bug with the current implementation of discharge events for some appliances. Some appliances are used in close succession such as the use of a
KitchenTap
during morning and evening use by multiple users. In a situation where the sampleddischarge_flow_rate
is slower than the consumption flow rate, the discharge time will extend past the consumption event time - this is correct. The problem arises if the next consumption event begins before the discharge event for the previous consumption event has finished. Currently the discharge event will overwrite the data from the previous discharge event -> therefore resulting in water volume vanishing from the system.The proposed solution is to add a check for each discharge event to check that if there is a non-zero
discharge_flow_rate
at the expected discharge start time, to delay this discharge start time to the next timestamp with a zerodischarge_flow_rate
. This would allow the full remaining water from the previous consumption event to be fully discharged before discharging the volume added by the latest consumption.The text was updated successfully, but these errors were encountered: