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

[AppleCarmine]

Someone can help me :(?

[jimklimov]

Sorry for the lapse. From my suggestion, what you need to do is run some NUT drivers directly (not via upsdrvctl) with higher debug settings.

For example nutdrv_qx -DDDDDD -d 1 -s testups -x port=... where port might be /dev/ttyUSB0 if this is a serial connection.

More generally speaking for context, some UPSes have a physical USB port connected to a serial dongle inside, while others would need port=auto for a more real USB, whether HID or other protocols on top. With port=auto you may need also vendorid and productid settings, or possibly pick subdriver and/or protocol values.

For further device nuances there are many other tweaks documented in corresponding driver man pages.

[AppleCarmine]

Sorry for the lapse. From my suggestion, what you need to do is run some NUT drivers directly (not via upsdrvctl) with higher debug settings.

For example nutdrv_qx -DDDDDD -d 1 -s testups -x port=... where port might be /dev/ttyUSB0 if this is a serial connection (some UPSes have a physical USB port connected to a serial dongle inside), or auto for a more real USB, whether HID or other protocols on top. With port=auto you may need also vendorid and productid settings, or possibly pick subdriver and/or protocol values.

For further device nuances there are many other tweaks documented in corresponding driver man pages.

https://pastebin.com/3WUnuApV

[jimklimov]

Thanks. So from those replies, the UPS does not seem to talk any Megatec dialect...

Potentially, it could be talking at a different data rate, so it just can't interpret the signal it sees from the driver. It seems that some serial drivers and devices hard-coded e.g. 2400bps, with a few having baudrate/parity/databit/stopbit settings at all.

Do you have a chance to sniff how the UPS talks to its Windows program, e.g. using https://learn.microsoft.com/en-us/sysinternals/downloads/portmon as suggested at https://stackoverflow.com/questions/461794/whats-a-good-free-serial-port-monitor-for-reverse-engineering or some other tool from that discussion? Hopefully that would show some useful clues.

Note that the serial port name can change as you re-plug the USB-Serial adapter, check the Device Manager for current name (probably the starting point would be COM5 or similar).

[AppleCarmine]

Thanks. So from those replies, the UPS does not seem to talk any Megatec dialect...

Potentially, it could be talking at a different data rate, so it just can't interpret the signal it sees from the driver. It seems that some serial drivers and devices hard-coded e.g. 2400bps, with a few having baudrate/parity/databit/stopbit settings at all.

Do you have a chance to sniff how the UPS talks to its Windows program, e.g. using https://learn.microsoft.com/en-us/sysinternals/downloads/portmon as suggested at https://stackoverflow.com/questions/461794/whats-a-good-free-serial-port-monitor-for-reverse-engineering or some other tool from that discussion? Hopefully that would show some useful clues.

Note that the serial port name can change as you re-plug the USB-Serial adapter, check the Device Manager for current name (probably the starting point would be COM5 or similar).

I can’t get this program to work for sniffing requests; I’m trying to find an alternative.

[AppleCarmine]

Grazie. Quindi da quelle risposte, l'UPS non sembra parlare alcun dialetto Megatec...

Potenzialmente, potrebbe parlare a una velocità dati diversa, quindi non riesce a interpretare il segnale che vede dal driver. Sembra che alcuni driver e dispositivi seriali abbiano codificato in modo rigido, ad esempio 2400 bps, con alcuni che hanno impostazioni baudrate/parità/bit dati/stopbit.

Hai la possibilità di annusare come l'UPS comunica con il suo programma Windows, ad esempio usando https://learn.microsoft.com/en-us/sysinternals/downloads/portmon come suggerito su https://stackoverflow.com/questions/461794/whats-a-good-free-serial-port-monitor-for-reverse-engineering o qualche altro strumento da quella discussione? Spero che ciò possa mostrare qualche indizio utile.

Tieni presente che il nome della porta seriale può cambiare se ricolleghi l'adattatore USB-Seriale; controlla il nome attuale in Gestione dispositivi (probabilmente il punto di partenza sarebbe COM5o simile).

https://pastebin.com/dJhb5YzH

I managed to sniff the requests with Portmon! Wow, it drove me crazy to get it working, I hope it will be useful! I had to use 32-bit Windows XP, and after several attempts, I finally did it. Let’s hope it was really worth it. If you need anything else, let me know :D

EDIT:

https://pastebin.com/ZM0dedri
I was able to ‘spy’ on the communication using another software as well (Serial Port Monitoring). Here is the result.

[jimklimov]

To my eye the protocol did not associate with any pattern I see often (like Megatec's characteristic (xxx.y zzz.w ... lines); however I see the K) part repeating often. ChatGPT suggested that this may be APC Smart protocol's status polling/report.

The "K)" messages in the log you referenced suggest that the protocol being used is likely related to the Uninterruptible Power Supply (UPS) communication, typically following the Smart Protocol or the APC (American Power Conversion) protocol for UPS devices. These protocols often involve queries and responses for status and configuration information.
The repetitive reads might be part of a polling mechanism where the software continuously checks the status of the UPS. If you can share more specific details or examples from the log, I could help identify the protocol more accurately!

At least, it is worth trying some APC drivers (although I am not sure if anyone but APC-branded devices used it).

[jimklimov]

It seems that ChatGPT only blurbs about "APC Smart UPS Protocol" as an example of UPS protocol it heard about, not a specific indication. (Still worth a try, why not)

FWIW, I filtered the second posted sniff log into actual R/W bytes if it helps later investigations, but so far am out of quick ideas, sorry :\

• curl https://pastebin.com/raw/ZM0dedri > /tmp/z1
• grep -E 'IRP_MJ_(READ|WRITE) UP STATUS_SUCCESS' /tmp/z1 | awk '{print $4" "$7" "$8}' > /tmp/z3
  • https://pastebin.com/uxH5gASe - with HEX and ASCII values
• grep -E 'IRP_MJ_(READ|WRITE) UP STATUS_SUCCESS' /tmp/z1 | awk '{print $4" "$7}' > /tmp/z2
  • https://pastebin.com/69D3rzfh - only HEX

If the Windows software (UPSMONProSer.exe looking at logs?) reports some numbers (charge, temperature, voltage etc.) see if they resemble anything from these messages? e.g. 0x63 is 99 decimal, might be the near-100% battery charge?

Note that a byte or two might be a checksum for the message, it is not uncommon.

Temperatures might be originally in any of Celsius, Fahrenheit or Kelvin, and converted to your locale/market for representation in the program.

[AppleCarmine]

Sembra che ChatGPT parli solo di "APC Smart UPS Protocol" come di un esempio di protocollo UPS di cui ha sentito parlare, senza fornire indicazioni specifiche. (Vale comunque la pena provare, perché no)

Per quel che vale, ho filtrato il secondo log sniff pubblicato in byte R/W effettivi se può essere utile per le indagini successive, ma finora sono a corto di idee veloci, scusate :\

• curl https://pastebin.com/raw/ZM0dedri > /tmp/z1

• grep -E 'IRP_MJ_(READ|WRITE) UP STATUS_SUCCESS' /tmp/z1 | awk '{print $4" "$7" "$8}' > /tmp/z3

  • https://pastebin.com/uxH5gASe - con valori HEX e ASCII

• grep -E 'IRP_MJ_(READ|WRITE) UP STATUS_SUCCESS' /tmp/z1 | awk '{print $4" "$7}' > /tmp/z2

  • https://pastebin.com/69D3rzfh - solo HEX

Se il software Windows ( UPSMONProSer.exeche esamina i registri?) segnala alcuni numeri (carica, temperatura, voltaggio, ecc.), verifica se assomigliano a qualcosa in questi messaggi. Ad esempio, 0x63se è 99 decimale, potrebbe essere la carica della batteria vicina al 100%?

Si noti che uno o due byte potrebbero costituire il checksum del messaggio, cosa piuttosto comune.

Le temperature potrebbero essere originariamente espresse in gradi Celsius, Fahrenheit o Kelvin e convertite in base alla propria località/mercato per essere rappresentate nel programma.

This is all I have on UPSMon. So, I believe that 99% refers to the ‘Battery Status.

So, do you recommend that I try with the APC driver?

[jimklimov]

Hopefully, it would not hurt...

As a paying customer, you can also try asking the vendor for their protocol. In some countries they can be obliged to share it.

[AppleCarmine]

Hopefully, it would not hurt...

As a paying customer, you can also try asking the vendor for their protocol. In some countries they can be obliged to share it.

What do you mean by ‘Hopefully, it would not hurt…’?

Anyway, I’ve written 4-5 emails to the seller, and they are not responding.”

[jimklimov]

What do you mean by ‘Hopefully, it would not hurt…’?

It depends on how "they" coded their firmware, with regard to unexpected input (or EMI noise on the wire misinterpreted as signal).

"Hopefully" they coded to ignore unexpectancies or at worst reboot the controller - not brick it etc.

Never underestimate the possibility of cut corners in economy of low margins :\

[AppleCarmine]

What do you mean by ‘Hopefully, it would not hurt…’?

It depends on how "they" coded their firmware, with regard to unexpected input (or EMI noise on the wire misinterpreted as signal).

"Hopefully" they coded to ignore unexpectancies or at worst reboot the controller - not brick it etc.

Never underestimate the possibility of cut corners in economy of low margins :\

Anyway, the software page says it supports NUT (https://www.upspowercom.com/Support-NUT.jsp), I tried with these configurations, but it doesn’t work. Maybe it needs some subdriver or something like that? It could be a clue.

[jimklimov]

Cool, did not know about that back-link :)

However, they list a number of models under their own brand - not sure if yours maps to any of those. Also if your communications go over a serial port, the usbhid-ups driver would not be it, I'm afraid...

I've had several different Powercoms early in my sysadmin career, decent bang for buck (and got me to meet NUT for the first time); at that time the serial-port oriented powercom driver did talk to them.

Which gives me another idea: if your UPS is old, it may be that over NUT's evolution a suitable driver was deprecated and removed (there were one or two large re-designs of the software so whatever was not ported to new architecture could not work and was eventually dropped for lack of interest). If you can build NUT, try giving a shot to some very old versions, just to check if they had a driver that understands your device and may be worth wedging into the modern design?..

Looking at history.txt, UPGRADING.adoc and NEWS.adoc, I think some of the critical points were around NUT 0.45.0, 1.4.0, 2.0.5, 2.4.3 and 2.6.5 as the last versions delivering some things summarily removed in later ones.

[AppleCarmine]

Fantastico, non sapevo di quel back-link :)

Tuttavia, elencano un certo numero di modelli sotto il loro marchio, non sono sicuro se il tuo sia mappato su uno di quelli. Inoltre, se le tue comunicazioni avvengono tramite una porta seriale, il usbhid-upsdriver non sarebbe quello, temo...

All'inizio della mia carriera di amministratore di sistema ho avuto diversi Powercom, un buon rapporto qualità-prezzo (e mi hanno fatto incontrare NUT per la prima volta); a quel tempo, il powercomdriver orientato alla porta seriale comunicava con loro.

Il che mi dà un'altra idea: se il tuo UPS è vecchio, potrebbe essere che durante l'evoluzione di NUT un driver adatto sia stato deprecato e rimosso (ci sono state una o due grandi riprogettazioni del software, quindi tutto ciò che non è stato portato sulla nuova architettura non poteva funzionare ed è stato infine abbandonato per mancanza di interesse). Se riesci a costruire NUT, prova a dare un'occhiata ad alcune versioni molto vecchie, solo per verificare se avevano un driver che capisce il tuo dispositivo e potrebbe valere la pena di essere inserito nel design moderno?..

Esaminando history.txt, UPGRADING.adoce NEWS.adoc, penso che alcuni dei punti critici riguardassero NUT 0.45.0, 1.4.0, 2.0.5, 2.4.3 e 2.6.5 come ultime versioni, che includevano alcune cose sommariamente rimosse in quelle successive.

Unfortunately, I’m not able to rebuild NUT from scratch, which is a shame. I’ll abandon the project and buy another supported UPS or make do with the proprietary software. Thanks anyway.

[jimklimov]

FWIW, for modern NUT, the toolkits for different platforms are listed at https://github.com/networkupstools/nut/blob/master/docs/config-prereqs.txt or prettily rendered at https://networkupstools.org/docs/user-manual.chunked/_build_prerequisites_to_make_nut_from_scratch_on_various_operating_systems.html

I suppose they should be able to build many older versions too, especially if you ignore the compiler warnings.

Out of curiosity, did you try the Linux version of their UPSMON PRO? https://www.upspowercom.com/Monitoring.jsp#Software

[AppleCarmine]

Per quel che vale, per i moderni NUT, i toolkit per le diverse piattaforme sono elencati su https://github.com/networkupstools/nut/blob/master/docs/config-prereqs.txt o resi in modo gradevole su https://networkupstools.org/docs/user-manual.chunked/_build_prerequisites_to_make_nut_from_scratch_on_various_operating_systems.html

Immagino che dovrebbero essere in grado di compilare anche molte versioni più vecchie, soprattutto se si ignorano gli avvisi del compilatore.

Per curiosità, hai provato la versione Linux del loro UPSMON PRO? https://www.upspowercom.com/Monitoring.jsp#Software

I tried installing it several times without success, it kept giving me error after error. Now I’m trying to install it on a Raspberry Pi 3 with an older version of Ubuntu.

[jimklimov]

Trying to make sense/educated guess of your sniffed data:

WRITE 01 . 

READ 2d - : varied 2b..31 (43..47dec)

READ 63 c : 99dec (battery %)

READ 6b k : same as below and varied 6b..6d (around 110dec - could be voltage minus 100, common trick for 270V scale representation)

READ 6b k 

READ 32 2 : 50dec (Hz?)

READ ff ÿ : 255dec

READ 32 2 : 50Hz (in/out?)

READ 00 . 

READ 00 . 

READ 14 . : 20dec

READ 00 . 

READ 4b K : 75dec

READ 29 ) : 41dec

READ 00 . 

READ 00 . 

READ 00 .

probably some of 0's (or bits in some unidentified numbers) are state, alarms etc.?...

could 40-ish numbers be load at that time?

maybe something for run time could be 2 bytes long...

[AppleCarmine]

Trying to make sense/educated guess of your sniffed data:

WRITE 01 . 

READ 2d - : varied 2b..31 (41..47dec)

READ 63 c : 99dec (battery %)

READ 6b k : same as below and varied 6b..6d (around 110dec - could be voltage minus 100, common trick for 270V scale representation)

READ 6b k 

READ 32 2 : 50dec (Hz?)

READ ff ÿ : 255dec

READ 32 2 : 50Hz (in/out?)

READ 00 . 

READ 00 . 

READ 14 . : 20dec

READ 00 . 

READ 4b K : 75dec

READ 29 ) : 41dec

READ 00 . 

READ 00 . 

READ 00 .

probably some of 0's (or bits in some unidentified numbers) are state, alarms etc.?...

If by alarms you mean beeps, no, at the exact moment I did the dump, I didn’t receive any alarm signals. Anyway, the proprietary Linux software is terrible, it just won’t start :(

[AppleCarmine]

I confirm, the UPSMON Pro software for Linux is terrible. It’s made with Java but doesn’t work; it’s missing libraries, it won’t start—it’s just a nightmare. Really disgusting. What a shame.