search

networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
1.88k stars 342 forks source link

Need riello_usb drivers for windows #2527

Open iAlexeyProkhorov opened 1 month ago

iAlexeyProkhorov commented 1 month ago

Hi! Will be good to make 'riello_usb' driver for windows version. I've Riello SEP1000 ups and can't connect it NUT(

Thank you for your work.

jimklimov commented 1 month ago

Hello, did you try snapshots from https://github.com/networkupstools/nut/wiki/NUT-for-Windows ?

iAlexeyProkhorov commented 1 month ago

Thank you! 😀 You're make my day mutch better).

Three days of pain at last finished😂.

iAlexeyProkhorov commented 1 month ago

One more question. I connect my UPS Riello SEP 1000 Sentinel PRO to NUT, but data looks bad. I've try to use localcalculation, but this not helps. May be somebody knows what should I add into ups.conf?

My ups.conf looks next:

[SEP1000]
    driver = riello_usb
    port = auto
    desc = "SEP 700/1000/1500/2200/3000"
    localcalculation

Безымянный

jimklimov commented 1 month ago

One thing that comes to mind, is if the libusb connection to the device, as used by NUT, does not really see all the data - and some other layer intercepts some bytes. In case of Windows it was seen when the system's "HID Battery" driver attached first, at least for USB HID devices. Then the device was sort of seen, but with bogus data that did not change over time and physical changes (e.g. plug/unplug the wall) power line. In issue #1690 and some earlier posts there is extensive discussion about the "Zadig" tool which tells the system which USB IDs to use with a driver stack usable by NUT.

Similar effects were seen also with virtualization and pass-through of USB devices, where NUT driver on host or guest system could not see everything, because another program (kernel handler, also NUT...) on the other side of the virtual border, in the guest or host system respectively, also tried to handle the device. This is not a conflict that can be always caught by either of the two kernels and virtualization layer, and each system thinks it fully owns the device, but it also leads to bogus reads.

So these are two first things I would check for.

iAlexeyProkhorov commented 1 month ago

Hi @jimklimov. Thank you for your reply, I'll try to use this information nearest time and write result here 😁