Tecnoware Era Plus 2000

[Alfatango12]

I have two ups tecnoware era plus 1500 that works well with both blazer_usb and nutdrv_qx driver. I have also a tecnoware era plus 2000 that works only with nutdrv_qx. The output of upsc for the 1500 looks like this:

battery.charge: 100
battery.voltage: 13.6
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.1
driver.version.data: Voltronic-QS 0.09
driver.version.internal: 0.36
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.voltage: 226.5
input.voltage.fault: 226.5
output.current.nominal: 3.0
output.frequency: 50.0
output.frequency.nominal: 50
output.voltage: 226.5
output.voltage.nominal: 230
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware.aux: PM-V
ups.load: 30
ups.productid: 5161
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0665

The output of upsc for the 2000 is:

battery.voltage: 27.10
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: Q1 0.07
driver.version.internal: 0.32
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.frequency: 50.0
input.voltage: 221.8
input.voltage.fault: 221.8
output.voltage: 221.8
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 2
ups.productid: 0000
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0001

As you can see all the battery related "values" aren't shown (especially the battery charge). Are there a way to get the driver read those values? I don't think it would be so difficult because the ups are basically the same, but with different battery. I can provide logs and test eventual changes since I have the device.

Edit 1: When I start with sudo upsdrvctl start on the tecnoware 2000 it seas Can't autodetect number of battery packs [-1/27.00] Battery runtime will not be calculated (runtimecal not set).

[jimklimov]

Can you check if NUT 2.8.1 (or a build of master) behaves differently yet? Maybe #1692 (IIRC OTOH) is related. UPDATE: #1652 is the relevant one for nutdrv_qx

[Alfatango12]

Oh I've just noticed that on Manjaro Arm (I'm running nut on a rpi) the package version is 2.8.0 and not 2.8.1 as I thought. This evening when I'll be at home I'll try the last version.

[Alfatango12]

Ok so I've installed the latest version from Manjaro testing branch but nothing changed. Output of sudo upsdrvctl start

Network UPS Tools - UPS driver controller 2.8.1
Network UPS Tools - Generic Q* USB/Serial driver 0.36 (2.8.1)
USB communication driver (libusb 1.0) 0.46
Duplicate driver instance detected (PID file /run/nut/nutdrv_qx-tecnowaremansarda.pid exists)! Terminating other driver!
Using protocol: Q1 0.08
Can't autodetect number of battery packs [-1/27.10]
Battery runtime will not be calculated (runtimecal not set)

and upsc

battery.voltage: 27.1
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.1
driver.version.data: Q1 0.08
driver.version.internal: 0.36
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.frequency: 50.1
input.voltage: 222.3
input.voltage.fault: 222.3
output.voltage: 222.3
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 20
ups.productid: 0000
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0001

[jimklimov]

This seems related to #1652 (relatively recent changes in just this area) and to an extent to #2267 (as a report of similar difference of driver behaviors).

Running the two drivers with raised debug verbosity (see e.g. https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity article) could help discern the issue better.

I think the battery.charge is derived from battery.voltage (unless reported directly by a device), and maybe 27.1V does not fall into any bucket of predefined min/max ranges for auto-detection (e.g. looks to human eye like a nominal 24V as a 2*12V PbAc pack).

FWIW, the report for "1500" model states a 13.6 in similar case (for 2x cells would be ~27.2), so not sure ATM if the value is so "out of range" as to matter here, or is okay in this regard.

Debug log would show some decisions made early in driver init...

[Alfatango12]

Thanks a lot for the responce, I thought that the issue would have been forgotten between other issues. I'm a bit busy this week but I'll definitely dive into it this weekend to provide all the logs.

[DjMayone]

Does the problem with Tecnoware 2000 was solved? I have the same UPS and not reporting too.

[jimklimov]

@DjMayone : did you check with a recent NUT release? What exactly does the driver debug log say?

[DjMayone]

I've added NUT add-on to my homeassistant. UPS is recognized but, in the log, I've a couple of errors:

• Battery runtime will not be calculated (runtimecal not set)
• 0.000000 fopen /run/nut/upsmon.pid: No such file or directory 0.000022 Could not find PID file to see if previous upsmon instance is already running!

I think Era Plus 2000 is not in NUT database... Could please help to configure it in the best way? Thank you!

[jimklimov]

The fopen part is okay - it means no competing older instance of the driver was running. It should be quieter in new NUT builds (currently on master, not in a release yet). With the explanation on second line it is already friendlier than it was for ages before :)

For runtimecal explanation see the driver man page, e.g. at https://networkupstools.org/docs/man/nutdrv_qx.html - not sure how it can be passed from HA configuration (if its YAML limits the keywords or not).

[lcavalli]

It seems you can specify any keyword in yaml

OIFS=$IFS
IFS=$'\n'
for configitem in $(bashio::config "devices[${device}].config"); do
    echo "  ${configitem}" >> /etc/nut/ups.conf
done
IFS="$OIFS"

[DjMayone]

So how I can configure "runtimecal"? Thank you!

[jimklimov]

@DjMayone : Did you read the man page linked above? After selecting the effective discharging speed numbers (ideally by experiment with your UPS and your workload for it - hence calibration in the name), add the line to ups.conf section for your device (or apparently equivalently - the YAML mapping in HA plugin configuration, but that's out of my pond).

I can only guess the YAML would be something like:

- upsname:
  - driver: nutdrv_qx
  - port: /dev/... for serial or "auto" for USB
  - runtimecal: X,Y,Z,W
  - ...

[mineLdiver]

I've encountered pretty much the same issue.

Says it can't detect the number of battery packs and that battery runtime will not be calculated.

I'm new to this, so how can I calculate the right values for runtimecal? Or should I wait for a new version?

[jimklimov]

@mineLdiver : I hate to be "that guy", but did you read NUT documentation (the driver man page)? The runtimecal is an experimentally determined value for your UPS and its load.

See e.g. https://networkupstools.org/docs/man/nutdrv_qx.html :)

[mineLdiver]

Well, sorry, but I'm more confused now. Are battery not being visible and runtimecal not being set - separate issues then?

[jimklimov]

Technically speaking, yes.

Since the runtimecal is a configuration option which a user should (optionally) set to estimate their remaining battery runtime with a given load, so something you would experiment with and write the numbers into configuration, it is separate from the driver not seeing battery information.

Following the work done with PR #1652 / issue #1279 (released with NUT v2.8.1) the nutdrv_qx driver should have more ways for user to configure and troubleshoot (via debug log messages) the override.battery.packs vs. battery_voltage_reports_one_pack, as well as settings of battery.voltage.low/battery.voltage.nominal/battery.voltage.high if not served by your device directly. These together should help the driver estimate the battery.voltage readings it does see from the device into a ballpark value of battery.charge percentage (and that can help with battery.runtime estimation).

You can also try to set the protocol parameter, to see if your device can be handled by Voltronic QS which seems to natively support more readings than plain Voltronic (as noted in that PR discussion) or the basic Q1 seen above.

In any case, it can be helpful to re-run the driver with raised debug verbosity, and check what subdrivers it tries by default and perhaps why it decides they are not a good fit (or if it stops on the first one that works, while there may be some other further in the loop - just not tried yet).

FWIW:

:; nutdrv_qx -h
...
Acceptable values for 'protocol' via -x or ups.conf in this driver:
  voltronic, voltronic-qs, voltronic-qs-hex, mustek, megatec/old,
  bestups, mecer, megatec, zinto, masterguard, hunnox, ablerex, q1

[DjMayone]

Technically speaking, yes.

Since the runtimecal is a configuration option which a user should (optionally) set to estimate their remaining battery runtime with a given load, so something you would experiment with and write the numbers into configuration, it is separate from the driver not seeing battery information.

Following the work done with PR #1652 / issue #1279 (released with NUT v2.8.1) the nutdrv_qx driver should have more ways for user to configure and troubleshoot (via debug log messages) the override.battery.packs vs. battery_voltage_reports_one_pack, as well as settings of battery.voltage.low/battery.voltage.nominal/battery.voltage.high if not served by your device directly. These together should help the driver estimate the battery.voltage readings it does see from the device into a ballpark value of battery.charge percentage (and that can help with battery.runtime estimation).

You can also try to set the protocol parameter, to see if your device can be handled by Voltronic QS which seems to natively support more readings than plain Voltronic (as noted in that PR discussion) or the basic Q1 seen above.

In any case, it can be helpful to re-run the driver with raised debug verbosity, and check what subdrivers it tries by default and perhaps why it decides they are not a good fit (or if it stops on the first one that works, while there may be some other further in the loop - just not tried yet).

FWIW:

:; nutdrv_qx -h

...

Acceptable values for 'protocol' via -x or ups.conf in this driver:

  voltronic, voltronic-qs, voltronic-qs-hex, mustek, megatec/old,

  bestups, mecer, megatec, zinto, masterguard, hunnox, ablerex, q1

I think I'll wait next release of HomeAssistant NUT component because I'm not so skilled to follow your advices 😉

[mineLdiver]

You can also try to set the protocol parameter, to see if your device can be handled by Voltronic QS which seems to natively support more readings than plain Voltronic (as noted in that PR discussion) or the basic Q1 seen above.

Tried setting every protocol you listed, all but Q1 either said they don't support the device or crash. It defaults to Q1 too.

[mineLdiver]

Oh, nevermind, I should have referred to the hardware compatibility list from the beginning, my bad. Turns out I simply had to use blazer_usb driver. Now it reports the battery percentage just fine!

However, it does mention that it's deprecated. Will it be removed in the future updates? I'm fine if it won't receive new development (as it says in the console), since my UPS isn't exactly new anyway, but I'd guess it's supposed to be fully replaced by nutdrv_qx?

[DjMayone]

Oh, nevermind, I should have referred to the hardware compatibility list from the beginning, my bad.

Turns out I simply had to use blazer_usb driver. Now it reports the battery percentage just fine!

However, it does mention that it's deprecated. Will it be removed in the future updates?

I'm fine if it won't receive new development (as it says in the console), since my UPS isn't exactly new anyway,

but I'd guess it's supposed to be fully replaced by nutdrv_qx?

So do you think is better to stay on blazer_usb? Another question: which number do you use as langid_fix? Thank you!

[jimklimov]

Can you please post the upsc data dumps with the two drivers to see what they detect differently (e.g. would they use same or different protocol values to query the device)?

If blazer works better for some cases, that is a good reason to:

• keep it around longer
• find what differs in code and port it, so nutdrv_qx can actually be a replacement for all earlier Megatec Q family protocol drivers

[DjMayone]

Can you please post the upsc data dumps with the two drivers to see what they detect differently (e.g. would they use same or different protocol values to query the device)?

If blazer works better for some cases, that is a good reason to:

• keep it around longer

• find what differs in code and port it, so nutdrv_qx can actually be a replacement for all earlier Megatec Q family protocol drivers

How can I execute upsc command from HomeAssistant OS?

[jimklimov]

Oh, HA. Don't use it s can't help directly.

Well, you could run a client from the outside if the data server does not LISTEN only on localhost... I gather the HA plugin is a docker(?) container so perhaps you can chroot or log into it from the host system like any other Linux?

[lcavalli]

@DjMayone, @jimklimov is right, you can open a bash shell inside a plugin container in HA given that you have a terminal plugin with disabled protection:

Then from the terminal prompt with exec -it addon_a0d7b954_nut bash you can open a shell inside NUT HA plugin and execute the upsc command like this:

root@a0d7b954-nut:/# upsc tecnoware@localhost
Init SSL without certificate database
battery.charge: 100
battery.voltage: 27.60
battery.voltage.high: 26.00
battery.voltage.low: 20.80
battery.voltage.nominal: 24.0
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 5161
driver.parameter.synchronous: auto
driver.parameter.vendorid: 0665
driver.version: 2.8.0
driver.version.data: Voltronic-QS 0.07
driver.version.internal: 0.32
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.voltage: 237.1
input.voltage.fault: 237.1
output.current.nominal: 5.0
output.frequency: 50.0
output.frequency.nominal: 50
output.voltage: 237.1
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware.aux: PM-V
ups.load: 9
ups.productid: 5161
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0665

[DjMayone]

Can you please post the upsc data dumps with the two drivers to see what they detect differently (e.g. would they use same or different protocol values to query the device)?

If blazer works better for some cases, that is a good reason to:

* keep it around longer

* find what differs in code and port it, so `nutdrv_qx` can actually be a replacement for all earlier Megatec Q family protocol drivers

That's my results:

blazer_usb

battery.charge: 100 battery.voltage: 27.20 battery.voltage.high: 26.00 battery.voltage.low: 20.80 battery.voltage.nominal: 24.0 device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: auto driver.version: 2.8.0 driver.version.internal: 0.14 driver.version.usb: libusb-1.0.26 (API: 0x1000109) input.current.nominal: 5.0 input.frequency: 50.0 input.frequency.nominal: 50 input.voltage: 235.0 input.voltage.fault: 235.0 input.voltage.nominal: 230 output.voltage: 235.0 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 4 ups.productid: 5161 ups.status: OL ups.type: offline / line interactive ups.vendorid: 0665

nutdrv_qx

battery.charge: 100 battery.voltage: 27.20 battery.voltage.high: 26.00 battery.voltage.low: 20.80 battery.voltage.nominal: 24.0 device.type: ups driver.name: nutdrv_qx driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: auto driver.version: 2.8.0 driver.version.data: Voltronic-QS 0.07 driver.version.internal: 0.32 driver.version.usb: libusb-1.0.26 (API: 0x1000109) input.voltage: 235.0 input.voltage.fault: 235.0 output.current.nominal: 5.0 output.frequency: 50.1 output.frequency.nominal: 50 output.voltage: 235.0 output.voltage.nominal: 230 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.firmware.aux: PM-V ups.load: 6 ups.productid: 5161 ups.status: OL ups.type: offline / line interactive ups.vendorid: 0665

[tomascaram-rely]

Just as a (hopefully taken friendly) comment. The whole issue discussion section of this repo is super broken. You guys can't open a technical issue about a clear defined situation and then end up talking about home assistant. Go to chat/discord for that. Or to the component repo. I've been reading 30 issues related to hunnox and i'm blown away by the amount of off topic there is in here. Totally unusable as an issue tracker.

Anyway. I mean this in a respectful and friendly way and I hope my comment is received that way. Or at least as a constructive criticism.