UPS information becomes unknown after restarting nut-driver

[gbakeman]

Originally posted by @deajan here:

Also, if I happen to stop and restart nut-driver via systemctl stop nut-driver; sleep 5; systemctl start nut-driver, my UPS model dissappears, as well as the consumed watts:

Before:

After:

If I happen to disconnect / re-connect to the UPS via the WinNUT interface, readings are okay again.

Logs attached to the issue. WinNUT-Client-2023-11-03.zip

I've updated WinNUT to latest release to make this test. Btw, thank you for making winnut ;)

Note: would like to have confirmation of UPS variable output after nut-driver is restarted.

[deajan]

Note: would like to have confirmation of UPS variable output after nut-driver is restarted.

What do you want me to do that I didn't already do ?

[gbakeman]

What do you want me to do that I didn't already do ?

WinNUT has a UPS Variables output window that shows exactly what data the NUT server is sending to WinNUT. This helps us confirm if the NUT server is sending bad data, or if WinNUT is displaying data incorrectly. I actually don't think I'll need that output after all. Here's some output in the log file you gave, after WinNUT reconnected to the NUT server:

03/11/2023 10:58:22 [25552, UPS_Device]: Beginning connection: @[removed]:3493, Name: eaton [AutoReconnect]
03/11/2023 10:58:22 [25552, Nut_Socket]: Attempting TCP socket connection to [removed]:3493...
03/11/2023 10:58:22 [25552, Nut_Socket]: Connection established and streams ready for [removed]:3493
03/11/2023 10:58:22 [25552, Nut_Socket]: Attempting authentication...
03/11/2023 10:58:22 [25552, Nut_Socket]: Error while attempting to log in: USERNAMEREQUIRED (ERR USERNAME-REQUIRED)
Query: LOGIN
03/11/2023 10:58:22 [25552, Nut_Socket]: NUT server reports VER: 2.8.0 NETVER: 
03/11/2023 10:58:22 [25552, UPS_Device]: Apply Fallback Value when retrieving ups.mfr
03/11/2023 10:58:22 [25552, UPS_Device]: Apply Fallback Value when retrieving ups.model
03/11/2023 10:58:22 [25552, UPS_Device]: Apply Fallback Value when retrieving ups.serial
03/11/2023 10:58:22 [25552, UPS_Device]: Apply Fallback Value when retrieving ups.firmware
03/11/2023 10:58:22 [25552, UPS_Device]: Unhandled error while getting ups.realpower
03/11/2023 10:58:22 [25552, UPS_Device]: Unhandled error while getting ups.realpower.nominal
03/11/2023 10:58:22 [25552, UPS_Device]: Unhandled error while getting input.current.nominal
03/11/2023 10:58:22 [25552, UPS_Device]: Unable to find a suitable method to calculate power usage.
03/11/2023 10:58:22 [25552, UPS_Device]: Apply Fallback Value when retrieving battery.capacity
03/11/2023 10:58:22 [25552, UPS_Device]: Apply Fallback Value when retrieving output.frequency.nominal
03/11/2023 10:58:22 [25552, WinNUT]: eaton has indicated it's ready to start sending data.

Here we see WinNUT set up the connection components, attempt to LOGIN as a dependent, then retrieve initial data about the UPS. Quite a few variables, including all the identifying information about the UPS, fail to lookup and are set to the default value (Unknown.) I didn't see this at the beginning of the log when you connected for the first time. I'm not sure how common it is to restart the nut-driver while upsd is running. It looks like there may be a bug with upsd trying to handle (or not) the nut driver restarting. Can you try restarting the main NUT server daemon and see if the results are any different?

Edit: I just saw this issue: networkupstools/nut#1903, looks like a new feature introduced in 2.8.1. Can you update NUT?

[gbakeman]

Hi @deajan, just want to check in and see if you've had a chance to confirm if restarting upsd has had any effect? If it turns out that the upsd daemon was just behaving oddly, then I think it would be best to continue along in #116 where I plan to improve how WinNUT handles missing or erroneous variables. Let me know if you disagree and feel something else should be done, but in the meantime I'll close this issue. Thanks again for the feedback!