[Nut-upsuser] Fwd: contineously receiving the same values

2017-03-22 Thread Matthew Wire
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=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

2017-03-22 Thread Arnaud Quette
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

2017-03-22 Thread Marc Kessels



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=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?

2017-03-22 Thread Arnaud Quette
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

2017-03-22 Thread Charles Lepple
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

2017-03-22 Thread Marc Kessels

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

2017-03-22 Thread Charles Lepple
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

2017-03-22 Thread Marc Kessels

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