gamatronic driver doesn't work on Raspberry Pi, works fine on x86 computer

[UnderEu]

I have this UPS unit w/ USB interface, 100% supported by the gamatronic driver. It works perfect on my x86 computer but it doesn't on my Raspberry Pi, which is the equipment I intended to plug it in.

All it logs on the RPI is:

~$ sudo upsdrvctl start 
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Gamatronic UPS driver 0.02 (2.7.4)
Connected to UPS on /dev/ttyACM0 baudrate: 1200
UPS: NHSemas de Enee Energia MINOI0AL 600 V600 VA
Driver exited abnormally

Meanwhile on x86 computer:

~$ sudo upsdrvctl start 
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Gamatronic UPS driver 0.02 (2.7.4)
Connected to UPS on /dev/ttyACM0 baudrate: 1200
UPS: NHS Sistemas de Energia MINI SENOIDAL 600 VA

~$ 

Software-wise, both equipments run the exact same stuff:

• Ubuntu 20.04 LTS (amd64 on PC, arm64 on RPi)
• nut version: 2.7.4-11ubuntu4

This is all running on default configuration (only changes: driver & port on ups.conf; mode=standalone on nut.conf), no service enabled, no upsmon, no permission changes, no nothing - all testing before moving to "production".

Am I doing something wrong?

[jimklimov]

Recently we've had several reports about issues with USB UPSes and Raspberry Pi of different generations, it may help if you reviewed other cases to judge if yours is similar or something new, as well as to look at launching the driver with higher verbosity to check why it aborts.

Some of the cases seemed to be due to 32-bit OS (at least per default Raspbian) or even CPU (Raspberry Pi 1 or 2) in those situations; I'd trust your statement that you do run arm64 :)

Another possibility (to be checked and ruled out... or confirmed) was some sort of mismatch between NUT codebase supporting libusb-0.1 and modern distros probably shipping libusb-1.x, and there are some API incompatibilities between the two so updating NUT to support both got bogged down and is still a target living in separate branches (see discussion and references from issue #300).

Finally (for a short check-list), can you please see if compiling NUT from the master branch, or a merge with master of one of those competing branches introducing libusb-1.x support, would provide a different behavior on your system? Sadly, the latest release 2.7.4 is rather old now, but master development is still converging to state that can yield a new release.

[Grandma-Betty]

Finally (for a short check-list), can you please see if compiling NUT from the master branch...

I would also like to try this for my open issue #1004 Is there an instruction somewhere how to compile nut?

Edit: Found here an instruction to lean on, I hope this will do the trick: https://github.com/mini-box/openups/blob/master/README.md

[jimklimov]

That instruction looks reasonable; note that depending on devices you would need to support, their drivers may need certain third-party libraries. See ./configure --help for options about enabling different classes of drivers; if you do require them and the configure script does not locate the dependency, it would fail the build and you'd know what additionally to install.

[Grandma-Betty]

Thank you. Just curious what value I would have to insert on the following command...

sudo /lib/nut/usbhid-ups -u root -a <myDevice>

...when my UPS device is a Eaton 5P650IR. Any hints where I can get this value from?

[jimklimov]

The -a <myDevice> part comes from the [myDevice] section name in /etc/{nut,ups}/ups.conf in a typical installation, which configures parameters for that device. A single installation of NUT can monitor/manage many devices, defining many such sections there and so launching many NUT drivers to talk to each UPS.

While testing, you can use the nut-scanner program which tries to detect devices and if successful - suggests the options section content.

On recent NUT you can also run the drivers (e.g. usbhid-ups) without a defined section, usually for similar probing but not with a half-mock like nut-scanner but with the real full-featured driver. This is done with syntax like <driverName> -s <myDevice> -DDDDDD -x port=auto [-x key=value...] where you can use a device not defined in any config file, and can provide all options on command line with -x k(=v) (some options are flags, most are key-value pairs); the -D's each bump debugging verbosity level. The port option is required, can be auto to iterate all ports it finds or a particular /dev/ttyUSB0 or similar path - but these system node names tend to get reenumerated between reboots based on amount of plugged devices, hub port used, etc. For USB-media drivers you can usually specify the product/vendor IDs to specify your device, especially if one comes with a USB chip whose IDs are not hardcoded in a driver but otherwise protocol is known.

Note that not all USB-connected UPSes follow the HID protocol; another large group is based on dialects derived from Megatec Q protocol. There are several drivers for this historically, but most (hopefully all) devices should be covered by the newest nutdrv_qx driver. Some Eaton devices, depending on heritage of the product line, might also use SHUT protocol so possibly mge-shut driver or some similar.

See command-line options with -h in any of these programs for more details.

UPDATE: Discussion at https://community.synology.com/enu/forum/17/post/109212 seems to confirm your UPS model should work with usbhid-ups indeed.

[UnderEu]

I just finished testing the quoted branches and, with all of them, ZERO success =( All logs are included in the following attachment. I'm including my x86 computer logs, for comparison

Logs

[Grandma-Betty]

Tried to compile and it worked without any hickups.

But when I try to execute the following command from the tutorial's step 3...

/usr/local/ups/sbin/upsdrvctl stop

... it gives me the following error:

Can't open /var/state/ups/usbhid-ups-nutdev1.pid: No such file or directory Can't open /var/state/ups/usbhid-ups-auto.pid either: No such file or directory

Which is logcal because the directory /var/state doesn't even exist.

Then, on step 4, when executing...

/usr/local/ups/bin/usbhid-ups -u ups -a <myDevice>

...it gives the following error:

-bash: /usr/local/ups/bin/usbhid-ups: No such file or directory

Which is also logcal because usbhid-ups does just not exist within the directory /usr/local/ups/bin/.

Seems like the tutorial is outdated according to the latest nut master branch on the official github repository, is it? Any hints what to do to make this work?

[jimklimov]

Being an autoconf-based project, a build of NUT may by default adapt its path to a distribution (e.g. basing at /usr/local/ups, /usr/local, /usr, /, /opt etc.). This is tweaked among hordes of flags you can pass to the configure script before executing a build; typical packaging impacts many of these tweaks - in particular where driver binaries would land.

If you did a sudo make install I am not sure why it would not make /var/state (and ups in it) appear though.

Thinking of it, for the purpose of testing you can just run the driver from build directory (probably as root to access the usb/serial device nodes in the OS) without even a make install, e.g.

sudo ./drivers/usbhid-ups ...

Also a recent driver general option -d for data-dump mode can come handy. It runs for a few (specified number) polling loops and then exits to report collected data points. I think it does not make a state file then.

An envvar like NUT_ALTSTATEPATH=/tmp can direct the driver to use a custom location as well.

On Wed, Apr 21, 2021, 16:12 neverEatYellowSwissSnow < @.***> wrote:

Tried to compile and it worked without any hickups.

But when I try to execute the following command from the tutorial's step 3...

/usr/local/ups/sbin/upsdrvctl stop

... it gives me the following error:

Can't open /var/state/ups/usbhid-ups-nutdev1.pid: No such file or directory Can't open /var/state/ups/usbhid-ups-auto.pid either: No such file or directory

Which is also logcal because the directory /var/state doesn't even exist.

Then, on step 4, when executing...

/usr/local/ups/bin/usbhid-ups -u ups -a

...it gives the following error:

-bash: /usr/local/ups/bin/usbhid-ups: No such file or directory

Which is also logcal because usbhid-ups is just not within the directory /usr/local/ups/bin/.

Seems like the tutorial is outdated according to the latest nut master branch on the official github repository, is it? Any hints what to do to make this work?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/1019#issuecomment-824093784, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFCNFS2A5EEQKRMG56LTJ3MMVANCNFSM43DOXWRA .

[Grandma-Betty]

Thinking of it, for the purpose of testing you can just run the driver from build directory (probably as root to access the usb/serial device nodes in the OS) without even a make install, e.g. sudo ./drivers/usbhid-ups ...

Well, the usbhid-ups doesn't even exist within the drivers directory. I went through the steps again and after the configure command I mentioned that the output said that USB drivers were not even ready to be built (look at build USB drivers: no):

Configuration summary: build serial drivers: yes build USB drivers: no build neon based XML driver: no enable Avahi support: no build Powerman PDU client driver: no build Modbus driver: no build IPMI driver: no build Mac OS X meta-driver: no build i2c based drivers: no enable SSL support: yes (OpenSSL) enable libwrap (tcp-wrappers) support: no enable libltdl (Libtool dlopen abstraction) support: yes build nut-scanner: yes build CGI programs: no build and install documentation: man=auto build specific documentation format(s): no build and install the development files: no build SNMP drivers: no

So I tried the following command:

configure --with-usb=yes

which threw the following error:

configure: error: USB drivers requested, but libusb not found.

What's the problem here? How can I include libusb to make this work?

[jimklimov]

Install it and its development files (headers, mayve versioned SO-links) which depends on the OS.

For Debian-like systems it libusb-1.0-0-dev : https://packages.debian.org/buster/libusb-1.0-0-dev

Do not mistake it for https://packages.debian.org/buster/libusb-dev which is 0.1.x

On Thu, Apr 22, 2021, 09:17 neverEatYellowSwissSnow < @.***> wrote:

Thinking of it, for the purpose of testing you can just run the driver from build directory (probably as root to access the usb/serial device nodes in the OS) without even a make install, e.g. sudo ./drivers/usbhid-ups ...

Well, the usbhid-ups doesn't even exist within the drivers directory. I went through the steps again and after the configure command I mentioned that the output said that USB drivers were not even ready to be built (look at build USB drivers: no):

Configuration summary: build serial drivers: yes build USB drivers: no build neon based XML driver: no enable Avahi support: no build Powerman PDU client driver: no build Modbus driver: no build IPMI driver: no build Mac OS X meta-driver: no build i2c based drivers: no enable SSL support: yes (OpenSSL) enable libwrap (tcp-wrappers) support: no enable libltdl (Libtool dlopen abstraction) support: yes build nut-scanner: yes build CGI programs: no build and install documentation: man=auto build specific documentation format(s): no build and install the development files: no build SNMP drivers: no

So I tried the following command:

configure --with-usb=yes

which threw the following error:

configure: error: USB drivers requested, but libusb not found.

What's the problem here? How can I include libusb to make this work?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/1019#issuecomment-824602979, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFB4I5TFHXATPJAXK43TJ7ERHANCNFSM43DOXWRA .

[Grandma-Betty]

I could indeed install it and now I'm on libusb-1.0-0-dev version (2:1.0.23-2build1) but the same error message still remains, even after a system reboot, when trying to execute configure --with-usb=yes:

configure: error: USB drivers requested, but libusb not found.

[Grandma-Betty]

OK, I'm a step further now. When executing uname -a , it shows the following ubuntu version: Linux ubuntu 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:32:12 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

So somehow in this version I had to install libusb-dev instead of libusb-1.0-0-dev to make the configure --with-usb=yes work.

Now: It really seems to be a problem that the path /vat/state/ with all its subfolders does not even exist because when trying to execute the driver directly by your suggested method sudo ./usbhid-ups -u root -a <myDevice> it throws the following error:

Network UPS Tools - Generic HID driver 0.43 (2.7.4-2257-g21462682) USB communication driver 0.33 Can't chdir to /var/state/ups: No such file or directory

[jimklimov]

The directory should have appeared if you sudo make install after the build, or had NUT package installed, for that matter...

You can also create it by mkdir -p /var/state/ups and chown it to nut (or ups) though that may be somewhat imperfect (again, specific account names to own filesystem objects as well as paths involved are corollaries of parameters you pass to a configure script, or defaults it guesses for an OS).

In hindsight, a good starting point can be to look at the source package of NUT for your distro, there should be a debian/rules file that contains configuration used to make the package. Then you'd tweak that for the custom build (e.g. add more parameters)...

On Fri, Apr 23, 2021, 14:28 neverEatYellowSwissSnow < @.***> wrote:

OK, I'm a step further now. When executing uname -a , it shows the following ubuntu version: Linux ubuntu 5.4.0-72-generic #80 https://github.com/networkupstools/nut/pull/80-Ubuntu SMP Mon Apr 12 17:32:12 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

So somehow in this version I had to install libusb-dev instead of libusb-1.0-0-dev to make the configure --with-usb=yes work.

Now: It really seems to be a problem that the path /vat/state/ with all its subfolders does not even exist because when trying to execute the driver directly by your suggested method sudo ./usbhid-ups -u root -a

it throws the following error: *Network UPS Tools - Generic HID driver 0.43 (2.7.4-2257-g21462682) USB communication driver 0.33 Can't chdir to /var/state/ups: No such file or directory* — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or unsubscribe .

[Grandma-Betty]

OK, got it now. When executing sudo ./usbhid-ups -u root -a <myDevice> it just tells me:

Network UPS Tools - Generic HID driver 0.43 (2.7.4-2257-g21462682) USB communication driver 0.33 No matching HID UPS found

So I guess even on the latest NUT master branch it has the same problem as already described in my issue #1004