search

networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
1.91k stars 344 forks source link

unhandled ASN ex5 received #2033

Open Briandr73 opened 1 year ago

Briandr73 commented 1 year ago

Hi,

I am receiving the following when running NUT via Home Assistant to a single CyberPower UPS with a Rmcard205 installed. Hoping someone could assist here.

[ups-PR20ØØRTXL2U] unhandled ASN ex5 received from 1.3808.1.1.1.2.2.2.e. Also getting multiple ups nut events towards bottom.

image

I know this is not a forum specific to Home Assistant issues, but I am running it via the NUT add-on. One UPS is configured via usbhid-ups. Ideally I need 2 snmp-ups configured. Right now I just want to get one running with the usbhid-ups and the other running with snmp-ups drivers.

Thanks in advance to someone offering help.

jimklimov commented 1 year ago

It seems you've passed the string above through OCR and it did a poor job :\

-[ups-PR20ØØRTXL2U] unhandled ASN ex5 received from 1.3808.1.1.1.2.2.2.e
+[ups-PR2000RTXL2U] unhandled ASN 0x5 received from .1.3.6.1.4.1.3808.1.1.1.2.2.2.0

FWIW, the OIDs in question are:

...which are in the mapping table since 2019 and 2021, so should be in NUT v2.8.0 :\ Perhaps the device returns something unexpected on those queries (e.g. not numbers, or in case of that source for ups.status - that the cyberpower_cal_status[] map returned an empty or null value (so it would look for another on the next OID)?..

In the log above I do not see actually errors, a client could log into the data server for both UPSes... beside the messages, are there specific faults, lack of data, etc.? (it may be possible that some data are missing for example - mappings do grow over time; CPS ones had several commits on master branch recently...)

Briandr73 commented 1 year ago

Hi,

I have noticed these events were happening with both snmp v1 and v3. I did not see any errors myself. I was just starting to see if NUT could communicate with the UPS via the rmcard205 that is installed.

https://peterkieser.com/2020/11/16/home-assistant-sensors-and-cyberpower-ups-via-rmcard205/

I had been using this code in HA and was getting ups status. The code writer did not include entries relating to delay start and shutdown. I was able to nominal input and output voltage from the code example above, but I know NUT could give me a lot more so I was hoping to get away from it all together. I am not sure if this helps, but as an example he was using 1.3.6.1.4.1.3808.1.1.1.4.1.1.0 and it did return the correct status for ups.

I am not sure where to go from here. The rmcard 205 has the most up to date firmware and this is a CyberPower OR1000LCDRM1U

jimklimov commented 1 year ago

From the reply here I'm none the wiser about whether you do or don't get the measurements in HA using their NUT plugin? :)

There are start-up messages with some warnings and some successful client connections. Unless proven otherwise, (at least some) things seem to work well...

For context, values (and SNMP OIDs behind them) that you can expect to see for different CPS models would be:

Bomorav commented 1 year ago

I successfully use NUT with Cyberpower OLS1500ERT2U + RMCARD205 but also saw these errors when I first tried it.

The problem is that most recent distros and probably also HA contains the latest stable version of nut-2.8.0 where the cyberpower driver is broken. The cyberpower driver (v0.51) included in nut-2.8.0 contains this bug (https://github.com/networkupstools/nut/issues/1427). This was fixed in v0.52 https://github.com/networkupstools/nut/commit/6a6888e9b5fd995e79e3db335ff4c9c524f31b51.

A recompiled nut-2.8.0 patched with this driver version works as to reading UPS status but still has a bug regarding ups commands (https://github.com/networkupstools/nut/commit/f56b99ceaf594cf11a4a03986c200137a5d8c27b). This is fixed in current master branch.

Briandr73 commented 1 year ago

Thanks for replying @jimklimov and @Bomorav. Hopefully NUT for HA gets updated soon. I been using the yaml code referenced above (from Peter Kieser) for a while and will continue to do so, but my end goal is to fully leverage NUT.

ComputerComa commented 11 months ago

It seems you've passed the string above through OCR and it did a poor job :\

-[ups-PR20ØØRTXL2U] unhandled ASN ex5 received from 1.3808.1.1.1.2.2.2.e
+[ups-PR2000RTXL2U] unhandled ASN 0x5 received from .1.3.6.1.4.1.3808.1.1.1.2.2.2.0

FWIW, the OIDs in question are:

  • "ups.status", ST_FLAG_STRING, SU_INFOSIZE, ".1.3.6.1.4.1.3808.1.1.1.7.2.7.0", "", ...
  • "battery.voltage", 0, 0.1, ".1.3.6.1.4.1.3808.1.1.1.2.2.2.0", "", ...
  • "ups.delay.start", ST_FLAG_RW, 1.0, ".1.3.6.1.4.1.3808.1.1.1.5.2.9.0", "0", ...
  • "ups.delay.shutdown", ST_FLAG_RW, 1.0, ".1.3.6.1.4.1.3808.1.1.1.5.2.11.0", "60", ...

...which are in the mapping table since 2019 and 2021, so should be in NUT v2.8.0 :\ Perhaps the device returns something unexpected on those queries (e.g. not numbers, or in case of that source for ups.status - that the cyberpower_cal_status[] map returned an empty or null value (so it would look for another on the next OID)?..

In the log above I do not see actually errors, a client could log into the data server for both UPSes... beside the messages, are there specific faults, lack of data, etc.? (it may be possible that some data are missing for example - mappings do grow over time; CPS ones had several commits on master branch recently...)

I have been getting the same error when I start mine too.

Log

Detected CP1500PFCRM2U on host 10.0.2.50 (mib: cyberpower 0.51) [CP1500PFCRM2U] unhandled ASN 0x5 received from .1.3.6.1.4.1.3808.1.1.1.7.2.7.0 [CP1500PFCRM2U] unhandled ASN 0x5 received from .1.3.6.1.4.1.3808.1.1.1.5.2.9.0 [CP1500PFCRM2U] unhandled ASN 0x5 received from .1.3.6.1.4.1.3808.1.1.1.5.2.11.0 Network UPS Tools - UPS driver controller 2.8.0 cont-init: info: /etc/cont-init.d/nut.sh exited 0 cont-init: info: running /etc/cont-init.d/nutclient.sh cont-init: info: /etc/cont-init.d/nutclient.sh exited 0 s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service legacy-services: starting services-up: info: copying legacy longrun upsd (no readiness notification) services-up: info: copying legacy longrun upsmon (no readiness notification) s6-rc: info: service legacy-services successfully started

I'm abble to pull those up using a third party client and get a response from them. I just wanted to point out that according to the latest MIB the OID .1.3.6.1.4.1.3808.1.1.1.7.2.7.0 does not point to a status code of any kind (at least according to the MIB browser I'm using. Acoording to this (See attached Screenshot) it matches to upsAdvanceTestEstimationResults.0 not sure if this is intended or the mapping has since changed but i'm not sure how that correlates to a UPS status code. All of the other OID's appear to map correctly on my RMCAD 205 image