Energenie 1202 works, but fails to read ups.load%

[K1m0n]

Hi. I got myself an energenie (gembird) ups. model#: UPS-PC-1202AP see-> https://energenie.com/item.aspx?id=4781&lang=en

Identifies itself as 0001/0000, like:

kernel: ugen1.3: <vendor 0x0001 product 0x0000> at usbus1

It looks like one of the many rebranded units based on East EA200 platform, see -> https://energenie.com/item.aspx?id=4781&lang=en Comes with UPSmart, connects with the "mega-usb" option, so megatec-based.

Other similar units should be the various DEXP/SNR/HUNNOX/Crown units based on EA200.

I got a config, that sort-of works with nut v2022.12.20:

------------------------------------
driver=nutdrv_qx
vendorid=0001
productid=0000
langid_fix=0x409
protocol=megatec # or "hunnox"
subdriver=hunnox # or "snr"
novendor
noscanlangid
runtimecal=180,100,540,50 #approximate numbers for 1202
------------------------------------

Basic comms (batt.voltages/bat.charge/OL) ok. It detects/comunicates power-down state, so the load atached (xigmanas) can shut-down. I say sort-of, because nutdrv_qx fails to read ups.load %. I tried blazer_usb, it succesfully reads ups.load for a few seconds, then no-reading.

So... 2 things:

1) Could someone update the hcl with a relevant entry for 1202? The minimal config could be:

port=auto
driver=nutdrv_qx
langid_fix=0x409

2) If the nice devs of nutdrv_qx are interested, and in the spitit of improving nutdrv_qx (and maybe succesfully reading ups.load, so one could estimate runtime...), I could provide a debug log of nutdrv_qx vs blazer_usb (which initialy detects ups.load%), and/or I suppose I could capture the comm ups<->host using upsmart on windows or in bsd/linux, if given some instructions.

The unfortunate thing is that given that xigmanas is an embeded nas distro, no compilation is possible, and updating/testing binaries can be an issue.

Thanks :)

[jimklimov]

Regarding test builds of NUT, I hope a FreeBSD installation can yield results "close enough" to what you would get on the matching XigmaNAS. Alternately, you could investigate their (open, right?) build system to roll a custom firmware or ISO with updated NUT injected...

Perhaps building in a FreeBSD VM, in a directory shared over NFS from the NAS, would get the workspace with binaries visible to the NAS OS, and so testable in-place (to run a custom driver and see how it behaves, etc.)

That said, I haven't dealt with that platform so far, and have little idea which NUT version they could have packaged as "nut v2022.12.20" (and e.g. how it differs from "vanilla NUT"). The little one I have is to find something like https://sourceforge.net/p/xigmanas/code/HEAD/tree/trunk/build/ports/nut-devel/ to look at ;)

[jimklimov]

So yours currently is https://sourceforge.net/p/xigmanas/code/9453/tree/trunk/build/ports/nut-devel/Makefile => https://github.com/networkupstools/nut/tree/95fd0fc5f2274e8575caae5eb8d2b52c5acf5c5f (per GH_TAGNAME = 95fd0fc5f)

That should be fairly fresh, and I'm impressed by their cadence of updates - respect and kudos to @zoon01 :)

[K1m0n]

According to zoon (https://www.xigmanas.com/forums/viewtopic.php?t=954), they switched to head so I suupose they just include a recent snapshot from head. Other than that I myself have limited knowledge of the innerworkings of the platform. I know its FreeBSD 13.1p5 + some minimal tools + a php gui, it boots from external media and runs from ram. Its the continuation of the original freenas. I could setup a freebsd vm for tests if needed, building my own image, well... that could be chalenging.

[jimklimov]

Back to the UPS question: a debug log of those driver start-ups sounds like it could help figure out where they differ. Also a confirmation that UPSmart does report the realistic load would be good :)

Also it could help to check all the subdrivers defined for each driver, possibly finding one that works better for this device - some of them talk/expect certain protocol dialects, others may have different mapping tables (more or less entries) between NUT datapoints and device commands. For example, sources say several subdrivers can match these unregistered VID:PID combos: https://github.com/networkupstools/nut/blob/95fd0fc5f2274e8575caae5eb8d2b52c5acf5c5f/drivers/nutdrv_qx.c#L1984-L1988

It might be possible that whoever wrote a particular subdriver did not add a mapping (maybe their device did not report the value)... It seems hunnox does have a query for it however (so maybe it is somehow wrong for the dialect your device actually talks): https://github.com/networkupstools/nut/blob/95fd0fc5f2274e8575caae5eb8d2b52c5acf5c5f/drivers/nutdrv_qx_hunnox.c#L44

If some subdriver, say hunnox, proves to best support the device and only lacks the ups.load in the reports (and others lack more or do not connect at all), and yet some other subdriver can query the ups.load, then possibly a solution could be to copy a line from that other subdriver into the "hunnox" mapping table. Not sure quickly if QX drivers can do it, but many others (usbhid, snmp) support having many mappings for same data point and use them in order until the first success (or possibly until the last success in some drivers).

Note there is also a PR #1652 stuck in reviews, which might change behaviors (or misbehave) here, for detection of voltages and runtimes that your device seems to serve (or the driver guesses too from other data, and then the logic might be impacted by that PR).

Check the docs about "runtimecal" - it is something normally tuned for each environment with its UPS power and load's draw, after experimental timing of the UPS with different loads. Sample values may be a randomly suitable first approximation, and their usefulness does depend on knowing the load :)

[K1m0n]

About the possible subdrivers: I think I tried the most probable combinations: auto (driver did it's magic, picked megatec protocol) protocol megatec + hunnox subdriver protocol hunnox + hunnox subdriver protocol megatec + snr subdriver protocol megatec + krauler subdriver All those are usable, more-or-less correctly report status/batt./voltages in-out, all fail to read ups.load.

• various other combinations that failed to start

About the values of UPSmart: Well... I'll be damned, on closer exam, UPSmart also fails to reliably read load%. Reads for some seconds, stops for a minute, re-reads for some seconds, then stops completely. When I initialy checked I just glanced that value was there... When it does, its ballpark correct, and inline with what blazer_usb initially reports. The rest of the values seem ok and agree between upsmart/blazer_usb/nutdrv_qx. Maybe the ups just stops sending the load%

I will upload debug logs for cross-reference later.

As for the runtime cal., I don't really need it, this unit is for soho use, since it can report power-down reliably and the nas can shutdown itself, its all ok. I don't have high expectations from a 1200va unit that is sold for like 80$. That beeing said, if driver support could easily be improved that would be nice.

[K1m0n]

Well.. i'm scratching my head with this issue. Now, blazer_usb also insists on reporting 0 load... Usually when nut was restarted with blazer_usb it would, occasionaly (like half, or maybe the 1/3rd of the attempts), show ups.load for some seconds, then update to "0". Now, both drivers come up with 0 load. I did question my sanity/memory, but I have a pic with blazer showing load% on the gui, so I'm not loosing it (yet...). I tried repetedly, after reboot/cold boot/re-plug usb, nada, blazer_usb insists on 0% load too. Attached both log files for nutdrv_qx & blazer_usb. nutdrv_qx.log.txt blazer_usb.log.txt

Maybe the data is there and it's a case of vendor magic (an art that seems the oem hasn't mastered yet, given that its own app fails to reliably report ups.load), or maybe the unit sends the load reading when it feels like it, idk.

If/when I manage to capture a log when driver does read the ups.load I will update my post.