How does one start "nut" to handle a local UPS?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have one UPS (with an almost dead battery) and I want to at least see it with NUT. When I connect it, I see in the log: <0.6> 2021-04-14T23:36:49.659987+02:00 Isengard kernel - - - [11662.628468] usb 1-2.2: new low-speed USB device number 5 using xhci_hcd <0.6> 2021-04-14T23:36:49.815973+02:00 Isengard kernel - - - [11662.787160] usb 1-2.2: New USB device found, idVendor=0665, idProduct=5161, bcdDevice= 0.02 <0.6> 2021-04-14T23:36:49.816019+02:00 Isengard kernel - - - [11662.787165] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 <0.6> 2021-04-14T23:36:49.816023+02:00 Isengard kernel - - - [11662.787168] usb 1-2.2: Product: USB to Serial <0.6> 2021-04-14T23:36:49.816026+02:00 Isengard kernel - - - [11662.787170] usb 1-2.2: Manufacturer: INNO TECH <0.6> 2021-04-14T23:36:49.816049+02:00 Isengard kernel - - - [11662.787172] usb 1-2.2: SerialNumber: 20.... <0.6> 2021-04-14T23:36:49.827962+02:00 Isengard kernel - - - [11662.798017] hid-generic 0003:0665:5161.0005: hiddev97,hidraw2: USB HID v1.00 Device [INNO TECH USB to Serial] on usb-0000:00:14.0-2.2/input0 <1.6> 2021-04-14T23:36:49.951367+02:00 Isengard mtp-probe - - - checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2" <1.6> 2021-04-14T23:36:49.952720+02:00 Isengard mtp-probe - - - bus: 1, device: 5 was not an MTP device I read the documentation file "/usr/share/doc/packages/nut/README.SUSE" It says: It requires only few adoptions before you can start the service: * Configuration of a locally connected UPS: In /etc/ups/ups.conf: - Go to the [myups] section at the end of the file. - Set driver key to the driver name supporting your UPS. (see /usr/lib/ups/driver/ for possible drivers. Each driver has a man page. Many USB UPSes are usbhid-ups.) - Set port key to the device your UPS is connected to, e.g. /dev/ttyS0 for first serial port (COM1) or /dev/usb/hiddev0 for USB HID UPS. - Adjust desc key as you want. Start the service: - "/etc/init.d/upsd start" No autodetection script in year 2021? Sigh. :-( Ok, so I configure "ups.conf". What driver? My UPS is "Salicru", there is no driver listed. Google sugest "blazer_usb". [myups] driver = blazer_usb port = /dev/usb/hiddev0 desc = "Salicru SPS SOHO+ 800VA" Start the service with "/etc/init.d/upsd start". Surely this is obsolete! Yes, the documentation is dated 2014. The posibilities are: /usr/sbin/rcnut-driver /usr/sbin/rcnut-monitor /usr/sbin/rcnut-server or /usr/lib/systemd/system/nut-driver.service /usr/lib/systemd/system/nut-monitor.service /usr/lib/systemd/system/nut-server.service No "/etc/init.d/upsd". So how do I start it? I try "systemctl start nut-driver.service" <3.6> 2021-04-15T00:12:36.916959+02:00 Isengard systemd 1 - - Started Session 5 of user root. <10.6> 2021-04-15T00:12:36.922301+02:00 Isengard sshd 11557 - - pam_unix(sshd:session): session opened for user root by (uid=0) <3.6> 2021-04-15T00:12:53.295533+02:00 Isengard systemd 1 - - nut-driver.service: Unit not needed anymore. Stopping. <3.5> 2021-04-15T00:12:53.296254+02:00 Isengard systemd 1 - - Requested transaction contradicts existing jobs: Transaction for nut-driver.service/stop is destructive (nut-driver.service has 'start' job queued, but 'stop' is included in transaction). <3.4> 2021-04-15T00:12:53.296799+02:00 Isengard systemd 1 - - nut-driver.service: Failed to enqueue stop job, ignoring: Transaction for nut-driver.service/stop is destructive (nut-driver.service has 'start' job queued, but 'stop' is included in transaction). <3.6> 2021-04-15T00:12:53.297378+02:00 Isengard systemd 1 - - Starting Network UPS Tools - power device driver controller... <3.6> 2021-04-15T00:12:53.578538+02:00 Isengard upsdrvctl 11633 - - Supported UPS detected with megatec protocol <3.6> 2021-04-15T00:12:53.898349+02:00 Isengard upsdrvctl 11633 - - Vendor information unavailable <3.6> 2021-04-15T00:12:53.898943+02:00 Isengard upsdrvctl 11633 - - No values provided for battery high/low voltages in ups.conf <3.6> 2021-04-15T00:12:53.899339+02:00 Isengard upsdrvctl 11633 - - Using 'guestimation' (low: 10.400000, high: 13.000000)! <3.6> 2021-04-15T00:12:53.899719+02:00 Isengard upsdrvctl 11633 - - Battery runtime will not be calculated (runtimecal not set) <3.6> 2021-04-15T00:12:54.156106+02:00 Isengard upsdrvctl 11633 - - Network UPS Tools - UPS driver controller 2.7.4 <3.6> 2021-04-15T00:12:54.156653+02:00 Isengard blazer_usb 11636 - - Startup successful <3.6> 2021-04-15T00:12:54.157393+02:00 Isengard systemd 1 - - Started Network UPS Tools - power device driver controller. <3.6> 2021-04-15T00:12:54.157981+02:00 Isengard systemd 1 - - nut-driver.service: Unit not needed anymore. Stopping. <3.6> 2021-04-15T00:12:54.164015+02:00 Isengard systemd 1 - - Stopping Network UPS Tools - power device driver controller... <3.6> 2021-04-15T00:12:54.167969+02:00 Isengard upsdrvctl 11638 - - Network UPS Tools - UPS driver controller 2.7.4 <3.6> 2021-04-15T00:12:56.156325+02:00 Isengard blazer_usb 11636 - - Signal 15: exiting <3.6> 2021-04-15T00:12:56.159324+02:00 Isengard systemd 1 - - Stopped Network UPS Tools - power device driver controller. So what next? I understand nothing. Did it work? I tried removing the AC cord. Nothing appears in the log. Google suggests that I edit "nut.conf": MODE=standalone done. ... No change, doesn't seem to work at all. - -- Cheers Carlos E. R. (from 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHdvZRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVNtIAnRr/gM7VpAuJOHHArKGC 39NPDQW5AJ9aACYcyCV9e/oC8Zsstcx6JzKAJg== =5Irv -----END PGP SIGNATURE-----
On 2021-04-14 17:40:37 Carlos E. R. wrote:
|Hi, | |I have one UPS (with an almost dead battery) and I want to at least see it |with NUT. When I connect it, I see in the log: | |<0.6> 2021-04-14T23:36:49.659987+02:00 Isengard kernel - - - | [11662.628468] usb 1-2.2: new low-speed USB device number 5 using | xhci_hcd <0.6> 2021-04-14T23:36:49.815973+02:00 Isengard kernel - - - | [11662.787160] usb 1-2.2: New USB device found, idVendor=0665, | idProduct=5161, bcdDevice= 0.02 <0.6> 2021-04-14T23:36:49.816019+02:00 | Isengard kernel - - - [11662.787165] usb 1-2.2: New USB device strings: | Mfr=1, Product=2, SerialNumber=3 <0.6> 2021-04-14T23:36:49.816023+02:00 | Isengard kernel - - - [11662.787168] usb 1-2.2: Product: USB to Serial | <0.6> 2021-04-14T23:36:49.816026+02:00 Isengard kernel - - - | [11662.787170] usb 1-2.2: Manufacturer: INNO TECH <0.6> | 2021-04-14T23:36:49.816049+02:00 Isengard kernel - - - [11662.787172] usb | 1-2.2: SerialNumber: 20.... <0.6> 2021-04-14T23:36:49.827962+02:00 | Isengard kernel - - - [11662.798017] hid-generic 0003:0665:5161.0005: | hiddev97,hidraw2: USB HID v1.00 Device [INNO TECH USB to Serial] on | usb-0000:00:14.0-2.2/input0 <1.6> 2021-04-14T23:36:49.951367+02:00 | Isengard mtp-probe - - - checking bus 1, device 5: | "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2" <1.6> | 2021-04-14T23:36:49.952720+02:00 Isengard mtp-probe - - - bus: 1, | device: 5 was not an MTP device | | |I read the documentation file "/usr/share/doc/packages/nut/README.SUSE" | |It says: | |It requires only few adoptions before you can start the service: | | | * Configuration of a locally connected UPS: | | In /etc/ups/ups.conf: | - Go to the [myups] section at the end of the file. | - Set driver key to the driver name supporting your UPS. | (see /usr/lib/ups/driver/ for possible drivers. Each driver | has a man page. Many USB UPSes are usbhid-ups.) | - Set port key to the device your UPS is connected to, | e.g. /dev/ttyS0 for first serial port (COM1) or | /dev/usb/hiddev0 | for USB HID UPS. | - Adjust desc key as you want. | | Start the service: | - "/etc/init.d/upsd start" | | | |No autodetection script in year 2021? Sigh. :-( |Ok, so I configure "ups.conf". | |What driver? My UPS is "Salicru", there is no driver listed. Google sugest | "blazer_usb". | |[myups] | driver = blazer_usb | port = /dev/usb/hiddev0 | desc = "Salicru SPS SOHO+ 800VA" | |Start the service with "/etc/init.d/upsd start". Surely this is obsolete! |Yes, the documentation is dated 2014. The posibilities are: | |/usr/sbin/rcnut-driver |/usr/sbin/rcnut-monitor |/usr/sbin/rcnut-server | |or | |/usr/lib/systemd/system/nut-driver.service |/usr/lib/systemd/system/nut-monitor.service |/usr/lib/systemd/system/nut-server.service | | |No "/etc/init.d/upsd". So how do I start it? | |I try "systemctl start nut-driver.service" | | |<3.6> 2021-04-15T00:12:36.916959+02:00 Isengard systemd 1 - - Started | Session 5 of user root. <10.6> 2021-04-15T00:12:36.922301+02:00 Isengard | sshd 11557 - - pam_unix(sshd:session): session opened for user root by | (uid=0) <3.6> 2021-04-15T00:12:53.295533+02:00 Isengard systemd 1 - - | nut-driver.service: Unit not needed anymore. Stopping. <3.5> | 2021-04-15T00:12:53.296254+02:00 Isengard systemd 1 - - Requested | transaction contradicts existing jobs: Transaction for | nut-driver.service/stop is destructive (nut-driver.service has 'start' | job queued, but 'stop' is included in transaction). <3.4> | 2021-04-15T00:12:53.296799+02:00 Isengard systemd 1 - - | nut-driver.service: Failed to enqueue stop job, ignoring: Transaction for | nut-driver.service/stop is destructive (nut-driver.service has 'start' | job queued, but 'stop' is included in transaction). <3.6> | 2021-04-15T00:12:53.297378+02:00 Isengard systemd 1 - - Starting Network | UPS Tools - power device driver controller... <3.6> | 2021-04-15T00:12:53.578538+02:00 Isengard upsdrvctl 11633 - - Supported | UPS detected with megatec protocol <3.6> 2021-04-15T00:12:53.898349+02:00 | Isengard upsdrvctl 11633 - - Vendor information unavailable <3.6> | 2021-04-15T00:12:53.898943+02:00 Isengard upsdrvctl 11633 - - No values | provided for battery high/low voltages in ups.conf <3.6> | 2021-04-15T00:12:53.899339+02:00 Isengard upsdrvctl 11633 - - Using | 'guestimation' (low: 10.400000, high: 13.000000)! <3.6> | 2021-04-15T00:12:53.899719+02:00 Isengard upsdrvctl 11633 - - Battery | runtime will not be calculated (runtimecal not set) <3.6> | 2021-04-15T00:12:54.156106+02:00 Isengard upsdrvctl 11633 - - Network | UPS Tools - UPS driver controller 2.7.4 <3.6> | 2021-04-15T00:12:54.156653+02:00 Isengard blazer_usb 11636 - - Startup | successful <3.6> 2021-04-15T00:12:54.157393+02:00 Isengard systemd 1 - - | Started Network UPS Tools - power device driver controller. <3.6> | 2021-04-15T00:12:54.157981+02:00 Isengard systemd 1 - - | nut-driver.service: Unit not needed anymore. Stopping. <3.6> | 2021-04-15T00:12:54.164015+02:00 Isengard systemd 1 - - Stopping Network | UPS Tools - power device driver controller... <3.6> | 2021-04-15T00:12:54.167969+02:00 Isengard upsdrvctl 11638 - - Network | UPS Tools - UPS driver controller 2.7.4 <3.6> | 2021-04-15T00:12:56.156325+02:00 Isengard blazer_usb 11636 - - Signal | 15: exiting <3.6> 2021-04-15T00:12:56.159324+02:00 Isengard systemd 1 - - | Stopped Network UPS Tools - power device driver controller. | | |So what next? I understand nothing. Did it work? | |I tried removing the AC cord. Nothing appears in the log. | | | | |Google suggests that I edit "nut.conf": | | |MODE=standalone | | |done. | |... | | |No change, doesn't seem to work at all.
Looking at https://networkupstools.org/stable-hcl.html/ (the compatibility list for NUT (listed at the bottom of the man page for upsd), I see that many of the entries specify the usbhid-ups driver, which appears to match | 0003:0665:5161.0005: hiddev97,hidraw2: USB HID v1.00 Device [INNO TECH USB to Serial] on usb-0000:00:14.0-2.2/input0 in your log output. From what I see on their website, Salicru apparently thinks that there is only one OS in the world: Windows; but you might try their tech support. Leslie -- openSUSE Leap 15.2 x86_64
On 2021-04-14 17:40:37 Carlos E. R. wrote:
|Hi, | |I have one UPS (with an almost dead battery) and I want to at least see it |with NUT. When I connect it, I see in the log: | |<0.6> 2021-04-14T23:36:49.659987+02:00 Isengard kernel - - - | [11662.628468] usb 1-2.2: new low-speed USB device number 5 using | xhci_hcd <0.6> 2021-04-14T23:36:49.815973+02:00 Isengard kernel - - - | [11662.787160] usb 1-2.2: New USB device found, idVendor=0665, | idProduct=5161, bcdDevice= 0.02 <0.6> 2021-04-14T23:36:49.816019+02:00 | Isengard kernel - - - [11662.787165] usb 1-2.2: New USB device strings: | Mfr=1, Product=2, SerialNumber=3 <0.6> 2021-04-14T23:36:49.816023+02:00 | Isengard kernel - - - [11662.787168] usb 1-2.2: Product: USB to Serial | <0.6> 2021-04-14T23:36:49.816026+02:00 Isengard kernel - - - | [11662.787170] usb 1-2.2: Manufacturer: INNO TECH <0.6> | 2021-04-14T23:36:49.816049+02:00 Isengard kernel - - - [11662.787172] usb | 1-2.2: SerialNumber: 20.... <0.6> 2021-04-14T23:36:49.827962+02:00 | Isengard kernel - - - [11662.798017] hid-generic 0003:0665:5161.0005: | hiddev97,hidraw2: USB HID v1.00 Device [INNO TECH USB to Serial] on | usb-0000:00:14.0-2.2/input0 <1.6> 2021-04-14T23:36:49.951367+02:00 | Isengard mtp-probe - - - checking bus 1, device 5: | "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2" <1.6> | 2021-04-14T23:36:49.952720+02:00 Isengard mtp-probe - - - bus: 1, | device: 5 was not an MTP device | | |I read the documentation file "/usr/share/doc/packages/nut/README.SUSE" | |It says: | |It requires only few adoptions before you can start the service: | | | * Configuration of a locally connected UPS: | | In /etc/ups/ups.conf: | - Go to the [myups] section at the end of the file. | - Set driver key to the driver name supporting your UPS. | (see /usr/lib/ups/driver/ for possible drivers. Each driver | has a man page. Many USB UPSes are usbhid-ups.) | - Set port key to the device your UPS is connected to, | e.g. /dev/ttyS0 for first serial port (COM1) or | /dev/usb/hiddev0 | for USB HID UPS. | - Adjust desc key as you want. | | Start the service: | - "/etc/init.d/upsd start" | | | |No autodetection script in year 2021? Sigh. :-( |Ok, so I configure "ups.conf". | |What driver? My UPS is "Salicru", there is no driver listed. Google sugest | "blazer_usb". | |[myups] | driver = blazer_usb | port = /dev/usb/hiddev0 | desc = "Salicru SPS SOHO+ 800VA" | |Start the service with "/etc/init.d/upsd start". Surely this is obsolete! |Yes, the documentation is dated 2014. The posibilities are: | |/usr/sbin/rcnut-driver |/usr/sbin/rcnut-monitor |/usr/sbin/rcnut-server | |or | |/usr/lib/systemd/system/nut-driver.service |/usr/lib/systemd/system/nut-monitor.service |/usr/lib/systemd/system/nut-server.service | | |No "/etc/init.d/upsd". So how do I start it? | |I try "systemctl start nut-driver.service" | | |<3.6> 2021-04-15T00:12:36.916959+02:00 Isengard systemd 1 - - Started | Session 5 of user root. <10.6> 2021-04-15T00:12:36.922301+02:00 Isengard | sshd 11557 - - pam_unix(sshd:session): session opened for user root by | (uid=0) <3.6> 2021-04-15T00:12:53.295533+02:00 Isengard systemd 1 - - | nut-driver.service: Unit not needed anymore. Stopping. <3.5> | 2021-04-15T00:12:53.296254+02:00 Isengard systemd 1 - - Requested | transaction contradicts existing jobs: Transaction for | nut-driver.service/stop is destructive (nut-driver.service has 'start' | job queued, but 'stop' is included in transaction). <3.4> | 2021-04-15T00:12:53.296799+02:00 Isengard systemd 1 - - | nut-driver.service: Failed to enqueue stop job, ignoring: Transaction for | nut-driver.service/stop is destructive (nut-driver.service has 'start' | job queued, but 'stop' is included in transaction). <3.6> | 2021-04-15T00:12:53.297378+02:00 Isengard systemd 1 - - Starting Network | UPS Tools - power device driver controller... <3.6> | 2021-04-15T00:12:53.578538+02:00 Isengard upsdrvctl 11633 - - Supported | UPS detected with megatec protocol <3.6> 2021-04-15T00:12:53.898349+02:00 | Isengard upsdrvctl 11633 - - Vendor information unavailable <3.6> | 2021-04-15T00:12:53.898943+02:00 Isengard upsdrvctl 11633 - - No values | provided for battery high/low voltages in ups.conf <3.6> | 2021-04-15T00:12:53.899339+02:00 Isengard upsdrvctl 11633 - - Using | 'guestimation' (low: 10.400000, high: 13.000000)! <3.6> | 2021-04-15T00:12:53.899719+02:00 Isengard upsdrvctl 11633 - - Battery | runtime will not be calculated (runtimecal not set) <3.6> | 2021-04-15T00:12:54.156106+02:00 Isengard upsdrvctl 11633 - - Network | UPS Tools - UPS driver controller 2.7.4 <3.6> | 2021-04-15T00:12:54.156653+02:00 Isengard blazer_usb 11636 - - Startup | successful <3.6> 2021-04-15T00:12:54.157393+02:00 Isengard systemd 1 - - | Started Network UPS Tools - power device driver controller. <3.6> | 2021-04-15T00:12:54.157981+02:00 Isengard systemd 1 - - | nut-driver.service: Unit not needed anymore. Stopping. <3.6> | 2021-04-15T00:12:54.164015+02:00 Isengard systemd 1 - - Stopping Network | UPS Tools - power device driver controller... <3.6> | 2021-04-15T00:12:54.167969+02:00 Isengard upsdrvctl 11638 - - Network | UPS Tools - UPS driver controller 2.7.4 <3.6> | 2021-04-15T00:12:56.156325+02:00 Isengard blazer_usb 11636 - - Signal | 15: exiting <3.6> 2021-04-15T00:12:56.159324+02:00 Isengard systemd 1 - - | Stopped Network UPS Tools - power device driver controller. | | |So what next? I understand nothing. Did it work? | |I tried removing the AC cord. Nothing appears in the log. | | | | |Google suggests that I edit "nut.conf": | | |MODE=standalone | | |done. | |... | | |No change, doesn't seem to work at all.
I think that the usbhid-ups driver is the one you want, based on the message | 0003:0665:5161.0005: hiddev97,hidraw2: USB HID v1.00 Device [INNO TECH USB to Serial] on usb-0000:00:14.0-2.2/input0 in your log. https://networkupstools.org/docs/man/usbhid-ups.html tells you how to set ups.conf. I think that | [Salicru] | driver = usbhid-ups | port = auto ought to be enough, given that you are only communicating with one UPS. There is also a reference there to nut-usbups.rules, to be placed in /etc/udev/rules.d Leslie -- openSUSE Leap 15.2 x86_64
On 2021-04-14 19:14:01 J Leslie Turriff wrote:
| I think that the usbhid-ups driver is the one you want, based on | the message | || 0003:0665:5161.0005: hiddev97,hidraw2: USB HID v1.00 Device [INNO TECH || USB to Serial] on | |usb-0000:00:14.0-2.2/input0 |in your log. | https://networkupstools.org/docs/man/usbhid-ups.html tells you how | to set ups.conf. I think that | || [Salicru] || driver = usbhid-ups || port = auto | |ought to be enough, given that you are only communicating with one UPS. | There is also a reference there to nut-usbups.rules, to be placed | in /etc/udev/rules.d
This might also be useful: http://rogerprice.org/NUT.html Leslie -- openSUSE Leap 15.2 x86_64
On Wed, 14 Apr 2021, J Leslie Turriff wrote:
On 2021-04-14 19:14:01 J Leslie Turriff wrote: This might also be useful: http://rogerprice.org/NUT.html
I havn't done any maintenance on that text for a while. I wrote a more complete NUT User's Guide which is at http://rogerprice.org/NUT/ConfigExamples.A5.pdf On Thu, 15 Apr 2021, Carlos E. R. wrote:
I read the documentation file "/usr/share/doc/packages/nut/README.SUSE"
I try "systemctl start nut-driver.service"
In general one starts NUT by starting the server daemon, and then the monitor daemon. The driver daemon is started automatically by the server. If you have specific questions about the driver, try the NUT mailing list: https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser Roger
On 15/04/2021 08.41, Roger Price wrote:
On Wed, 14 Apr 2021, J Leslie Turriff wrote:
On 2021-04-14 19:14:01 J Leslie Turriff wrote: This might also be useful: http://rogerprice.org/NUT.html
I havn't done any maintenance on that text for a while. I wrote a more complete NUT User's Guide which is at http://rogerprice.org/NUT/ConfigExamples.A5.pdf
Thanks, opened it up, I'll read it up later. I should go and buy a new battery this morning.
On Thu, 15 Apr 2021, Carlos E. R. wrote:
I read the documentation file "/usr/share/doc/packages/nut/README.SUSE"
I try "systemctl start nut-driver.service"
In general one starts NUT by starting the server daemon, and then the monitor daemon. The driver daemon is started automatically by the server.
If you have specific questions about the driver, try the NUT mailing list: https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Well, I need to know which is the correct driver for my device or how to find out. Thanks for the pointer. I hate having to become an expert in a tool in order to just use it. Typical Linux. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 15/04/2021 08.41, Roger Price wrote:
On Wed, 14 Apr 2021, J Leslie Turriff wrote:
On 2021-04-14 19:14:01 J Leslie Turriff wrote: This might also be useful: http://rogerprice.org/NUT.html
I havn't done any maintenance on that text for a while. I wrote a more complete NUT User's Guide which is at http://rogerprice.org/NUT/ConfigExamples.A5.pdf
I'm reading it. Re "Figure 16: NUT provided script for delayed UPS shutdown." ... «This script is executed late in the system shutdown process, and there is no trace in the systemlog of it’s action. If, like the editor, you believe that shutting off power to a system is a majorevent, and should be logged, then you are invited to replace the script provided by NUT with asystemd service unit as shown in appendix 21 which will log the delayed shutdown command.» Why not use "logger"? NAME logger - enter messages into the system log SYNOPSIS logger [options] [message] DESCRIPTION logger makes entries in the system log. When the optional message argument is present, it is written to the log. If it is not present, and the -f option is not given either, then standard input is logged. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Fri, 16 Apr 2021, Carlos E. R. wrote:
I'm reading it.
Re "Figure 16: NUT provided script for delayed UPS shutdown." ... «This script is executed late in the system shutdown process, and there is no trace in the systemlog of it’s action. If, like the editor, you believe that shutting off power to a system is a majorevent, and should be logged, then you are invited to replace the script provided by NUT with asystemd service unit as shown in appendix 21 which will log the delayed shutdown command.»
Why not use "logger"?
The service unit nut-delayed-ups-shutdown.service described in appendix 21 does use logger: ... [Service] Type=oneshot ExecStart=/usr/bin/logger -t nut-delayed-ups-shutdown "upsdrvctl shutting down UPS" ExecStart=/sbin/upsdrvctl shutdown # Debian ... Sorry about the Debianism - an opensuse sysadmin would replace /sbin/upsdrvctl by /usr/sbin/upsdrvctl Roger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2021-04-16 a las 21:48 +0200, Roger Price escribió:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
I'm reading it.
Re "Figure 16: NUT provided script for delayed UPS shutdown." ... «This script is executed late in the system shutdown process, and there is no trace in the systemlog of it’s action. If, like the editor, you believe that shutting off power to a system is a majorevent, and should be logged, then you are invited to replace the script provided by NUT with asystemd service unit as shown in appendix 21 which will log the delayed shutdown command.»
Why not use "logger"?
The service unit nut-delayed-ups-shutdown.service described in appendix 21 does use logger:
Ah, didn't look that far yet. But I mean, the script can also use logger, I do all the time. Needs less complication with enabling services and such ;-)
... [Service] Type=oneshot ExecStart=/usr/bin/logger -t nut-delayed-ups-shutdown "upsdrvctl shutting down UPS" ExecStart=/sbin/upsdrvctl shutdown # Debian ...
Sorry about the Debianism - an opensuse sysadmin would replace /sbin/upsdrvctl by /usr/sbin/upsdrvctl
Oh, it is interesting to see the differences :-) - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHnunRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVgc4AmQF2dYRRdhQlQkgvUj14 XLWCXoEbAJ0UbE6khI2jntMrsEIcLuwzhEx5cw== =9mYu -----END PGP SIGNATURE-----
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Why not use "logger"?
The service unit nut-delayed-ups-shutdown.service described in appendix 21 does use logger:
Ah, didn't look that far yet. But I mean, the script can also use logger, I do all the time. Needs less complication with enabling services and such ;-)
The script is executed so late in the shutdown that there is no longer a logging service. That is the reason I suggest the nut-delayed-ups-shutdown service unit. Roger __________________________________________________________________________
Sorry about the Debianism Oh, it is interesting to see the differences :-)
As George Orwell might have said: All Linux distributions are equal. Some are more equal than others.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2021-04-16 a las 22:42 +0200, Roger Price escribió:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Why not use "logger"?
The service unit nut-delayed-ups-shutdown.service described in appendix 21 does use logger:
Ah, didn't look that far yet. But I mean, the script can also use logger, I do all the time. Needs less complication with enabling services and such ;-)
The script is executed so late in the shutdown that there is no longer a logging service. That is the reason I suggest the nut-delayed-ups-shutdown service unit.
Ah! - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHn9oRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV4P8AniwByxry23XGdwGFi4VY t8Ny7DACAJ9DbniKebS4NOYqv0dqzUnUMyEKnA== =Ztne -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2021-04-14 at 19:14 -0500, J Leslie Turriff wrote:
On 2021-04-14 17:40:37 Carlos E. R. wrote:
|Hi, | |I have one UPS (with an almost dead battery) and I want to at least see it |with NUT. When I connect it, I see in the log:
|... | | |No change, doesn't seem to work at all.
I think that the usbhid-ups driver is the one you want, based on the message | 0003:0665:5161.0005: hiddev97,hidraw2: USB HID v1.00 Device [INNO TECH USB to Serial] on usb-0000:00:14.0-2.2/input0 in your log.
No, that's a red herring. These things do not "talk usb". Somebody designed this with an RS232 interface long ago. When computers stoped having serrial ports, they did not switch to USB; instead, they added a serial to USB converter. Thus the identification we get is that from the USB converter, NOT from the actual machine behind it. You have to talk with the serial port to find out what is there. Anyway, I tried "driver = usbhid-ups". Apr 15 11:30:33 Isengard systemd[1]: Starting Network UPS Tools - power device driver controller... Apr 15 11:30:33 Isengard upsdrvctl[28250]: Network UPS Tools - Generic HID driver 0.41 (2.7.4) Apr 15 11:30:33 Isengard upsdrvctl[28250]: USB communication driver 0.33 Apr 15 11:30:33 Isengard upsdrvctl[28250]: No matching HID UPS found Apr 15 11:30:33 Isengard upsdrvctl[28250]: Driver failed to start (exit status=1) Apr 15 11:30:33 Isengard upsdrvctl[28250]: Network UPS Tools - UPS driver controller 2.7.4 Apr 15 11:30:33 Isengard systemd[1]: nut-driver.service: Control process exited, code=exited status=1 Apr 15 11:30:33 Isengard systemd[1]: Failed to start Network UPS Tools - power device driver controller. Apr 15 11:30:33 Isengard systemd[1]: nut-driver.service: Unit entered failed state. Apr 15 11:30:33 Isengard systemd[1]: nut-driver.service: Failed with result 'exit-code'. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHgLgRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV5O4AnRtD2p2HJdSXytvBBT1b mdhLPm5yAJ4mUNPsE6UgXOxNpwxq7uxrqUVyYg== =CMWM -----END PGP SIGNATURE-----
On 2021-04-14 17:40:37 Carlos E. R. wrote:
| Start the service: | - "/etc/init.d/upsd start" | | | |No autodetection script in year 2021? Sigh. :-(
In the NUT User Manual (https://networkupstools.org/docs/user-manual.chunked/ar01s06.html) it tells us to use | /usr/local/ups/sbin/upsdrvctl start (In OpenSuSE it's /usr/sbin/upsdrvctl). Strangely, when I did this on my machine, I got this: |● upsdrvctl start | Network UPS Tools - UPS driver controller 2.7.4 | Can't start /usr/lib/ups/driver/upshid-usb: No such file or directory | @19:16:45,root@pinto rc=1 but poking around, I see | ● ll /usr/lib/ups/driver/ | total 4640 | -rwxr-xr-x 1 root root 64528 2020-04-25 22:02:56 al175 | : | -rwxr-xr-x 1 root root 260736 2020-04-25 22:02:56 usbhid-ups | -rwxr-xr-x 1 root root 64536 2020-04-25 22:02:56 victronups | @19:16:36,root@pinto rc=0 How about that? Leslie -- openSUSE Leap 15.2 x86_64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2021-04-14 at 19:23 -0500, J Leslie Turriff wrote:
On 2021-04-14 17:40:37 Carlos E. R. wrote:
| Start the service: | - "/etc/init.d/upsd start" | | | |No autodetection script in year 2021? Sigh. :-(
In the NUT User Manual (https://networkupstools.org/docs/user-manual.chunked/ar01s06.html) it tells us to use | /usr/local/ups/sbin/upsdrvctl start (In OpenSuSE it's /usr/sbin/upsdrvctl).
Isengard:/etc/ups # upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Megatec/Q1 protocol USB driver 0.12 (2.7.4) No supported UPS detected Driver failed to start (exit status=1) Isengard:/etc/ups # Ah, UPS was off. Starting it. Isengard:/etc/ups # upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Megatec/Q1 protocol USB driver 0.12 (2.7.4) Supported UPS detected with megatec protocol Vendor information unavailable No values provided for battery high/low voltages in ups.conf Using 'guestimation' (low: 10.400000, high: 13.000000)! Battery runtime will not be calculated (runtimecal not set) Isengard:/etc/ups # There is something in the log: <3.6> 2021-04-15T11:35:12.285428+02:00 Isengard blazer_usb 28384 - - Startup successful <3.4> 2021-04-15T11:35:53.321331+02:00 Isengard blazer_usb 28384 - - Communications with UPS lost: status read failed! <3.5> 2021-04-15T11:35:54.555506+02:00 Isengard blazer_usb 28384 - - Communications with UPS re-established <3.6> 2021-04-15T11:36:51.108696+02:00 Isengard blazer_usb 28384 - - Signal 15: exiting <3.6> 2021-04-15T11:37:11.771634+02:00 Isengard blazer_usb 28433 - - Startup successful That's all? I get no message when I unplug it from the mains. It doesn't "work". It doesn't even read the voltage values. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHgMOhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVFYsAoJi2IFFWzN982J/nYO7U U4ZqQlL7AJ9ShsbC6s4+XtMbBsf6CGtgTGZzow== =29iM -----END PGP SIGNATURE-----
On 4/14/21 5:40 PM, Carlos E. R. wrote:
Hi,
I have one UPS (with an almost dead battery) and I want to at least see it with NUT. When I connect it, I see in the log:
You need to set a few setting in the /etc/ups files. Here is how I have a ups setup with nut on host valkyrie that has a ups I name "valkyrie_ups" for nut. Only the uncommented lines are shown under the config file name and the password is needed where I have "MyPassword": (the noc script below is just my "no comment" script that picks out lines not commented using sed) $ for i in *.conf; do printf "\n%s\n\n" $i; noc $i; done hosts.conf MONITOR valkyrie_ups@localhost "Valkyrie CP1350PFCLCD UPS" nut.conf MODE=standalone ups.conf [valkyrie_ups] driver = usbhid-ups port = /dev/hiddev0 desc = "Valkyrie CP1350PFCLCD UPS" upsd.conf upsmon.conf MONITOR valkyrie_ups@localhost 1 david MyPassword master MINSUPPLIES 1 SHUTDOWNCMD "/usr/bin/systemctl poweroff" POLLFREQ 5 POLLFREQALERT 5 HOSTSYNC 15 DEADTIME 15 POWERDOWNFLAG /etc/ups/killpower RBWARNTIME 86400 NOCOMMWARNTIME 300 FINALDELAY 5 upssched.conf CMDSCRIPT /usr/bin/upssched-cmd upsset.conf I_HAVE_SECURED_MY_CGI_DIRECTORY -- David C. Rankin, J.D.,P.E.
On 15/04/2021 04.33, David C. Rankin wrote:
On 4/14/21 5:40 PM, Carlos E. R. wrote:
Hi,
I have one UPS (with an almost dead battery) and I want to at least see it with NUT. When I connect it, I see in the log:
You need to set a few setting in the /etc/ups files. Here is how I have a ups setup with nut on host valkyrie that has a ups I name "valkyrie_ups" for nut. Only the uncommented lines are shown under the config file name and the password is needed where I have "MyPassword":
(the noc script below is just my "no comment" script that picks out lines not commented using sed)
$ for i in *.conf; do printf "\n%s\n\n" $i; noc $i; done
hosts.conf
MONITOR valkyrie_ups@localhost "Valkyrie CP1350PFCLCD UPS"
nut.conf
MODE=standalone
ups.conf
[valkyrie_ups] driver = usbhid-ups port = /dev/hiddev0 desc = "Valkyrie CP1350PFCLCD UPS"
upsd.conf
upsmon.conf
MONITOR valkyrie_ups@localhost 1 david MyPassword master MINSUPPLIES 1 SHUTDOWNCMD "/usr/bin/systemctl poweroff" POLLFREQ 5 POLLFREQALERT 5 HOSTSYNC 15 DEADTIME 15 POWERDOWNFLAG /etc/ups/killpower RBWARNTIME 86400 NOCOMMWARNTIME 300 FINALDELAY 5
upssched.conf
CMDSCRIPT /usr/bin/upssched-cmd
upsset.conf
Not using network or apache yet.
I_HAVE_SECURED_MY_CGI_DIRECTORY
But what command is supposed to start it? The documentation says commands that do not exist! -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2021-04-15 at 22:25 -0500, David C. Rankin wrote:
On 4/15/21 4:31 AM, Carlos E. R. wrote:
But what command is supposed to start it? The documentation says commands that do not exist!
Oh, the nut-server.service E.g.
# systemctl start nut-server
Thanks. Isengard:~ # systemctl start nut-server Isengard:~ # Isengard:~ # systemctl status nut-server ● nut-server.service - Network UPS Tools - power devices information server Loaded: loaded (/usr/lib/systemd/system/nut-server.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-04-16 12:08:22 CEST; 1min 2s ago Process: 1244 ExecStart=/usr/sbin/upsd (code=exited, status=0/SUCCESS) Main PID: 1245 (upsd) Tasks: 1 CGroup: /system.slice/nut-server.service └─1245 /usr/sbin/upsd Apr 16 12:08:22 Isengard systemd[1]: Starting Network UPS Tools - power devices information server... Apr 16 12:08:22 Isengard upsd[1244]: fopen /var/lib/ups/upsd.pid: No such file or directory Apr 16 12:08:22 Isengard upsd[1244]: listening on 127.0.0.1 port 3493 Apr 16 12:08:22 Isengard upsd[1244]: listening on 127.0.0.1 port 3493 Apr 16 12:08:22 Isengard upsd[1244]: Connected to UPS [salicru]: blazer_usb-salicru Apr 16 12:08:22 Isengard upsd[1244]: Connected to UPS [salicru]: blazer_usb-salicru Apr 16 12:08:22 Isengard systemd[1]: Started Network UPS Tools - power devices information server. Apr 16 12:08:22 Isengard upsd[1245]: Startup successful Isengard:~ # Well, it does start. nut-driver is started automatically, but not nut-monitor. 3.6> 2021-04-16T12:08:21.783974+02:00 Isengard systemd 1 - - Starting Network UPS Tools - power device driver controller... <3.6> 2021-04-16T12:08:22.063019+02:00 Isengard upsdrvctl 1236 - - Supported UPS detected with megatec protocol <3.6> 2021-04-16T12:08:22.382613+02:00 Isengard upsdrvctl 1236 - - Vendor information unavailable <3.6> 2021-04-16T12:08:22.383145+02:00 Isengard upsdrvctl 1236 - - No values provided for battery high/low voltages in ups.conf <3.6> 2021-04-16T12:08:22.383624+02:00 Isengard upsdrvctl 1236 - - Using 'guestimation' (low: 10.400000, high: 13.000000)! <3.6> 2021-04-16T12:08:22.383976+02:00 Isengard upsdrvctl 1236 - - Battery runtime will not be calculated (runtimecal not set) <3.6> 2021-04-16T12:08:22.640210+02:00 Isengard blazer_usb 1241 - - Startup successful <3.6> 2021-04-16T12:08:22.640909+02:00 Isengard upsdrvctl 1236 - - Network UPS Tools - UPS driver controller 2.7.4 <3.6> 2021-04-16T12:08:22.641365+02:00 Isengard systemd 1 - - Started Network UPS Tools - power device driver controller. <3.6> 2021-04-16T12:08:22.644498+02:00 Isengard systemd 1 - - Starting Network UPS Tools - power devices information server... <3.6> 2021-04-16T12:08:22.652537+02:00 Isengard upsd 1244 - - fopen /var/lib/ups/upsd.pid: No such file or directory <3.6> 2021-04-16T12:08:22.653648+02:00 Isengard upsd 1244 - - listening on 127.0.0.1 port 3493 <3.6> 2021-04-16T12:08:22.654180+02:00 Isengard upsd 1244 - - listening on 127.0.0.1 port 3493 <3.6> 2021-04-16T12:08:22.654630+02:00 Isengard upsd 1244 - - Connected to UPS [salicru]: blazer_usb-salicru <3.6> 2021-04-16T12:08:22.655119+02:00 Isengard upsd 1244 - - Connected to UPS [salicru]: blazer_usb-salicru <3.6> 2021-04-16T12:08:22.658216+02:00 Isengard systemd 1 - - Started Network UPS Tools - power devices information server. <3.6> 2021-04-16T12:08:22.660530+02:00 Isengard upsd 1245 - - Startup successful But I removed the mains power, the UPS switched on, but no message anywhere, no action. I will continue reading. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHlkhRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVllYAn3UPVZeoFOIsUgS0MZnj jQGXQRLgAKCK6k1QHtjbr06tfJ3SoqzhoUBuqg== =16+u -----END PGP SIGNATURE-----
On Fri, 16 Apr 2021 12:18:45 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2021-04-15 at 22:25 -0500, David C. Rankin wrote:
On 4/15/21 4:31 AM, Carlos E. R. wrote:
But what command is supposed to start it? The documentation says commands that do not exist!
Oh, the nut-server.service E.g.
# systemctl start nut-server
Thanks.
Isengard:~ # systemctl start nut-server Isengard:~ # Isengard:~ # systemctl status nut-server ● nut-server.service - Network UPS Tools - power devices information server Loaded: loaded (/usr/lib/systemd/system/nut-server.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-04-16 12:08:22 CEST; 1min 2s ago Process: 1244 ExecStart=/usr/sbin/upsd (code=exited, status=0/SUCCESS) Main PID: 1245 (upsd) Tasks: 1 CGroup: /system.slice/nut-server.service └─1245 /usr/sbin/upsd
Apr 16 12:08:22 Isengard systemd[1]: Starting Network UPS Tools - power devices information server... Apr 16 12:08:22 Isengard upsd[1244]: fopen /var/lib/ups/upsd.pid: No such file or directory Apr 16 12:08:22 Isengard upsd[1244]: listening on 127.0.0.1 port 3493 Apr 16 12:08:22 Isengard upsd[1244]: listening on 127.0.0.1 port 3493 Apr 16 12:08:22 Isengard upsd[1244]: Connected to UPS [salicru]: blazer_usb-salicru Apr 16 12:08:22 Isengard upsd[1244]: Connected to UPS [salicru]: blazer_usb-salicru Apr 16 12:08:22 Isengard systemd[1]: Started Network UPS Tools - power devices information server. Apr 16 12:08:22 Isengard upsd[1245]: Startup successful Isengard:~ #
Well, it does start.
nut-driver is started automatically, but not nut-monitor.
Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot. [snip]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2021-04-16 at 11:42 +0100, Dave Howorth wrote:
On Fri, 16 Apr 2021 12:18:45 +0200 (CEST) "Carlos E. R." <> wrote:
...
Well, it does start.
nut-driver is started automatically, but not nut-monitor.
Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot.
I don't know. I also started it manuall, then cycled the mains power. No reaction from nut. [...] Ok, got a reaction. I have to wait several seconds, so probably using "poll". <3.6> 2021-04-16T13:06:19.910036+02:00 Isengard systemd 1 - - Starting Network UPS Tools - power device monitor and shutdown controller... <3.6> 2021-04-16T13:06:19.917370+02:00 Isengard upsmon 2819 - - fopen /var/run/upsmon.pid: No such file or directory <3.6> 2021-04-16T13:06:19.918869+02:00 Isengard upsmon 2819 - - UPS: salicru@127.0.0.1:3493 (master) (power value 1) <3.6> 2021-04-16T13:06:19.919287+02:00 Isengard systemd 1 - - nut-monitor.service: PID file /var/run/upsmon.pid not readable (yet?) after start: No such file or directory <3.6> 2021-04-16T13:06:19.919900+02:00 Isengard upsmon 2820 - - Startup successful <3.6> 2021-04-16T13:06:19.920448+02:00 Isengard upsmon 2819 - - Using power down flag file /etc/killpower <3.4> 2021-04-16T13:06:19.920683+02:00 Isengard systemd 1 - - nut-monitor.service: Supervising process 2821 which is not our child. We'll most likely not notice when it exits. <3.6> 2021-04-16T13:06:19.921333+02:00 Isengard systemd 1 - - Started Network UPS Tools - power device monitor and shutdown controller. <3.6> 2021-04-16T13:06:19.922519+02:00 Isengard upsd 1245 - - User upsmon@127.0.0.1 logged into UPS [salicru] <3.5> 2021-04-16T13:06:59.926598+02:00 Isengard upsmon 2821 - - UPS salicru@127.0.0.1:3493 on battery <3.5> 2021-04-16T13:07:19.928924+02:00 Isengard upsmon 2821 - - UPS salicru@127.0.0.1:3493 on line power Well, it is "working" now. No battery status information? (I need more reading) - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHlyKhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVEtUAn2EPKNerfZNsmWGU9uI3 tNsuDgT6AJ9tcN8MzyVwkhr4FZ2BZaqkGwz3Eg== =hkRA -----END PGP SIGNATURE-----
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot.
Yes, they both need starting. The server first.
No battery status information? (I need more reading)
Independent of the monitor, command upsc <myUPS> will give the current status of the UPS. Roger
On 16/04/2021 14.08, Roger Price wrote:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot.
Yes, they both need starting. The server first.
No battery status information? (I need more reading)
Independent of the monitor, command upsc <myUPS> will give the current status of the UPS.
It does now, but until today it did not. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Fri, 16 Apr 2021 14:08:17 +0200 (CEST) Roger Price <opensuse@rogerprice.org> wrote:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot.
Yes, they both need starting. The server first.
So there should be an After or a Before dependency somewhere in the service files?
No battery status information? (I need more reading)
Independent of the monitor, command upsc <myUPS> will give the current status of the UPS.
Roger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2021-04-16 a las 20:25 +0100, Dave Howorth escribió:
On Fri, 16 Apr 2021 14:08:17 +0200 (CEST) Roger Price <opensuse@rogerprice.org> wrote:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot.
Yes, they both need starting. The server first.
So there should be an After or a Before dependency somewhere in the service files?
Correct, the nut-server.service file "wants" nut-driver.service. cer@Telcontar:~> systemctl cat nut-server.service # /usr/lib/systemd/system/nut-server.service [Unit] Description=Network UPS Tools - power devices information server After=local-fs.target network.target nut-driver.service # We don't Require drivers to be successfully started! This would be # a change of behavior compared to init SysV, and could prevent from # accessing successfully started, at least to audit a system. Wants=nut-driver.service <========== Before=nut-monitor.service <---------- [Service] ExecStart=/usr/sbin/upsd Type=forking [Install] WantedBy=multi-user.target cer@Telcontar:~> cer@Telcontar:~> systemctl cat nut-monitor.service # /usr/lib/systemd/system/nut-monitor.service [Unit] Description=Network UPS Tools - power device monitor and shutdown controller After=local-fs.target network.target nut-server.service [Service] ExecStart=/usr/sbin/upsmon PIDFile=/var/run/upsmon.pid Type=forking [Install] WantedBy=multi-user.target cer@Telcontar:~> cer@Telcontar:~> systemctl cat nut-driver.service # /usr/lib/systemd/system/nut-driver.service [Unit] Description=Network UPS Tools - power device driver controller After=local-fs.target network.target StopWhenUnneeded=yes [Service] ExecStart=/usr/sbin/upsdrvctl start ExecStop=/usr/sbin/upsdrvctl stop Type=forking cer@Telcontar:~> - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHnnHhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVL+0Ani2KQrlTIr7BfgSYpXyh pd7EmJVcAJ9MruAAfu1xyU3gioHt/xEH5GU25A== =D8QZ -----END PGP SIGNATURE-----
On 4/16/21 5:42 AM, Dave Howorth wrote:
Well, it does start.
nut-driver is started automatically, but not nut-monitor. Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot.
[snip]
You do NOT need nut-monitor. That is for monitoring additional peripherals attached to a nut server, e.g. NUT-Monitor is a graphical user interface to monitor and manage devices connected to the Network UPS Tools server. -- David C. Rankin, J.D.,P.E.
On Fri, 16 Apr 2021, David C. Rankin wrote:
On 4/16/21 5:42 AM, Dave Howorth wrote:
Well, it does start.
nut-driver is started automatically, but not nut-monitor. Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot.
[snip]
You do NOT need nut-monitor. That is for monitoring additional peripherals attached to a nut server, e.g.
I assume that by nut-monitor you mean program upsmon. This is the daemon which takes the decision to shutdown a system when it reaches status OB-LB (on battery and low battery). If you do not have this program, how will you order the shutdown?
NUT-Monitor is a graphical user interface to monitor and manage devices connected to the Network UPS Tools server.
Are you referring to upsmon or some other program? Roger
On 16/04/2021 19.51, David C. Rankin wrote:
On 4/16/21 5:42 AM, Dave Howorth wrote:
Well, it does start.
nut-driver is started automatically, but not nut-monitor. Didn't somebody say earlier that nut-monitor also had to be started, just like nut-driver? Presumably once enabled and started they'll restart after boot.
[snip]
You do NOT need nut-monitor. That is for monitoring additional peripherals attached to a nut server, e.g.
NUT-Monitor is a graphical user interface to monitor and manage devices connected to the Network UPS Tools server.
Without nut-monitor, which is a service, not a GUI, there are no messages in the log when I disconnect the mains. The entire thing becomes useless, there is no reaction to a power failure. On the other hand, nut is not correctly integrated with systemd:
<3.6> 2021-04-16T20:58:02.538963+02:00 Isengard systemd 1 - - Reloading. <3.4> 2021-04-16T20:58:03.533437+02:00 Isengard systemd 1 - - nut-monitor.service: Supervising process 2821 which is not our child. We'll most likely not notice when it exits.
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 4/16/21 2:01 PM, Carlos E. R. wrote:
Without nut-monitor, which is a service, not a GUI, there are no messages in the log when I disconnect the mains. The entire thing becomes useless, there is no reaction to a power failure.
On the other hand, nut is not correctly integrated with systemd:
Apologies, I was thinking about the web interface cgi scripts. Yes, you need to part that shuts the server down. -- David C. Rankin, J.D.,P.E.
On 4/16/21 5:18 AM, Carlos E. R. wrote:
On Thursday, 2021-04-15 at 22:25 -0500, David C. Rankin wrote:
On 4/15/21 4:31 AM, Carlos E. R. wrote:
But what command is supposed to start it? The documentation says commands that do not exist!
Oh, the nut-server.service E.g.
# systemctl start nut-server
Thanks.
Isengard:~ # systemctl start nut-server Isengard:~ # Isengard:~ # systemctl status nut-server ● nut-server.service - Network UPS Tools - power devices information server Loaded: loaded (/usr/lib/systemd/system/nut-server.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-04-16 12:08:22 CEST; 1min 2s ago Process: 1244 ExecStart=/usr/sbin/upsd (code=exited, status=0/SUCCESS) Main PID: 1245 (upsd) Tasks: 1 CGroup: /system.slice/nut-server.service └─1245 /usr/sbin/upsd
Apr 16 12:08:22 Isengard systemd[1]: Starting Network UPS Tools - power devices information server... Apr 16 12:08:22 Isengard upsd[1244]: fopen /var/lib/ups/upsd.pid: No such file or directory Apr 16 12:08:22 Isengard upsd[1244]: listening on 127.0.0.1 port 3493 Apr 16 12:08:22 Isengard upsd[1244]: listening on 127.0.0.1 port 3493 Apr 16 12:08:22 Isengard upsd[1244]: Connected to UPS [salicru]: blazer_usb-salicru Apr 16 12:08:22 Isengard upsd[1244]: Connected to UPS [salicru]: blazer_usb-salicru Apr 16 12:08:22 Isengard systemd[1]: Started Network UPS Tools - power devices information server. Apr 16 12:08:22 Isengard upsd[1245]: Startup successful Isengard:~ #
Now just, $ upsc blazer_usb-salicru to see the UPS details. -- David C. Rankin, J.D.,P.E.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2021-04-16 at 12:45 -0500, David C. Rankin wrote:
On 4/16/21 5:18 AM, Carlos E. R. wrote:
On Thursday, 2021-04-15 at 22:25 -0500, David C. Rankin wrote:
On 4/15/21 4:31 AM, Carlos E. R. wrote:
But what command is supposed to start it? The documentation says commands that do not exist!
Oh, the nut-server.service E.g.
# systemctl start nut-server
Thanks.
Also "nut-monitor.service" has to be started and enabled.
Now just,
$ upsc blazer_usb-salicru
to see the UPS details.
Yes, I noticed, after sucessfully starting the above services. Isengard:~ # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.12 input.current.nominal: 3.0 input.frequency: 50.0 input.frequency.nominal: 50 input.voltage: 226.9 input.voltage.fault: 226.9 input.voltage.nominal: 230 output.voltage: 226.9 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 10 ups.productid: 5161 ups.status: OL ups.temperature: 25.0 ups.type: offline / line interactive ups.vendorid: 0665 Isengard:~ # But I don't see anything yet that collects stats. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHngURwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVkXwAn2Ak6K4+PMonbHK2vBDv KX1+3eK8AJ0cqc4Zh8a9ipWLGRmIeN0He0YuVQ== =uczE -----END PGP SIGNATURE-----
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Isengard:~ # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 ...
I don't see variable battery.charge.low which specifies the charge below which the LB (Low Battery) status is raised, signalling that the time has come to shutdown. Does the command "upsrw Salicru" list the variable battery.charge.low ? Roger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2021-04-16 a las 21:29 +0200, Roger Price escribió:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Isengard:~ # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 ...
I don't see variable battery.charge.low which specifies the charge below which the LB (Low Battery) status is raised, signalling that the time has come to shutdown.
Does the command "upsrw Salicru" list the variable battery.charge.low ?
Isengard:~ # upsrw Salicru Isengard:~ # Nope... - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHnnshwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVmncAn3Poncj1osM54g3/QDa6 fk41qye8AKCIdB0Yd3LWGJ0aAzE+1ZiumA82ow== =pTVt -----END PGP SIGNATURE-----
On Fri, 16 Apr 2021, Carlos E. R. wrote:
El 2021-04-16 a las 21:29 +0200, Roger Price escribió:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Isengard:~ # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 ...
I don't see variable battery.charge.low which specifies the charge below which the LB (Low Battery) status is raised, signalling that the time has come to shutdown.
Does the command "upsrw Salicru" list the variable battery.charge.low ?
Isengard:~ # upsrw Salicru Isengard:~ #
Nope...
If you are using the blazer_usb driver there is a workaround using extra arguments to the driver: * default.battery.voltage.high = value Maximum battery voltage that is reached after about 12 to 24 hours charging. If you want the driver to report a guesstimated battery.charge, you need to specify this (see BATTERY CHARGE). * default.battery.voltage.low = value Minimum battery voltage just before the UPS automatically shuts down. If you want the driver to report a guesstimated battery.charge, you need to specify this (see BATTERY CHARGE). See man blazer_usb Roger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2021-04-16 at 22:22 +0200, Roger Price wrote:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
El 2021-04-16 a las 21:29 +0200, Roger Price escribió:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Isengard:~ # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 ...
I don't see variable battery.charge.low which specifies the charge below which the LB (Low Battery) status is raised, signalling that the time has come to shutdown.
Does the command "upsrw Salicru" list the variable battery.charge.low ?
Isengard:~ # upsrw Salicru Isengard:~ #
Nope...
If you are using the blazer_usb driver there is a workaround using extra arguments to the driver:
* default.battery.voltage.high = value
Maximum battery voltage that is reached after about 12 to 24 hours charging. If you want the driver to report a guesstimated battery.charge, you need to specify this (see BATTERY CHARGE).
Well, that voltage is the same for every battery of the same chemicals :-)
* default.battery.voltage.low = value
Minimum battery voltage just before the UPS automatically shuts down. If you want the driver to report a guesstimated battery.charge, you need to specify this (see BATTERY CHARGE).
I don't like the idea of stressing the battery to exhaustion in order to find out that value. Doesn't the hardware communicate the battery percent itself? It has an LCD display with a graph display of charge. I have this: Isengard:~ # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 Aren't those the values told by the UPS itself? It prints battery charge.
See man blazer_usb
"Salicru" is not even listed at <https://networkupstools.org/stable-hcl.html> There is only a user report for the "SPS One 700VA": <https://networkupstools.org/ddl/Salicru/index.html> Anyway... I changed the configuration a bit: [salicru] driver = blazer_usb #port = /dev/usb/hiddev0 port = auto desc = "Salicru SPS SOHO+ 800VA" default.battery.voltage.high = 13.60 default.battery.voltage.low = 10.40 The utility reports the same values as before: Isengard:/etc/ups # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb I switched off the mains for a few seconds: sengard:/etc/ups # upsc Salicru battery.charge: 92 <============= battery.voltage: 12.80 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.12 input.current.nominal: 3.0 input.frequency: 50.0 input.frequency.nominal: 50 input.voltage: 3.9 <=========== input.voltage.fault: 3.9 input.voltage.nominal: 230 output.voltage: 227.7 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 6 ups.productid: 5161 ups.status: OB ups.temperature: 25.0 ups.type: offline / line interactive ups.vendorid: 0665 Isengard:/etc/ups # And with mains back on: Isengard:/etc/ups # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.12 input.current.nominal: 3.0 input.frequency: 50.0 input.frequency.nominal: 50 input.voltage: 228.9 input.voltage.fault: 228.9 input.voltage.nominal: 230 output.voltage: 228.9 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 7 ups.productid: 5161 ups.status: OL ups.temperature: 25.0 ups.type: offline / line interactive ups.vendorid: 0665 Isengard:/etc/ups # - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHn3xBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVqR0AnAyIGssvXhAt6NsrtiRi LghqlteTAJ4qT4htx32MSZZhda7R2II4OY6cqw== =UIlv -----END PGP SIGNATURE-----
On Fri, 16 Apr 2021, Carlos E. R. wrote:
"Salicru" is not even listed at <https://networkupstools.org/stable-hcl.html> There is only a user report for the "SPS One 700VA": <https://networkupstools.org/ddl/Salicru/index.html>
There have been requests to the NUT developers to support Salicru, but this hasn't happened yet. An example is https://github.com/networkupstools/nut/issues/450 There is a README at https://github.com/tiagofreire-pt/Home_Assistant_Salicru_SOHO_UPS which uses the usbhid-ups driver. Here is his ups.conf: [salicru] driver = usbhid-ups port = auto desc = "Salicru" Maybe its worth a try.
Anyway...
I changed the configuration a bit:
[salicru] driver = blazer_usb #port = /dev/usb/hiddev0 port = auto desc = "Salicru SPS SOHO+ 800VA" default.battery.voltage.high = 13.60 default.battery.voltage.low = 10.40
The utility reports the same values as before:
Isengard:/etc/ups # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb
Are the ups.conf values taken into account? If you set default.battery.voltage.high = 13.5 does the new value appear in the upsc output? It is surprising to see the battery.voltage 13.6 outside the low-high interval {10.4, 13.0}. Perhaps battery.voltage.high should be at least 13.6 . Roger
On 4/16/21 3:47 PM, Carlos E. R. wrote:
On Friday, 2021-04-16 at 22:22 +0200, Roger Price wrote:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
El 2021-04-16 a las 21:29 +0200, Roger Price escribió:
On Fri, 16 Apr 2021, Carlos E. R. wrote:
Isengard:~ # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 ...
I don't see variable battery.charge.low which specifies the charge below which the LB (Low Battery) status is raised, signalling that the time has come to shutdown.
Does the command "upsrw Salicru" list the variable battery.charge.low ?
Isengard:~ # upsrw Salicru Isengard:~ # Nope...
If you are using the blazer_usb driver there is a workaround using extra arguments to the driver:
* default.battery.voltage.high = value
Maximum battery voltage that is reached after about 12 to 24 hours charging. If you want the driver to report a guesstimated battery.charge, you need to specify this (see BATTERY CHARGE).
Well, that voltage is the same for every battery of the same chemicals :-)
* default.battery.voltage.low = value
Minimum battery voltage just before the UPS automatically shuts down. If you want the driver to report a guesstimated battery.charge, you need to specify this (see BATTERY CHARGE).
I don't like the idea of stressing the battery to exhaustion in order to find out that value. Doesn't the hardware communicate the battery percent itself? It has an LCD display with a graph display of charge.
I have this:
Isengard:~ # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0
Aren't those the values told by the UPS itself? It prints battery charge.
See man blazer_usb
"Salicru" is not even listed at <https://networkupstools.org/stable-hcl.html>
There is only a user report for the "SPS One 700VA":
<https://networkupstools.org/ddl/Salicru/index.html>
Anyway...
I changed the configuration a bit:
[salicru] driver = blazer_usb #port = /dev/usb/hiddev0 port = auto desc = "Salicru SPS SOHO+ 800VA" default.battery.voltage.high = 13.60 default.battery.voltage.low = 10.40
The utility reports the same values as before:
Isengard:/etc/ups # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb
I switched off the mains for a few seconds:
sengard:/etc/ups # upsc Salicru battery.charge: 92 <============= battery.voltage: 12.80 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.12 input.current.nominal: 3.0 input.frequency: 50.0 input.frequency.nominal: 50 input.voltage: 3.9 <=========== input.voltage.fault: 3.9 input.voltage.nominal: 230 output.voltage: 227.7 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 6 ups.productid: 5161 ups.status: OB ups.temperature: 25.0 ups.type: offline / line interactive ups.vendorid: 0665 Isengard:/etc/ups #
And with mains back on:
Isengard:/etc/ups # upsc Salicru battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.12 input.current.nominal: 3.0 input.frequency: 50.0 input.frequency.nominal: 50 input.voltage: 228.9 input.voltage.fault: 228.9 input.voltage.nominal: 230 output.voltage: 228.9 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 7 ups.productid: 5161 ups.status: OL ups.temperature: 25.0 ups.type: offline / line interactive ups.vendorid: 0665 Isengard:/etc/ups #
-- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar)
The battery.charge.low is just the percentage of battery you want remaining when the shutdown is initiated. Usually it defaults to 10 (10% remaining). You do want to ensure you have it set, either by hook, crook or hack, e.g. # upsc phoinix_ups battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 1710 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 24.0 battery.voltage.nominal: 24 device.mfr: CPS device.model: CP1350PFCLCD device.serial: 000000000000 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: /dev/hiddev0 driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.data: CyberPower HID 0.4 driver.version.internal: 0.41 input.transfer.high: 139 input.transfer.low: 88 input.voltage: 125.0 input.voltage.nominal: 120 output.voltage: 141.0 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.load: 22 ups.mfr: CPS ups.model: CP1350PFCLCD ups.productid: 0501 ups.realpower.nominal: 810 ups.serial: 000000000000 ups.status: OL ups.test.result: No test initiated ups.timer.shutdown: -60 ups.timer.start: -60 ups.vendorid: 0764 Nut never got around to dividing the battery.voltage by 2 for this 2-12V battery UPS. -- David C. Rankin, J.D.,P.E.
On 17/04/2021 12.53, David C. Rankin wrote:
On 4/16/21 3:47 PM, Carlos E. R. wrote:
The battery.charge.low is just the percentage of battery you want remaining when the shutdown is initiated. Usually it defaults to 10 (10% remaining). You do want to ensure you have it set, either by hook, crook or hack, e.g.
# upsc phoinix_ups battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20
Methinks that depleting the battery to 10 is a very severe wear on it. I would go for 50% tops. If the system is not capable of going down fast... If you try to power down my machine at 23:50 hours, it will not go down till 00:15, or worse, 00:30. Other times, yes, it will go down fast. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sat, 17 Apr 2021, Carlos E. R. wrote:
Methinks that depleting the battery to 10 is a very severe wear on it. I would go for 50% tops. If the system is not capable of going down fast...
If you try to power down my machine at 23:50 hours, it will not go down till 00:15, or worse, 00:30. Other times, yes, it will go down fast.
How do you hold back /sbin/shutdown for what might be 40 minutes? Is the Salicru capable of supplying power to the system for 40 minutes and still have 50% reserve? This will need testing. Roger
On 17/04/2021 21.43, Roger Price wrote:
On Sat, 17 Apr 2021, Carlos E. R. wrote:
Methinks that depleting the battery to 10 is a very severe wear on it. I would go for 50% tops. If the system is not capable of going down fast...
If you try to power down my machine at 23:50 hours, it will not go down till 00:15, or worse, 00:30. Other times, yes, it will go down fast.
How do you hold back /sbin/shutdown for what might be 40 minutes? Is the Salicru capable of supplying power to the system for 40 minutes and still have 50% reserve? This will need testing.
I don't. If the mains power fails that instant and I'm not there, the UPS dies of exhaustion and the machine with it. At least with hibernation, which is what I do. The system tries to sync the filesystem, and if it does that during the interval 23:45 to 00:15 the kernel is not capable of syncing the filesystem while texpire is running. The cron-job texpire has to be killed first, then the machine can be told to hibernate. I have not tested this yet. I have not tested power down during that interval yet (I thought I had). There are other issues: - sometimes hibernation fails, and has to be called a second time. How to automate this? - if hibernation stalls while texpire is running, powerdown also fails (this I have tested). -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sat, 17 Apr 2021, Carlos E. R. wrote:
On 17/04/2021 21.43, Roger Price wrote:
On Sat, 17 Apr 2021, Carlos E. R. wrote:
Methinks that depleting the battery to 10 is a very severe wear on it. I would go for 50% tops. If the system is not capable of going down fast...
If you try to power down my machine at 23:50 hours, it will not go down till 00:15, or worse, 00:30. Other times, yes, it will go down fast.
How do you hold back /sbin/shutdown for what might be 40 minutes? Is the Salicru capable of supplying power to the system for 40 minutes and still have 50% reserve? This will need testing.
I don't. If the mains power fails that instant and I'm not there, the UPS dies of exhaustion and the machine with it.
For me, this would not be acceptable.
At least with hibernation, which is what I do. The system tries to sync the filesystem, and if it does that during the interval 23:45 to 00:15 the kernel is not capable of syncing the filesystem while texpire is running. The cron-job texpire has to be killed first, then the machine can be told to hibernate. I have not tested this yet.
What is the advantage of hibernation for a desktop system? The machine does no useful work, yet consumes energy from the UPS. A "proper" shutdown would kill texpire and not drain the battery, which you have said you want to avoid. I do not use hibernation. I find I am better served with a shutdown --poweroff and an automatic restart when utility power returns.
I have not tested power down during that interval yet (I thought I had).
There are other issues:
- sometimes hibernation fails, and has to be called a second time. How to automate this?
I'm guessing that you specify something like SHUTDOWNCMD "systemctl start systemd-hibernate.service" in upsmon.conf. You would have to replace this with a call of a script which watches over systemctl status systemd-hibernate.service and restarts the service if it fails. This is becoming complicated. It might also be advisable to not execute the command upsdrvctl shutdown in order to avoid turning off the UPS power outlets. Roger
On 18/04/2021 11.19, Roger Price wrote:
On Sat, 17 Apr 2021, Carlos E. R. wrote:
On 17/04/2021 21.43, Roger Price wrote:
On Sat, 17 Apr 2021, Carlos E. R. wrote:
Methinks that depleting the battery to 10 is a very severe wear on it. I would go for 50% tops. If the system is not capable of going down fast...
If you try to power down my machine at 23:50 hours, it will not go down till 00:15, or worse, 00:30. Other times, yes, it will go down fast.
How do you hold back /sbin/shutdown for what might be 40 minutes? Is the Salicru capable of supplying power to the system for 40 minutes and still have 50% reserve? This will need testing.
I don't. If the mains power fails that instant and I'm not there, the UPS dies of exhaustion and the machine with it.
For me, this would not be acceptable.
It isn't.
At least with hibernation, which is what I do. The system tries to sync the filesystem, and if it does that during the interval 23:45 to 00:15 the kernel is not capable of syncing the filesystem while texpire is running. The cron-job texpire has to be killed first, then the machine can be told to hibernate. I have not tested this yet.
What is the advantage of hibernation for a desktop system? The machine does no useful work, yet consumes energy from the UPS. A "proper" shutdown would kill texpire and not drain the battery, which you have said you want to avoid.
Hibernation (if it works properly) saves battery and preserves the status and my work (sleep mode needs power for the ram; hibernation doesn't). I may be doing something important which will be lost with a power down. Maybe I left the office for a moment to buy some milk for the coffee, without saving, and the power fails just then. Or maybe I'm running a long process which does not save intermediate steps, it would be lost. I may be doing things in the terminals and taking notes, and I have not yet took and saved the notes for something. Myriad cases. But otherwise, I simply use hibernation every day because it preserves the status of the desktop, and restoring saves me a few minutes of starting again all the things and load all the files (no, desktop save doesn't go that far). Normally I have open several workspaces, and have different things started on each (mail, web, libreoffice, photos, a virtual machine...). If I tire of something I switch to another one with a different task and continue later or tomorrow, knowing that tomorrow everything will be there because I do not poweroff but hibernate. Yes, I could leave the machine running all the time, but that wears the hard disks and uses electricity which has to be paid.
I do not use hibernation. I find I am better served with a shutdown --poweroff and an automatic restart when utility power returns.
I have not tested power down during that interval yet (I thought I had).
I did yesterday, it works.
There are other issues:
- sometimes hibernation fails, and has to be called a second time. How to automate this?
I'm guessing that you specify something like SHUTDOWNCMD "systemctl start systemd-hibernate.service" in upsmon.conf. You would have to replace this with a call of a script which watches over systemctl status systemd-hibernate.service and restarts the service if it fails. This is becoming complicated.
It is complicated, because that service returns instantly, while the hibernation sequence runs independently. I don't know of a way to find out (by script) if it worked or failed. Consider that if it worked, my script may continue running after restoring two hours later. Not easy.
It might also be advisable to not execute the command upsdrvctl shutdown in order to avoid turning off the UPS power outlets.
The proper thing would be to power down the UPS automatically either a minute after issuing the command, or when it senses the computer is down. But this is a job for the hardware. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 4/17/21 6:24 AM, Carlos E. R. wrote:
Methinks that depleting the battery to 10 is a very severe wear on it. I would go for 50% tops. If the system is not capable of going down fast...
If you try to power down my machine at 23:50 hours, it will not go down till 00:15, or worse, 00:30. Other times, yes, it will go down fast.
Eh..., Normally I agree, but here you are just handling the power fail case. I always get to my machines and shut them down before they reach 10%. Only time they exhaust the battery to 10% is if the office goes down at night -- and well, that's what the $25 batteries are supposed to do. Regardless of the number of discharges, I always get 3-5 years out of the batteries. I have a separate UPS that only powers the cable modem and wireless router, I will let go to the 10% for any outage that lasts that long. Generally gives about 2.5 hours of runtime. Setting at 50% would be fine, that would just shorten the runtime to power off. Whatever you set it at is fine -- just make sure it is set :) -- David C. Rankin, J.D.,P.E.
On 17/04/2021 23.15, David C. Rankin wrote:
On 4/17/21 6:24 AM, Carlos E. R. wrote:
Methinks that depleting the battery to 10 is a very severe wear on it. I would go for 50% tops. If the system is not capable of going down fast...
If you try to power down my machine at 23:50 hours, it will not go down till 00:15, or worse, 00:30. Other times, yes, it will go down fast.
Eh...,
Normally I agree, but here you are just handling the power fail case. I always get to my machines and shut them down before they reach 10%. Only time they exhaust the battery to 10% is if the office goes down at night -- and well, that's what the $25 batteries are supposed to do. Regardless of the number of discharges, I always get 3-5 years out of the batteries. I have a separate UPS that only powers the cable modem and wireless router, I will let go to the 10% for any outage that lasts that long. Generally gives about 2.5 hours of runtime.
Setting at 50% would be fine, that would just shorten the runtime to power off. Whatever you set it at is fine -- just make sure it is set :)
It is not set yet, I'm trying to read up material :-) (I hate having to become an expert to be able to use new tools) The only computer that now runs "nut" is the mini server, which runs 24*7, so it can be running with me away. The desktop machine, I should be in the house if it is running. The other day the mains power failed (the house earth fault switch triggered), and the mini server went down, its UPS could not take the load for maybe the 2 minutes it took me to notice and reset the switch. The other two UPS in the house took the load just fine. So I started to look at nuts again, hopping the thing would report battery life. It doesn't. There is an applet in xfce that reports battery life of the wireless keyboard. I think it also said something about the UPS several years ago, dunno. I had an UPS daemon thing running perhaps a decade or two ago. I changed UPS brand and it stopped working, and I did not take the effort to configure it again. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 4/17/21 4:35 PM, Carlos E. R. wrote:
The other day the mains power failed (the house earth fault switch triggered), and the mini server went down, its UPS could not take the load for maybe the 2 minutes it took me to notice and reset the switch. The other two UPS in the house took the load just fine.
Chuckling... You recall the ice storm in Texas if February? I was without power for 6 days 6 hours and the temperature got down to -3 F (41 inside...). No UPS on earth would have saved me :) -- David C. Rankin, J.D.,P.E.
On 19/04/2021 05.44, David C. Rankin wrote:
On 4/17/21 4:35 PM, Carlos E. R. wrote:
The other day the mains power failed (the house earth fault switch triggered), and the mini server went down, its UPS could not take the load for maybe the 2 minutes it took me to notice and reset the switch. The other two UPS in the house took the load just fine.
Chuckling...
You recall the ice storm in Texas if February? I was without power for 6 days 6 hours and the temperature got down to -3 F (41 inside...). No UPS on earth would have saved me :)
Oh, it would. One with gasoline instead of sulphuric in its veins ;-p Nah, I don't have one, either. The worst power failure I suffered has been a night. Well, once the entire wiring in the first floor had to be replaced, so I had an extension cable from downstairs to feed things. I don't think an internet failure (means internet, phone and tv) during an entire weekend counts. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar) (18.5°C inside the house now)
participants (7)
-
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
David C. Rankin -
J Leslie Turriff -
Peter Suetterlin -
Roger Price