• Content Count

  • Joined

  • Last visited

Community Reputation

31 Good

About Gnomuz

  • Rank
  • Birthday 10/21/1964


  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, Thanks for the template, I was waiting for it because my full node is on a Raspberry Pi4 and everything works fine, but harvesting from the Pi on an Unraid Samba share was just awful from a performance standpoint, especially while a new plot was being copied to the array (I saw response times beyond 30 seconds!). Now I run only a harvester in the container, and response times are more in the milliseconds range ! By tweaking config.yaml it's easy to connect the container harvester to the full node, after having generated keys for the harvester with chia init -c /path/to/ful
  2. Hi, I have exactly the same issue as @kyis and will try to elaborate a bit further. I live in a area in France where ADSL connections are awfully slow (5Mbps DL / 0.7Mbps UL). So I have a 4G router (in bridge mode) with an external antenna as the main internet connection with very decent speeds (150Mbps DL/45Mbps UP), the ADSL ISP box is only used as a failover. An internal router manages the failover and routing for all internal devices. The issue is that port forwarding is not available on the 4G connection, as often. The workaround I've found is to have a Wireguard tunnel over the 4G
  3. @i-B4se, according to , you may try to populate the "Device" setting with "IPAddr:161:APC", in case the autodetection of the "vendor" qualifier fails with our UPS. Another option seems to switch from SNMP to PCNET protocol, see , if your UPS/Network management card support it. But it's pure guess, I have no practical experience with Network Card / SNMP APC UPSes. Good luck, from my painful personal experience, getting apcupsd to w
  4. Thanks @ich777, quick and efficient, as usual ! I have a strong preference in Production branch rather than the New Features one on my server ...
  5. I agree the USB-RS232 adapters with genuine FTDI chips are fine, and this product seems to be serious. The problem is it costs around 50€ here in France, so the add-on card would be cheaper for @tetrapod if he has a free Pcie slot.
  6. If you have a free pcie 1x slot on your motherboard, that will do the trick. The other route would be a USB to rs232 adapter, but there are many compatibility issues as most of these so-called FTDI adapters are Chinese cheap crap. So stick with the add-on card if you can.
  7. Hi @ich777, I've seen the latest New Feature Branch driver 465.24.02 is now available in the settings page. Could you also make the latest Production Branch driver 460.73.01 available please ? The download page for this one also indicates "File Size: Temporarily unavailable", but the download link is fine, I just downloaded and installed it on another machine. Thanks for the great job, as usual 😉
  8. Thanks for praising my perseverance, I hate giving up, maybe a kind of OCD, but it's sometimes useful The "magic recipe" for getting correct numbers was only a poor workaround for me, as t didn't survive a reboot as you mentioned. The issue we face is a apcupsd bug, reported on the apcupsd mailing list on various OSes. But if you read my recent posts since late March 2021, you'll see I've now implemented a working solution which consists in replacing the USB connection with a good old RS232 serial connection between the UPS and the server ("Smart" cable ref AP940-0625A
  9. No spin down issue here for 6.9.2, working as expected, six SATA HDDs with LSI HBA
  10. @limetech, @jonp Maybe this thread should be moved by a forum admin in the "General support" section. I initially posted it as a prerelease bug report as I discovered the issue when I installed the UPS and my server was on 6.9.0 beta30, but it's obviously Unraid version agnostic. Moreover, it's very likely an apcupsd package and/or UPS firmware issue with USB connection, as others report the same under various distros in the apcupsd general mailing list. Despite, as it is the built-in Unraid solution to communicate with UPSes, I think it would make sense to have this te
  11. You're welcome, I've been fiddling with this for so long that I'm glad to share and help others get rid of this "ritual", as you say, that I very regularly forgot when rebooting ... 😉
  12. Changed Status to Solved Changed Priority to Annoyance
  13. Next and hopefully last episodes : 1) Reboot I've rebooted the server, and no issue after reboot, the daemon restarts properly and immediately gets good values from the UPS 2) Full power outage simulation - I set "Battery level to initiate shutdown (%)" to 85% to avoid discharging the UPS battery too much - I've unplugged the UPS to simulate a power outage. - Unraid server orderly shutdown was initiated @ 85% - 3 minutes later (default UPS grace period of 180 seconds), the UPS turned off as expected - when plugging the UPS back to mains, it
  14. I confirm I didn't configure the serial port for baud rate, stop bit, parity, ... For reference, current (default) serial port setup : stty -F /dev/ttyS0 -a speed 9600 baud; rows 0; columns 0; line = 16; intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; eol = <undef>; eol2 = ); swtch = M-0; start = M-s; stop = f; susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = M-h; discard = <undef>; min = 0; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts -ignbrk -brkint ig
  15. Hi all, I just received the serial cable and have a first positive feedback. I stopped the apcupsd daemon, unplugged the USB cable, plugged the serial cable. Then I modified the UPS settings as per the apcupsd manual : After restarting the apcupsd daemon, and a few seconds for refreshing, the daemon obviously gets consistent data from the UPS : /dev/ttyS0 was obviously the unique DB9 serial port on my motherboard, and all values are correct. I have simulated a short power outage of 2 mins (without shutdown, batteries @ 90% and 18 mi