Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
UnderEu opened this issue Apr 17, 2021 · 14 comments
Open

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

UnderEu opened this issue Apr 17, 2021 · 14 comments
Labels
raspberry USB

Comments

@UnderEu
Copy link

UnderEu commented Apr 17, 2021 •
edited
Loading

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?
@UnderEu UnderEu changed the title gamatronic driver doesn't work on Raspberry Pi, works just fine on x86 computer gamatronic driver doesn't work on Raspberry Pi, works fine on x86 computer Apr 17, 2021
@jimklimov
Copy link
Member

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
Copy link

Grandma-Betty commented Apr 20, 2021 •
edited
Loading

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
Copy link
Member

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
Copy link

Grandma-Betty commented Apr 21, 2021 •
edited
Loading

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
Copy link
Member

jimklimov commented Apr 21, 2021 •
edited
Loading

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
Copy link
Author

UnderEu commented Apr 21, 2021

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
Copy link

Grandma-Betty commented Apr 21, 2021 •
edited
Loading

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
Copy link
Member

jimklimov commented Apr 21, 2021 via email

@Grandma-Betty
Copy link

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
Copy link
Member

jimklimov commented Apr 22, 2021 via email

@Grandma-Betty
Copy link

Grandma-Betty commented Apr 22, 2021 •
edited
Loading

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
Copy link

Grandma-Betty commented Apr 23, 2021 •
edited
Loading

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
Copy link
Member

jimklimov commented Apr 23, 2021 via email

@Grandma-Betty
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
raspberry USB
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jimklimov @UnderEu @Grandma-Betty