ABEIDO

Hi Any possiblitiy of updating to 2.0.16? https://github.com/hyperion-project/hyperion.ng/releases/tag/2.0.16

Same here and downgrade fixed it. Using remote mounts from a Qnap NAS. Noticed it when i got issues with Bazarr container not able to handle local subtitles.

Thanks for quick answer, its just me wanting to understand as much as i could about it all. I will leave it alone and not tinker with it as its only logs.

Sorry for bringing back a old post. I get this in Unraid log: Mar 25 11:22:19 UNRAID usbhid-ups[6922]: ups_status_set: seems that UPS [qnapups] is in OL+DISCHRG state now. Is it calibrating (perhaps you want to set 'onlinedischarge_calibration' option)? Note that some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when in fact offline/on-battery (perhaps you want to set 'onlinedischarge' option). But everything works as it should and nothing is being shutdown when my APC UPS is doing its biweekly test. But it logs that above message. In previous poster he had problems with pfsense shutting down which i dont have problems with. And according to documentation it states that APC models are effected. Can i add a flag/line some where to fix this or is not a "real" problem as its only shown in the logs?

Bokker, any possible fix for getting rid of nchan error thats spamming the unraid log like crazy which came after last update: Also have a question if there is a possible fix for neededing rsetart container whenever HA is restarted, was working before last update. To add to above poster i also have issues with attributes on status sensor. Example of nchan error: Jan 29 05:28:42 UNRAID monitor: Stop running nchan processes Jan 29 05:29:15 UNRAID monitor: Stop running nchan processes Jan 29 05:29:48 UNRAID monitor: Stop running nchan processes Jan 29 05:30:21 UNRAID monitor: Stop running nchan processes Jan 29 05:30:54 UNRAID monitor: Stop running nchan processes Jan 29 05:31:28 UNRAID monitor: Stop running nchan processes Jan 29 05:32:01 UNRAID monitor: Stop running nchan processes Jan 29 05:32:34 UNRAID monitor: Stop running nchan processes Jan 29 05:33:07 UNRAID monitor: Stop running nchan processes Jan 29 05:33:40 UNRAID monitor: Stop running nchan processes Jan 29 05:34:13 UNRAID monitor: Stop running nchan processes Jan 29 05:34:46 UNRAID monitor: Stop running nchan processes

Yes bokker/unraidapi-re:6.12-naming, but to be honest i cannot find where to look for any errors for sure. I remember it there was supposed to be errors in debug log regarding naming. Cannot find any there now. So it seems to be working fine. Example from core.entity_registry file looks ok: "original_name": "docker_bazarr_restart", "unique_id": "unraid_bazarr_restart", That said i rename my entities always according to my own standard thats why i need to look in core.entity_registry file. Example:

Updated and couldnt find any issues with the naming I keep it kinda simple and set my entities to: docker on/off = mdi:power docker restart = mdi:restart mover: mdi:folder-arrow-up-down-outline array on/off: mdi:power parity check: mdi:sync-alert reboot: mdi:restart shutdown: mdi:power status: mdi:checkbox-marked-outline

Tested everything now: Change the NUT backend to "legacy (2.7.4)" in NUT Settings Kill UPS Power off Worked perfect Change the NUT backend to "stable (2.8.0)" in NUT Settings, Kill UPS Power off Worked perfect Change the NUT backend to "stable (2.8.0)" in NUT Settings, Kill UPS Power on Worked perfect So seems to have be something with backend then. And i can run on stable i guess. I REALLY want to thank you for the time you put into this. And for all the good info. UPS Model Back-UPS RS 900MI https://www.apc.com/se/sv/product/BR900MI/apc-backups-pro-900va-230v-avr-lcd-6-iecuttag/ Not to be confused with below(mine has IEC outlets and below has Schuko outlets). There are other diffrences aswell. https://www.apc.com/se/sv/product/BR900G-GR/powersaving-backups-pro-900-230-v-schuko/?%3Frange=61888-backups-pro&parent-subcategory-id=88975&selected-node-id=27590292604

I didnt know that with slave and master users, good info. Have changed that now. The manual test acts the same as the schedueled in regards of symptons which i didnt thought was the case, so i have a way of testing solutions now. Btw i tested without Qnap running, didnt want to messup the NAS. And problems is the same even the load now only is 34w when ups is off. Test 1 -Did a test before but with only Kill UPS Power change to No. Only Unraid shuts down (correctly thou as it always had) but it does it directly. So not staying on until set rule. Test 2 -Tested with all the suggested changes. Unraid shuts down (correctly thou as it always had) So not staying on until set rule. So same as before. Test 3 -Tested with all the suggested changes but with Shutdown Mode Battery Level . Unraid shuts down (correctly thou as it always had). So not staying on until set rule. So same as before. Saw below just before it turned off both times. 1 2 In Home Assistant (just as extra info). Yellow status name is same status as above 2. Black part is when unraid is off. So still same issue but without the powerloss for the connected devices. When i thinkm about it i couldnt have had these problem before on the old repo. I mean i would remember that my nas/unraid/server was down randomly every 2 weeks as i cannot disable auto selftest (what i have found) Only other ui option i havent touched is: and Are those of any importance in regads to the problem? Some Log from a test.

Firstly, not many takes the time you took here. So a massive thanks for that :). Im kinda torn were the problem is as explained below. But in short the UPS new, tests ok and only happens during 2 week auto selftest. Auto Selftest: It seems that the problem only occur during auto selftest thats done every 2 weeks. Havent been able to find any way to disable those. They are done at start aswell but no problem then with either blinking or power offs(hard to see as devices are off as ups is off aswell). Blinking lights: When i got the ups (first setup) i had some issues with blinking monitor when inverter acted and that was plugged into same area as UPS. This went away as i think i changed Input Sensitivity to low. No blinking during my own testing at all. Age/wear: My UPS is kinda new is less than a year old (even warranty on both batteries and ups) and is in a good location with normal temps. All selftest reports ok. Overload: Average usage is 80-100w and it should be able to handle 540w and havent been close to that. My homelab is based on lower power usage so no fancy big machines (Optiplex x2, RPI, router and QNAP Intel Atom) Load history Test: Have done full test to make sure all devices and automations works fine before and it was working, had battery runtime on about 40-45 min before it was depleted. Tested a quickie now so i unplugged power to UPS with everything up and running as normal and it worked as expected. Log below QNAP power outtage test Oct 8 15:11:04 NAS qlogd[9991]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: Power loss detected on UPS. System would be shutdown after 10 minute(s). Oct 8 15:11:37 NAS qlogd[9991]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: Power has returned to UPS. Canceling shutdown. UNRAID power outtage test Oct 8 15:10:40 UNRAID upsmon[3260]: UPS [email protected] on battery Oct 8 15:11:35 UNRAID upsmon[3260]: UPS [email protected] on line power Full log: Theres nothing close before that log, earlier there were unrelated logs imo. Regarding Stop running nchan processes i think its related to other problems with a container in below thread. And this error is always getting logged and i would have issue all the time with the NUT ot that was causing it. https://forums.unraid.net/topic/141974-support-fork-unraid-api-re/?do=findComment&comment=1314157 and so on...

Have happend a couple of times and im not sure really why. Been reading logs a lot and it seems that the plugin was updated in the vicinity of the time it happend. Som maybe incorrect deduction by me. Setup: UPS: Back-UPS RS 900MI connected via USB to Unraid. Unraid: NUT controls Unraid shutdown normally, power via UPS Qnap: Builtin QNAP UPS feature is controlling shutdown, power via UPS RPI(Home Assistant): NUT Integration to HA and automation thats shutdown server at 50% battery and then RPI(itself) at 20% battery, power via UPS. Server(Windows): Shutdown via automation as above, power via UPS. Router: No NUT, power via UPS After looking closer the UPS kills power to all connected devices (Router, Unraid, RPI Home Assistant, Qnap NAS, Server Windows). It seems that Unraid gets shutdown command and turns of fast enough but the others shows logs or messages that points to that they werent shutdown correctly The Home Assistant automation above wasnt triggerd by low battery so the server lost power. Windows logs confirm it too. So thats why i was thinking that the UPS kills the power outlets before the battery can even be drained by the machines and trigger the automation and so on. Can also add that i heard the UPS tick (switch between battery and power) a couple of times during this(no home power outage thou). It seems to run selftest every 2 weeks and thereyby the ticking and switching between battert and power. Is there anything you see that im doing wrong? Could the selftest affect NUT in some way(dont seem to be a way to disable it)? Could the the kill ups power to no help(or what does it do)? Logs/info QNAP LOG(that shows that shutdown was incorrectly done): Oct 8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: The system was not shut down properly last time. Oct 8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: System started. Oct 8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: [UPS] USB UPS device plugged in. Oct 8 02:48:57 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: [Volume DataVol1, Pool 1] The file system is not clean. NUT/UNRAID Log: Oct 8 02:35:51 UNRAID upsmon[27897]: UPS [email protected]: administratively OFF or asleep Oct 8 02:35:51 UNRAID upsd[27893]: Client [email protected] set FSD on UPS [qnapups] Oct 8 02:35:51 UNRAID upsmon[27897]: Executing automatic power-fail shutdown Oct 8 02:35:51 UNRAID upsmon[27897]: Auto logout and shutdown proceeding Oct 8 02:35:56 UNRAID shutdown[3133]: shutting down for system halt Oct 8 02:35:57 UNRAID init: Switching to runlevel: 0 Oct 8 02:35:57 UNRAID init: Trying to re-exec init Oct 8 02:35:58 UNRAID kernel: mdcmd (36): nocheck cancel Oct 8 02:35:59 UNRAID emhttpd: Spinning up all drives... Qnap settings NUT Settings (i change Kill UPS Power this morning to NO)

Hi Been having issues with UPS clients (servers thats using the UPS) power off when NUT plugin is updating. Am i right to think that changing the Kill UPS Power: Yes to No will solve this?

@Booker First checking if im using correct repo. Im using bokker/unraidapi-re:6.12 and i am again having issues after restarting HA that all sensors goes unavailable and i need restart UnraidApi container to get the sensors working again. Wrote here about but no one else seemed to have this issue. This was fixed before new restart/button updat. So im wondering if im using incorrect repo or something? Also a new issue that ive traced back to UnraidAPI. Whenever this docker is running my Unraid log gets spammed but below. Have had this a while but didnt know what was the source. Other people have talked about it (unknown if they were running UnraidAPI) and said that its most likely it isnt more than logspamm, but it would be nice to not have them. Example: Oct 7 14:14:01 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:14:34 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:15:07 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:15:40 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:16:13 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:16:46 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:17:20 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:17:53 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:18:26 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:18:59 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:19:32 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:20:05 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:20:39 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:21:12 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:21:45 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:22:18 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:22:51 SERVER-NAME monitor: Stop running nchan processes Oct 7 14:23:24 SERVER-NAME monitor: Stop running nchan processes

Yeah theres more integrations with the same issue with naming. Ive never really understood the issue fully more than that entity cannot have the devicename in its name. And i rename everything to fit my naming scheme. With thats said keep it simple and set unraidapi or unraid, short and simple. FYI: When you do update i noticed that parity-check button was misspelled, now we are on a really shallow level of problems :) And regarding the HA restart issue that was back for me (where you need to restart UnraidAPI docker after HA restart), did anyone else notice this or is it something at my setup only?

Hi, that you went with the restart and buttons, awsome to see that the integration grows. Good work Bokker. Im having 2 issues thou: HA Restart bug: But it seems that the HA restart issue is back which you fixed a couple of updates before. When i restart HA the sensors/switches/buttons goes unavailable again. Doubled naming: Same as above that has strange naming on the 5 ”new” button/switch, doubled unraidserver name. button.unraidservername_unraidservername_mover button.unraidservername_unraidservername__partitycheck button.unraidservername_unraidservername__power_off button.unraidservername_unraidservername__reboot switch.unraidservername_unraidservername__array