Not supported UPS in NUT

[AppleCarmine]

Hello everyone, I have a slightly old UPS from Control Systems 2, model STD60S. There’s not much information about this UPS on the web. It has a serial port, and with the Powercom software (https://www.upspowercom.com/Monitoring.jsp#Software), I managed to get it working and monitored on Windows. I installed the drivers for the USB SERIAL adapter, the Powercom software, and it works perfectly.

However, I can’t get it to work on NUT. Unfortunately, I’ve tried several serial drivers, including powercom, usbhid-ups, blazer_ser, and nutdrv_qx, but nothing seems to work. It just can’t detect it, and it doesn’t function.

The strange thing is that if the Powercom software works with my UPS, I don’t understand why the NUT drivers for Powercom UPSs aren’t working.

Could you please help me? I’ve been struggling with this for days. I’ve tried it on a Proxmox node, on a Proxmox VM using passthrough, and on a Raspberry Pi, but nothing seems to work.

[desertwitch]

Have you tried what running nut-scanner returns? https://networkupstools.org/docs/man/nut-scanner.html

[jimklimov]

Well, for one - it would be beneficial to start directly the driver programs, not via upsdrvctl, so you can pass debug options to them. It may also help to custom-build recent NUT sources for the investigation - more drivers were added, and code may be more talkative for the troubleshooting part. See https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests about that.

Some ideas OTOH:

• Higher debug verbosity would expose how the driver tries to match the device and why it decides that it can not talk to it.
  • With usbhid-ups it might get to dumping the data exchange, if there were HID reports.
  • With nutdrv_qx (in both serial and USB modes) it can show which Megatec Q protocol family commands it sent, and perhaps which replies it got. If there are replies starting with a parenthesis and a sequence of floating-point numbers - that is likely some dialect of Qx.
• USB-capable drivers like usbhid-ups and nutdrv_qx (in not-serial mode with port=auto) may require you to pass vendorid and productid options if the device uses some IDs not known to the driver. With NUT v2.8.2 and newer you can also specify a subdriver to try for usbhid-ups; the nutdrv_qx and blazer* drivers had that ability for longer (and also a protocol option).
• Also check that no other program grabbed the device (especially if it identifies as USB HID, so udev or similar might lay hands on it).
• I don't have direct experience, but in many issues saw USB-level sniffing used with Wireshark or similar, to check what the vendor protocol looks like with their tools. Allegedly there are variants that work on Windows too.

The strange thing is that if the Powercom software works with my UPS, I don’t understand why the NUT drivers for Powercom UPSs aren’t working.

Finally, on this point: many vendors use a lot of protocols over time that they are on the market. Sometimes this even changes for the same device as firmwares are updated. They may have started with one protocol (that someone developed a NUT driver for back in the day), then adopted or licensed another. There are vendors whose similarly named models talk USB HID in one version and Qx in another. APC scaled down on common USB HID and pushes for modbus since 2010's, but due to having purchased many companies is also represented by protocols with "smart", "sol", etc. in the name. TLDR - it is a very mixed bag.

In case of USB-connected devices done diligently, vendors would have an identifier for themselves, and the further product identifier helps know which protocol it talks (I saw firmwares even change the announced productid when different protocols become supported, kudos). Sadly, many vendors do take the cheap-o route of using bogus identifiers like a mix of 0000, 0001 and ffff usually, which does not help discern them.

[AppleCarmine]

Have you tried what running nut-scanner returns? https://networkupstools.org/docs/man/nut-scanner.html

Yes, but without success.

[AppleCarmine]

Bene, per prima cosa, sarebbe utile avviare direttamente i programmi driver, non tramite upsdrvctl, in modo da poter passare loro le opzioni di debug. Potrebbe anche essere utile creare fonti NUT recenti personalizzate per l'indagine: sono stati aggiunti più driver e il codice potrebbe essere più loquace per la parte di risoluzione dei problemi. Vedi https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests a riguardo.

Alcune idee OTOH:

• Una maggiore verbosità del debug mostrerebbe come il driver tenta di adattarsi al dispositivo e perché decide di non poter comunicare con esso.

  • Potrebbe anche usbhid-upsverificarsi l'interruzione dello scambio di dati, se ci fossero segnalazioni HID.
  • Con nutdrv_qx(sia in modalità seriale che USB) può mostrare quale famiglia di protocolli Megatec Q ha inviato i comandi, e forse quali risposte ha ricevuto. Se ci sono risposte che iniziano con una parentesi e una sequenza di numeri in virgola mobile, è probabile che si tratti di un dialetto di Qx.
• Driver abilitati per USB come usbhid-upse nutdrv_qx(in modalità non seriale con port=auto) potrebbero richiedere di passare le opzioni vendoride productidse il dispositivo utilizza alcuni ID non noti al driver. Con NUT v2.8.2 e versioni successive puoi anche specificare a subdriverper provare usbhid-ups; i driver nutdrv_qxe blazer*hanno avuto questa capacità per più tempo (e anche protocolun'opzione).
• Controllare inoltre che nessun altro programma abbia intercettato il dispositivo (soprattutto se identificato come USB HID, udevo simili, che potrebbero averci messo le mani).
• Non ho esperienza diretta, ma in molti casi ho visto lo sniffing a livello USB utilizzato con Wireshark o simili, per controllare come appare il protocollo del fornitore con i loro strumenti. A quanto pare ci sono varianti che funzionano anche su Windows.

La cosa strana è che se il software Powercom funziona con il mio UPS, non capisco perché i driver NUT per gli UPS Powercom non funzionano.

Infine, su questo punto: molti venditori usano molti protocolli nel tempo in cui sono sul mercato. A volte questo cambia anche per lo stesso dispositivo man mano che i firmware vengono aggiornati. Potrebbero aver iniziato con un protocollo (per il quale qualcuno ha sviluppato un driver NUT all'epoca), quindi averne adottato o concesso in licenza un altro. Ci sono venditori i cui modelli con nomi simili parlano USB HID in una versione e Qx in un'altra. APC ha ridotto il comune USB HID e spinge per modbus dal 2010, ma avendo acquistato molte aziende è anche rappresentata da protocolli con "smart", "sol", ecc. nel nome. TLDR: è un insieme molto eterogeneo.

Nel caso di dispositivi USB collegati realizzati con diligenza, i venditori avrebbero un identificativo per sé stessi, e l'ulteriore identificativo del prodotto aiuta a sapere quale protocollo parla (ho visto firmware cambiare persino il productid annunciato quando vengono supportati protocolli diversi, complimenti). Purtroppo, molti venditori prendono la strada più economica per usare identificativi fasulli come un mix di 0000, 0001e ffffdi solito, il che non aiuta a distinguerli.

I’m very sorry, I’m not very experienced, and I’m not clear on what exactly I need to do: do I need to debug NUT? Which drivers do you recommend I use for this? I’m sorry again, but I’ve really never used NUT before, and I’m not sure how the debugging process works