Hilbrand
I installed 2.5M3 and Ive created a couple items as per your first post in this thread. The Network UPS tool shows as online in Paper UI. Properties in Paper UI are correct model ect. Couple questions:
A thing file is not needed if a thing is created in Paper UI correct?
Is the file /etc/openhab2/services/networkupstools.cfg now unneeded?
Should it be deleted?
How does the new binding know the name of the ups? Where do I get the ‘ups1’ in the item channel config? example
From the outside looking in, upsmon independently gets the status changes and gets them pretty immediately so it appears to be a push from the server to the client. But I’ve not looked at the code, it might just be a really fast poll.
If you can’t rely upon it to run a test like this than how can you rely on it in a true power failure? I make it a point to test my ups about once a quarter because I need to know how it will behave in a real power loss.
Recently the power company tested it for me. Everything sheathed up and running great.
I gave the new version a try and ti seems to work as expected. I’m a little disappointed in the selection of Channels though, but it’s probably just that I have an odd CyberPower UPS model so have a different set of pieces of info.
The only channels that report are:
level
runtime
status
inputVoltage
The rest remain without a value.
After running for awhile I see:
x2019-10-05 21:07:59.558 [TRACE] [ools.internal.NetworkUPSToolsHandler] - Calling updateRefreshVariables networkupstools:ups:nut x
x2019-10-05 21:07:59.559 [TRACE] [ools.internal.NetworkUPSToolsHandler] - Get NUT variables from server for thing: Network UPS Tool x
x2019-10-05 21:07:59.559 [TRACE] [tools.internal.nut.NutResponseReader] - Reading VAR ups x
x2019-10-05 21:07:59.559 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.559 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.559 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.559 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.560 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.560 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.560 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.560 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.560 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.560 [TRACE] [tools.internal.nut.NutResponseReader] - Line read:VAR ups driver.version.internal "0.41" x
x2019-10-05 21:07:59.560 [DEBUG] [ools.internal.NetworkUPSToolsHandler] - Refresh Network UPS Tools failed: x
xorg.openhab.binding.networkupstools.internal.nut.NutException: Could not find the begin string pattern in the data while reading VAR ups x
x at org.openhab.binding.networkupstools.internal.nut.NutResponseReader.validateBegin(NutResponseReader.java:106) ~[?:?] x
x at org.openhab.binding.networkupstools.internal.nut.NutResponseReader.parseList(NutResponseReader.java:75) ~[?:?] x
x at org.openhab.binding.networkupstools.internal.nut.NutApi.lambda$1(NutApi.java:52) ~[?:?] x
20x at org.openhab.binding.networkupstools.internal.nut.NutConnector.read(NutConnector.java:91) ~[?:?] x
00x at org.openhab.binding.networkupstools.internal.nut.NutApi.getVariables(NutApi.java:52) ~[?:?] x41
20x at org.openhab.binding.networkupstools.internal.NetworkUPSToolsHandler.wrappedCall(NetworkUPSToolsHandler.java:256) ~[?:?] x
20x at org.openhab.binding.networkupstools.internal.NetworkUPSToolsHandler.updateVariables(NetworkUPSToolsHandler.java:244) ~[?:?] x
x at org.eclipse.smarthome.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:97) ~[?:?] x
20x at org.eclipse.smarthome.core.cache.ExpiringCache.getValue(ExpiringCache.java:68) ~[?:?] x
20x at org.openhab.binding.networkupstools.internal.NetworkUPSToolsHandler.updateRefreshVariables(NetworkUPSToolsHandler.java:198) ~[?:?] x
20x at org.eclipse.smarthome.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:97) ~[?:?] x
20x at org.eclipse.smarthome.core.cache.ExpiringCache.getValue(ExpiringCache.java:68) ~[?:?] x
20x at org.openhab.binding.networkupstools.internal.NetworkUPSToolsHandler.refreshStatus(NetworkUPSToolsHandler.java:188) ~[?:?] x
20x at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?] x
20x at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?] x
20x at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?] x n
otx at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?] x
20x at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?] x
20x at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?] xad
: x at java.lang.Thread.run(Thread.java:748) [?:?] x
20x2019-10-05 21:07:59.592 [TRACE] [ools.internal.NetworkUPSToolsHandler] - No data from NUT server received.
every three seconds.
When the exception occurs, the status channel become UNDEF but the other three that work for me remain their last value. A restart of OH gets things working again. We will see how long it works. Hopefully it was a momentary hickup. Restarting the bundle probably would have worked too.
I pulled the plug on the UPS to see what would happen. upsmon on the machine running OH received the alert within a second or so. About three seconds after pulling the plug the status, input voltage, and runtime Channels started changing, as expected. The alarm Channel never changed and remained NULL or UNDEF (I should probably check to see which).
The one channel I wish it supported without needing to manually add a .things file is ups.load rather than input.load.
I think if you need a Channel that is not in the default set you need a .things file.
No and probably yes. I doubt it hurts to keep it but it’s not being used any longer.
It’s the first field when you create your Thing in PaperUI.
The circuit breaker of the power circuit is not just dedicated to the outlet where the UPS is connected to.
And unplugging the power cable from the UPS with load attached is dangerous because it breaks the ground/protective connector too. Without a second/dedicated protective ground this may destroy devices powered by the UPS which have a connection to devices NOT powered by the UPS or vice versa (beside imposing risk of electrocution)
for completeness:
This is the section in ups.conf to create the"dummy"-UPS:
[dummy]
driver = dummy-ups
port = /etc/nut/openHAB-testcases.dev
I can confirm, that the we now have an almost immediate update of the ups.status channel (compare the timestamps below from event log and upslog):
2019-10-06 10:17:57.571 [vent.ItemStateChangedEvent] - networkupstools_ups_02a0a8b8_upsStatus changed from OB to OL
2019-10-06 10:17:57.606 [vent.ItemStateChangedEvent] - networkupstools_ups_02a0a8b8_batteryCharge changed from 100.0 % to 85.0 %
2019-10-06 10:17:57.610 [vent.ItemStateChangedEvent] - networkupstools_ups_02a0a8b8_batteryRuntime changed from 4500.0 s to 4000.0 s
2019-10-06 10:18:30.632 [vent.ItemStateChangedEvent] - networkupstools_ups_02a0a8b8_upsStatus changed from OL to OB
2019-10-06 10:18:30.667 [vent.ItemStateChangedEvent] - networkupstools_ups_02a0a8b8_batteryCharge changed from 85.0 % to 100.0 %
2019-10-06 10:18:30.670 [vent.ItemStateChangedEvent] - networkupstools_ups_02a0a8b8_batteryRuntime changed from 4000.0 s to 4500.0 s
Coresponding upslog:
20191006 101757 85 NA NA [OL] NA NA
20191006 101758 85 NA NA [OL] NA NA
20191006 101759 85 NA NA [OL] NA NA
20191006 101800 85 NA NA [OL] NA NA
20191006 101801 85 NA NA [OL] NA NA
20191006 101802 85 NA NA [OL] NA NA
<-- some output omitted -->
20191006 101825 100 NA NA [OL] NA NA
20191006 101826 100 NA NA [OL] NA NA
20191006 101827 100 NA NA [OL] NA NA
20191006 101828 100 NA NA [OL] NA NA
20191006 101829 100 NA NA [OB] NA NA
20191006 101830 100 NA NA [OB] NA NA
20191006 101831 100 NA NA [OB] NA NA
So, it works as intended. Thanks a lot!
Currently, I can’t see the config option for the “fast poll” of the ups.status. But this might be caused by a missing clean-cache…
I’ve uploaded a new version (06/10/2019) of the binding. With some better handling of unexpected input. I would suggest to update. The previous version can hang if it gets unexpected input when starting to read the variables.
I’ll see if I can add this. No promises made though.
This was a bug in handling unexpected input. I’ve made a fix. So it should not happen anymore.
There are some advanced channels. Maybe you missed those . ups.load is included as advanced channel.
But also. If you do really miss some channels please report. This is whole topic is to inquire about
channels that are needed, and any requested channel will be added.
Correct.
There isn’t one I opted for not making this configurable because the whole intention of this binding is to get status information of the ups. So I didn’t want to make it more complex than needed. So if you think it should be configurable let me know. You can set the refresh time for the other variables though.
I suspect this might be an issue of caching in combination with replacing a binding in the addons folder with one that is almost the same. Possible a restart of the bundle could also fix such issues.
Update again. I’ve made some more changes. Binding version (07/10/2019) The dynamic channels are now better supported using the openHAB 2 channel configuration. You can see the channel properties in PaperUI. I’ve looked at adding more features. But for those I would need more time and I first want to have this work done. The current status is the base for the pull request (#6192). Any more additional channels are welcome. But can also be added easily later.
For now:
Please do install and test the latest version to see if everything is still ok.
It would be helpful to review the pull request. If you’re not a developer you can still give feedback on the readme.
I updated to 07/10/2019 and all seems well except that I still can’t get anything from the upsAlarm Channel. But it’s not that huge of a deal because I can just look at the status and see what’s going on.
Great work! Thanks for posting it!
Oops, I notices one minor weirdness. In PaperUI the upsStatus Channel doesn’t look to be lined up correctly.
Here it’s aligned correctly, see below. But have to admit, that I too have some weird rendering in PaperUI from time to time like missing scrollbars, overlapping widgets in control section, etc. (not related to NUT2 though).
Ok another update. @rlkoshak pointed me to having support for creating dynamic channels for via the UI. I wasn’t aware this was already possible, but had most of what was needed already in place. So I’ve added it. The binding is available as 09/10/2019.
Thanks for your great job @hilbrand !!!
May I ask to have the channels
upsOutputVoltage
upsOutputCurrent
being added. Both are working through Things definition, but would like to see them in general.
There is just one issue I am seeing. The state of my Best Fortress UPS is still shown as “OL” and not transformed to “Online”
Any more information I could give you to debug ??
I’ll add the channels. It could be the ups reports something other than expected and it simply can’t set a value, which could default to the first entry. If you have created the thing with an earlier version of the binding, try recreating the thing first. Else can you run with log level trace. It should log what value is returned by the nut server.
. ups.load is included as advanced channel.
can’t find the new version, I see only the upload from 12:45