[SOLVED] Network UPS Tools binding for openHAB 2 available

hilbrand · October 9, 2019, 2:10pm

Ok. I’ll trim the value t remove the space.

The release is the same. Just the jar was changed on GitHub as the source code for the release wasn’t changed. I’ve updated the title with updates time information. So the jar should be newer.

hmerk · October 9, 2019, 2:20pm

Great, Thanks

Udo_Hartmann · October 9, 2019, 2:20pm

Ah, I see. Works

hilbrand · October 9, 2019, 2:58pm

Are the for nut variables:

output.voltage
output.current

Because in the nut-names.txt I don’t see them with ups prefixed, as in ups.output.voltage?

rlkoshak · October 9, 2019, 3:05pm

Since you are in the code right now. One thing I noticed is I get some INFO level logging statements indicating some of the fields that map to paramters don’t exist.

2019-10-09 08:36:11.463 [INFO ] [.networkupstools.internal.NUTHandler] - Variabele 'ups.firmware' was not available in the NUT data of thing Network UPS Tool(networkupstools:ups:nut)
2019-10-09 08:36:11.469 [INFO ] [.networkupstools.internal.NUTHandler] - Variabele 'ups.firmware.aux' was not available in the NUT data of thing Network UPS Tool(networkupstools:ups:nut)
2019-10-09 08:36:11.472 [INFO ] [.networkupstools.internal.NUTHandler] - Variabele 'ups.id' was not available in the NUT data of thing Network UPS Tool(networkupstools:ups:nut)
2019-10-09 08:36:11.473 [INFO ] [.networkupstools.internal.NUTHandler] - Variabele 'ups.mfr.date' was not available in the NUT data of thing Network UPS Tool(networkupstools:ups:nut)
2019-10-09 08:36:11.473 [INFO ] [.networkupstools.internal.NUTHandler] - Variabele 'usp.serial' was not available in the NUT data of thing Network UPS Tool(networkupstools:ups:nut)

It would be better I think if these were debug. There is nothing I can do about them, my UPS driver simply doesn’t provide those values. It’s also not an error. So DEBUG feels like a better level to me rather than having these posted to the logs forever.

Also note: you have an extra “e” in “Variable”.

hmerk · October 9, 2019, 3:12pm

Yes, sorry, just copied the wrong part from my Thing definition.

hilbrand · October 9, 2019, 6:29pm

Update 09/10/2019 20:30

Added 2 new channels.
trim variable value to handle extra space in ups.status data.
Changed log of variables for properties to debug level, because the are not user configurable and if the data is not available should not result in lots of info logging.

rlkoshak · October 9, 2019, 8:19pm

Installed the latest and all seems to work as expected. I’m very pleased with how quickly this binding has come together. Your efforts are hugely appreciated!

hmerk · October 10, 2019, 1:03pm

Thanks, working as expected

hilbrand · October 15, 2019, 8:07pm

The binding has been merged and will be available in the next (milestone M4) release 2.5. Thanks everyone for the extensive testing.

rlkoshak · October 15, 2019, 9:12pm

I saw the merge and am already using the merged version. Thanks for migrating this binding, and so quickly too!

Andrew_Rowe · October 19, 2019, 7:46pm

Yes yes, finally got it running Thanks Hilbrand!

Nightman · October 29, 2019, 1:18pm

Hello Hilbrand,
I need your help. I am on openHAB 2.4, too. What Version of the binding does run with 2.4? Where can I download that version of the binding?
(I want to stay on a released version of openHAB)

FredericMa · October 29, 2019, 2:11pm

Hi @hilbrand,

Thanks for the binding! I started using it today and I encountered 1 issue.
To give some context first, my OpenHAB is running on a Windows Server machine and NUT is installed on a Raspberry Pi. The UPS I’m using is an APC Back-UPS ES 700G

When the binding is started, it connects to the NUT server like it should and it functions correctly.
When I restart the NUT server, the connection is lost but it never gets restored unless I restart the binding via bundle:restart.
I enabled debugging for the binding and found the following stack trace which pops up every 3 seconds:

2019-10-29 14:13:15.068 [DEBUG] [.networkupstools.internal.NUTHandler] - Updating ups status failed: 
java.lang.NullPointerException: null
	at java.util.regex.Matcher.getTextLength(Matcher.java:1283) ~[?:?]
	at java.util.regex.Matcher.reset(Matcher.java:309) ~[?:?]
	at java.util.regex.Matcher.<init>(Matcher.java:229) ~[?:?]
	at java.util.regex.Pattern.matcher(Pattern.java:1093) ~[?:?]
	at org.openhab.binding.networkupstools.internal.nut.NutResponseReader.parseVariable(NutResponseReader.java:44) ~[?:?]
	at org.openhab.binding.networkupstools.internal.nut.NutApi.lambda$2(NutApi.java:94) ~[?:?]
	at org.openhab.binding.networkupstools.internal.nut.NutConnector.read(NutConnector.java:94) ~[?:?]
	at org.openhab.binding.networkupstools.internal.nut.NutApi.getVariable(NutApi.java:94) ~[?:?]
	at org.openhab.binding.networkupstools.internal.NUTHandler.lambda$5(NUTHandler.java:289) ~[?:?]
	at org.openhab.binding.networkupstools.internal.NUTHandler.wrappedNutApiCall(NUTHandler.java:321) ~[?:?]
	at org.openhab.binding.networkupstools.internal.NUTHandler.retrieveUpsStatus(NUTHandler.java:289) ~[?:?]
	at org.eclipse.smarthome.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:97) ~[?:?]
	at org.eclipse.smarthome.core.cache.ExpiringCache.getValue(ExpiringCache.java:68) ~[?:?]
	at org.openhab.binding.networkupstools.internal.NUTHandler.refreshStatus(NUTHandler.java:219) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

The binding is not able to reconnect to the NUT server even though it is online. A bundle restart fixes the problem and everything is back to normal.
I’m running NUT v2.7.2-4. OpenHAB is 2.5.0-SNAPSHOT Build #1731.

Two other minor things I see while debugging is enabled:
Every minute (poll interval) I see this in the log file:

2019-10-29 14:13:21.143 [DEBUG] [.networkupstools.internal.NUTHandler] - Variable 'usp.serial' intented as property for thing Network UPS Tool(networkupstools:ups:apcups) is not available in the NUT data.

At startup of the bundle I see the following:

2019-10-29 14:13:21.143 [DEBUG] [.networkupstools.internal.NUTHandler] - Variable 'usp.serial' intented as property for thing Network UPS Tool(networkupstools:ups:apcups) is not available in the NUT data.

This just looks like a typo in the variable name. It says “usp.serial” instead of “ups.serial” I guess.

Greetings,
Frederic

hilbrand · October 29, 2019, 2:18pm

Hi Peter,

The new binding isn’t supported on version 2.4 as it relies some code from openHAB core not available in 2.4. Only the older version OH1 does work on 2.4. It’s available when you enable legacy bindings.

hilbrand · October 29, 2019, 2:58pm

Looks like it doesn’t handle reading errors well. I’ve updated the jar on the link to the GitHub page in the first post of this topic (Binding with date (29/10/2019) in name). Also fixed the other typo. Thanks for reporting.
Can you test this update?

FredericMa · October 29, 2019, 3:10pm

I can confirm, it works like a charm now!
Thanks for the lightning fast support

Olymp · October 31, 2019, 12:11pm

Hi!
My NUT server is installed on synology.
Is it necessary to install a client on a computer from an openHAB?

upsd.users:

[monuser]
password=secret
upsmon master

upsmon.conf:

MONITOR ups@localhost 1 monuser secret master

on Synology:

root@g-backup:/usr/syno/etc/ups$ upsc ups@localhost:3493
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 2001/09/25
battery.mfr.date: 2016/12/09
battery.runtime: 12810
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 27.3
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Back-UPS RS 900G
device.serial: 3B1649X17301
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.version: DSM6-2-2-24922-broadwell-fmp-repack-24922-190507
driver.version.data: APC HID 0.95
driver.version.internal: 0.38
input.sensitivity: medium
input.transfer.high: 294
input.transfer.low: 176
input.voltage: 234.0
input.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 879.L4 .I
ups.firmware.aux: L4
ups.load: 5
ups.mfr: American Power Conversion
ups.mfr.date: 2016/12/09
ups.model: Back-UPS RS 900G
ups.productid: 0002
ups.realpower.nominal: 540
ups.serial: 3B1649X17301
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

ups.things:

Thing networkupstools:ups:ups1 [ device="ups", host="192.168.215.4", username="monuser", password="secret", refresh=60 ]

on Synology:

root@g-backup:/usr/syno/etc/ups$ netstat -an | grep 3493
tcp        0      0 192.168.215.4:3493      0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:3493          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:35257         127.0.0.1:3493          ESTABLISHED
tcp        0      0 127.0.0.1:3493          127.0.0.1:35257         ESTABLISHED
tcp        0      0 192.168.215.4:3493      192.168.215.3:39336     ESTABLISHED
tcp6       0      0 ::1:3493                :::*                    LISTEN

192.168.215.4 - Synology
192.168.215.3 - server openHAB
Please tell me what I’m doing wrong?
Thank!

hilbrand · October 31, 2019, 1:53pm

No that’s not needed…

You can try to test it first by temporary removing the user and password from the nut server and run without login. If that doesn’t work either than its likely something different. You can try installing a client on the computer running openHAB and see if the client can get information from the nut server. If it does work it might be a problem with the binding.

You can also enable trace logging on the binding org.openhab.binding.networkupstools to see if there is any unexpected data communication that could explain the problem.

Olymp · October 31, 2019, 2:05pm

I tried:

2019-10-31 19:23:06.937 [DEBUG] [.networkupstools.internal.NUTHandler] - Refresh Network UPS Tools failed: 

org.openhab.binding.networkupstools.internal.nut.NutException: ERR ACCESS-DENIED

	at org.openhab.binding.networkupstools.internal.nut.NutConnector.writeCommand(NutConnector.java:191) ~[?:?]

	at org.openhab.binding.networkupstools.internal.nut.NutConnector.connectIfClosed(NutConnector.java:125) ~[?:?]

	at org.openhab.binding.networkupstools.internal.nut.NutConnector.read(NutConnector.java:82) ~[?:?]

	at org.openhab.binding.networkupstools.internal.nut.NutApi.getVariables(NutApi.java:82) ~[?:?]

	at org.openhab.binding.networkupstools.internal.NUTHandler.wrappedNutApiCall(NUTHandler.java:321) ~[?:?]

	at org.openhab.binding.networkupstools.internal.NUTHandler.retrieveVariables(NUTHandler.java:304) ~[?:?]

	at org.eclipse.smarthome.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:97) ~[?:?]

	at org.eclipse.smarthome.core.cache.ExpiringCache.getValue(ExpiringCache.java:68) ~[?:?]

	at org.openhab.binding.networkupstools.internal.NUTHandler.updateRefreshVariables(NUTHandler.java:249) ~[?:?]

	at org.eclipse.smarthome.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:97) ~[?:?]

	at org.eclipse.smarthome.core.cache.ExpiringCache.getValue(ExpiringCache.java:68) ~[?:?]

	at org.openhab.binding.networkupstools.internal.NUTHandler.refreshStatus(NUTHandler.java:233) ~[?:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

I’ll try the rest later, I already left from there
PS

But how to do it right?