First attempt to add support for Ippon Innova RT 3/1 #2712

dvdesolve · 2024-12-06T15:12:44Z

We own a bunch of Innova RT 3/1 (20K version) UPSes. They are of 3-in (+bypass) 1-out type UPS. COM port sniffing + tickling "official" software called WinPower gave some useful info for RE this version of protocol. Also I see that there are some issues regarding Q6 variant of protocol already (#1039, #1395).

Below is a short description of all commands that I was able to successfully intercept and decode (partially, though).

Serial number

SASV07?
GASV07DN05K10KB100004

Seems like to be true, starting from position 7 (my real s/n was N05K10KB100004). As far as I remember occurs only once during initial scan by WinPower.
Not used in protocol implementation.

Ping

PI
(0F

Not sure if this is true. This message occurs from time to time during WinPower's agent working.
Not used in protocol implementation.

Model (+specs)

WH
(00 00.00 00.00 INN3T20K                 2 3/1 6 230 50.00 024 02.00 005.00 015.00 005 00 40 110 276 45.00 55.00

Seems to be model code (field 4), topology (field 6), nominal voltage (field 8) and frequency (field 9), number of batteries (field 10). Wasn't able to find real meaning of other fields.
Not used at all in protocol implementation.

Load stats

WA
(001.4 000.0 000.0 001.4 000.0 000.0 001.4 001.4 006.5 000.0 000.0 007 00000000

Fields 1 and 7 seems to be real power measurements on output while fields 4 and 8 - the full one. This example a bit clumsy because in that case cos(phi) was about 1, but in another measurements I was able to get different readings. Not sure why these fields are in pairs (m. b. rolling average?). Field 9 is a current (amps), field 12 - load (percents).
Used in load measurements.

Bypass stats

BPS
(230.4 000.0 000.0 49.9

Field 1 corresponds to bypass voltage and field 4 stands for bypass frequency. I suspect that fields 2 and 3 will have non-zeroes for 3/3 UPS models.
Used in bypass stats.

Common stats

Q6
(227.0 225.6 230.0 50.0 229.9 000.0 000.0 49.9 007 000 000 327.8 000.0 23.0 06932 100 32 00000000 00000000 11

That's the core command to get stats of input/output and battery. First 3 fields correspond to voltages on input phases, field 4 is an input frequency, fields 5-7 are for output voltages (6 and 7 are zeroes because of 3/1 UPS model in my case), field 8 is output frequency, field 9 is load (percents), field 12 is battery voltage, field 14 is internal temperature, field 15 is estimated runtime, field 16 is battery charge level (percents). Not sure what other fields mean.
Heavily used for main stats.

Temperature reading

TC?
(023.0

Seems like it's just a duplicate.
Not used.

Battery level

BL?
100

The same story as above. Not used.

Bypass limits

QP
(45.0 55.0 176 264 EpbraDokc

Seems to be limits for bypass: low frequency, high frequency, low voltage and high voltage, respectively.
Not used.

Ratings

F
#230.0 087 288.0 50.0

Seems like to be a standard one: nominal voltage, nominal current, nominal battery voltage, nominal frequency.
Used for the sake of completeness.

ECO mode acceptable frequency range

EF?
(005 005

Looks like these values are acceptable percentages of marginal deviations in frequency while being on High Efficiency (or ECO) mode.
Not used.

ECO mode acceptable voltage range

EV?
(005 005

The same as above but for voltage story.
Not used.

Firmware version

FW?
05516-1100

Not sure if that's true - I don't have any firmware files to check this fact. May be useful if full Blazer claiming procedure is used (my PR uses light version).
Not used.

Unknown function request

FUNC?
(0000005C

Don't know what that mean at all.
Not used.

Also I have few questions.

Seems like that UPS is able to report estimated runtime (ERT) and battery charge level (BL). Currently my PR reports ERT for NUT but dismisses BL. I wonder if it's safe to report both of ERT+BL or end user should use runtimecal or magic with battery.voltage vars. Or is there some settings which allow to use guesstimated/calculated runtimes/levels or reported ones?
As far as I understood this UPS answers info for request commands and ACKs for existing instcmds while NAK for forbidden ones. I may be completely wrong about that and more testing is needed. However, I've tried sending some instcmds (only tests, though) and it worked fine.
I'm not sure what TESTING table does. I've filled it with some strings that I knew but I can't test this structure by myself. Any help is appreciated!

AppVeyorBot · 2024-12-06T18:20:23Z

❌ Build nut 2.8.2.2498-master failed (commit 9495a68c7c by @dvdesolve)

dvdesolve · 2024-12-06T18:41:40Z

seems like CI failed because of aspell check. how and what should I add to the dictionary exclusion list?

jimklimov · 2024-12-06T18:58:59Z

Thanks, by Q in queries and parentheses in ASCII numbered answers, this indeed seems like a Megatec Qx variant.

For spell checker update, make spellcheck-interactive should help (prints an instruction in the end).

dvdesolve · 2024-12-06T19:29:37Z

Yes, this UPS speaks Q* variant of protocol. It also answers back to the Q1 and some other requests (such as Q2, Q4 and so on).
BTW, that may be useful for further development of Qx driver. The page is in Russian but the table is self-explaining

Also I would like to say that I've faced some kind of troubles during writing this protocol dialect. In ups.conf there is directive subdriver while in nutdrv_qx.c there is subdrivers_list array. At first I've thought that these two entities are the same but then realized that subdrivers_list corresponds to the protocol directive in ups.conf. May be it would be useful to mention such nuance in documentation...

AppVeyorBot · 2024-12-06T20:10:38Z

✅ Build nut 2.8.2.2500-master completed (commit b59ed04781 by @dvdesolve)

Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov · 2024-12-08T14:48:54Z

@dvdesolve : Do you know if "that" documentation can be absorbed back into NUT protocol library, maybe "as is" for international reference or translated to English for another sort of international reference? :)

Is that (especially the smaller chapters for other devices) based on NUT docs (so there is no value adding it back) or independent research and bringing in new information?

dvdesolve · 2024-12-08T15:01:38Z

According to the author of that webpage and software information about communication protocols was collected by googling, usb and com sniffing, firmware decompiling etc

BTW I can help with translation if you want, it's not too hard

jimklimov · 2024-12-08T15:05:16Z

Thanks for the offer, that would be most welcome. The first step should be about checking if documents at https://networkupstools.org/ups-protocols.html, aka https://github.com/networkupstools/nut-website/tree/master/protocols in source form, already contain all of that information, or if there is something new to add.

…arify that "subdriver" is for Serial-over-USB dialect, and "protocol" is for Qx dialect [networkupstools#2712] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…1 subdriver [networkupstools#2712] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

dvdesolve · 2024-12-08T15:07:39Z

should that translation/addition be in the same PR or may be I can do it via next PR?

jimklimov · 2024-12-08T15:08:49Z

Another PR (if deemed needed) - separate repo anyway :)

jimklimov · 2024-12-08T15:12:37Z

I've updated the PR with a bit of documentation change, including the inherited mess about "subdriver" terminology in Qx codebase, so be careful about not force-pushing any changes but rebasing on top of what is in your fork first.

Your devices only have the serial port, right? There is no chance/need of adding static qx_usb_device_id_t qx_usb_id[] = {...} entries for these UPSes at the moment?

jimklimov · 2024-12-08T15:15:33Z

Also, just in case - do you know the actual OEM and/or vendor of your devices? Quick googling for "Innova RT" showed hits for PhoenixTec, Eaton and Ippon, just on the first page...

dvdesolve · 2024-12-08T17:42:21Z

Another PR (if deemed needed) - separate repo anyway :)

oh, that's me being inattentive - haven't noticed that your link refers to the webpage rather than source code

Your devices only have the serial port, right? There is no chance/need of adding static qx_usb_device_id_t qx_usb_id[] = {...} entries for these UPSes at the moment?

These big UPSes have both DB9 connector and USB port on the rear panel but it seems like internally they're just the same thing (I've found some evidences during extensive googling) and USB is not HID device - just a serial-to-com adapter inside UPS. Also cypress USB subdriver seems to be auto-detected option although it is named something like PhoenixTec in lsusb output

Also, just in case - do you know the actual OEM and/or vendor of your devices? Quick googling for "Innova RT" showed hits for PhoenixTec, Eaton and Ippon, just on the first page...

We bought Ippon model explicitly, I didn't even know that Eaton and so on can be a vendor for Innova RT 3/1 20K

dvdesolve · 2024-12-08T17:47:32Z

I've updated the PR with a bit of documentation change, including the inherited mess about "subdriver" terminology in Qx codebase, so be careful about not force-pushing any changes but rebasing on top of what is in your fork first.

Can you please advise me what I should to do? I have little experience with collaborative work and PRs so I don't want to break something by accident

dvdesolve · 2024-12-08T19:37:31Z

Thanks for the offer, that would be most welcome. The first step should be about checking if documents at https://networkupstools.org/ups-protocols.html, aka https://github.com/networkupstools/nut-website/tree/master/protocols in source form, already contain all of that information, or if there is something new to add.

I'll try to do it in short time, may be even on a next week

dvdesolve · 2024-12-09T03:02:41Z

btw, what about battery.charge and battery.runtime metrics? is it safe for the subdriver to report these values (because UPS does) or user should rely on runtime calibration and/or battery voltage measurements?

jimklimov · 2024-12-09T04:06:30Z

btw, what about battery.charge and battery.runtime metrics? is it safe for the subdriver to report these values (because UPS does) or user should rely on runtime calibration and/or battery voltage measurements?

If the UPS provides them, these are preferred over software "guesstimates".

I've updated the PR with a bit of documentation change, including the inherited mess about "subdriver" terminology in Qx codebase, so be careful about not force-pushing any changes but rebasing on top of what is in your fork first.

Can you please advise me what I should to do? I have little experience with collaborative work and PRs so I don't want to break something by accident

In your local repository workspace, run git fetch --all && git rebase origin/innova_rt_31 (assuming the workspace knows your github fork as origin). This should make your local branch same as the current PR source, or if you had any committed changes - it would "rebase" them on top of the PR source, as if you coded them later (starting from the PR codebase).

jimklimov · 2024-12-09T04:14:21Z

These big UPSes have both DB9 connector and USB port on the rear panel but it seems like internally they're just the same thing (I've found some evidences during extensive googling) and USB is not HID device - just a serial-to-com adapter inside UPS. Also cypress USB subdriver seems to be auto-detected option although it is named something like PhoenixTec in lsusb output

Yes, this is typically the case with QX devices. My changes to the documentation point to some C methods and lists involved in USB support, whether it would suffice to reuse an existing USB subdriver (per ups.conf option name) or if you'd need to write a custom one. So if you have a chance to make these devices supported also with USB cabling - that would be welcome. Maybe as a later PR though.

jimklimov · 2024-12-09T04:19:49Z

CC @arnaudquette-eaton : do you know if different "Innova RT" models from different vendors come from same OEM, or are they completely unrelated? Eaton and Phoenixtec seem to be together, e.g. https://www.eaton.com/content/dam/phoenixtec/brochure/online-ups/innova-rt/INNOVA_RT%20.pdf URL and content implies that, not sure about Ippon...

Practical aspect: should this new driver stress it is for "Ippon Innova RT 3/1" or it should fit other Innova's too?

dvdesolve · 2024-12-09T04:40:31Z

I should say that RE was conducted via RS232 sniffing and then I seamlessly moved to the USB connection. Auto detect lead to the cypress subdriver and it just worked well without any issues, so right now I have this UPS connected via USB-B cable

Also I think that 3/3 models should work in the same fashion - we just need to report output.Lx-N.voltage and input.bypass.Lx-n.voltage together with output.phases = 3. Model version signaling should make this decision automatic, bit I don't have enough hardware at hand to test it

Moreover, as for now I've decided to use light versions of Blazer init and claim functions because I'm not sure if FW? request returns consistent data. If it does, then full init and claim may be possible including vendor and rating info request. Also because these UPSes are of three phase we may check for support for Q6 or similar requests as well. What do you think?

The main problem is that I only have a bunch of identical Innovas which are all just a copy of each other. I can't test on similar equipment with different ratings or in-to-out topologies

dvdesolve · 2024-12-09T14:11:04Z

CC @arnaudquette-eaton : do you know if different "Innova RT" models from different vendors come from same OEM, or are they completely unrelated? Eaton and Phoenixtec seem to be together, e.g. https://www.eaton.com/content/dam/phoenixtec/brochure/online-ups/innova-rt/INNOVA_RT%20.pdf URL and content implies that, not sure about Ippon...

Practical aspect: should this new driver stress it is for "Ippon Innova RT 3/1" or it should fit other Innova's too?

According to your link there are models ranging from 1 kVA to 10 kVA. Ippon has 10k, 20k and 10k compact versions only. So, Ippon's UPSes should be different from Eaton/Phoenixtec ones.

dvdesolve · 2024-12-09T14:13:59Z

In this case it may suffice to add a line to qx_usb_id[] array then, with your devices' USB VID/PID and maybe strings, if there isn't already an entry that would point these VID/PID numbers to cypress.

From lsusb I get the following:

Bus 001 Device 006: ID 06da:0004 Phoenixtec Power Co., Ltd USB UPS

Grepping in drivers source tree reveals that this VID/PID pair is referred to as Phoenixtec while cypress is used as USB subdriver:

./blazer_usb.c:399:	{ USB_DEVICE(0x06da, 0x0004), &cypress_subdriver },	/* Phoenixtec Innova 3/1 T */
./nutdrv_qx.c:2252:	{ USB_DEVICE(0x06da, 0x0004),	NULL,		NULL,			&cypress_subdriver },	/* Phoenixtec Innova 3/1 T */

jimklimov · 2024-12-09T14:31:42Z

Cool, thanks for checking! So it seems the devices are related after all. Maybe that Eaton PDF was older, or limited to the smaller line-up. Ippon photos looked roughly reminiscent of Eaton Powerware 9395 or some such, but the photos I found now are not that similar, except that both are whole-rack-sized UPSes :)

…ecognized by hardware). Added firmware version and serial number of UPS. Reorganized readings to minimize data between host and UPS according to the developer docs. Added known input, output and bypass readings as comments for future development (3/3 versions). Signed-off-by: Viktor Drobot <linux776@gmail.com>

Signed-off-by: Viktor Drobot <linux776@gmail.com>

dvdesolve · 2024-12-10T14:09:08Z

Hmm, something strange happens when queries to the UPS are minimized. Now I can't even initialize driver:

0.517151	Using protocol: INNOVART31 0.01
   0.517302	[D1] upsdrv_initinfo...
   0.519688	[D3] send: Q6
   0.997008	[D3] read: (229.1 228.6 232.3 49.9 229.9 000.0 000.0 50.0 000 000 000 327.7 000.0 17.5 50000 091 30 00000000 00000000 11
   0.998801	[D3] send: WA
   1.357057	[D3] read: (000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000 00000000
   1.359795	[D3] send: BPS
   1.501065	[D3] read: 
   1.501108	[D2] qx_process_answer: input.bypass.voltage - invalid start character [00], expected [28]
   1.502812	[D3] send: BPS
   1.645157	[D3] read: 
   1.645212	[D2] qx_process_answer: input.bypass.frequency - invalid start character [00], expected [28]
   1.647835	[D3] send: F
   1.757103	[D3] read: 
   1.757152	[D2] qx_process_answer: input.voltage.nominal - invalid start character [00], expected [23]
   1.758850	[D3] send: F
   1.877118	[D3] read: 
   1.877158	[D2] qx_process_answer: input.current.nominal - invalid start character [00], expected [23]
   1.879867	[D3] send: F
   1.997132	[D3] read: 
   1.997171	[D2] qx_process_answer: input.frequency.nominal - invalid start character [00], expected [23]
   1.998877	[D3] send: Q1
   2.221164	[D3] read: 
   2.221209	[D2] qx_process_answer: ups.status - invalid start character [00], expected [28]
   2.221232	Can't initialise data from the UPS
   2.221266	[D1] upsdrv_cleanup...

There was no such a problem when requests were placed in logical groups rather than minimizing ones

PS: now I've moved bypass readings before WA and the situation is different:

0.512158	Using protocol: INNOVART31 0.01
   0.512319	[D1] upsdrv_initinfo...
   0.514626	[D3] send: Q6
   0.991941	[D3] read: (226.8 226.8 231.4 50.0 229.9 000.0 000.0 49.9 000 000 000 327.7 000.0 18.5 50000 093 30 00000000 00000000 11
   0.993683	[D3] send: BPS
   1.135955	[D3] read: (230.6 000.0 000.0 49.9
   1.138702	[D3] send: WA
   1.513442	[D3] read: 
   1.513595	[D2] qx_process_answer: output.current - invalid start character [00], expected [28]
   1.515766	[D3] send: WA
   1.872054	[D3] read: 
   1.872197	[D2] qx_process_answer: ups.realpower - invalid start character [00], expected [28]
   1.874802	[D3] send: WA
   2.232106	[D3] read: 
   2.232241	[D2] qx_process_answer: ups.power - invalid start character [00], expected [28]
   2.233851	[D3] send: F
   2.344120	[D3] read: #230.0 087 288.0 50.0
   2.346868	[D3] send: Q1
   2.568150	[D3] read: 
   2.568203	[D2] qx_process_answer: ups.status - invalid start character [00], expected [28]
   2.568229	Can't initialise data from the UPS
   2.568265	[D1] upsdrv_cleanup...

PS2: even with original order it seems like answers will or will not come at random:

0.508054	Using protocol: INNOVART31 0.01
   0.508128	[D1] upsdrv_initinfo...
   0.510564	[D3] send: Q6
   1.004020	[D3] read: (227.9 227.0 232.8 50.0 230.1 000.0 000.0 50.0 000 000 000 327.7 000.0 17.4 50000 096 30 00000000 00000000 11
   1.005636	[D3] send: BPS
   1.148026	[D3] read: (231.3 000.0 000.0 49.9
   1.150650	[D3] send: Q6
   1.644097	[D3] read: 
   1.644155	[D2] qx_process_answer: output.voltage - invalid start character [00], expected [28]
   1.645719	[D3] send: WA
   2.004144	[D3] read: (000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000 00000000
   2.006764	[D3] send: Q6
   2.484221	[D3] read: 
   2.484261	[D2] qx_process_answer: output.frequency - invalid start character [00], expected [28]
   2.485298	[D3] send: Q6
   2.964282	[D3] read: (228.4 227.0 232.8 50.0 229.9 000.0 000.0 50.0 000 000 000 327.6 000.0 17.4 50000 096 30 00000000 00000000 11
   2.966028	[D3] send: WA
   3.324324	[D3] read: (000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000 00000000
   3.327071	[D3] send: Q6
   3.804389	[D3] read: 
   3.804446	[D2] qx_process_answer: ups.temperature - invalid start character [00], expected [28]
   3.806137	[D3] send: Q6
   4.284456	[D3] read: (227.3 226.6 231.9 49.9 230.1 000.0 000.0 50.0 000 000 000 327.7 000.0 17.4 50000 096 30 00000000 00000000 11
   4.287202	[D3] send: Q1
   4.508479	[D3] read: (228.4 228.4 229.9 000 50.0 2.27 17.4 00000000
   4.510235	[D3] send: F
   4.620504	[D3] read: #230.0 087 288.0 50.0
   4.620788	[D1] upsdrv_updateinfo...
   4.620816	[D1] Quick update...
   4.623253	[D3] send: Q1
   4.844526	[D3] read: 
   4.844572	[D2] qx_process_answer: ups.status - invalid start character [00], expected [28]
   4.844597	[D1] Communications with the UPS lost: status read failed!
   4.844855	[D2] dstate_init: sock /var/lib/nut/nutdrv_qx-ippon open on fd 9
   4.844909	Running as foreground process, not saving a PID file
   4.844964	[D1] Driver initialization completed, beginning regular infinite loop
   4.844992	upsnotify: notify about state NOTIFY_STATE_READY_WITH_PID with libsystemd: was requested, but not running as a service unit now, will not spam more about it
   4.845023	[D1] On systems without service units, consider `export NUT_QUIET_INIT_UPSNOTIFY=true`
   4.845044	upsnotify: failed to notify about state NOTIFY_STATE_READY_WITH_PID: no notification tech defined, will not spam more about it
   4.845073	upsnotify: logged the systemd watchdog situation once, will not spam more about it
   4.845101	[D1] upsdrv_updateinfo...
   4.845125	[D1] Quick update...
   4.846287	[D3] send: Q1
   5.068558	[D3] read: (228.8 228.8 229.9 000 50.0 2.27 17.4 00000000

Maybe timings between requests can produce such behavior...

PS3: tried with serial-to-usb converter, got the following results:

0.113577	[D3] send: 'Q6'
   0.152894	[D3] read: 'NAK'
   0.152933	[D2] qx_process_answer: query rejected by the UPS (input.voltage)
   0.153062	[D3] send: 'Q6'
   0.634915	[D3] read: '(227.3 226.6 229.8 50.0 229.9 000.0 000.0 50.0 000 000 000 327.7 000.0 18.0 50000 100 30 00000000 00000000 11'
   0.635011	Using protocol: INNOVART31 0.01
   0.635107	[D1] upsdrv_initinfo...
   0.635284	[D3] send: 'Q6'
   1.115263	[D3] read: '(227.3 226.6 230.0 50.0 229.9 000.0 000.0 50.0 000 000 000 327.7 000.0 18.0 50000 100 30 00000000 00000000 11'
   1.115884	[D3] send: 'BPS'
   1.237346	[D3] read: '(229.0 000.0 000.0 50.0'
   1.237823	[D3] send: 'Q6'
   1.716046	[D3] read: '(226.1 225.9 229.8 50.0 229.9 000.0 000.0 50.0 000 000 000 327.6 000.0 18.0 50000 100 30 00000000 00000000 11'
   1.716628	[D3] send: 'WA'
   2.071404	[D3] read: '(000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000 00000000'
   2.071924	[D3] send: 'Q6'
   2.556786	[D3] read: '(226.4 225.6 229.6 49.9 229.9 000.0 000.0 50.0 000 000 000 327.7 000.0 18.0 50000 100 30 00000000 00000000 11'
   2.557175	[D3] send: 'WA'
   2.912152	[D3] read: '(000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000.0 000 00000000'
   2.912741	[D3] send: 'Q6'
   3.397550	[D3] read: '(227.5 226.8 230.0 50.0 230.1 000.0 000.0 50.0 000 000 000 327.6 000.0 18.0 50000 100 30 00000000 00000000 11'
   3.398084	[D3] send: 'Q1'
   3.615419	[D3] read: '(227.3 227.3 230.1 000 50.0 2.27 18.0 00000000'
   3.615887	[D3] send: 'F'
   3.731232	[D3] read: '#230.0 087 288.0 50.0'
   3.731716	[D1] upsdrv_updateinfo...
   3.731745	[D1] Quick update...
   3.732022	[D3] send: 'Q1'
   3.955369	[D3] read: '(228.4 228.4 229.9 000 50.0 2.27 18.0 00000000'
   3.955937	[D2] dstate_init: sock /var/lib/nut/nutdrv_qx-ippon open on fd 5
   3.956432	Running as foreground process, not saving a PID file

So it works much better than using direct USB connection. But first Q6 request fails anyway.

dvdesolve · 2024-12-10T15:11:33Z

OK, to summarize my previous message. Internal implementation of USB in this UPS is buggy - answers depend on the order of requests, different readings fail on random causes. Using RS232->USB converter:

Bus 001 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Phone Data Cable

resolves such problems (so, nutdrv_qx uses serial mode instead of USB). However, sometimes the very first Q6 request to the UPS (in initups function) also fails - may be because of some characters being in a buffer (~~can we flush it by sending \r first?~~ MAXTRIES should help to avoid glitches at cold start, though).

I think there's nothing more to do here because all critical parameters and commands are working fine at least with serial communication line. At least now we can read all info that official WinPower software provides. Glitches with USB are related to the specific integrated converter, I think

Signed-off-by: Viktor Drobot <linux776@gmail.com>

Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

…2712] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov · 2024-12-12T17:01:35Z

@dvdesolve : would you please post a data dump from a recent build for the DDL collection?

dvdesolve · 2024-12-13T06:37:00Z

Ippon__Innova_RT_3_1_20K__nutdrv_qx2.8.2.101.dev

# Please add if relevant: DEVICE:URL:REPORT: <GitHub issue/PR or Mailing list archive entry URL>
# Please add if relevant: DEVICE:URL:VENDOR: <Vendor/Manufacturer/Product page URL>

# Please add comments for humans here and perhaps raise concerns about the data points,
# see https://networkupstools.org/ddl/#devseq-files for comment-tag syntax
# strip sensitive data (passwords, SNMP community, serial number, IP address, host name...)
# and post as a pull request to https://github.com/networkupstools/nut-ddl/
# DEVICE:COMMENT:
# Device dump generated by ./nut-ddl-dump.sh on Fri, 13 Dec 2024 09:34:34 +0300
# DEVICE:EOC

# :; upsc ippon
battery.charge: 100
battery.charge.low: 20
battery.runtime: 50000
battery.voltage: 327.7
battery.voltage.high: 326.4
battery.voltage.low: 249.6
battery.voltage.nominal: 288
device.serial: N05K10KB100004
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: nutdrv_qx
driver.parameter.chargetime: 18000
driver.parameter.default.battery.voltage.high: 326.4
driver.parameter.default.battery.voltage.low: 249.6
driver.parameter.override.battery.charge.low: 20
driver.parameter.override.battery.voltage.nominal: 288
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyUSB0
driver.parameter.protocol: innovart31
driver.parameter.synchronous: auto
driver.state: updateinfo
driver.version: 2.8.2.1
driver.version.data: INNOVART31 0.01
driver.version.internal: 0.39
driver.version.usb: libusb-1.0.27 (API: 0x100010a)
input.bypass.frequency: 50.0
input.bypass.phases: 1
input.bypass.voltage: 232.0
input.current.nominal: 87.0
input.frequency: 50.0
input.frequency.nominal: 50
input.L1-N.voltage: 229.9
input.L2-N.voltage: 225.6
input.L3-N.voltage: 233.2
input.phases: 3
input.voltage: 229.9
input.voltage.nominal: 230
output.current: 0.0
output.frequency: 50.0
output.phases: 1
output.voltage: 230.1
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: 05516-1100
ups.load: 0
ups.power: 0.00
ups.realpower: 0.00
ups.serial: N05K10KB100004
ups.status: OL
ups.temperature: 18.8
ups.type: online

# DEVICE:COMMENT-BLOCK:FIXME:UPSRW: ippon
# [driver.debug]
# Current debug verbosity level of the driver program
# Type: NUMBER
# Value: 0
#
# [driver.flag.allow_killpower]
# Safety flip-switch to allow the driver daemon to send UPS shutdown command (accessible via driver.killpower)
# Type: NUMBER
# Value: 0
#
# [ups.delay.shutdown]
# Interval to wait after shutdown with delay command (seconds)
# Type: RANGE NUMBER
# Option: "12-600" SELECTED
#
# [ups.delay.start]
# Interval to wait before (re)starting the load (seconds)
# Type: RANGE NUMBER
# Option: "0-599940" SELECTED
# DEVICE:EOC

# DEVICE:COMMENT-BLOCK:FIXME:UPSCMD: ippon
# Instant commands supported on UPS [ippon]:
#
# driver.killpower - Tell the driver daemon to initiate UPS shutdown; should be unlocked with driver.flag.allow_killpower option or variable setting
# driver.reload - Reload running driver configuration from the file system (only works for changes in some options)
# driver.reload-or-error - Reload running driver configuration from the file system (only works for changes in some options); return an error if something changed and could not be applied live (so the caller can restart it with new options)
# driver.reload-or-exit - Reload running driver configuration from the file system (only works for changes in some options); exit the running driver if something changed and could not be applied live (so service management framework can restart it with new options)
# load.off - Turn off the load immediately
# load.on - Turn on the load immediately
# shutdown.default - Run the driver-defined UPS shutdown sequence (as opposed to user-configured 'sdcommands')
# shutdown.return - Turn off the load and return when power is back
# shutdown.stayoff - Turn off the load and remain off
# shutdown.stop - Stop a shutdown in progress
# test.battery.start - Start a battery test
# test.battery.start.deep - Start a deep battery test
# test.battery.start.quick - Start a quick battery test
# test.battery.stop - Stop the battery test
# DEVICE:EOC

dvdesolve · 2024-12-13T06:39:24Z

A bit offtopic: I want to add that I've tested Ippon Back Basic 650, 850, 1500 and 2200 (both Euro and IEC versions) with nutdrv_qx driver and all of them are working fine. I think that info can be added to the HCL

jimklimov · 2024-12-13T08:22:16Z

Thanks for the info! If you've got those data dumps, feel free to post them too (maybe in a separate ticket to keep things tidy).

dvdesolve · 2024-12-13T09:16:59Z

Thanks for the info! If you've got those data dumps, feel free to post them too (maybe in a separate ticket to keep things tidy).

Done in #2720

dvdesolve · 2024-12-17T08:31:50Z

Thanks for the offer, that would be most welcome. The first step should be about checking if documents at https://networkupstools.org/ups-protocols.html, aka https://github.com/networkupstools/nut-website/tree/master/protocols in source form, already contain all of that information, or if there is something new to add.

I'll try to do it in short time, may be even on a next week

Done in networkupstools/nut-website#58

…T 3/1 driver development [networkupstools#58] * networkupstools#58 * networkupstools/nut#2712 Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

shangjiaxuan · 2024-12-23T07:09:34Z

I recently acquired a piece of documentation from a SANTAK reseller on their product using Q6 query. I hope this helps to understand the Q6 query.

#1395 (comment)

dvdesolve · 2024-12-24T04:55:47Z

Thank you a lot for your PDF! I was able to translate almost all of its contents and it looks like our guesses about three phase measurements were right! I'll try to prepare human-readable description soon - there are some interesting details about service flags etc and I think we should discuss them and may be even try to implement common Q6 driver, not only for Ippon Innova RT 3/1

dvdesolve and others added 2 commits December 6, 2024 16:19

First attempt to add support for Innova RT 3/1

f8eecc6

Merge branch 'master' into innova_rt_31

70b6ba3

Fix aspell complaining about InnovaRT

eb4779d

Merge branch 'master' into innova_rt_31

a53f8a5

jimklimov added the Qx protocol driver Driver based on Megatec Q<number> such as new nutdrv_qx, or obsoleted blazer and some others label Dec 8, 2024

jimklimov added this to the 2.8.3 milestone Dec 8, 2024

NEWS.adoc: introduced innovart31 in nutdrv_qx [networkupstools#2712]

a6194db

Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov added 2 commits December 8, 2024 16:06

docs/nutdrv_qx-subdrivers.txt, drivers/nutdrv_qx.c, docs/nut.dict: cl…

03dfd92

…arify that "subdriver" is for Serial-over-USB dialect, and "protocol" is for Qx dialect [networkupstools#2712] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

drivers/nutdrv_qx.c: bump DRIVER_VERSION due to addition of innovart3…

1077726

…1 subdriver [networkupstools#2712] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov added the WinPower Some devices are shipped with WinPower as their vendor's companion software label Dec 8, 2024

Use battery runtime and charge data from UPS

5f0cef5

dvdesolve added 3 commits December 10, 2024 16:03

Firmware reading leads to the driver stale state

53c562a

Signed-off-by: Viktor Drobot <linux776@gmail.com>

Giving up on reading firmware and serial number data from UPS

150f3dc

Signed-off-by: Viktor Drobot <linux776@gmail.com>

dvdesolve and others added 3 commits December 10, 2024 18:30

We can use full Blazer claiming and initialization routines now

c665f42

Signed-off-by: Viktor Drobot <linux776@gmail.com>

Merge remote-tracking branch 'upstream/master' into innova_rt_31

a09f472

Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

data/driver.list.in: add Ippon Innova RT 3/1 models [networkupstools#…

242e46a

…2712] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>

jimklimov changed the title ~~First attempt to add support for Innova RT 3/1~~ First attempt to add support for Ippon Innova RT 3/1 Dec 12, 2024

jimklimov added the Ippon Ippon branded devices label Dec 12, 2024

jimklimov added HCL DDL labels Dec 13, 2024

jimklimov merged commit 3928f04 into networkupstools:master Dec 14, 2024
30 checks passed

This was referenced Dec 17, 2024

protocols/megatec.txt: "Additional information from 21st century" networkupstools/nut-website#59

Merged

Cannot setup battery.charge and temperature sensor for Green Cell PowerProof 2000VA UPS05 #2727

Open

dvdesolve mentioned this pull request Dec 24, 2024

Request for generic Q2/Q6 protocol variants #2737

Open

dvdesolve deleted the innova_rt_31 branch December 31, 2024 18:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First attempt to add support for Ippon Innova RT 3/1 #2712

First attempt to add support for Ippon Innova RT 3/1 #2712

dvdesolve commented Dec 6, 2024

AppVeyorBot commented Dec 6, 2024

dvdesolve commented Dec 6, 2024

jimklimov commented Dec 6, 2024

dvdesolve commented Dec 6, 2024

AppVeyorBot commented Dec 6, 2024

jimklimov commented Dec 8, 2024

dvdesolve commented Dec 8, 2024

jimklimov commented Dec 8, 2024

dvdesolve commented Dec 8, 2024

jimklimov commented Dec 8, 2024

jimklimov commented Dec 8, 2024

jimklimov commented Dec 8, 2024 •

edited

Loading

dvdesolve commented Dec 8, 2024

dvdesolve commented Dec 8, 2024

dvdesolve commented Dec 8, 2024

dvdesolve commented Dec 9, 2024

jimklimov commented Dec 9, 2024 •

edited

Loading

jimklimov commented Dec 9, 2024

jimklimov commented Dec 9, 2024

dvdesolve commented Dec 9, 2024

dvdesolve commented Dec 9, 2024

dvdesolve commented Dec 9, 2024

jimklimov commented Dec 9, 2024

dvdesolve commented Dec 10, 2024 •

edited

Loading

dvdesolve commented Dec 10, 2024 •

edited

Loading

jimklimov commented Dec 12, 2024

dvdesolve commented Dec 13, 2024 •

edited

Loading

dvdesolve commented Dec 13, 2024

jimklimov commented Dec 13, 2024

dvdesolve commented Dec 13, 2024

dvdesolve commented Dec 17, 2024

shangjiaxuan commented Dec 23, 2024

dvdesolve commented Dec 24, 2024 •

edited

Loading

First attempt to add support for Ippon Innova RT 3/1 #2712

First attempt to add support for Ippon Innova RT 3/1 #2712

Conversation

dvdesolve commented Dec 6, 2024

Serial number

Ping

Model (+specs)

Load stats

Bypass stats

Common stats

Temperature reading

Battery level

Bypass limits

Ratings

ECO mode acceptable frequency range

ECO mode acceptable voltage range

Firmware version

Unknown function request

AppVeyorBot commented Dec 6, 2024

dvdesolve commented Dec 6, 2024

jimklimov commented Dec 6, 2024

dvdesolve commented Dec 6, 2024

AppVeyorBot commented Dec 6, 2024

jimklimov commented Dec 8, 2024

dvdesolve commented Dec 8, 2024

jimklimov commented Dec 8, 2024

dvdesolve commented Dec 8, 2024

jimklimov commented Dec 8, 2024

jimklimov commented Dec 8, 2024

jimklimov commented Dec 8, 2024 • edited Loading

dvdesolve commented Dec 8, 2024

dvdesolve commented Dec 8, 2024

dvdesolve commented Dec 8, 2024

dvdesolve commented Dec 9, 2024

jimklimov commented Dec 9, 2024 • edited Loading

jimklimov commented Dec 9, 2024

jimklimov commented Dec 9, 2024

dvdesolve commented Dec 9, 2024

dvdesolve commented Dec 9, 2024

dvdesolve commented Dec 9, 2024

jimklimov commented Dec 9, 2024

dvdesolve commented Dec 10, 2024 • edited Loading

dvdesolve commented Dec 10, 2024 • edited Loading

jimklimov commented Dec 12, 2024

dvdesolve commented Dec 13, 2024 • edited Loading

Ippon__Innova_RT_3_1_20K__nutdrv_qx__2.8.2.1__01.dev

dvdesolve commented Dec 13, 2024

jimklimov commented Dec 13, 2024

dvdesolve commented Dec 13, 2024

dvdesolve commented Dec 17, 2024

shangjiaxuan commented Dec 23, 2024

dvdesolve commented Dec 24, 2024 • edited Loading

jimklimov commented Dec 8, 2024 •

edited

Loading

jimklimov commented Dec 9, 2024 •

edited

Loading

dvdesolve commented Dec 10, 2024 •

edited

Loading

dvdesolve commented Dec 10, 2024 •

edited

Loading

dvdesolve commented Dec 13, 2024 •

edited

Loading

Ippon__Innova_RT_3_1_20K__nutdrv_qx2.8.2.101.dev

dvdesolve commented Dec 24, 2024 •

edited

Loading