[Plugin] NUT v2 - Network UPS Tools

francishe · October 23, 2023

SOS!!! Help

After I was given the notice of an latest update and I did this morning. Then i am being troubled by constant auto-shutdown of my unraid server triggered by NUT. This action was logged:

Oct 23 16:50:08 Tower upsmon[4631]: Poll UPS [[email protected]] failed - Server disconnected
Oct 23 16:50:08 Tower upsmon[4631]: Communications with UPS [email protected] lost
Oct 23 16:50:08 Tower upsmon[4631]: UPS [[email protected]] was last known to be not fully online and currently is not communicating, assuming dead
Oct 23 16:50:08 Tower upsmon[4631]: Executing automatic power-fail shutdown
Oct 23 16:50:08 Tower upsmon[4631]: Auto logout and shutdown proceeding
Oct 23 16:50:13 Tower shutdown[3942]: shutting down for system halt
Oct 23 16:50:13 Tower init: Switching to runlevel: 0
Oct 23 16:50:13 Tower init: Trying to re-exec init
Oct 23 16:50:14 Tower kernel: mdcmd (36): nocheck cancel
Oct 23 16:50:15 Tower emhttpd: Spinning up all drives...
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdd
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sde
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdr
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdf
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdc
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdn
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdq
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdo
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdl
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdp
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdm
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdj
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdk
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdh
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdg
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdd
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sde
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdb
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdr
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdf
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdc
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdn
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdq
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/nvme0n1
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdo
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdl
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdi
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdp
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sda
Oct 23 16:50:35 Tower emhttpd: Stopping services...
Oct 23 16:50:35 Tower emhttpd: shcmd (170780): /etc/rc.d/rc.libvirt stop
Oct 23 16:50:35 Tower root: Shutting down VM: DSM 710
Oct 23 16:50:35 Tower root: Shutting down VM: Gateway Router
Oct 23 16:50:35 Tower root: Shutting down VM: BT Proxy
Oct 23 16:50:35 Tower root: Shutting down VM: HuiGuo Proxy
Oct 23 16:50:35 Tower root: Shutting down VM: Windows 11
Oct 23 16:50:35 Tower root: Shutting down VM: openwrt test
Oct 23 16:50:36 Tower sshd[4678]: Connection from 103.166.11.21 port 43222 on 10.0.0.254 port 22 rdomain ""
Oct 23 16:50:37 Tower sshd[4678]: Connection closed by 103.166.11.21 port 43222 [preauth]
Oct 23 16:50:43 Tower kernel: br0: port 5(vnet3) entered disabled state
Oct 23 16:50:43 Tower kernel: device vnet3 left promiscuous mode
Oct 23 16:50:43 Tower kernel: br0: port 5(vnet3) entered disabled state
Oct 23 16:50:43 Tower kernel: usb 9-2: reset high-speed USB device number 2 using xhci_hcd
Oct 23 16:50:44 Tower kernel: br0: port 3(vnet1) entered disabled state
Oct 23 16:50:44 Tower kernel: device vnet1 left promiscuous mode
Oct 23 16:50:44 Tower kernel: br0: port 3(vnet1) entered disabled state
Oct 23 16:50:47 Tower kernel: br0: port 4(vnet2) entered disabled state
Oct 23 16:50:47 Tower kernel: device vnet2 left promiscuous mode
Oct 23 16:50:47 Tower kernel: br0: port 4(vnet2) entered disabled state
Oct 23 16:51:29 Tower nginx: 2023/10/23 16:51:29 [alert] 9905#9905: worker process 9906 exited on signal 6
Oct 23 16:51:54 Tower kernel: br0: port 7(vnet5) entered disabled state
Oct 23 16:51:54 Tower kernel: device vnet5 left promiscuous mode
Oct 23 16:51:54 Tower kernel: br0: port 7(vnet5) entered disabled state
Oct 23 16:53:19 Tower nginx: 2023/10/23 16:53:19 [alert] 9905#9905: worker process 5570 exited on signal 6

Before this latest version dated 2023.10.22, it was working perfectly for me, never bothered by any problem. I have now disabled the NUT. Thanks

Rysz · October 23, 2023

Just now, francishe said:

SOS!!! Help

After I was given the notice of an latest update and I did this morning. Then i am being troubled by constant auto-shutdown of my unraid server triggered by NUT. This action was logged:

Oct 23 16:50:08 Tower upsmon[4631]: Poll UPS [[email protected]] failed - Server disconnected
Oct 23 16:50:08 Tower upsmon[4631]: Communications with UPS [email protected] lost
Oct 23 16:50:08 Tower upsmon[4631]: UPS [[email protected]] was last known to be not fully online and currently is not communicating, assuming dead
Oct 23 16:50:08 Tower upsmon[4631]: Executing automatic power-fail shutdown
Oct 23 16:50:08 Tower upsmon[4631]: Auto logout and shutdown proceeding
Oct 23 16:50:13 Tower shutdown[3942]: shutting down for system halt
Oct 23 16:50:13 Tower init: Switching to runlevel: 0
Oct 23 16:50:13 Tower init: Trying to re-exec init
Oct 23 16:50:14 Tower kernel: mdcmd (36): nocheck cancel
Oct 23 16:50:15 Tower emhttpd: Spinning up all drives...
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdd
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sde
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdr
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdf
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdc
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdn
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdq
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdo
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdl
Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdp
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdm
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdj
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdk
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdh
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdg
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdd
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sde
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdb
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdr
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdf
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdc
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdn
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdq
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/nvme0n1
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdo
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdl
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdi
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdp
Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sda
Oct 23 16:50:35 Tower emhttpd: Stopping services...
Oct 23 16:50:35 Tower emhttpd: shcmd (170780): /etc/rc.d/rc.libvirt stop
Oct 23 16:50:35 Tower root: Shutting down VM: DSM 710
Oct 23 16:50:35 Tower root: Shutting down VM: Gateway Router
Oct 23 16:50:35 Tower root: Shutting down VM: BT Proxy
Oct 23 16:50:35 Tower root: Shutting down VM: HuiGuo Proxy
Oct 23 16:50:35 Tower root: Shutting down VM: Windows 11
Oct 23 16:50:35 Tower root: Shutting down VM: openwrt test
Oct 23 16:50:36 Tower sshd[4678]: Connection from 103.166.11.21 port 43222 on 10.0.0.254 port 22 rdomain ""
Oct 23 16:50:37 Tower sshd[4678]: Connection closed by 103.166.11.21 port 43222 [preauth]
Oct 23 16:50:43 Tower kernel: br0: port 5(vnet3) entered disabled state
Oct 23 16:50:43 Tower kernel: device vnet3 left promiscuous mode
Oct 23 16:50:43 Tower kernel: br0: port 5(vnet3) entered disabled state
Oct 23 16:50:43 Tower kernel: usb 9-2: reset high-speed USB device number 2 using xhci_hcd
Oct 23 16:50:44 Tower kernel: br0: port 3(vnet1) entered disabled state
Oct 23 16:50:44 Tower kernel: device vnet1 left promiscuous mode
Oct 23 16:50:44 Tower kernel: br0: port 3(vnet1) entered disabled state
Oct 23 16:50:47 Tower kernel: br0: port 4(vnet2) entered disabled state
Oct 23 16:50:47 Tower kernel: device vnet2 left promiscuous mode
Oct 23 16:50:47 Tower kernel: br0: port 4(vnet2) entered disabled state
Oct 23 16:51:29 Tower nginx: 2023/10/23 16:51:29 [alert] 9905#9905: worker process 9906 exited on signal 6
Oct 23 16:51:54 Tower kernel: br0: port 7(vnet5) entered disabled state
Oct 23 16:51:54 Tower kernel: device vnet5 left promiscuous mode
Oct 23 16:51:54 Tower kernel: br0: port 7(vnet5) entered disabled state
Oct 23 16:53:19 Tower nginx: 2023/10/23 16:53:19 [alert] 9905#9905: worker process 5570 exited on signal 6

Before this latest version dated 2023.10.22, it was working perfectly for me, never bothered by any problem. I have now disabled the NUT. Thanks

I've just identified and been able to reproduce this as a bug in the backend in the relatively rare situation of a not 100% correctly treated ONLINE state in combination with a network loss. I've reported this to the upstream backend developer and hopefully we'll see a fix for this ASAP.

In the meantime, you can switch to the release/legacy backend, if those work for you:

grafik.png.c5eb384a896af4dd8db7db53c3425cc3.png

Sorry for the inconvenience - I'll post here as soon as this is fixed in the "default (recent master)" backend.

Edited October 23, 2023 by Rysz

JudasD · October 23, 2023

is anyone seeing the upssched-cmd script not triggering on the recent releases? I was able to get the script to trigger 2 weeks ago, but after the plugin update i am not able to get any script execution. all on Rysz's releases.

Thanks,

JD

Rysz · October 23, 2023

1 hour ago, JudasD said:

is anyone seeing the upssched-cmd script not triggering on the recent releases? I was able to get the script to trigger 2 weeks ago, but after the plugin update i am not able to get any script execution. all on Rysz's releases.

Thanks,

JD

Nothing was changed on that, do you have the correct CMDSCRIPT directive in your upssched.conf?

Anything in the logs, particularly when starting up NUT?

Edited October 23, 2023 by Rysz

francishe · October 24, 2023

14 hours ago, Rysz said:

I've just identified and been able to reproduce this as a bug in the backend in the relatively rare situation of a not 100% correctly treated ONLINE state in combination with a network loss. I've reported this to the upstream backend developer and hopefully we'll see a fix for this ASAP.

In the meantime, you can switch to the release/legacy backend, if those work for you:

Sorry for the inconvenience - I'll post here as soon as this is fixed in the "default (recent master)" backend.

Thanks for the reply. I've tried switching to the stable version, which gave me the same problem too. Looking forward to the fix.

Rysz · October 24, 2023

5 hours ago, francishe said:

Thanks for the reply. I've tried switching to the stable version, which gave me the same problem too. Looking forward to the fix.

I've just pushed an update with a fixed backend for your issue.

Please do as follows:

Stop NUT on your UNRAID if running.
Set "Network UPS Tools Backend Switch:" to "default (recent master)" in NUT Settings
Click on "Apply" button to save the changed backend setting.
Update the NUT plugin to version 2023.10.24
Make sure "Network UPS Tools Backend:" now says: "nut-2.8.0-x86_64-12master.ssl11"
Start NUT, should work now. 🙂

Hiko0 · October 24, 2023

I have encountered an issue. I don't know whether it's been a recent reboot or the update from 10-22-2023/10-24-2023, but there's no load shown anymore. Everything was working out of the box with NUT a few days ago. My UPS is an Eaton Ellipse ECO 800 USB DIN.

Any idea, what the problem might be, @Rysz?

EDIT: Reverting back to 2.8.0 didn't help.

Edited October 24, 2023 by Hiko0

Rysz · October 24, 2023

1 hour ago, Hiko0 said:

I have encountered an issue. I don't know whether it's been a recent reboot or the update from 10-22-2023/10-24-2023, but there's no load shown anymore. Everything was working out of the box with NUT a few days ago. My UPS is an Eaton Ellipse ECO 800 USB DIN.

Any idea, what the problem might be, @Rysz?

EDIT: Reverting back to 2.8.0 didn't help.

The settings are greyed out because NUT is running (you'd need to stop NUT to change them).

Why the load doesn't display I'm not sure, nothing was changed in the backend that would cause this.

If reverting back to 2.8.0 also doesn't change this (the load missing), it's likely not caused by the backend, but the UPS - can you try connecting your UPS on a different USB port?

Edited October 24, 2023 by Rysz

rjorgenson · October 24, 2023

Trying to get this plugin setup to replace the outdated NUT plugin. I used the auto-config and it detected my UPS but the service wont start. When trying to start it manually form the command line it gives a timeout error.

Writing NUT configuration...
Updating permissions for NUT...
Checking if the NUT Runtime Statistics Module should be enabled...
Disabling the NUT Runtime Statistics Module...
Network UPS Tools - UPS driver controller 2.8.0.1
Network UPS Tools - NUT APC Modbus driver 0.01 (2.8.0.1)
_apc_modbus_read_registers: Read of 516:604 failed: Connection timed out (auto)
Can't read inventory information from the UPS
upsnotify: failed to notify about state 4: no notification tech defined, will not spam more about it
Driver failed to start (exit status=1)

The autoconfig sees the device plugged in over USB and says it's writing the config

NUT Scanner is now searching for UPS devices...
#####################################################

[nutdev1]
driver = "apc_modbus"
port = "auto"
vendorid = "051D"
productid = "0003"
product = "Smart-UPS 1500 FW:UPS 08.8 / ID=18"
serial = "__REDACTED__"
vendor = "American Power Conversion"
bus = "005"
device = "003"
busport = "001"
###NOTMATCHED-YET###bcdDevice = "0106"

#####################################################

I'm not sure what could be the issue here, is this config actually written? It looks like it's trying to connect to a busport other than what is detected.

Rysz · October 24, 2023

30 minutes ago, rjorgenson said:
Trying to get this plugin setup to replace the outdated NUT plugin. I used the auto-config and it detected my UPS but the service wont start. When trying to start it manually form the command line it gives a timeout error.
Writing NUT configuration...
Updating permissions for NUT...
Checking if the NUT Runtime Statistics Module should be enabled...
Disabling the NUT Runtime Statistics Module...
Network UPS Tools - UPS driver controller 2.8.0.1
Network UPS Tools - NUT APC Modbus driver 0.01 (2.8.0.1)
_apc_modbus_read_registers: Read of 516:604 failed: Connection timed out (auto)
Can't read inventory information from the UPS
upsnotify: failed to notify about state 4: no notification tech defined, will not spam more about it
Driver failed to start (exit status=1)
The autoconfig sees the device plugged in over USB and says it's writing the config
NUT Scanner is now searching for UPS devices...
#####################################################

[nutdev1]
driver = "apc_modbus"
port = "auto"
vendorid = "051D"
productid = "0003"
product = "Smart-UPS 1500 FW:UPS 08.8 / ID=18"
serial = "__REDACTED__"
vendor = "American Power Conversion"
bus = "005"
device = "003"
busport = "001"
###NOTMATCHED-YET###bcdDevice = "0106"

#####################################################
I'm not sure what could be the issue here, is this config actually written? It looks like it's trying to connect to a busport other than what is detected.

MODBUS is an APC protocol that needs to be specifically activated on the UPS:

Note that you will have to enable Modbus communication. In the front panel of

the UPS, go to Advanced Menu mode, under Configuration and enable Modbus.

If you don't have this/want this activated you should use the driver usbhid-ups instead.

The old version of NUT didn't include the MODBUS driver, so you were using usbhid-ups there.

You will need to click "Reset Config" first to remove the configuration by the auto-config tool.

Then set the NUT settings up as follows:

Please let me know if that works for you! 🙂

Edited October 24, 2023 by Rysz

francishe · October 25, 2023

18 hours ago, Rysz said:

I've just pushed an update with a fixed backend for your issue.

Please do as follows:

Stop NUT on your UNRAID if running.

Set "Network UPS Tools Backend Switch:" to "default (recent master)" in NUT Settings

Click on "Apply" button to save the changed backend setting.

Update the NUT plugin to version 2023.10.24

Make sure "Network UPS Tools Backend:" now says: "nut-2.8.0-x86_64-12master.ssl11"

Start NUT, should work now. 🙂

Many thanks. Updated.

rjorgenson · October 25, 2023

4 hours ago, Rysz said:

MODBUS is an APC protocol that needs to be specifically activated on the UPS:

Note that you will have to enable Modbus communication. In the front panel of

the UPS, go to Advanced Menu mode, under Configuration and enable Modbus.

If you don't have this/want this activated you should use the driver usbhid-ups instead.

The old version of NUT didn't include the MODBUS driver, so you were using usbhid-ups there.

You will need to click "Reset Config" first to remove the configuration by the auto-config tool.

Then set the NUT settings up as follows:

Please let me know if that works for you! 🙂

Thanks! I dug around in the menu on the device but couldn't find an option to enable modbus anywhere, there was an NMC setting that was network based but I decided not to mess with that and just set it up as usbhid-ups and everything worked as before =]

atsrxL · October 25, 2023

Hi , I'm using a huawei UPS which use ModBus a protocol as connection method, I noticed on the newest version of Nut can select UPS Driver to apc_modbus , when I choose and set Driver port to USB or /dev/ttyUSB0 in standalone mode also keep other setting default , it does't work . there are no any information on screen only ''status:service stopped'' at right corner.

Can you please give a hand on this ,thank you.

nut-debug-20231024235612.zip

Rysz · October 25, 2023

4 minutes ago, atsrxL said:

Hi , I'm using a huawei UPS which use ModBus a protocol as connection method, I noticed on the newest version of Nut can select UPS Driver to apc_modbus , when I choose and set Driver port to USB or /dev/ttyUSB0 in standalone mode also keep other setting default , it does't work . there are no any information on screen only ''status:service stopped'' at right corner.

Can you please give a hand on this ,thank you.

nut-debug-20231024235612.zip 12.83 kB · 0 downloads

You have the old backend selected which didn't have this driver yet, you'll need to make sure you are on the latest NUT plugin version and then select the backend "default (recent master)". After either restart the system or reinstall the plugin - then make sure "Network UPS Tools Backend:" now says: "nut-2.8.0-x86_64-12master.ssl11".

Edited October 25, 2023 by Rysz

atsrxL · October 25, 2023

1 minute ago, Rysz said:

You have the old backend selected which didn't have this driver yet, you'll need to make sure you are on the latest NUT plugin version and then select the backend "default (recent master)". After either restart the system or reinstall the plugin - then make sure "Network UPS Tools Backend:" now says: "nut-2.8.0-x86_64-12master.ssl11".

Thanks for reply , the pic of showing elder backend is just a try, does't work also on the default backend, and based on huawei's ups menu i'am sure that modbus is on, any other suggistion?

Rysz · October 25, 2023

Just now, atsrxL said:

Thanks for reply , the pic of showing elder backend is just a try, does't work also on the default backend, and based on huawei's ups menu i'am sure that modbus is on, any other suggistion?

What UPS model do you have?

Can you please upload another debug package where you are on the current backend?

Your debug package is from the (older) stable backend.

Hiko0 · October 25, 2023

@Rysz

I noticed why the options are greyed out as well, thanks.

However, I can't seem to fix the load not being displayed. I switched through different USB-ports but I can't get it to work again.

Edited October 25, 2023 by Hiko0

Rysz · October 25, 2023

2 minutes ago, Hiko0 said:

I noticed why the options are greyed out as well, thanks.

However, I can't seem to fix the load not being displayed. I switched through different USB-ports but I can't get it to work again.

Can you try with the "legacy (2.7.4)" backend - some UPS don't play well with the newer backends. Please note that if you switch backends you need to either restart your system or re-install the plugin. Otherwise the backend change will not be in effect, so worth attempting to change to 2.8.0 or 2.7.4 with this in mind.

Edited October 25, 2023 by Rysz

Hiko0 · October 25, 2023

1 minute ago, Rysz said:

Can you try with the "legacy (2.7.4)" backend - some UPS don't play well with the newer backends. Please note that if you switch backends you need to either restart your system or re-install the plugin. Otherwise the backend change will not be in effect, so worth attempting to change to 2.8.0 or 2.7.4 with this in mind.

Ah, so when I tried switching back to 2.8.0, it couldn't work. I wouldn't like to reboot the system right now. So, in options I choose 2.8.0, then uninstall the plugin and install it again?

Rysz · October 25, 2023

2 minutes ago, Hiko0 said:

Ah, so when I tried switching back to 2.8.0, it couldn't work. I wouldn't like to reboot the system right now. So, in options I choose 2.8.0, then uninstall the plugin and install it again?

Yes, select the backend you want to switch to and then uninstall and reinstall the plugin. 🙂 You'll see that the backend was changed when the "Network UPS Tools Backend:" says something different than before. I'd try release (2.8.0 stable) first, if that doesn't work then legacy (2.7.4 stable).

Edited October 25, 2023 by Rysz

atsrxL · October 25, 2023

7 minutes ago, Rysz said:

What UPS model do you have?

Can you please upload another debug package where you are on the current backend?

Your debug package is from the (older) stable backend.

Model : UPS2000-A-3KTTS

https://support.huawei.com/enterprise/en/doc/EDOC1000084260

Here the newer debug package

nut-debug-20231025001422.zip

Rysz · October 25, 2023

1 minute ago, atsrxL said:

Model : UPS2000-A-3KTTS

https://support.huawei.com/enterprise/en/doc/EDOC1000084260

Here the newer debug package

nut-debug-20231025001422.zip 11.89 kB · 0 downloads

This UPS won't work with the APC modbus driver (which is mostly for APC devices).

Instead it even has it's own driver:

https://networkupstools.org/docs/man/huawei-ups2000.html

You can attempt to set it up as follows:

Rysz · October 25, 2023

5 minutes ago, Hiko0 said:

Thanks for your excellent support. I tried to do that, however it didn't switch backends, though it says 2.8.0 right after re-install.

Are you sure the text in "Network UPS Tools Backend" didn't change? Because this is the (older) stable backend which you've selected - so the correct backend is installed (according to your selection). Maybe you were on the (older) stable backend already - which is why your load value wasn't shown and the backend hasn't changed? The new backend is "nut-2.8.0-x86_64-11master.ssl11" or "nut-2.8.0-x86_64-12master.ssl11".

In any case the backend definitely switches when reinstalling, so worth trying changing again to:

default (recent master) => reinstall plugin => test if it works
legacy (2.7.4. stable) => reinstall plugin => test if it works

Edited October 25, 2023 by Rysz

atsrxL · October 25, 2023

3 minutes ago, Rysz said:

This UPS won't work with the APC modbus driver (which is mostly for APC devices).

Instead it even has it's own driver:

https://networkupstools.org/docs/man/huawei-ups2000.html

You can attempt to set it up as follows:

Had tried but still not working

Rysz · October 25, 2023

Just now, atsrxL said:

Had tried but still not working

What does it say in the log when you start NUT with the huawei_ups2000 driver?

[Plugin] NUT v2 - Network UPS Tools

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

SimonF

dmacias

SimonF

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation