[Nut-upsdev] Nut-upsdev Digest, Vol 206, Issue 5

[Jim Klimov]

Well, now that the `subdriver` option got added to `usbhid-ups` too, you
can at least try that (by building again the current master). See
command-line help for the subdrivers it would currently recognize, and copy
e.g. the first word as the matching option, e.g.:

    ./drivers/usbhid-ups -DDDDDD -d1 -s test -x port=auto -x vendorid=...
-x productid=... -x subdriver=...

and try to lockpick your way here.

On a side note, some long-awaited tinkering began on making an APC modbus
driver a reality, but so far it is in such early stages that it relies on
an unpublished version of the modbus library so is not trivial to even
build (or get packaged).

Jim


On Tue, Sep 19, 2023 at 9:13 PM FatGear <fatgear1 at free.fr> wrote:

> Hello there,
>
> I don't think that's working,😕
>
> I have done all your repo but i don't know how it's supposed to work.
>
> I have a idea, change vendor id and product id  to make the driver try to
> connect to the ups, what do you think of that ? With this driver maybe :
> usbhid-ups
>
> FatGear
> Le 16/09/2023 à 20:40, Jim Klimov a écrit :
>
> It seems the `libmodbus` library or headers were not found, or something
> similar - so the driver against it was not built. Did you install
> `libmodbus-dev` before the build? What does `config.log` in the build root
> say (and.or the summary shown after you run the `configure` script)?
>
> On Sat, Sep 16, 2023 at 7:46 PM FatGear <fatgear1 at free.fr> wrote:
>
>> Hi,
>>
>> I don't know what i'm doing wrong but it seams that is not working,
>>
>> I tried to put and remove id but it's not fonctioning,
>>
>> /etc/nut/ups.conf
>>
>> "
>>
>> pollinterval = 1
>> maxretry = 3
>>
>> [ups1kva]
>>         driver = huawei-ups2000
>>         port auto
>>         vendorid = "04e2"
>>         productid = "1410"
>> "
>>
>> Then i use this commands for rebooting the drivers
>>
>> https://techno-tim.github.io/posts/NUT-server-guide/
>>
>> "
>>
>> /tmp# sudo service nut-server restart
>> /tmp# sudo service nut-client restart
>> /tmp# sudo systemctl restart nut-monitor
>> /tmp# sudo upsdrvctl stop
>> Network UPS Tools - UPS driver controller 2.8.0-2454-g91b3ee057
>> Can't open /var/state/ups/huawei-ups2000-ups1kva.pid either: No such file
>> or directory
>> /tmp# sudo upsdrvctl start
>> Network UPS Tools - UPS driver controller 2.8.0-2454-g91b3ee057
>> Can't start /usr/bin/huawei-ups2000: No such file or directory
>> "
>>
>> On my "/tmp/nut/drivers/" i have :
>>
>> huawei-ups2000.c
>>
>> And in my "ls /lib/nut/" I haven't huawey-ups2000
>>
>>
>> "APC" became "schneider" i don't know this is relevant or not.
>>
>> What are you sugesting i do next ?
>>
>> If you want we can call each others, via discord maybe ?
>>
>> FatGear
>>
>>
>> Le 16/09/2023 à 17:00, Jim Klimov a écrit :
>>
>> Hi, sounds like we're making progress here :)
>>
>>   Well, if you've tried *all* of those commands, it should have made a
>> build workspace under /tmp/nut where it has a current NUT codebase build.
>>
>>   That should include a `/tmp/nut/drivers/huawei-ups2000` binary right
>> there (assuming you also did follow the link to
>> https://github.com/networkupstools/nut/blob/master/docs/config-prereqs.txt
>> and installed the `libmodbus-dev` or equivalent for your OS distribution,
>> among other prerequisites). This one should suffice to try testing if your
>> device is supported by that driver.
>>
>>   The contents of `/lib/nut` are relevant if you've also followed up with
>> `sudo make install` noted at the end of the doc, to replace your packaged
>> NUT installation. Perhaps even then, it might not auto-detect the custom
>> paths to drivers like these and would just place the new ones into /usr/bin
>> or some such.
>>
>>   All that said however, if the UPS you are looking at is still the APC
>> mentioned earlier, I have doubts if the huawei driver would handle it
>> (might... maybe they are an OEM for rebranding now?..) or if that device
>> just happens to use the same USB interface chip as some of those Huawei's
>> did - and perhaps without changing the IDs to APC's (which seems strange,
>> they have an assigned ID), but talks a different protocol using such chip.
>>
>>
>> On Sat, Sep 16, 2023 at 10:09 AM FatGear via Nut-upsdev <
>> nut-upsdev at alioth-lists.debian.net> wrote:
>>
>>> Hi,
>>>
>>> I tried all commands on
>>>
>>> https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
>>>
>>> but i don't know what i'm supposed to do next, it seams to download some
>>> things on my /tmp/nut/ but i don't know what is it.
>>>
>>> My kernel is Linux 5.4.0-162-generic x86_64 and i don't have
>>> huawei-ups2000 driver.
>>>
>>> I have "/lib/nut$ ls
>>> al175         blazer_usb    metasys          riello_ser
>>> apcsmart      clone         mge-shut         riello_usb
>>> apcsmart-old  clone-outlet  mge-utalk        safenet
>>> apcupsd-ups   dummy-ups     microdowell      solis
>>> bcmxcp        etapro        nutdrv_atcl_usb  tripplite
>>> bcmxcp_usb    everups       nutdrv_qx        tripplitesu
>>> belkin        gamatronic    oldmge-shut      tripplite_usb
>>> belkinunv     genericups    oneac            upscode2
>>> bestfcom      isbmex        optiups          upsd
>>> bestfortress  ivtscd        powercom         upsmon
>>> bestuferrups  liebert       powerpanel       usbhid-ups
>>> bestups       liebert-esp2  rhino            victronups
>>> blazer_ser    masterguard   richcomm_usb
>>> "
>>>
>>> My lsusb is showing "Bus 001 Device 008: ID 04e2:1410 Exar Corp.
>>> XR21V1410 USB-UART IC"
>>>
>>> And i don't know what to do next.
>>>
>>> Fatgear
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230919/1d5f5f2c/attachment-0001.htm>