[Nut-upsuser] request - nutdrv_qx_megatec.c: update/fix the code for "new" UPS

Fri Aug 19 10:53:32 BST 2022

Don't worry, many of us started as sysadmins - creative, adaptive,
investigative and sooo not stupid to get things done ;)

Can you re-run the driver without specifying a subdriver, so it would try
all of the dialects?

>From logs it seems the device indeed keeps not-replying (in time?); I
vaguely remember something in recent years of commits addressing that part
of instability but can't quickly point to that.

Also, to try any fixes you'd have to build a new NUT version for that
platform anyway, might as well learn how to now...

While checking hypotheses though, is it possible for you to attach USB
cable of this UPS to a PC so you can iterate custom NUT builds faster? It
is more about sysadmining to make the build env (see
docs/config-prereqs.txt for hints) and running the build (ci_build.sh can
help) than programming, so far :)

S pozdravem,
Jim

On Thu, Aug 18, 2022, 23:01 Tomáš Thiemel <thiemel at centrum.cz> wrote:

> Jim,
>
> I understand you want to help but it looks like neither of us is a
> programmer. I also posted "debug output" from the NUT in my inital e-mail
> so any programmer should be able to tell us what's really wrong.
>
>
>
> If my assumption is correct, the easiest way to test it would be to
> replace the line 103 in the
> https://github.com/networkupstools/nut/blob/master/drivers/nutdrv_qx_megatec.c
> by
>
> " { "Q1\r", "(215.0 195.0 230.0 014 49.0 22.7 --.- 00000000\r", -1 },"
>
> or by
>
> " { "Q1\r", "(215.0 195.0 230.0 014 49.0 --.- 30.0 00000000\r", -1 },"
>
> and then "run the test".
>
>
>
> PS: I am just stupid sysadmin - I can read the code slightly but I cannot
> write it. I already found a solution to my problem (copied some Python code
> from the internet into big ugly blob - I'm not proud of it but it works). I
> just wanted to report "new" UPS on the market so anybody around the NUT
> project would be able fix/update the code. Honestly - I don't have skills
> (and time) to "find the bug", fix the code,  cross-compile it for MIPS
> architecture, and then finally upload it to the Mikrotik router with
> OpenWRT firmware, which is used as a cheap & simple UPS monitor for one
> remote AP/HotSpot. I could use 3x more expensive APC UPS but everything is
> about money.
>
>
>
> Cheers / S pozdravem
>
>
>
> Tomáš Thiemel
>
> thiemel at centrum.cz
>
>
>
> ______________________________________________________________
> > Od: "Jim Klimov" <jimklimov+nut at gmail.com>
> > Komu: "Tomáš Thiemel" <thiemel at centrum.cz>
> > Datum: 18.08.2022 19:49
> > Předmět: Re: [Nut-upsuser] request - nutdrv_qx_megatec.c: update/fix the
> code for "new" UPS
> >
>
> > CC: <nut-upsuser at alioth-lists.debian.net>
> I can best suppose so far that for one, printf in shell may differ from
> that  in C and from scanf for that matter. And I think OTOH that scanf can
> signal an error if the formatting string does not match expected pattern.
> Maybe this is what happens to reject the device, maybe some other fault.
> Try finding where it parses that input to fall back treating `-.--` as
> zero or something to mean "known-mussing"... Ideally just a lack of that
> reading in dstate, in the end - e.g. no temperature field for this device.
>
> On Tue, Aug 16, 2022, 15:24 Tomáš Thiemel <thiemel at centrum.cz> wrote:
>
>> Hi Jim,
>>
>> I am afraid that the main problem is in '%.1f' in the "lookup table" when
>> UPS returns "--.-" (string) instead of "12.3" (float):
>>
>>
>> root at OpenWrt:~# printf '%.1f \n' "12.3"
>>
>> 12.3
>>
>> root at OpenWrt:~# printf '%.1f \n' "--.-"
>>
>> ash: invalid number '--.-'
>>
>> 0.0
>>
>>
>> I checked source codes at
>> https://github.com/networkupstools/nut/tree/master/drivers and all these
>> protocols have similar "lookup table":
>>
>> - nutdrv_qx_zinto.c
>>
>> - nutdrv_qx_voltronic-qs.c
>>
>> - nutdrv_qx_q1.c
>>
>> - nutdrv_qx_mustek.c
>>
>> - nutdrv_qx_megatec.c
>>
>> - nutdrv_qx_megatec-old.c
>>
>> - nutdrv_qx_mecer.c
>>
>> - nutdrv_qx_hunnox.c
>>
>> - nutdrv_qx_bestups.c
>>
>>
>> BTW - I already wrote some "basic" code in Python using PyUSB to read
>> desired data from the UPS, but the communication with it is very very bad. Probably
>> due to the bad the quality of the electronics in it. Sometimes it
>> returns data with missing initial characters (missing first 8 bytes) so I
>> have to re-read the status, sometimes the communication freezes completely
>> so I have to power-cycle the USB port.
>>
>>
>>
>> Best regards / S pozdravem
>>
>>
>>
>> Tomáš Thiemel
>>
>> thiemel at centrum.cz
>>
>>
>>
>> ______________________________________________________________
>> > Od: "Jim Klimov" <jimklimov+nut at gmail.com>
>> > Komu: "Tomáš Thiemel" <thiemel at centrum.cz>
>> > Datum: 16.08.2022 12:44
>> > Předmět: Re: [Nut-upsuser] request - nutdrv_qx_megatec.c: update/fix
>> the code for "new" UPS
>> >
>>
>> > CC: <nut-upsuser at alioth-lists.debian.net>
>> Ahoj,
>>   Just in case, did you check other subdrivers there? They all are for
>> variants of Megatec Qx family, UPS vendors were creative with it...
>> Jim
>>
>> On Tue, Aug 16, 2022, 03:46 Tomáš Thiemel via Nut-upsuser <
>> nut-upsuser at alioth-lists.debian.net> wrote:
>>
>>> Hi.
>>>
>>> I bought new UPS which is not "supported", yet.
>>>
>>>
>>>
>>> Brand: Volt Polska
>>>
>>> Model: Micro 800
>>>
>>> have USB with Megatec protocol ("Q1<cr>")
>>>
>>> Data returned by UPS: *"(242.9 242.9 242.9 000 50.0 13.3 --.- 00001001"*
>>>
>>> Problem: data returned by UPS is not handled correctly by
>>> nutdrv_qx/megatec driver, although the SW from
>>> https://www.power-software-download.com/viewpower.html (JAVA) works
>>> fine.
>>>
>>>
>>>
>>> "ups.temperature" is defined as "%.1f" in the source code but my UPS
>>> returns "--.-"
>>>
>>>
>>> Debug info:
>>>
>>> root at patschkav-OpenWrt:~# /lib/nut/nutdrv_qx -DDDDDDDDDD -a ups -x
>>> protocol=megatec
>>>
>>> Network UPS Tools - Generic Q* USB/Serial driver 0.28 (2.7.4)
>>>
>>> USB communication driver 0.33
>>>
>>>    0.000000     send_to_all: SETINFO driver.parameter.port "auto"
>>>
>>>    0.006788     send_to_all: SETINFO driver.parameter.vendorid "0665"
>>>
>>>    0.008047     send_to_all: SETINFO driver.parameter.productid "5161"
>>>
>>>    0.010655     send_to_all: SETINFO driver.parameter.protocol "megatec"
>>>
>>>    0.011858     debug level is '10'
>>>
>>>    0.014225     upsdrv_initups...
>>>
>>>    0.019924     Checking device (0665/5161) (001/014)
>>>
>>>    0.036693     - VendorID: 0665
>>>
>>>    0.036788     - ProductID: 5161
>>>
>>>    0.036819     - Manufacturer: unknown
>>>
>>>    0.036850     - Product:
>>>
>>>    0.036881     - Serial Number: unknown
>>>
>>>    0.036912     - Bus: 001
>>>
>>>    0.036942     - Device release number: 0002
>>>
>>>    0.036971     Trying to match device
>>>
>>>    0.037069     Device matches
>>>
>>>    0.037178     nut_usb_set_altinterface: skipped
>>> usb_set_altinterface(udev, 0)
>>>
>>>    0.037262     send_to_all: SETINFO ups.vendorid "0665"
>>>
>>>    0.037317     send_to_all: SETINFO ups.productid "5161"
>>>
>>>    0.037361     Skipping protocol Voltronic 0.06
>>>
>>>    0.037399     Skipping protocol Voltronic-QS 0.07
>>>
>>>    0.037438     Skipping protocol Voltronic-QS-Hex 0.10
>>>
>>>    0.037477     Skipping protocol Mustek 0.07
>>>
>>>    0.037514     Skipping protocol Megatec/old 0.07
>>>
>>>    0.037551     Skipping protocol BestUPS 0.06
>>>
>>>    0.037589     Skipping protocol Mecer 0.07
>>>
>>>    0.052692     send: Q1
>>>
>>>    0.054678     read: timeout (0)
>>>
>>>    0.054842     qx_process_answer: short reply (input.voltage)
>>>
>>>    1.465747     send: Q1
>>>
>>>    1.494790     read [  0]: (8 bytes) => 28 32 34 30 2e 38 20 32
>>>
>>>    1.526803     read [  8]: (8 bytes) => 34 30 2e 38 20 32 34 30
>>>
>>>    1.558795     read [ 16]: (8 bytes) => 2e 38 20 30 30 30 20 35
>>>
>>>    1.590799     read [ 24]: (8 bytes) => 30 2e 32 20 31 33 2e 33
>>>
>>>    1.622797     read [ 32]: (8 bytes) => 20 2d 2d 2e 2d 20 30 30
>>>
>>>    1.654819     read [ 40]: (8 bytes) => 30 30 31 30 30 31 0d 00
>>>
>>>    1.654919     read: (240.8 240.8 240.8 000 50.2 13.3 --.- 00001001
>>>
>>>    1.655052     send_to_all: SETINFO input.voltage "240.8"
>>>
>>>    3.061834     send: I
>>>
>>>    3.094895     read [  0]: (8 bytes) => 31 0d 00 00 00 00 00 00
>>>
>>>    3.094994     read: 1
>>>
>>>    3.095100     qx_process_answer: short reply (ups.firmware)
>>>
>>>    3.095161     send_to_all: DELINFO input.voltage
>>>
>>>    4.506937     send: Q1
>>>
>>>    5.509389     read: Operation timed out (-145)
>>>
>>>    5.509494     qx_process_answer: short reply (input.voltage)
>>>
>>>    5.509541     Skipping protocol Zinto 0.06
>>>
>>>    5.509578     Skipping protocol Q1 0.07
>>>
>>>    5.509608     Device not supported!
>>>
>>>    5.509638     Device not supported!
>>> Can some skilled programmer fix the code in nutdrv_qx_megatec.c,
>>> please? I'm just stupid sysadmin. :-(
>>> Thank you very much.
>>>
>>>
>>>
>>> Best regards / S pozdravem
>>>
>>>
>>>
>>> Tomáš Thiemel
>>>
>>> thiemel at centrum.cz
>>>
>>>
>>>
>>> _______________________________________________
>>> Nut-upsuser mailing list
>>> Nut-upsuser at alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220819/3b4fc511/attachment-0001.htm>