Networkupstools Stopped Working

Add-ons Bindings
1

I noticed that my networkupstools binding stopped working. I am guessing this happened over the last couple of months as there were some OpenHAB updates propagated from the Debian repos around that time.

Here’s what I’m seeing in /var/log/openhab2/openhab2.log:

2019-03-24 09:29:29.974 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'nut.things' has errors, therefore ignoring it: [1,1]: no viable alternative at input 'networkupstools'
[2,1]: no viable alternative at input 'networkupstools'
[3,1]: no viable alternative at input 'networkupstools'
[4,1]: no viable alternative at input 'networkupstools'

…followed shortly after by:

2019-03-24 09:29:31.505 [ERROR] [org.apache.felix.configadmin        ] - [org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService, id=410, bundle=245/mvn:org.openhab.binding/org.openha
b.binding.networkupstools/1.14.0.M1]: Updating property ups:refresh of configuration org.openhab.networkupstools caused a problem: Invalid configuration setting. Configuration key must contain a period ('.'), but does not.
org.osgi.service.cm.ConfigurationException: ups:refresh : Invalid configuration setting. Configuration key must contain a period ('.'), but does not.
        at org.openhab.binding.networkupstools.internal.NetworkUpsToolsBinding.updated(NetworkUpsToolsBinding.java:167) ~[?:?]
        at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189) ~[9:org.apache.felix.configadmin:1.9.10]
        at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152) [9:org.apache.felix.configadmin:1.9.10]
        at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85) [9:org.apache.felix.configadmin:1.9.10]
        at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1113) [9:org.apache.felix.configadmin:1.9.10]
        at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1069) [9:org.apache.felix.configadmin:1.9.10]
        at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138) [9:org.apache.felix.configadmin:1.9.10]
        at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105) [9:org.apache.felix.configadmin:1.9.10]
        at java.lang.Thread.run(Thread.java:834) [?:?]

Here is my /etc/openhab2/services/networkupstools.cfg file:

refresh=5000
ups1.device=myups1
ups1.host=localhost

I have experimented with ups1.refresh=5000 and that did not fix the issue.

Here is my /etc/openhab2/things/nut.things file:

networkupstools="ups1:battery.percentage"
networkupstools="ups1:input.voltage"
networkupstools="ups1:ups.load"
networkupstools="ups1:ups.status"

To illustrate my UPS communication is working:

$ upsc myups1@localhost
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 40
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 1140
battery.runtime.low: 600
battery.type: PbAcid
battery.voltage: 24.0
battery.voltage.nominal: 24
device.mfr: CPS
device.model: CST135XLU
device.serial: CR7GT2000910
device.type: ups
driver.flag.ignorelb: enabled
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 10
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.parameter.vendorid: 0764
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 120.0
input.voltage.nominal: 120
output.voltage: 136.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 31
ups.mfr: CPS
ups.model: CST135XLU
ups.productid: 0501
ups.realpower.nominal: 810
ups.serial: CR7GT2000910
ups.status: OL
ups.test.result: No test initiated
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764

Note that the default port is used and user/pass not needed.

I realize the documentation is lacking for this binding. I also see lots of questions in the forums but I didn’t see anyone discussing this. For me, it was working as recently as January so I’m thinking something changed with either the binding or OpenHAB.

I don’t understand the missing ‘.’ that it is complaining about. It would be greatly appreciated if someone could shed some insight on this, and anything else that might need to change.

Here are the details of my setup:

  • OpenHAB and NUT run on the same server
  • Server is Debian testing (buster)
  • dpkg -l reports OpenHAB version 2.5.0~M1-1
  • Binding version is binding-networkupstools1 - 1.14.0.M1 as reported in Paper UI

Thank you very much!

2

No related issues found on github but maybe for the missing ‘.’ try:

ups1.refresh=5000
ups1.device=myups1
ups1.host=localhost
3

I did try using ups1.refresh instead of refresh and the same issue is present in the openhab2.log after a restart.

4

It appears the binding is receiving a key of ups:refresh when it’s expecting just refresh.
Is it possible you had this key configured and just need to clear the cache?

5

I had previously not tried to clear the cache. Here is the procedure I used to clear the cache:

systemctl stop openhab2.service
sleep 1
rm -rf /var/lib/openhab2/cache/*
sleep 1
rm -rf /var/lib/openhab2/tmp/*
sleep 1
systemctl start openhab2.service

However, the problem still exists. I see both errors in the log file still.

To be clear, I’m using refresh=5000. I ran grep -R refresh /etc/openhab2/* to see if the problem might exist elsewhere, and I did not see anything that indicated it would cause the problem.

6

For the heck of it, I removed the binding, purged the cache, and re-installed the binding but that did not fix the problem either.

7

Alright, I think I found the source of the problem It seems there’s another directory for configuration info: /var/lib/openhab2/config/org/openhab, and in there is a file called networkupstools.config. Why this is, I have no idea.

$ cat /var/lib/openhab2/config/org/openhab/networkupstools.config
:org.apache.felix.configadmin.revision:=L"9"
myups1.device="myups1"
myups1.host="localhost"
refresh="5000"
service.pid="org.openhab.networkupstools"
ups.device="myups1"
ups.host="localhost"
ups1.device="myups1"
ups1.host="localhost"
ups1.login="myups1"
ups1.pass="******"
ups1.port="3493"
ups1.refresh="5000"
ups:refresh="20000"

That last line says it all. Perhaps it was a typo I did a while back but not sure. It’s also not removed with a cache purge. I did perform openhab-cli clean-cache earlier today and the problem persisted. I didn’t care for the required user confirmation so I did some research to fully automate it.

Does anyone know what the deal is with the /var/lib/openhab2/config directory? It’s like the evil twin brother in a horror movie.

Should I remove /var/lib/openhab2/config/org/openhab/networkupstools.config or keep the file and remove the last line (and other conflicting lines)?

8

This is the cached configuration. Stop the binding (or shut down OH), delete the file, and then restart.

1 Like
9

Yes, should have remembered this. I don’t know why xxx.config exists, but this scenario afflicts other 1.x bindings too. Ghost settings removed by stop, delete xxx.config, on reboot it gets recreated from xxx.cfg

10

???

The NUT Binding is a 1.x binding. There are not Things for 1.x bindings. Furthermore, that syntax is not a valid Thing syntax assuming it were.

Just delete it. You don’t need it and shouldn’t have it. At best it’s ignored. At worse it can cause problems.

This comes from the way that the old OH 1 style of handling configs and the OH 2 style of handling configs are completely incompatible. In the case of the .cfg files, what OH ends up doing is reading them in and creating a cached version of them under $USERDATA/config with some slight changes to their format. It’s the .conf file that is the real config file.

Unfortunately, this process isn’t perfect. Often, when you delete a field or a parameter from the .cfg file that parameter doesn’t get deleted from the .conf file.

11

Here are my takeaways from this thread.

  • things file is not needed for version 1 bindings
  • version 1 bindings move & possibly modify the config file to /var/lib/openhab2/config
  • will keep an eye on the .config files in /var/lib/openhab2/config as needed

Thanks a lot for all of the information. I have and am still learning a lot.

12

Not quite. OH reads the 1 bindings .cfg file and moves the contents to the config file in var/lib/openhab2/config.

The bindings themselves actually don’t have anything directly to do with the config files in either location. It’s the core of OH that reads them in and provides the data to the bindings.

It may seem like a distinction that doesn’t really matter, but sometimes these little nuances are important. In this case it tells you that all the 1.x binding configs will be treated the same way.

You primarily need to keep an eye there when you delete something from a .cfg file. And there is some trick where you can add a line at the top of the cfg file which will cause OH to delete the conf file for you, but I don’t know what that is right now and can’t seem to find the posts that talk about it.

13

This is good information. Thanks again for sharing. It’s always good to know as much as possible when you’re debugging, especially when it’s something new (to me).