You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looks great upon first impression, so please don't take this post as criticism but rather as points of improvement :)
One thing that I stumbled upon in a local setup was that I selected the "NUT" option as the server protocol and initially entered just the IP address (hoping to see the list of one or more UPSes exposed there, to select one). Alas, nothing appeared and the full devicename@servername had to be typed (as suggested in help text for the field). Fetching a list of devices and configuring them in clickety-click style would be a welcome addition. Likewise, discovering a server in the subnet which listens on expected port (and/or using mDNS/avahi if user's NUT is built with that) could be a further friendly option.
Another was that actually my first try was the hostname (which goes to IPv6 for me), and whether due to app or Android or networking concerns, it did not go well. UPDATE: After some investigation, I found that my upsd was actually only listening on IPv4. When I fixed that (adding a LISTEN myIPV6hostname along with LISTEN * for IPv4), the app picked it up well - so both DNS and IPv4/IPv6 are supported properly.
Finally, the issue because of which I came to post here: I had to explicitly enter the port number (3493). Although the help text speaks about default ports for different protocols, I somehow expected that an absent entry would cause the app to use that default port. This did not happen and feels like a bug :)
PS: not "remove server" but "remote server" in some message, and "18 of load" (missing "%" char) caught my eye ;)
The text was updated successfully, but these errors were encountered:
I added "help wanted" label to this issue because NUT support is something I never had in mind and it came due request by users. I only needed "apcupsd" support as app name says. I hope someone else finds this message and joins development to make this NUT support usable.
Fair enough, thanks. I'll let the NUT mailing lists know, maybe someone would like it and chime in with code :)
That would be very nice. I can review and do testing that apcupsd side still works after changes. Any contributions are welcome. I am doing basic maintenance to keep this app in Google Play.
Cheers, I was made aware of this app by a NUT community member and posted a link at https://github.com/networkupstools/nut/wiki/Android-clients (will add to proper docs later).
Looks great upon first impression, so please don't take this post as criticism but rather as points of improvement :)
One thing that I stumbled upon in a local setup was that I selected the "NUT" option as the server protocol and initially entered just the IP address (hoping to see the list of one or more UPSes exposed there, to select one). Alas, nothing appeared and the full
devicename@servername
had to be typed (as suggested in help text for the field). Fetching a list of devices and configuring them in clickety-click style would be a welcome addition. Likewise, discovering a server in the subnet which listens on expected port (and/or using mDNS/avahi if user's NUT is built with that) could be a further friendly option.Another was that actually my first try was the hostname (which goes to IPv6 for me), and whether due to app or Android or networking concerns, it did not go well. UPDATE: After some investigation, I found that my
upsd
was actually only listening on IPv4. When I fixed that (adding aLISTEN myIPV6hostname
along withLISTEN *
for IPv4), the app picked it up well - so both DNS and IPv4/IPv6 are supported properly.Finally, the issue because of which I came to post here: I had to explicitly enter the port number (3493). Although the help text speaks about default ports for different protocols, I somehow expected that an absent entry would cause the app to use that default port. This did not happen and feels like a bug :)
PS: not "remove server" but "remote server" in some message, and "18 of load" (missing "%" char) caught my eye ;)
The text was updated successfully, but these errors were encountered: