jbrodriguez

that makes sense, yea awesome that everything worked fine for you, thanks for reporting back !

progress ! you run your server on a port different than 443 ?

if you connect to your server via http, you don't need a cert if you connect to your server via https, you will need a cert Unraid provisions a free certificate (from well established Let's Encrypt provider) go to the Settings / Management Access page if you have set up SSL to anything other than "No", you will need to provision the Unraid letsencrypt cert then use the qr code add server method in the app (make sure to restart the controlrd plugin after you provision the cert) or import the URL that uses the certificate (more details here https://www.apertoire.com/faq/controlr/)

cool that you were able to add your servers !!! yea, about the ups data, you have a custom setup, can you do me a favor, can you show me what data is displayed on the UPS plugin page ? anonymize as needed, id like to have a reference of what is shown there

aaa i see the issue, thanks a lot for posting the output, ill look to fix this 🙏

the one that ends in myunraid.net, as wgstarks mentioned

awesome news !!! thanks for the report !! 🙏

hi, it can definitely support a certificate from a trusted authority (letsencrypt just happens to be very free 😀) the qrcode and import methods to add a server, support only *.myunraid.net, because it's the "standard" in Unraid and "easy" to find/detect by the plugin if you already have a certificate from a trusted authority for your domain, you should be able to add a server using the manual method i understand letscrypt can/should be able to create certificates for internal domains ? (not sure on this though)

yea, self signed certificates wont work anymore with the app, there are restrictions both in android and ios that make this less than optimal and insecure from the app perspective if you set up ssl, pls provision a letsencrypt certificate and connect using that URL

yea, self signed certificates wont work anymore with the app, there are restrictions both in android and ios that make this less than optimal and insecure from the app perspective if you set up ssl, pls provision a letsencrypt certificate and connect using that URL

yea, self signed certificates wont work anymore with the app, there are restrictions both in android and ios that make this less than optimal and insecure from the app perspective however, you don't need to be signed in to unraid connect to provision the letsencrypt certificate

it seems you set up ssl on your server, the only supported way to connect is by provisioning a let's encrypt certificate, self signed certificates will not work (as mentioned in this post) https://forums.unraid.net/topic/51332-plugin-controlrd/?do=findComment&comment=1459304 - If you access your server via SSL (https), the app will only connect to the `*.myunraid.net` URL, which is backed by a certificate provisioned via Let's Encrypt (certificate_bundle)

aaahhh finally, the config file !!! ill publish the plugin pointing to the correct location of the config file, but im not sure that will solve your specific case ill look into it this weekend, i have more info now thank you !!!

the plot thickens 🤔 ok, i'll troubleshoot tomorrow, strange stuff though oh, one thought ... in your /var/local/emhttp/myservers.cfg, do both hashes appear ? the correct one 192-168-1-20*.myunraid.net and the "incorrect" one ... 10.253.0.1*.myunraid.net ?

actually, im rereading the code and the config file is at /boot/config/plugins/nut-dw/nut-dw.cfg do you have that file ?

ah, now the purpose of /etc/nut/ups.conf is clearer i assume the web interface for the nut plugin does show the ups info correctly right ? its strange though that the /usr/bin/upsc command is still failing i think it's failing because of the "ups" name ... is there a name entry in your /etc/nut/ups.conf file ? if there is, does it work when you replace it in the command ? /usr/bin/upsc "<name from /etc/nut/ups.conf>@192.168.254.5"

right, i see that file in the plugin code, doesn't seem to be used elsewhere though, however i havent looked too deep still, the code does look for the main config at /boot/config/plugins/nut-dw/nut.cfg i understand /boot/config/plugins/nut-dw/nut.cfg doesn't exist in your system right ? the other 2 commands i sent you, are they throwing the same error as the initial one ? with single quotes /usr/bin/upsc '[email protected]' with double quotes /usr/bin/upsc "[email protected]" thanks for the help in troubleshooting, hopefully we can get to the bottom of it

that's weird, the nut plugin code is reading the config from /boot/config/plugins/nut-dw/nut.cfg, can you confirm you're using the latest nut plugin ?

thank you, can you try /usr/bin/upsc '[email protected]' if that doesnt work /usr/bin/upsc "[email protected]" finally, would you mind sending me your /boot/config/plugins/nut-dw/nut.cfg ? im not sure why the plugin cant parse it, would like to fix the parsing if possible

i see, can you provide the output of /usr/bin/upsc [email protected]

cool, can you do cat /var/log/controlrd.log and post that log (anonymize any private info you want, send me a dm if you prefer)

they should be in the main tab for the server, to the right of the status, cpu load, etc.

release controlrd 2024.08.30, which should support the new nut plugin. i checked the code for the new nut plugin, the core binary is the same, so the output should be the same (unless there are some upstream changes) if you're usingthe nut plugin, let me know if this now works for you

it also depends on your source disks, if they have some hardware issue, copying will also be slow but mostly what mam59 mentioned, if you have other services reading from the source and/or writing to the source/target disks, it will result in a slower operation and unpredictable results, if writing to the same disks involved in the operation

yes, ill focus on ups support now that the core of the new plugin is done, there's a new nut plugin, ill be adding support for it (prob over the weekend)