The problem is working with several UPS at the same time, connected via USB (Instructions, Setup, Logs) #1754
Comments
|
Thanks for the very detailed write-up :) I think I'll comment as I read it, going along... One thing that seems odd is about The numbers are about how many power sources of the current computer are fed by that device. Unless your rPi sits on an ATS/STS, it probably has one PSU so would be "1" on one UPS (if fed from it) and "0" on other(s). Although Pi's are fun to set up, a HAT like PiJuice might add other power inputs (different USB, solar/battery, etc.) so it is feasible that a Pi really is fed from several different UPSes at once... Unless they somehow conflict on its power bus and burn it - not sure about the wiring there ;-\ The |
…(.in) to install a *.conf pattern [networkupstools#1754] Follow-up for networkupstools#1030, networkupstools#1037, networkupstools#1117 May be related to networkupstools#1712
|
Also note the permissions warnings about files potentially with passwords and other sensitive data (ups.conf, upsd.conf, upsd.users, upsmon.conf), they should only be accessible to daemon accounts - usually as RW for |
|
Also wondering how this worked before first reboot: Such units would be generated (and enabled unless you pre-masked them) by I guess you experimented several times so a copy of that service ran and picked up edition events of the ups.conf file?.. |
|
Overall, it is really encouraging that at least initially the two drivers did run together and detected different instances of the devices (was it deterministic though - did "riello1000" always grab "SWM073-01-00", and did "rps1000" always grab "SWM073-01-01"; did it reliably succeed at all - if you ran the experiment several times?)
Alas, the behavior in the end of the post seems to match my expectations from detection logic described in #1744 - that to monitor several devices you need to match some unique set of their properties. In your case serial numbers are different (empty in one, nontrivial in the other) so that may help. Another possibility is that |
jimklimov
added
Riello
|
Would some progress on #1756 address the problem? At least it is something we can try to avoid the stalemate... |
Sorry, it's my fault. Thanks for correct.
The connection is as follows: I have two UPS - this RPi is connected to the power supply, as well as a gateway, a switch and Wi-Fi to the first, and more energy-intensive devices are connected to the second. Both UPSs are connected via USB to the RPi, where I want to take measurements.
Agreed. |
I tried to replace it - the situation remained unchanged. |
I never did without rebooting: systemctl start
Immediately after installing the package, these services are visible - without any startup - so it was done as above.
I'm not sure if I understood you correctly, but - yes, of course I experimented for several days, each time installing a clean system and setting up the configs again and again |
I can confidently say that the first time - there was always a correct connection, the names corresponded to the required indicators. After reboots - then it was already different: several reboots - no driver connected, rebooted again - connected, but the indicators did not match the names of the UPS, rebooted several times - they did. In other words, everything goes chaotically. |
I still don't understand what exactly I should do/check. |
At a minimum - confirm that such option makes sense? It will probably still be chaotic - which device is known as "riello1000" or "rps1000" from one boot to another. But at least it is a step forward if you want the two UPS states monitored without caring for their identity - which matches not providing any uniquely identifying data into their configurations. At a maximum, propose a PR :) Though in fact I hope to get to it some day... |
|
Also it might help to look into higher debug-verbosity messages from the drivers being started and trying to match their devices when you provide valid Note you can use |
|
Of course, if there was an identification of each device - bus, device - it would really solve the problem. But as I already noted (#1744) - the driver does not support these parameters. |
|
Looking at code I am fairly sure it does. But lacking a device I can't run and step through it to prove that - or to catch it by hand where it calls something different than what I expect from reading the C words :\ |
Checked. Fresh install (not reboot). When enable only nut-driver.target & nut.target then start only nut.target - run all services without: Maybe that why: Here is nothig about nut-driver@*****.service |
ups.confsyslog |
|
What was done: Then enter only: |
|
Thanks!.. so it bypasses usb-common init template, will check... (Part of why there is a long-standing quest to combine all drivers for similar media into a few, ideally one, to avoid surprises like this). |
|
Is there anything else I can do/check something to solve my problem? |
|
By the way, I found out that But must be enabled - In the end: After that only enough - |
|
Normally, the |
It might be quicker if you can also go over riello_usb.c sources (and whatever libusbX.c or usb-common.c the build pulls in) to check where it misses the |
…in nut_usb_addvars() where needed [networkupstools#1754]
… sneak in nut_usb_addvars() where needed [networkupstools#1754]
…le() to sneak in nut_usb_addvars() where needed [networkupstools#1754]
|
Hello, hopefully the fix from https://github.com/jimklimov/nut/tree/issue-1754-riello-device should let custom-built NUT discover the riello (and some other) USB devices with more variables to consider. UPDATE: Now merged to master branch. |
…in nut_usb_addvars() where needed [networkupstools#1754]
…t_usb_addvars() [networkupstools#1754]" This reverts commit 3b1b921. This driver uses a very custom device-matcher.
…t_usb_addvars() [networkupstools#1754]" This reverts commit 3b1b921. This driver uses a very custom device-matcher.
|
Looking for some more clues in "Next, a normal system reboot and this is what the system log shows" part, I think I could have gotten the reason for driver abortions (so one runs at a time) inverted. I wrote that one starts first, another sees the same device (first match by VID:PID as the only values tested) as busy and aborts. In fact it may be that the latest newly started grabs the matched device (intentionally, to try and resume monitoring if an older process froze somehow), and then the other driver which is not frozen but used same libusb device entry says "Got disconnected by another driver: Device or resource busy" and aborts. I see your |
|
...or maybe not: here I'm trying to start another driver for my device, and it is not hijacking it (did not kill the competitor either, different state paths used for test): |
…in nut_usb_addvars() where needed [networkupstools#1754]
Hi to all
I've been trying to figure out for a few days what I'm doing wrong with the installation and subsequent setup of version 2.8.0. The result is the same every time.
At first, I even thought that the problem was in the riello_usb driver, that it had no parameters: bus, device, and so on. Even created a post about it - #1744. But then I found out that the package can work without them.
I believe that this post will be relevant to many people, because many problems that I have had to deal with, have not been written about anywhere. I used the search, but I did not find the answer, only by the method of my mistakes and reading the logs, I discovered the necessary actions to prevent problems with the NUT.
I have several UPSs connected to a Raspberry Pi4 4GB via USB. The installation was performed on a clean system by Buster. The only thing that I immediately changed for my needs was the Shell (tcsh), but I also used the default (bash). The behavior is as follows when I start it for the first time - everything works as it should: it finds both devices, drivers are connected, all services are started. But it is enough to reboot only once, as the struggle for the USB port immediately begins. Below I will show all the necessary data.
Immediately the question:
First about the system.
cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.1uname -a
Linux rasp4 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linuxcat /etc/os-release
lsusb
Models of my UPSs.
Next, I want to show step by step how I install and configure NUT. The type of instruction is similar to what is written in the Wiki, but a little easier (although I tried to install it as it was proposed).
1. Install packages:
apt-get update && apt-get install -y build-essential autoconf gettext libusb-dev libtool libgd-dev2. Get 'nut-master':
3. Create new group 'nut':
groupadd --system nut4. Create new user 'ups':
useradd --system --gid=nut --home-dir=/var/lib/nut --shell=/sbin/nologin ups5. Configure and make source:
6. Setup NUT.
mv /usr/lib/tmpfiles.d/nut-common.tmpfiles /usr/lib/tmpfiles.d/nut-common.confshutdown -r nowList of folder '/var/run/nut/':
This is what is written in the logs at the first start of the system with the newly installed NUT package
For run command 'upsc -l' need some change in file '/etc/hosts'
The data is correctly read from each device
upsc [email protected]
upsc [email protected]
Next, a normal system reboot and this is what the system log shows
Please, I'm really begging for someone's feedback, I'm just stuck and don't know how to proceed. Any information I can provide.
Thanks for paying attention, everyone
The text was updated successfully, but these errors were encountered: