huawei-ups2000: USB and serial ports work on Linux but not on Windows (file locking)

[Jason-2048]

Summary

I am reporting a reproducible issue with the huawei-ups2000 driver on Windows.

The same UPS (Huawei UPS2000-A-1KTTS) and NUT version (2.8.4 development) work correctly on Linux (kernel >= 5.12),
but communication consistently fails on Windows when using the USB interface based on XR21V1410 (USB-to-UART).

This appears to be related to Modbus RTU timing / serial backend behavior on Windows.

---

Environment

UPS model:

• Huawei UPS2000-A-1KTTS

NUT version:

• 2.8.4 development (2.8.4.1059-1059+g8989fdaa2)

Connection:

• USB interface (XR21V1410 USB UART)
• Windows 10 x64

Driver:

• huawei-ups2000 (libmodbus-based)

---

Linux (WORKING)

• Kernel: Linux 5.12+
• Device: /dev/ttyUSB0
• Configuration:

[huawei]
driver = huawei-ups2000
port = /dev/ttyUSB0

Command:
upsc huawei
Result:

battery.capacity: 9
battery.charge: 100.0
battery.charger.status: charging
battery.packs: 2
battery.runtime: 2524
battery.voltage: 27.3
device.mfr: Huawei
device.model: UPS2000A
device.serial: /
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: huawei-ups2000
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyUSB0
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.2
driver.version.internal: 0.06
input.bypass.frequency: 50.0
input.bypass.voltage: 236.7
input.frequency: 50.0
input.voltage: 236.7
output.current: 0.7
output.frequency: 50.0
output.power: 100.0
output.realpower: 100.0
output.voltage: 220.0
ups.beeper.status: enabled
ups.delay.reboot: 60
ups.delay.shutdown: 60
ups.delay.start: 60
ups.firmware: V2R1C1SPC50
ups.firmware.aux: P1.0-D1.0
ups.load: 18.0
ups.mfr: Huawei
ups.model: UPS2000A
ups.power.nominal: 1000
ups.serial: /
ups.status: OL CHRG
ups.temperature: 19.8
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.type: online

---

Windows (NOT WORKING)

• COM port detected correctly in Device Manager as COM4
• NUT executables (upsdrvctl, upsd, upsc) installed under C:\Software\nut\mingw64\bin

Behavior:

upsdrvctl.exe -DDDD start
...
w32_serial_open (\.\COM4)
setting initial state on \.\COM4
modbus_connect: unable to connect: No error
Driver failed to start (exit status=1)

• Driver fails to connect via Modbus RTU
• upsc reports:

upscli_tryconnect: Connection to host timed out: '::1'
Error: Connection failure: Unknown error

Analysis:

• Driver can open COM4, but Modbus RTU communication fails
• Linux works thanks to kernel USB-serial handling (xr_serial / tty layer)
• Windows serial backend cannot satisfy Modbus RTU timing requirements (frame spacing / half-duplex)
• This prevents the driver from starting, so upsd is never running, causing upsc to timeout

Reference documentation:

• https://networkupstools.org/historic/v2.8.4/docs/man/huawei-ups2000.html

---

Request

Could the NUT project consider:

1. Adding a clear note in documentation about XR21V1410 / Windows limitation?
2. Exploring a possible Windows-specific workaround for Modbus RTU timing?
3. Or suggesting alternative approaches (like SNMP or Linux master) to monitor Huawei UPS2000?

I am willing to provide additional debug logs or help test any patches.

---

Additional notes:

• The problem is not configuration-related; basic dummy-ups driver works fine on Windows
• The issue only appears with XR21V1410 USB-serial + huawei-ups2000 driver

---

Note: This issue template was prepared with guidance from ChatGPT.

[jimklimov]

Cheers, thanks for the report, although I have few quick ideas how to approach it in practice (what I do have is noted below). Maybe @biergaizi would have more ideas.

Some quick shots in the dark:

NUT for Windows so far remains highly experimental, with few people giving feedback and I think only myself committing any code in the past few years (to revive the fork made a decade+ ago based on NUT v2.6.5 by my predecessors). There are also known incomplete pieces, including some around serial-port code IIRC, see more at https://github.com/networkupstools/nut/issues?q=state%3Aopen%20label%3A%22Windows-not-on-par-with-POSIX%22 and NUT for Windows

Adding a clear note in documentation about XR21V1410 / Windows limitation?

Can be done. Until this report it was not even known.

What is known (and documented) however is that even on Linux this UPS requires a fairly recent kernel (5.12+) with a new low-level USB driver for the chip introduced there. Older UART drivers are not compatible with the chip.

Maybe an equivalent consideration actually applies to other platforms too, I now wonder if ultimately only Linux has some sort of the driver and other platforms need to catch up (maybe not only Windows)?..

Or suggesting alternative approaches (like SNMP or Linux master) to monitor Huawei UPS2000?

In docs? Probably, PRs welcome.

Analysis: ... Windows serial backend cannot satisfy Modbus RTU timing requirements (frame spacing / half-duplex)

Where does this statement come from? AI? If yes, it might be or not be taken with a grain of salt, depending on where it found such information. In the logs above I do not see any other mention of duplex, timing, etc.

Exploring a possible Windows-specific workaround for Modbus RTU timing?

If we find and entice someone well-versed with all of technologies involved, maybe. It is worth exploring if this is not even a modbus issue at all, but "just" one of the known missing pieces that are not "on par with POSIX". Usually the debug log messages are emitted when there was known stub code and lack of real implementation.

upsdrvctl.exe -DDDD start

Did you run this in command line? Did you use nut.exe or the service it ends up creating?

This is a loaded stack of questions actually:

• In the past couple of weeks several PRs were merged to modernize nut.exe behavior, so you might want to try the latest master-branch build from Appveyor CI (and not the months-old NUT v2.8.4 release archive from the web site)
• While experimenting with those PRs, I noted that real device access may need the drivers to run from a terminal started explicitly "As Administrator" - possibly your upsdrvctl session was just not privileged enough to see hardware?
• Likewise, for inter-process access via named pipes to work, all NUT daemons should be started as same user with same privileges (whether as admin or not as admin).
• Try upsdrvctl.exe -DDDD -d start - the lower-case -d should propagate debugging request into the called driver, otherwise you just trace the tool to run drivers
• It might be in fact easier for troubleshooting to directly run the driver program and pass all options on command line (or use -a upsname to refer to ups.conf) so there are less moving parts while you debug this.

upscli_tryconnect: Connection to host timed out: '::1'

If you did not use nut.exe and did not start upsd explicitly (and with same privileges as the driver), this might happen. Otherwise (running via nut.exe) I think the data server should have started and if the ups.conf file is defined - it would know about the device and that it is not connected or stale. The ::1 is IPv6 or dual-stack localhost, does your upsd.conf LISTEN on that? (One of those recent PRs fixed LISTEN * on WIN32 among other things - this is what might also be failing in older builds).

[biergaizi]

First a clarification

Driver can open COM4, but Modbus RTU communication fails. Linux works thanks to kernel USB-serial handling (xr_serial / tty layer). Windows serial backend cannot satisfy Modbus RTU timing requirements (frame spacing / half-duplex). This prevents the driver from starting, so upsd is never running, causing upsc to timeout

Was this bug report generated with the assistant of a Large Language Model?

I have no problem of using an LLM per se to help drafting the report, as long as the bug report contains factually-accurate debugging information for developers. For this bug report, the debugging information is of high quality, so I mostly don't have any problem in this case.

But to avoid confusions, as the developer of the huawei-ups2000 driver, I must clarify that the so-called "Windows serial backend cannot satisfy Modbus RTU timing requirements (frame spacing / half-duplex)" is a highly speculative idea without evidence (if you have evidence, please submit oscilloscope waveforms or logic analyzer traces, I can read both). From the available information:

w32_serial_open (\.\COM4)
setting initial state on \.\COM4
modbus_connect: unable to connect: No error
Driver failed to start (exit status=1)

The best we can conclude is that the serial port communication is not working, but the reason is unknown, and requires further investigation. The claim that "Modbus RTU timing requirements (frame spacing / half-duplex)" looks like LLM hallucination. Modbus RTU frames over serial are regular RS-232 text, without the so-called "frame spacing" requirement.

Next, further investigation

Can you check whether the XR21V1410 USB-serial interface even works on Windows? In particular, check the following things:

0. What is the serial port COM4's driver name and version, displayed in the Windows Device Manager?

1. According to the official Huawei UPS2000 (1 kVA-3 kVA) Modbus Protocol Development Guide, you need to install a special MaxLinear device driver called XR21x141x-XP2KVista7-DriversOnly-Vers1.7.0.0 before XR21V1410 can work. I'm not sure if this document is still up-to-date, but can you please check if installing the driver fixes the problem? You should be able to find the driver in the CD.

2. Does your UPS2000 work with the official Huawei software that comes with the CD?

3. The file XR21x141x-XP2KVista7-DriversOnly-Vers1.7.0.0 is perhaps incompatible with Windows 10 and 11 from its name. But I also noticed that the MaxLinear website also provides the latest driver at the product page. Try downloading and installing "Software: Drivers, Windows 10 and newer", and download XR21x_Win10_V2.7.0.0.zip.

4. UPS2000 has a dedicated RS-232 port in additional to USB. Both ports use the same protocol. Can you check if this port works with other common external USB-to-serial converter cables (such as PL2302-based converters) on Windows? This would isolate whether the problem exists in XR21V1410, libmodbus, or huawei-ups2000.

   Please unplug the USB cable and perform a cold UPS shutdown/startup before testing the serial port, according to the notes in the huawei-ups2000 man page. You may also want to short-circuit RX/TX and perform a "RS-232 loopback test" using a terminal emulator to ensure the cable itself works.

Once we have answers of these questions, we can continue investigating it.

[Jason-2048]

@jimklimov
Thanks for your reply.

I conducted a test using version 2.8.4.3923-master. I extracted the mingw64 folder into C:\Software\nut and ran the program directly using pwsh (Administrator).

Below is the output when running upsdrvctl.exe -DDDD -d start :

Network UPS Tools upsdrvctl.exe - UPS driver controller 2.8.4.1059-1059+g8989fdaa2 (development iteration after 2.8.4)
   0.000000     [D3] getprocname: try to parse the name from WIN32 process info
   0.003991     [D1] getprocname: determined process name for PID 30972: D:\Software\nut\mingw64\sbin\upsdrvctl.exe
   0.011803     [D1:init] upsdrvctl commanding all drivers (1 found): start
   0.015503     [D1:start-all] Starting UPS: huawei
   0.018643     [D1:start-all] WARNING: Requested a debugging level but not explicitly a backgrounding mode - driver may never try to fork away; however the upsdrvctl tool will fork it and not wait.
   0.028215     [D2:start-all] 3 remaining attempts
   0.030491     [D2:start-all] exec:  C:\Software\nut\mingw64\sbin\..\bin/huawei-ups2000.exe -DDDD -a huawei
Network UPS Tools 2.8.4.1059-1059+g8989fdaa2 (development iteration after 2.8.4) - NUT Huawei UPS2000 (1kVA-3kVA) RS-232 Modbus driver (libmodbus link type: static) 0.11
Warning: This is an experimental driver.
Some features may not function correctly.

   0.000000     [D3] do_global_args: var='maxretry' val='3'
   0.003562     [D3] main_arg: var='driver' val='huawei-ups2000'
   0.006891     [D3] main_arg: var='port' val='\\.\COM4'
   0.010758     [D3] main_arg: var='desc' val='Huawei'
   0.014398     [D1] Network UPS Tools version 2.8.4.1059-1059+g8989fdaa2 (development iteration after 2.8.4), 64-bit build for x86_64, built with gcc (Rev8, Built by MSYS2 project) 15.2.0 and configured with flags: --enable-Wcolor --enable-configure-debug --enable-warnings --enable-Werror --enable-keep_nut_report_feature --with-all=auto --with-cgi=auto --with-serial=auto --with-dev=auto --with-nut_monitor=auto --with-pynut=auto --disable-force-nut-version-header --enable-check-NIT --enable-maintainer-mode --with-docs=no --enable-docs-man-for-progs-built-only=no PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig:../lib/pkgconfig;../share/pkgconfig --with-modbus+usb=yes --disable-silent-rules --enable-docs-changelog=no --with-unmapped-data-points --with-debuginfo=auto CC=/mingw64/lib/ccache/bin/gcc CXX=/mingw64/lib/ccache/bin/g++ CPP='gcc -E'
   0.069310     [D1] debug level is '4'
   0.072472     [D1] Can not become_user(<null>): not implemented on this platform
   0.079055     [D1] Signalling UPS [huawei]: driver.exit (quietly, no fuss if no driver is running or responding)
   0.088570     WaitNamedPipe (\\.\pipe\huawei-ups2000-huawei): 2: No error [系统找不到指定的文件。 ]
   0.094090     [D1] Request for other driver to exit returned code -1
   0.097084     [D1] Socket dialog with the other driver instance (may be absent) failed: No error [系统找不到指定的文件。 ]
   0.100866     [D2] upsdrv_initups
   0.104678     w32_serial_open (\\.\COM4)
   0.161868     setting initial state on \\.\COM4
   0.257244     0000000000000108 = w32_serial_open (\\.\COM4)
   0.259427     Warning: no locking method is available: No error [操作成功完成。 ]
   0.262215     vmin_ 0, vtime_ 0
   0.366345     action 0
   0.369298     vtime 0, vmin 1

   0.371985     ReadTotalTimeoutConstant -2, ReadIntervalTimeout -1, ReadTotalTimeoutMultiplier -1
   0.380436     modbus_connect: unable to connect: No error
   0.385207     [D1] upsnotify: failed to notify about state NOTIFY_STATE_STOPPING: no notification tech defined, will not spam more about it
   0.395388     [D1] On systems without service units, consider `export NUT_QUIET_INIT_UPSNOTIFY=true`
   0.639858     Driver failed to start (exit status=1)
   5.656507     [D2:start-all] 2 remaining attempts
   5.659690     [D2:start-all] exec:  C:\Software\nut\mingw64\sbin\..\bin/huawei-ups2000.exe -DDDD -a huawei
Network UPS Tools 2.8.4.1059-1059+g8989fdaa2 (development iteration after 2.8.4) - NUT Huawei UPS2000 (1kVA-3kVA) RS-232 Modbus driver (libmodbus link type: static) 0.11
Warning: This is an experimental driver.
Some features may not function correctly.

   0.000000     [D3] do_global_args: var='maxretry' val='3'
   0.003074     [D3] main_arg: var='driver' val='huawei-ups2000'
   0.007471     [D3] main_arg: var='port' val='\\.\COM4'
   0.010973     [D3] main_arg: var='desc' val='Huawei'
   0.014864     [D1] Network UPS Tools version 2.8.4.1059-1059+g8989fdaa2 (development iteration after 2.8.4), 64-bit build for x86_64, built with gcc (Rev8, Built by MSYS2 project) 15.2.0 and configured with flags: --enable-Wcolor --enable-configure-debug --enable-warnings --enable-Werror --enable-keep_nut_report_feature --with-all=auto --with-cgi=auto --with-serial=auto --with-dev=auto --with-nut_monitor=auto --with-pynut=auto --disable-force-nut-version-header --enable-check-NIT --enable-maintainer-mode --with-docs=no --enable-docs-man-for-progs-built-only=no PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig:../lib/pkgconfig;../share/pkgconfig --with-modbus+usb=yes --disable-silent-rules --enable-docs-changelog=no --with-unmapped-data-points --with-debuginfo=auto CC=/mingw64/lib/ccache/bin/gcc CXX=/mingw64/lib/ccache/bin/g++ CPP='gcc -E'
   0.077995     [D1] debug level is '4'
   0.081082     [D1] Can not become_user(<null>): not implemented on this platform
   0.089575     [D1] Signalling UPS [huawei]: driver.exit (quietly, no fuss if no driver is running or responding)
   0.102226     WaitNamedPipe (\\.\pipe\huawei-ups2000-huawei): 2: No error [系统找不到指定的文件。 ]
   0.111583     [D1] Request for other driver to exit returned code -1
   0.121317     [D1] Socket dialog with the other driver instance (may be absent) failed: No error [系统找不到指定的文件。 ]
   0.130240     [D2] upsdrv_initups
   0.132164     w32_serial_open (\\.\COM4)
   0.192323     setting initial state on \\.\COM4
   0.285122     0000000000000058 = w32_serial_open (\\.\COM4)
   0.288470     Warning: no locking method is available: No error [操作成功完成。 ]
   0.292943     vmin_ 0, vtime_ 0
   0.409375     action 0
   0.412287     vtime 0, vmin 1

   0.414508     ReadTotalTimeoutConstant -2, ReadIntervalTimeout -1, ReadTotalTimeoutMultiplier -1
   0.422382     modbus_connect: unable to connect: No error
   0.425941     [D1] upsnotify: failed to notify about state NOTIFY_STATE_STOPPING: no notification tech defined, will not spam more about it
   0.433314     [D1] On systems without service units, consider `export NUT_QUIET_INIT_UPSNOTIFY=true`
   6.224350     Driver failed to start (exit status=1)
  11.237957     [D2:start-all] 1 remaining attempts
  11.241636     [D2:start-all] exec:  C:\Software\nut\mingw64\sbin\..\bin/huawei-ups2000.exe -DDDD -a huawei
Network UPS Tools 2.8.4.1059-1059+g8989fdaa2 (development iteration after 2.8.4) - NUT Huawei UPS2000 (1kVA-3kVA) RS-232 Modbus driver (libmodbus link type: static) 0.11
Warning: This is an experimental driver.
Some features may not function correctly.

   0.000000     [D3] do_global_args: var='maxretry' val='3'
   0.003066     [D3] main_arg: var='driver' val='huawei-ups2000'
   0.006226     [D3] main_arg: var='port' val='\\.\COM4'
   0.009287     [D3] main_arg: var='desc' val='Huawei'
   0.012283     [D1] Network UPS Tools version 2.8.4.1059-1059+g8989fdaa2 (development iteration after 2.8.4), 64-bit build for x86_64, built with gcc (Rev8, Built by MSYS2 project) 15.2.0 and configured with flags: --enable-Wcolor --enable-configure-debug --enable-warnings --enable-Werror --enable-keep_nut_report_feature --with-all=auto --with-cgi=auto --with-serial=auto --with-dev=auto --with-nut_monitor=auto --with-pynut=auto --disable-force-nut-version-header --enable-check-NIT --enable-maintainer-mode --with-docs=no --enable-docs-man-for-progs-built-only=no PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig:../lib/pkgconfig;../share/pkgconfig --with-modbus+usb=yes --disable-silent-rules --enable-docs-changelog=no --with-unmapped-data-points --with-debuginfo=auto CC=/mingw64/lib/ccache/bin/gcc CXX=/mingw64/lib/ccache/bin/g++ CPP='gcc -E'
   0.062272     [D1] debug level is '4'
   0.064518     [D1] Can not become_user(<null>): not implemented on this platform
   0.069082     [D1] Signalling UPS [huawei]: driver.exit (quietly, no fuss if no driver is running or responding)
   0.076979     WaitNamedPipe (\\.\pipe\huawei-ups2000-huawei): 2: No error [系统找不到指定的文件。 ]
   0.082130     [D1] Request for other driver to exit returned code -1
   0.086170     [D1] Socket dialog with the other driver instance (may be absent) failed: No error [系统找不到指定的文件。 ]
   0.094311     [D2] upsdrv_initups
   0.096218     w32_serial_open (\\.\COM4)
   0.153571     setting initial state on \\.\COM4
   0.240709     0000000000000108 = w32_serial_open (\\.\COM4)
   0.244622     Warning: no locking method is available: No error [操作成功完成。 ]
   0.249835     vmin_ 0, vtime_ 0
   0.375609     action 0
   0.384687     vtime 0, vmin 1

   0.386907     ReadTotalTimeoutConstant -2, ReadIntervalTimeout -1, ReadTotalTimeoutMultiplier -1
   0.394795     modbus_connect: unable to connect: No error
   0.397635     [D1] upsnotify: failed to notify about state NOTIFY_STATE_STOPPING: no notification tech defined, will not spam more about it
   0.406240     [D1] On systems without service units, consider `export NUT_QUIET_INIT_UPSNOTIFY=true`
  11.766354     Driver failed to start (exit status=1)
  11.767703     [D1:start-all] upsdrvctl: got some errors with preceding operations, exiting with failure now
  11.770713     [D1:start-all] Completed the job of upsdrvctl tool, cleaning up and exiting now
  11.780318     [D1:start-all] Completed the job of upsdrvctl tool, clean-up finished, exiting now
  11.786840     [D2:start-all] a upsdrvctl.exe sub-process (start-all) is exiting now

[biergaizi]

Please also perform the suggested hardware and driver checks/tests.

[Jason-2048]

@biergaizi
Thank you for your reply.
Please give me some time. I'm currently on a business trip and using RDP to control my computer.

2. Does your UPS2000 work with the official Huawei software that comes with the CD?

I previously tried using iManagerNetEco1000U_V100R002C10SPC290_X86, and it was able to connect to the UPS normally.

3. The file XR21x141x-XP2KVista7-DriversOnly-Vers1.7.0.0 is perhaps incompatible with Windows 10 and 11 from its name. But I also noticed that the MaxLinear website also provides the latest driver at the product page. Try downloading and installing "Software: Drivers, Windows 10 and newer", and download XR21x_Win10_V2.7.0.0.zip.

I have installed the driver XR21x_Win10_V2.7.0.0.zip (from maxlinear) and restarted my computer. When I tried running upsdrvctl.exe -DDDD -d start again, the information returned was the same as before.

4. UPS2000 has a dedicated RS-232 port in additional to USB. Both ports use the same protocol. Can you check if this port works with other common external USB-to-serial converter cables (such as PL2302-based converters) on Windows? This would isolate whether the problem exists in XR21V1410, libmodbus, or huawei-ups2000.

Sorry, I'm not at my computer right now. I'll try it when I get back, but it might not be that fast.

Please unplug the USB cable and perform a cold UPS shutdown/startup before testing the serial port, according to the notes in the huawei-ups2000 man page. You may also want to short-circuit RX/TX and perform a "RS-232 loopback test" using a terminal emulator to ensure the cable itself works.

I tried using VMware Workstation to connect a USB device to a Linux (Rocky Linux 9) virtual machine. I was able to connect to the UPS normally using nut 2.8.2, and the data changed (e.g., output.current, output.frequency, output.voltage, ups.load). This should indicate that the serial port is not locked?

Also, I found an article on Zhihu. Are you the author?

[biergaizi]

I previously tried using iManagerNetEco1000U_V100R002C10SPC290_X86, and it was able to connect to the UPS normally. [...] I have installed the driver XR21x_Win10_V2.7.0.0.zip (from maxlinear) and restarted my computer. When I tried running upsdrvctl.exe -DDDD -d start again, the information returned was the same as before.

Thanks for providing the crucial troubleshooting information, this shows the serial port hardware and driver are working, so it's an application-level problem.

Sorry, I'm not at my computer right now. I'll try it when I get back, but it might not be that fast.

If iManagerNetEco1000U works, it already proves the serial port hardware and driver are working on Windows, so this test is no longer needed.

The problem must exist somewhere within libmodbus or NUT itself. Since you used an Administrator terminal, it's probably not a permission problem. Let me see what I can do on my side to help troubleshooting the problem.

I think it's perhaps a file locking problem. Because libmodbus doesn't implement the "device identification" handshake option, ups2000 opens the serial port twice. Once via ser_open() for the initial model identification, and once via modbus_new_rtu() for nominal driver operation. It's possible that on Windows NT, the serial port is locked by Windows after ser_open(), making reopening it via modbus_new_rtu() impossible. Solving this problem requires adjusting locking or initialization orders (open, close, open).

Until the problem is diagnosed and solved, as a temporary workaround, you can run NUT in a VM as a server, and run NUT on Windows as a client upsc, and connect both sides via TCP/IP.

I was able to connect to the UPS normally using nut 2.8.2, and the data changed (e.g., output.current, output.frequency, output.voltage, ups.load). This should indicate that the serial port is not locked?

Correct. Usually, a cold restart is not really needed. But this step is recommended (after changing ports from USB or SNMP to serial), because it's meant prevent potential problems if more than one port tried to send data.

Also, I found an article on Zhihu. Are you the author?

Yes, but please keep NUT-related problems and discussions on GitHub, not private messages, so they remain visible to all developers and users.

[biergaizi]

Can you try if disabling file locking works? It's not guaranteed to work, but it's a quick test.

nolock

Optional. When you specify this, the driver skips the port locking routines every time it starts. This may allow other processes to seize the port if you start more than one accidentally.

I think the syntax is:

[huawei]
driver = huawei-ups2000
port = XXXX
nolock = 1