The problem
I have 2 remote NUT UPS systems and 1 local NUT UPS system. The local NUT integration works fine. However, after one hour or so one or both remote NUT UPS systems fail to get state.
Sometimes one fails, sometime both.
I use telnet to check the connection, and it is fine. I then use ‘upsc’ to check the remote data, and it also works fine.
If I ‘reload’ the integration from the UI, it works again. That is, without having to restart the daemons on the remote nut server.
Environment
- Home Assistant Core release with the issue: 0.118.0
- Last working Home Assistant Core release (if known): configuration.yaml manual edit worked fine
- Operating environment (OS/Container/Supervised/Core): Intel NUC Container
- Integration causing this issue: NUT
- Link to integration documentation on our website: https://www.home-assistant.io/integrations/nut/
Problem-relevant configuration.yaml
Old, non-integrated previous config that was working continually without issue:
-
platform: nut
name: HA UPS
host: localhost
port: 3493
alias: HA
resources:- ups.load
- ups.realpower.nominal
- input.voltage
- battery.runtime
- ups.status.display
-
platform: nut
name: AV UPS
host: rpi
port: 3493
alias: Raspberry Pi AV
username: !secret av_nut_username
password: !secret av_nut_password
resources:- ups.load
- ups.realpower.nominal
- input.voltage
- battery.runtime
- ups.status.display
Traceback/Error logs
ERROR (MainThread) [homeassistant.components.nut] Error fetching NUT resource status data: Error fetching UPS state
Additional information
I just setup NUT on home assistant os.
I got this error twice so far.
Error fetching NUT resource status data: Error fetching UPS state
The first time I just restarted the supervisor add on and pressed reconfigure in the integrations and it worked again.
Now it happened again. The issue is it’s still connected so why did it switch to unavailable?
It appeared to work for an hour before doing this both times. It’s reading properly while it works as I unplugged the ups as a test and it immediately switched the state to on battery.
users:
- username: xxxx
password: xxxx
instcmds:
- all
actions: []
devices:
- name: myups
driver: usbhid-ups
port: auto
config: []
mode: netserver
shutdown_host: 'false'
That’s my config in the supervisor add on.
Addon Logs:
8400.434497 Poll UPS [myups@localhost] failed - Data stale
8405.434769 Poll UPS [myups@localhost] failed - Data stale
8410.435062 Poll UPS [myups@localhost] failed - Data stale
8415.435348 Poll UPS [myups@localhost] failed - Data stale
8420.435624 Poll UPS [myups@localhost] failed - Data stale
8425.435908 Poll UPS [myups@localhost] failed - Data stale
8430.436180 Poll UPS
Does anyone know why it keeps becoming unavailable?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
Describe the issue you are experiencing
It seems Supervisor stops to works randomly, then HA loses connection and also SSH connection is lost. Raspberry Pi3 completely stuck, I need to unplug the power supply to reboot the system. I changed the sdhc card, reinstalled HA OS from scratch and restored the backup
What is the used version of the Supervisor?
supervisor-2021.12.2
What type of installation are you running?
Home Assistant OS
Which operating system are you running on?
Home Assistant Operating System
What is the version of your installed operating system?
Home Assistant OS 7.1
What version of Home Assistant Core is installed?
core-2021.12.9
Steps to reproduce the issue
- It seems sometimes I have the issue starting some add-on
- Sometimes just when I try to open the Supervisor page
- Sometimes when I changed some cards in Lovelace front-end
…
Anything in the Supervisor logs that might be useful for us?
22-01-15 15:05:18 ERROR (MainThread) [asyncio] Task exception was never retrieved future: <Task finished name='Task-277' coro=<HomeAssistantWebSocket.async_send_message() done, defined at /usr/src/supervisor/supervisor/homeassistant/websocket.py:210> exception=TypeError('Received message 8:1000 is not str')> Traceback (most recent call last): File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 212, in async_send_message if not await self._can_send(message): File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 190, in _can_send self._client = await self._get_ws_client() File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 171, in _get_ws_client client = await WSClient.connect_with_auth( File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 147, in connect_with_auth auth_ok_message = await client.receive_json() File "/usr/local/lib/python3.9/site-packages/aiohttp/client_ws.py", line 290, in receive_json data = await self.receive_str(timeout=timeout) File "/usr/local/lib/python3.9/site-packages/aiohttp/client_ws.py", line 275, in receive_str raise TypeError(f"Received message {msg.type}:{msg.data!r} is not str") TypeError: Received message 8:1000 is not str
Additional information
No response
Describe the issue you are experiencing
The system constantly looses connection/reloads (up to every few minutes, and sometimes it restarts without reason), especially when editing or reloading automations.
This makes a propper work flow nearly impossible.
Since core version 2022.3.3 the cpu usage jumped from ca. 20% to over 50%.
Example log below.
My system:
Home Assistant Supervised
Core version 2022.3.7
Supervisor version 2022.03.5
Debian 11 Bullseye on an old Acer netbook
Python 3.9.9
Docker version 20.10.12
What is the used version of the Supervisor?
supervisor-2022.03.5
What type of installation are you running?
Home Assistant Supervised
Which operating system are you running on?
Debian
What is the version of your installed operating system?
Debian 11 (Bullseye)
What version of Home Assistant Core is installed?
core-2022.3.4
Steps to reproduce the issue
If I’d know… but it especially occurs when automations are reloaded via config/server_control
Anything in the Supervisor logs that might be useful for us?
22-03-13 16:25:53 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 22-03-13 16:25:53 WARNING (MainThread) [supervisor.misc.tasks] Watchdog miss API response from Home Assistant 22-03-15 18:21:56 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 22-03-15 18:21:57 ERROR (MainThread) [supervisor.misc.tasks] Watchdog found a problem with Home Assistant API! 22-03-17 12:34:59 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 22-03-17 12:34:59 WARNING (MainThread) [supervisor.misc.tasks] Watchdog miss API response from Home Assistant 22-03-17 12:37:30 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 22-03-17 12:37:30 ERROR (MainThread) [supervisor.misc.tasks] Watchdog found a problem with Home Assistant API! Logger: homeassistant.components.http.ban Source: components/http/ban.py:125 Integration: HTTP (documentation, issues) First occurred: 08:54:37 (1 occurrences) Last logged: 08:54:37 Login attempt or request with invalid authentication from supervisor (172.30.32.2). (HomeAssistantSupervisor/2022.03.5 aiohttp/3.8.1 Python/3.9)
Additional information
No response
Есть UPS Powercom WOW-1000U
# lsusb
...
Bus 004 Device 002: ID 0d9f:00a4 Powercom Co., Ltd WOW Uninterruptible Power Supply (HID PDC)
Nut версии 2.7.2 под Centos 7.
# dmesg | tail
[99924.596286] usb 4-2: new low-speed USB device number 2 using ohci-pci
[99924.990367] usb 4-2: New USB device found, idVendor=0d9f, idProduct=00a4
[99924.990377] usb 4-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[99924.990383] usb 4-2: Product: UPS WOW-1000U FW3.A4
[99924.990388] usb 4-2: Manufacturer: POWERCOM Co.,LTD
[99924.990393] usb 4-2: SerialNumber: 3A4-0000-0001
[99925.024491] hid-generic 0003:0D9F:00A4.0001: hiddev0,hidraw0: USB HID v1.00 Device [POWERCOM Co.,LTD UPS WOW-1000U FW3.A4 ] on usb-0000:00:12.1-2/input0
# cat /etc/ups/ups.conf
[ups]
#driver = powercom
driver = usbhid-ups
port = auto
#port = /dev/usb/hiddev0
При запуске утилиты получаю ошибку:
# sudo upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - Generic HID driver 0.38 (2.7.2)
USB communication driver 0.32
No matching HID UPS found
Driver failed to start (exit status=1)
Нашла вариант запуска команды от рута:
# upsdrvctl -u root start ups
Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - Generic HID driver 0.38 (2.7.2)
USB communication driver 0.32
На сколько поняла из форумов, дальше нужно запустить сервер:
# sudo service nut-server start
Redirecting to /bin/systemctl start nut-server.service
A dependency job for nut-server.service failed. See 'journalctl -xe' for details.
Мануалов толком не нашла, настраиваю по темам форумов, в т.ч. этого.
]# journalctl -xe
июл 16 19:17:57 apollo16 systemd[1]: Dependency failed for Network UPS Tools - power devices information
-- Subject: Ошибка юнита nut-server.service
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Произошел сбой юнита nut-server.service.
--
-- Результат: dependency.
июл 16 19:17:57 apollo16 systemd[1]: Job nut-server.service/start failed with result 'dependency'.
июл 16 19:17:57 apollo16 systemd[1]: Unit nut-driver.service entered failed state.
июл 16 19:17:57 apollo16 systemd[1]: nut-driver.service failed.
июл 16 19:17:57 apollo16 polkitd[813]: Unregistered Authentication Agent for unix-process:18179:20416609
Это сам ups:
# lsusb -v -d 0d9f:00a4
Bus 004 Device 002: ID 0d9f:00a4 Powercom Co., Ltd WOW Uninterruptible Power Supply (HID PDC)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0d9f Powercom Co., Ltd
idProduct 0x00a4 WOW Uninterruptible Power Supply (HID PDC)
bcdDevice 0.01
iManufacturer 3 POWERCOM Co.,LTD
iProduct 1 UPS WOW-1000U FW3.A4
iSerial 2 3A4-0000-0001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 747
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 100
Device Status: 0x0002
(Bus Powered)
Remote Wakeup Enabled
Пробовала в настройка использовать другой порт и другой драйвер, но всегда были ошибки.
Теперь при повторном выполнение команды, появляется ошибка:
# sudo upsdrvctl -u root start ups
Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - Generic HID driver 0.38 (2.7.2)
USB communication driver 0.32
Can't claim USB device [0d9f:00a4]: No such file or directory
Driver failed to start (exit status=1)
При изменении драйвера — ошибка другая:
# cat /etc/ups/ups.conf
[ups]
driver = powercom
port = auto
# upsdrvctl -u root start ups
Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - PowerCom protocol UPS driver 0.14 (2.7.2)
Unable to open auto: No such file or directory
Things to try:
- Check 'port=' in ups.conf
- Check owner/permissions of all parts of path
Fatal error: unusable configuration
Driver failed to start (exit status=1)
Если порт поменять на определяемое устройство, выдает такое:
# cat /etc/ups/ups.conf
[ups]
driver = powercom
port = /dev/usb/hiddev0
# upsdrvctl -u root start ups
Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - PowerCom protocol UPS driver 0.14 (2.7.2)
Unable to open /dev/usb/hiddev0: No such file or directory
Things to try:
- Check 'port=' in ups.conf
- Check owner/permissions of all parts of path
Fatal error: unusable configuration
Driver failed to start (exit status=1)
Для Powercom драйверов всего два. Подскажите, как подключить UPS?
-
#1
Hi friends! I have a problem. I configured
sysutils/nut
for UPS and when I want get data from UPS (serial cable) getting error.
# upsc King@localhost
I have «Powercom 1500 King UPS» and FreeBSD 9.3 RELEASE x64. In configuration file
ups.conf
I using:
Code:
[King]
driver = powercom
port = /dev/cuau0
When I restart service «nut» I getting:
# /usr/local/etc/rc.d/nut restart
Code:
Stopping nut.
Waiting for PIDS: 1099.
Network UPS Tools - UPS driver controller 2.7.3
Network UPS Tools - UPS driver controller 2.7.3
Network UPS Tools - PowerCom protocol UPS driver 0.14 (2.7.3)
data receiving error (0 instead of 11 bytes)
Starting nut.
Network UPS Tools upsd 2.7.3
fopen /var/db/nut/upsd.pid: No such file or directory
/usr/local/etc/nut/upsd.conf is world readable
listening on 127.0.0.1 port 3493
Connected to UPS [King]: powercom-King
/usr/local/etc/nut/upsd.users is world readable
# ls -l /var/db/nut/
Code:
total 16
srw-rw---- 1 uucp uucp 0 1 січ 22:57 powercom-King
-rw-r--r-- 1 uucp uucp 6 1 січ 22:57 powercom-King.pid
-rw-r--r-- 1 uucp uucp 6 1 січ 22:57 upsd.pid
-rw-r--r-- 1 root uucp 5 30 гру 21:20 upslog.pid
-rw-r--r-- 1 root uucp 5 30 гру 21:20 upsmon.pid
I give group
wheel
permission on
/var/db/nut/upsd.pid
, but after restart nut permission change to only user and group
uucp
. What is wrong?
Last edited by a moderator: Jan 20, 2016
-
#2
Ownerships changing to uucp might not be a problem. Word stale would indicate a communication problem. Does /usr/local/ups/sbin/upsdrvctl start
show what it should be?
Juha
-
Thread Starter
-
#3
Hi.
# /usr/local/sbin/upsdrvctl start
Code:
Network UPS Tools - UPS driver controller 2.7.3
Network UPS Tools - PowerCom protocol UPS driver 0.14 (2.7.3)
Duplicate driver instance detected! Terminating other driver!
data receiving error (0 instead of 11 bytes)
Broadcast Message from andrian@freebsd
(no tty) at 16:45 EET...
Communications with UPS kin@localhost established
Broadcast Message from andrian@freebsd
(no tty) at 16:45 EET...
Communications with UPS kin@localhost lost
Last edited by a moderator: Jan 20, 2016
-
#4
, could there be a typo, missing g somewhere?
Juha
-
Thread Starter
-
#5
I change name «kin» in config files, but no data from ups.
# ps -aux | grep uucp
Code:
root 30595 0,0 0,1 16324 2228 0 R+ 9:52 0:00,00 grep uucp
# /usr/local/sbin/upsdrvctl start
Code:
Network UPS Tools - UPS driver controller 2.7.3
Network UPS Tools - PowerCom protocol UPS driver 0.14 (2.7.3)
data receiving error (0 instead of 11 bytes)
# ps -aux | grep uucp
Code:
uucp 30670 0,0 0,1 16468 2272 ?? Ss 9:53 0:00,00 /usr/local/libexec/nut/powercom -a king
root 30714 0,0 0,1 16324 2252 0 S+ 9:53 0:00,01 grep uucp
# /usr/local/etc/rc.d/nut start
Code:
Network UPS Tools - UPS driver controller 2.7.3
Network UPS Tools - PowerCom protocol UPS driver 0.14 (2.7.3)
Duplicate driver instance detected! Terminating other driver!
data receiving error (0 instead of 11 bytes)
Starting nut.
Network UPS Tools upsd 2.7.3
fopen /var/db/nut/upsd.pid: No such file or directory
/usr/local/etc/nut/upsd.conf is world readable
listening on 127.0.0.1 port 3493
Connected to UPS [king]: powercom-king
/usr/local/etc/nut/upsd.users is world readable
# ps -aux | grep uucp
Code:
uucp 30782 0,0 0,1 16468 2272 ?? Ss 9:54 0:00,02 /usr/local/libexec/nut/powercom -a king
uucp 30784 0,0 0,1 18340 2140 ?? Ss 9:54 0:00,01 /usr/local/sbin/upsd
root 30968 0,0 0,1 16324 2252 0 S+ 9:55 0:00,00 grep uucp
root@freebsd:/usr/local/etc/nut #
I not see
upslog
and
upsmon
in process list and I run theirs manually.
Last edited by a moderator: Jan 20, 2016
-
#1
PLEASE SEE MY LATER POST FOR THE SOLUTION
THANKS TO DLAVIGNE AND CYBERJOCK FOR THEIR HELP
Hi FreeNAS brethren,
I’ve scoured the forums and found a few entries with suggestions, but after adding what I could find as the most useful suggestion: «polinterval=11» to my GUI UPS auxiliary parameters to delay the data check, there is still no change. My logs are still inundated with the below messages:
May 14 16:59:27 TheShed upsmon[2516]: Communications with UPS CyberUPS established
May 14 17:01:06 TheShed upsd[2508]: Data for UPS [CyberUPS] is stale — check driver
May 14 17:01:07 TheShed upsd[2508]: UPS [CyberUPS] data is no longer stale
May 14 17:06:57 TheShed upsd[2508]: Data for UPS [CyberUPS] is stale — check driver
May 14 17:06:59 TheShed upsd[2508]: UPS [CyberUPS] data is no longer stale
May 14 17:35:54 TheShed upsd[2508]: Data for UPS [CyberUPS] is stale — check driver
May 14 17:35:55 TheShed upsd[2508]: UPS [CyberUPS] data is no longer stale
May 14 17:38:17 TheShed upsd[2508]: Data for UPS [CyberUPS] is stale — check driver
May 14 17:38:19 TheShed upsd[2508]: UPS [CyberUPS] data is no longer stale
May 14 17:39:21 TheShed upsd[2508]: Data for UPS [CyberUPS] is stale — check driver
May 14 17:39:22 TheShed upsmon[2516]: Poll UPS [CyberUPS] failed — Data stale
May 14 17:39:22 TheShed upsmon[2516]: Communications with UPS CyberUPS lost
May 14 17:39:23 TheShed upsd[2508]: UPS [CyberUPS] data is no longer stale
May 14 17:39:27 TheShed upsmon[2516]: Communications with UPS CyberUPS established
May 14 17:48:42 TheShed upsd[2508]: Data for UPS [CyberUPS] is stale — check driver
May 14 17:48:43 TheShed upsd[2508]: UPS [CyberUPS] data is no longer stale
This goes on for hours. Any thoughts? The UPS is responding to the upsc shell command and seems to be working fine apart from choking my log.
(UPS is a Cyber Power CP1000PFCLCD using the right driver on /dev/ugen1.5 as master)
dlavigne
Guest
-
#3
Does bumping DEADTIME or MAXAGE improve it?
Thanks for this dlavigne. I’ve read it and the advice and logic sounds solid. Maybe I’m being daft, but I can’t find the upsd.conf file in my system to edit… I’ve tried browsing and searching for it from Flow (mac sftp client) and I’ve even tried running
Code:
find . -name "upsd.conf"
from the shell… nuthin’. Do I just add the adjustment lines in the UPS auxiliary parameters in the GUI?
dlavigne
Guest
-
#4
Now that is a good question and I wonder if the current UPS GUI updates/uses that file. My understanding is that the auxiliary parameters field updates ups.conf. Try adding it there and see if it makes a difference (e.g solves your problem), and more interestingly, generates that file. If it does neither, please create a bug report at bugs.freenas.org and post the issue number here. At the very least it is a doc bug, but it might also be a «not yet but should be implemented» bug.
-
#5
Now that is a good question and I wonder if the current UPS GUI updates/uses that file. My understanding is that the auxiliary parameters field updates ups.conf. Try adding it there and see if it makes a difference (e.g solves your problem), and more interestingly, generates that file. If it does neither, please create a bug report at bugs.freenas.org and post the issue number here. At the very least it is a doc bug, but it might also be a «not yet but should be implemented» bug.
Found it, was using the wrong find file command. Needed to search all directories of all files everywhere.
It’s in /etc/local/nut
upsd.conf and upsmon.conf are in there too. I’ll give it a shot and report back.
-
#6
Now that is a good question and I wonder if the current UPS GUI updates/uses that file. My understanding is that the auxiliary parameters field updates ups.conf. Try adding it there and see if it makes a difference (e.g solves your problem), and more interestingly, generates that file. If it does neither, please create a bug report at bugs.freenas.org and post the issue number here. At the very least it is a doc bug, but it might also be a «not yet but should be implemented» bug.
So I’m using «vi» to edit upsd.conf from Shell, but once open it’s empty except for a single line: «Listen 127.0.0.1». Is this normal? Shouldn’t there be a ton of stuff inside it??
upsmon.conf has plenty in there, but no lines pertaining to «deadtime». I guess I’m a little worried of adding lines unless I know the format. I would think that it would just take the fomat of
but I may hold off until I get confirmation from someone here…
-
#7
Ha, really edging my way towards glory here…
So I managed to edit upsd.conf with vi from the shell and found the upsd.conf.sample files to guide the values I’m using. I added «MAXAGE 25» before the «LISTEN» line.
Before I did that I used «mount -uw /» and after I used «mount -ur», hoping that the changes to the .conf would stick past boot… but they’re not…
Any thoughts?? Am I missing something?
-
#8
Yeah, you can’t edit the files as they are «generated» on bootup based on your WebGUI settings.
You might be able to do something like:
service upsd stop
edit the file
service upsd start
-
#9
Yeah, you can’t edit the files as they are «generated» on bootup based on your WebGUI settings.
You might be able to do something like:
service upsd stop
edit the file
service upsd start
Ola cyberjock. Thanks for chiming in. I was starting to figure out trying to stop all UPS service and trying it all again. Weirdly, there are NO ups processes in my «running processes». When I run»service upsd stop», I get:
upsd does not exist in /etc/rc.d or the local startup
directories (/etc/ix.rc.d /usr/local/etc/rc.d)
-
#10
oh.. I think it’s nut or nut_upsmon. I don’t use a UPS that is tied to my FreeNAS box so I can’t check that for you.
-
#11
Do you think turning the switch off in the services section should do the same thing?
Sent from my T0LTE using Tapatalk
-
#12
well, if you turn it off it might delete the config file you are wanting to edit. That’s why I recommended you do it from the CLI.
The important thing to keep in mind is you don’t want to conflict with the WebGUI. If you stop the service from the CLI make sure you start it from the CLI again.
-
#13
Got it. That’s probably why there are no services running right now… I edited a .conf that was in the process of being used.
Sent from my T0LTE using Tapatalk
-
#14
Update: Used «service nut stop» to stop all the ups processes while I edited the upsd.conf. Started the nut service again and restarted and…. duh doh doh. No dice. The upsd.conf had reset itself again. If anyone has any bright ideas about getting changes to stick, your help would greatly unclog my log, so to speak :).
-
#15
you started the nut service and restarted? Wha? You just stop the service from the CLI, make the change, then start the service. No rebooting or anything. This isn’t meant as a permanent change. This was meant to prove that the fix will work, then we’ll get the devs to implement it officially.
-
#16
Yup, was still trying to make the changes stick. I was stopping and starting the service from the CLI.
It still doesn’t make sense to me why the upsd.conf is being rewritten when the machine restarts. I get why ups.conf does as the GUI aux parameters take presidence.
I get what we’re trying to achieve now. (It’s been a long day and am admittedly being stubborn about not winning). Will report back soon…
-
#17
Literally all of the FreeNAS files are generated as the system boots up. Then, when you stop and start the services they are regenerated appropriately. This is why we tell people not to try to edit them and stuff. It’ll never work and you’ll be fighting a system that wants full control.
Once you’ve proven that the given change solves the problem we can look at trying to get it incorporated for everyone.
-
#18
Makes sense. Protect us from ourselves right
I’ll report back.
Sent from my T0LTE using Tapatalk
-
#19
Literally all of the FreeNAS files are generated as the system boots up. Then, when you stop and start the services they are regenerated appropriately. This is why we tell people not to try to edit them and stuff. It’ll never work and you’ll be fighting a system that wants full control.
Once you’ve proven that the given change solves the problem we can look at trying to get it incorporated for everyone.
UPDATE: Sorry for the delay of a couple days, but I wanted to remove other variables («pollinterval = 11» in the GUI) to make sure this was a true and last measure solve for the Stale Data issue. (With my UPS, anyway: Cyber Power CP1000PFCLCD).
Since I have implemented the below, my log has been beautifully silent. No more UPS stale data messages. This is what I did for anyone else that wants to try it:
# Enter the CLI through Shell or SSH in.
# Turn nut off (all the ups services):
# Mount / as read write:
# Edit upsd.conf (I used vi. I can’t show you here how to use it in totality, you’ll need to google-fu it, but will give a step by step of what I did).
Code:
vi /etc/local/nut/upsd.conf
# You’re in the vi editor.
# Press (Shift)o #(not a zero, a capital OW is the result you want. This will insert a line at the top).
# Enter this value into the list.
# Press esc which will exit you out of edit mode.
# You are back at the CLI. Make / read only again.
Start the nut service again.
You should now have a wonderfully silent log, free of UPS stale data messages. I DID NOT add the DEADTIME value to upsmon.conf because on my UPS it didn’t need it. It also directly affects how long you run on battery without knowing what’s going on with the UPS so I didn’t want to mess with it. Hopefully this can be adjusted in an upcoming release or added as an aux parameter field in the GUI one day. Right now, only the ups.conf is editable through GUI. But upsmon and upsd all have different values that affect different aspects of the nut service.
Hopefully all my info above is correct. Cyberdog/anyone else, let me know if you see any problems. Hope this helps someone. Below is part of the runout of my drivers and other ups data from upsc. My UPS is a Cyber Power CP1000PFCLCD.
device.mfr: CP1000PFCLCD
device.model: CRDA103*AF1
device.serial: CPS
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ugen1.5
driver.version: 2.7.1
driver.version.data: CyberPower HID 0.3
driver.version.internal: 0.38
input.transfer.high: 139
input.transfer.low: 88
input.voltage: 122.0
input.voltage.nominal: 120
output.voltage: 138.0
-
#20
This fix is great! But it won’t survive a reboot. I would also like to point out that you need to make sure the usbhid-ups driver actually started. You should get similar results to what I have listed below. I had the driver fail to start once, so i started it manually to debug it but it worked that time. I then started the nut service again and everything started successfully. FYI to start driver manually run ‘/usr/local/libexec/nut/usbhid-ups -a ups -DDD’
Code:
[root@FreeNAS ~]# service nut start Network UPS Tools - UPS driver controller 2.7.1 Network UPS Tools - Generic HID driver 0.38 (2.7.1) USB communication driver 0.32 Using subdriver: CyberPower HID 0.3 libusb_get_interrupt: Unknown error Starting nut. Network UPS Tools upsd 2.7.1 fopen /var/db/nut/upsd.pid: No such file or directory listening on 0.0.0.0 port 3493 Connected to UPS [ups]: usbhid-ups-ups [root@FreeNAS ~]# ps auxw | grep ups root 7763 0.0 0.0 20340 3820 ?? Is 7:31PM 0:00.00 /usr/local/sbin/upsmon localhost uucp 7764 0.0 0.0 20340 3932 ?? S 7:31PM 0:00.01 /usr/local/sbin/upsmon localhost uucp 7788 0.0 0.0 20340 3928 ?? Is 7:31PM 0:00.00 /usr/local/bin/upslog -s ups -l /var/log/ups.log -i 300 uucp 8099 0.0 0.0 14232 2148 ?? Ds 7:38PM 0:00.00 /usr/local/libexec/nut/usbhid-ups -a ups uucp 8101 0.0 0.0 20356 3856 ?? Ss 7:38PM 0:00.00 /usr/local/sbin/upsd