[Nut-upsuser] Fwd: contineously receiving the same values
The software UPSmart 1.5 is the same as I am using in this thread: http://lists.alioth.debian.org/pipermail/nut-upsdev/2016-November/007248. html (starts in 2016-August) for the powercool 1500VA USB UPS. Have not yet been successful with getting it working with NUT but the symptoms are the same and you may find some of the debug useful from https://github.com/ mattwire/powercool-ups If it helps, I can provide additional logging/testing etc. On 22 March 2017 at 14:09, Marc Kessels wrote: > > > On 22-3-2017 14:37, Charles Lepple wrote: > >> On Mar 22, 2017, at 9:29 AM, Marc Kessels wrote: >> >>> Hi Charles, >>> >>> >>> Upsmart version is 1.5, copyright says 2012-2014 >>> >> Do you have a direct link? I found UPSmart-DryContact-V3-4.zip and >> UPSmart-Networking-V2-4.zip via web search, but the dates for the Linux >> components are ~ 2002. >> > my version came from the supplied CD, but it can be found online as well: > http://www.gembird.nl/service.aspx?item=8087&key=eg-ups-033#item > >> the github issue seems a bit worse, since it reports: >>> >>> received 10 (85) >>>1.158700 read: UPS No Ack >>> >>> whereas my system reports : >>> >>> 6.239688 Full update... >>>6.239776 send: Q1 >>>6.261270 received 47 (40) >>>6.261371 read: (234.0 000.0 234.0 012 49.9 27.4 29.0 1000 >>> >>> but it keeps repeating the last line, so I am not getting any update. >>> >> I might have been confusing that issue with this comment in the parent >> thread, which seems to be similar underlying hardware repeating the last >> reading: >> >> https://github.com/networkupstools/nut/issues/307#issuecomment-243364229 >> >> The #409 report might have been due to a combination of the >> auto-detection, plus the lack of "vendor magic" from UPSmart. >> > indeed, the #307 looks remarkably the same. > > attached the wireshark traces for the UPSmart software and the nut > software. I see some differences, but I can't decipher what's going on > there... > hope you can share some insight. > > thanks, > marc > > > > > ___ > Nut-upsuser mailing list > Nut-upsuser@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] contineously receiving the same values
The software UPSmart 1.5 is the same as I am using in this thread: http://lists.alioth.debian.org/pipermail/nut-upsdev/2016-November/007248.html (starts in 2016-August) for the powercool 1500VA USB UPS. Have not yet been successful with getting it working with NUT but the symptoms are the same and you may find some of the debug useful from https://github.com/mattwire/powercool-ups If it helps, I can provide additional logging/testing etc. On 22 March 2017 at 14:09, Marc Kessels wrote: > > > On 22-3-2017 14:37, Charles Lepple wrote: > >> On Mar 22, 2017, at 9:29 AM, Marc Kessels wrote: >> >>> Hi Charles, >>> >>> >>> Upsmart version is 1.5, copyright says 2012-2014 >>> >> Do you have a direct link? I found UPSmart-DryContact-V3-4.zip and >> UPSmart-Networking-V2-4.zip via web search, but the dates for the Linux >> components are ~ 2002. >> > my version came from the supplied CD, but it can be found online as well: > http://www.gembird.nl/service.aspx?item=8087&key=eg-ups-033#item > >> the github issue seems a bit worse, since it reports: >>> >>> received 10 (85) >>>1.158700 read: UPS No Ack >>> >>> whereas my system reports : >>> >>> 6.239688 Full update... >>>6.239776 send: Q1 >>>6.261270 received 47 (40) >>>6.261371 read: (234.0 000.0 234.0 012 49.9 27.4 29.0 1000 >>> >>> but it keeps repeating the last line, so I am not getting any update. >>> >> I might have been confusing that issue with this comment in the parent >> thread, which seems to be similar underlying hardware repeating the last >> reading: >> >> https://github.com/networkupstools/nut/issues/307#issuecomment-243364229 >> >> The #409 report might have been due to a combination of the >> auto-detection, plus the lack of "vendor magic" from UPSmart. >> > indeed, the #307 looks remarkably the same. > > attached the wireshark traces for the UPSmart software and the nut > software. I see some differences, but I can't decipher what's going on > there... > hope you can share some insight. > > thanks, > marc > > > > > ___ > Nut-upsuser mailing list > Nut-upsuser@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] MGE ESV+ and Power Trim
Hi David, 2017-03-21 20:06 GMT+01:00 David Baker : > Hi, > > > Thanks for checking in – I managed to re-compile it but was getting the > same error – I then had other things to do so didn’t get further in my > investigation. > same error being "Can't chdir to /var/state/ups: No such file or directory"? if so, ensure that you use Charles' provided "configure" directives, and then make && make install. > I’m going to delete the installation and the re-make / install it to see > if that sorts it. > > > > I’ll let you know how I get on! > thanks, cheers, Arno -- Eaton Data Center Automation Solutions - Opensource Leader - http://42ity.org NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr > Dave > > > > *From:* Arnaud Quette [mailto:aquette@gmail.com] > *Sent:* 21 March 2017 15:10 > *To:* Charles Lepple > *Cc:* David Baker; NUT Users > *Subject:* Re: [Nut-upsuser] MGE ESV+ and Power Trim > > > > > > > > 2017-03-12 4:02 GMT+01:00 Charles Lepple : > > On Sat, Mar 11, 2017 at 7:15 PM, David Baker wrote: > > Hi Arnaud & Charles, > > > > > > Hi Dave, > > any news on your side from this venerable ESV+? > > > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] contineously receiving the same values
On 22-3-2017 14:37, Charles Lepple wrote: On Mar 22, 2017, at 9:29 AM, Marc Kessels wrote: Hi Charles, Upsmart version is 1.5, copyright says 2012-2014 Do you have a direct link? I found UPSmart-DryContact-V3-4.zip and UPSmart-Networking-V2-4.zip via web search, but the dates for the Linux components are ~ 2002. my version came from the supplied CD, but it can be found online as well: http://www.gembird.nl/service.aspx?item=8087&key=eg-ups-033#item the github issue seems a bit worse, since it reports: received 10 (85) 1.158700 read: UPS No Ack whereas my system reports : 6.239688 Full update... 6.239776 send: Q1 6.261270 received 47 (40) 6.261371 read: (234.0 000.0 234.0 012 49.9 27.4 29.0 1000 but it keeps repeating the last line, so I am not getting any update. I might have been confusing that issue with this comment in the parent thread, which seems to be similar underlying hardware repeating the last reading: https://github.com/networkupstools/nut/issues/307#issuecomment-243364229 The #409 report might have been due to a combination of the auto-detection, plus the lack of "vendor magic" from UPSmart. indeed, the #307 looks remarkably the same. attached the wireshark traces for the UPSmart software and the nut software. I see some differences, but I can't decipher what's going on there... hope you can share some insight. thanks, marc nut.pcapng.gz Description: GNU Zip compressed data upsmart.pcapng.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Is a timer a file?
Hi Roger 2017-03-21 19:34 GMT+01:00 Roger Price : > On Tue, 21 Mar 2017, Arnaud Quette wrote: > > Hi Roger, >> >> reviving this discussion, since we have a Github ticket for 2.7.5: >> https://github.com/networkupstools/nut/issues/293 >> > ... > >> I've made some additions to clarify things on the timer, and complete the >> script: >> https://github.com/networkupstools/nut/compare/upssched-doc?expand=1 >> > > Hi Arnaud, Your change to the documentation clears up what I had > mis-understood. The new text makes it clear that the upssched timers are > an in-memory device, and that they can only be turned on and off with > upssched.conf declarations such as > > AT ONBATT * START-TIMER onbattwarn 30 > AT ONLINE * CANCEL-TIMER onbattwarn > thanks for your confirmation. I'll check to merge that PR. > Is there some other way of forcing routine cancel_timer from a >> script or a configuration file? >> >> this is the last point to address, but I'd need to better understand >> prior to potentially taking action: >> theoretically, each event that triggers a timer (like ONBATT) has a >> counterpart to cancel it (like ONLINE). >> Ex (from the doc): >> AT ONBATT * START-TIMER onbattwarn 30 >> AT ONLINE * CANCEL-TIMER onbattwarn >> >> So is there any use case we're missing here? >> > > My use case was for a UPS unit which gave transient stupid status changes > such as "OL DISCHARG CHARG LB" when the battery was 100% charged. It was > an old MGE unit which has since died. > > When the stupid status change occured, the LB began a system shutdown. To > overcome this unwanted stutdown, I wanted to start a 5 second timer, and > when this ran out, upssched-cmd would review the situation, and decide if a > shutdown was really needed. If it was not needed, I had to cancel the > system-shutdown timer. I mistakenly assumed that such a timer was a file, > and that it was sufficient to erase the file. > > To solve the problem of cancelling an arbitrary timer from a script such > as upssched-cmd, I submitted a proposal to nut-upsdev: > >[Nut-upsdev] Proposal for technique to stop a timer at any moment > https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007202.html > > and a set of patches : > > https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007203.html > https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007204.html > > The technique is very general and is to send SIGUSR1/SIGUSR2 to the upsd > daemon. SIGUSR1 and SIGUSR2 are events just like ONBATT and ONLINE. The > patch runs successfully on my opensuse 13.2 box, and solves my problem. In > upssched.conf I now have declarations such as > >AT SIGUSR1 * CANCEL-TIMER shutdown-timer > > Will my patches be included in NUT? > Thanks for sharing your use case, and the rationales behind. First, the base point is to be able to cancel a timer anytime, from a command-line, which makes sense (as an extension, the opposite may also be true, to start a timer lively, without the event coming from upsmon). I've quickly checked your 2 patches. The solution seems to me not broad enough for injecting upstream. This works nice for a single device / UPS setup, but would not make it when there are more devices, as I get it. At first sight, I would more see something injecting into the PIPEFN fifo, i.e. acting the same way upsmon would when calling upssched with the upsname and the triggering event. I think that this can be solved more easily with tools like socat or nc, sending the command directly to the pipe. For example, to cancel the timer "shutdown-timer" from the upssched-cmd script, you would: echo "CANCEL shutdown-timer" | socat - UNIX-CLIENT:/var/run/nut/upssched.pipe Please tell me back if such solution would make it for you. I also realize that the distributed sample configuration and scripts do not fully match the doc. I'll make another round of update for this, still on the same branch. I would warmly welcome your help to complete the documentation, both with part of your patches that make sense, along with the above solution if it's good too. cheers, Arno -- Eaton Data Center Automation Solutions - Opensource Leader - http://42ity.org NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] contineously receiving the same values
On Mar 22, 2017, at 9:29 AM, Marc Kessels wrote: > > Hi Charles, > > > Upsmart version is 1.5, copyright says 2012-2014 Do you have a direct link? I found UPSmart-DryContact-V3-4.zip and UPSmart-Networking-V2-4.zip via web search, but the dates for the Linux components are ~ 2002. > > the github issue seems a bit worse, since it reports: > > received 10 (85) > 1.158700 read: UPS No Ack > > whereas my system reports : > > 6.239688 Full update... > 6.239776 send: Q1 > 6.261270 received 47 (40) > 6.261371 read: (234.0 000.0 234.0 012 49.9 27.4 29.0 1000 > > but it keeps repeating the last line, so I am not getting any update. I might have been confusing that issue with this comment in the parent thread, which seems to be similar underlying hardware repeating the last reading: https://github.com/networkupstools/nut/issues/307#issuecomment-243364229 The #409 report might have been due to a combination of the auto-detection, plus the lack of "vendor magic" from UPSmart. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] contineously receiving the same values
Hi Charles, Upsmart version is 1.5, copyright says 2012-2014 the github issue seems a bit worse, since it reports: received 10 (85) 1.158700 read: UPS No Ack whereas my system reports : 6.239688 Full update... 6.239776 send: Q1 6.261270 received 47 (40) 6.261371 read: (234.0 000.0 234.0 012 49.9 27.4 29.0 1000 but it keeps repeating the last line, so I am not getting any update. I'll give the wireshark sniffer a try, to see if I can find a solution there. thanks, marc On 22-3-2017 14:16, Charles Lepple wrote: On Mar 22, 2017, at 6:27 AM, Marc Kessels wrote: with NUT, I am able to connect to the UPS using the blazer_usb and nutdrv_qx. However, the reported values are constant, and only change if I run the UPSmart tool (It can run in parallel). What can I do to get NUT to receive updated values? Which version (and how old) is UPSmart? This just came up in a GitHub issue as well: https://github.com/networkupstools/nut/issues/409#issuecomment-288223536 @zykh wrote: In their case, if I recall correctly, the problem was that, using libusb (recte: libusb 0.x or libusb-compat), we can't reproduce the exact sequence of commands which appears to be needed to get valid and up-to-date values from the device. But now that we have a libusb 1.x branch, I think that, starting from it, we could implement something that should work for them. Assuming you have the original manufacturer-provided monitoring program, a capture of it 'talking' to the device could help diagnosing the problem. Is there a way to sniff the USB communication of the UPSmart? https://wiki.wireshark.org/CaptureSetup/USB#Linux Let us know if you have questions about the capture procedure. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] contineously receiving the same values
On Mar 22, 2017, at 6:27 AM, Marc Kessels wrote: > > with NUT, I am able to connect to the UPS using the blazer_usb and > nutdrv_qx. However, the reported values are constant, and only change if I > run the UPSmart tool (It can run in parallel). What can I do to get NUT to > receive updated values? Which version (and how old) is UPSmart? This just came up in a GitHub issue as well: https://github.com/networkupstools/nut/issues/409#issuecomment-288223536 > > @zykh wrote: > >> In their case, if I recall correctly, the problem was that, using libusb >> (recte: libusb 0.x or libusb-compat), we can't reproduce the exact sequence >> of commands which appears to be needed to get valid and up-to-date values >> from the device. But now that we have a libusb 1.x branch, I think that, >> starting from it, we could implement something that should work for them. >> Assuming you have the original manufacturer-provided monitoring program, a >> capture of it 'talking' to the device could help diagnosing the problem. > Is there a way to sniff the USB communication of the UPSmart? https://wiki.wireshark.org/CaptureSetup/USB#Linux Let us know if you have questions about the capture procedure. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] contineously receiving the same values
Hello, I'm trying to get an energenie EG-UPS-033 (http://energenie.com/item.aspx?id=8087) to work with nut. It standard comes with linux software (UPSmart), which shows the input/output voltage, load level, input frequency. and battery and case temperature. The values change about every second. The selected monitor mode in this tool is Mega(USB). The bad thing of this tool that it requires an X server, and does not provide a command line version. with NUT, I am able to connect to the UPS using the blazer_usb and nutdrv_qx. However, the reported values are constant, and only change if I run the UPSmart tool (It can run in parallel). What can I do to get NUT to receive updated values? I already tried the various subdrivers, and langid_fix , but to no avail. Is there a way to sniff the USB communication of the UPSmart? thanks a lot for your help, Marc here my details: * OS name and version,: ubuntu 14.04.1 64bit * exact NUT version: 2.74 * NUT installation method: from source tarball, package or Subversion, compiled from source tarball * exact device name and related information (manufacturing date, web pointers, …), energenie EG-UPS-033 (http://energenie.com/item.aspx?id=8087) * complete problem description, with any relevant traces, like system log excerpts, and driver debug output. You can obtain the latter using the following command, as root and after having stopped NUT: dmesg output upon connecting the UPS: [168841.020036] usb 5-2: new low-speed USB device number 8 using uhci_hcd [168841.187222] usb 5-2: New USB device found, idVendor=0001, idProduct= [168841.187231] usb 5-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [168841.187236] usb 5-2: Product: MEC0003 [168841.294695] hid-generic 0003:0001:.0005: hiddev0,hidraw0: USB HID v1.11 Device [MEC0003] on usb-:00:1d.3-2/input0 output of : sudo /lib/nut/blazer_usb -a myups -u nut - 0.00debug level is '4' 0.166331Checking device (1D6B/0003) (007/001) 0.166618- VendorID: 1d6b 0.17- ProductID: 0003 0.166698- Manufacturer: unknown 0.166730- Product: unknown 0.166761- Serial Number: unknown 0.166793- Bus: 007 0.166825- Device release number: 0316 0.166855Trying to match device 0.166897Device does not match - skipping 0.167052Checking device (1D6B/0002) (006/001) 0.167236- VendorID: 1d6b 0.167277- ProductID: 0002 0.167308- Manufacturer: unknown 0.167339- Product: unknown 0.167369- Serial Number: unknown 0.167400- Bus: 006 0.167431- Device release number: 0316 0.167461Trying to match device 0.167497Device does not match - skipping 0.167584Checking device (0001/) (005/008) 0.179225- VendorID: 0001 0.179299- ProductID: 0.179330- Manufacturer: unknown 0.179361- Product: MEC0003 0.179392- Serial Number: unknown 0.179423- Bus: 005 0.179454- Device release number: 0100 0.179484Trying to match device 0.179585Device matches 0.179666nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0) 0.179755Trying megatec protocol... 0.179792send: Q1 0.201201received 47 (40) 0.201251read: (230.0 000.0 231.0 012 50.0 27.2 29.0 1000 0.201404Status read in 1 tries 0.201439Supported UPS detected with megatec protocol 0.201473send: F 0.216208received 22 (35) 0.216267read: # .. . 0.216325blazer_rating: parsing failed 0.216358Rating read 1 failed 0.216390send: F 0.230202received 22 (35) 0.230274read: # .. . 0.230324blazer_rating: parsing failed 0.230356Rating read 2 failed 0.230387send: F 0.245193received 22 (35) 0.245239read: # .. . 0.245284blazer_rating: parsing failed 0.245315Rating read 3 failed 0.245346Rating information unavailable 0.245379send: I 0.265189received 39 (35) 0.265231read: # No No No No No No No No No 0.265285Vendor information read in 1 tries 0.265317No values provided for battery high/low voltages in ups.conf 0.265379Using 'guestimation' (low: 0.00, high: 0.00)! 0.265428Battery runtime will not be calculated (runtimecal not set) 0.265504send: Q1 0.287195received 47 (40) 0.287267read: (230.0 000.0 231.0 012 50.0 27.2 29.0 1000 0.287571dstate_init: sock /var/state/ups/blazer_usb-myups open on fd 5 0.287642send: Q1 0.309184received 47 (40) 0.309232read: (230.0 000.0 231.0 012 50.0 27.2 29.0 1000 2.289657send: Q1 2.310891received 47 (40) 2.310969read: (230.0 000.0 231.0 012 50.0 27.2 29.0 1000 4.291662send: Q1 4.313577received 47 (40) 4.313655read: (230.0 000.0
