The WinNUT variable update system has a design that causes it to substitute in default/fallback values for when there's an error retrieving a variable. This is a problem because the user may be unaware of when a variable is being substituted, and when it is a true value.
First, the concept of having fallback values should be removed. When an error is encountered retrieving a variable, that error (exception) should be passed along to the calling method. It will be up to the variables management system to handle errors. Most likely, an error will occur due to a variable not being available on the NUT server. In which case, the variable should be marked so that WinNUT knows how to handle it, and the variable is no longer fetched during periodic update calls.
Items
[ ] Alert user if battery condition is not available (#129) when stop conditions are active
[ ] Modify gauge displays to indicate that the value is invalid or not available (precludes larger change to gauges and how they're displayed or added?)
The WinNUT variable update system has a design that causes it to substitute in default/fallback values for when there's an error retrieving a variable. This is a problem because the user may be unaware of when a variable is being substituted, and when it is a true value.
Examples
Missing
battery.voltageUPS data retrieval subroutine https://github.com/nutdotnet/WinNUT-Client/blob/1d9fe473ffde007d75cbaa04c7aa09c3277ae69d/WinNUT_V2/WinNUT-Client_Common/UPS_Device.vb#L265-L268
Solution
First, the concept of having fallback values should be removed. When an error is encountered retrieving a variable, that error (exception) should be passed along to the calling method. It will be up to the variables management system to handle errors. Most likely, an error will occur due to a variable not being available on the NUT server. In which case, the variable should be marked so that WinNUT knows how to handle it, and the variable is no longer fetched during periodic update calls.
Items
Related
24
41
69
74
101