Just now, Rysz said:

@ich777: I'll trust you there, thanks for the compiling insight - closing PR.

I hope you don't get me wrong here but I've not gone through the entire rc.nut file which ships with the plugin but even in the rc.nut that I ship with the 2.8.0 release everything should work fine.

 

Hopefully you get my point here, I really don't want to mess with permissions which developers maybe intended to be differently.

Maybe I have some time to go through the whole rc.nut file and why it is even shipped with the plugin instead of using the one which ships with NUT itself.

 

Anyways thank you for your PRs and all that you contribute here.

15 minutes ago, SimonF said:

Unlikley to be the cable as udev reports correctly.

 

Im glad that plugin have new changes and fixes , maybe some future actions can fix it then ...

Just now, ich777 said:

I hope you don't get me wrong here but I've not gone through the entire rc.nut file which ships with the plugin but even in the rc.nut that I ship with the 2.8.0 release everything should work fine.

 

Hopefully you get my point here, I really don't want to mess with permissions which developers maybe intended to be differently.

Maybe I have some time to go through the whole rc.nut file and why it is even shipped with the plugin instead of using the one which ships with NUT itself.

 

Anyways thank you for your PRs and all that you contribute here.

 

No worries there at all, I'm thankful and glad everyone's chiming in on the pull requests - that's what open source development is for after all and it opens another perspective.

 

Generally it's probably a good idea to keep working permissions the same for now, if any problems happen down the line we can still treat them when they occur. I wouldn't want for things to break for current users either.

39 minutes ago, Masterwishx said:

 

I checked but still have unknown 2000 , i will try to check another usb cable when will buy it  

 

 

 

Did you follow just my steps has this looks like the plugin install which will overwrite the package.

 

Make sure 2.8.0 is installed.

 

Copy the new package to /boot/config/plugins/nut

 

In settings set this to no and apply

 

run the following:

 

cd /var/log/packages
removepkg nut-2.8.0-x86_64-1 
installpkg /boot/config/plugins/nut/nut-2.8.0-x86_64-1.txz 

 

Start ups tools service but change back to yes and apply.

 

 

 

 

@SimonF, I did try the new package, but my issue persists, as it's most probably driver related.

I am seeking assistance in an issue reported under the NUT repo https://github.com/networkupstools/nut/issues/1978, but if someone here has any pointers, I'd appreciate the help:

 

Simultaneously, while I have you, the package you shared as an attachment to test, was about half the size of a file under the exact same name, that was loaded to my folder most probably by the 2.8.0 installer for the NUT package shared earlier by @Rysz.
To this end, there could be a few scenarios where something went wrong. Same name, but different contents, is rarely a good thing in coding.

What I had in the ./config/plugins/nut/ folder:

What yours looked like:

Thank you!

Under the latest version: 2023.07.26, the ups is BK650M2-CH, and the status becomes On line - The battery is discharging when the device is plugged into the power supply

30 minutes ago, final said:

Under the latest version: 2023.07.26, the ups is BK650M2-CH, and the status becomes On line - The battery is discharging when the device is plugged into the power supply

The ups is connected to the Synology nas, and the unraid is connected through the slave mode. After the nut is updated to the latest version, the status of the ups in the Synology nas is displayed as online, but it is displayed as "On line - The battery is discharging" under unraid

5 hours ago, secretstorage said:

@SimonF, I did try the new package, but my issue persists, as it's most probably driver related.

I am seeking assistance in an issue reported under the NUT repo https://github.com/networkupstools/nut/issues/1978, but if someone here has any pointers, I'd appreciate the help:

 

Simultaneously, while I have you, the package you shared as an attachment to test, was about half the size of a file under the exact same name, that was loaded to my folder most probably by the 2.8.0 installer for the NUT package shared earlier by @Rysz.
To this end, there could be a few scenarios where something went wrong. Same name, but different contents, is rarely a good thing in coding.

What I had in the ./config/plugins/nut/ folder:

What yours looked like:

Thank you!

 

Was this before or after the reboot?

 

The logs from above were with the new package (smaller one) or the old package (larger one)?

 

The driver does seem to see your device, just not know how to talk to it.

 

@SimonF @ich777

 

Regarding the different sizes of the package, I think something is funky with the new package here:

 

It seems it is missing quite a few binaries and libraries.

I'll try to re-compile and re-package later and will report back here.

 

 

 

 

1 hour ago, final said:

The ups is connected to the Synology nas, and the unraid is connected through the slave mode. After the nut is updated to the latest version, the status of the ups in the Synology nas is displayed as online, but it is displayed as "On line - The battery is discharging" under unraid

 

Can you please post the diag-nostics file, go to the NUT settings => Save Diag-nostics so we can take a look what your UPS is doing?

 

Edited July 27, 20232 yr by Rysz

28 minutes ago, Rysz said:

 

Was this before or after the reboot?

 

The logs from above were with the new package (smaller one) or the old package (larger one)?

 

The driver does seem to see your device, just not know how to talk to it.

 

 

 

Can you please post the diag-nostics file, go to the NUT settings => Save Diag-nostics so we can take a look what your UPS is doing?

 

 

nut-diagnostics.dev

I deleted the nut.cfg file and uninstalled the plugin and reinstalled the settings

Just now, final said:

 

nut-diagnostics.dev 1 kB · 1 download

 

The status is correct, your driver is seeing "ups.status: OL DISCHRG" = online & discharging. In previous versions of the plugin not all possible status messages were always interpreted and shown, so it's probably always been there but was not displayed correctly until now. If the status message itself is wrong and your UPS screen/LEDs say otherwise, it's likely a problem with the driver but nothing we can affect from within the plugin. But really it could also mean that your UPS battery is not currently charging and in the process slightly discharging (as all batteries do when they're not being charged) and that's why your UPS is reporting itself as discharging. But don't worry, nothing happens because of this status.

3 minutes ago, Rysz said:

 

The status is correct, your driver is seeing "ups.status: OL DISCHRG" = online & discharging. In previous versions of the plugin not all possible status messages were always interpreted and shown, so it's probably always been there but was not displayed correctly until now. If the status message itself is wrong and your UPS screen/LEDs say otherwise, it's likely a problem with the driver but nothing we can affect from within the plugin. But really it could also mean that your UPS battery is not currently charging and in the process slightly discharging (as all batteries do when they're not being charged) and that's why your UPS is reporting itself as discharging. But don't worry, nothing happens because of this status.

ok thanks i'll keep watching how it goes

1 hour ago, Rysz said:

It seems it is missing quite a few binaries and libraries.

Not really.

 

It seems to me that the other package is compiled differently how it should be.

Please look again at my package and go into /usr/libexec/nut (this is the correct path) and you will see all the drivers (at least that's how NUT calls them).

 

I don't know how the other package is compiled but when you use the flag:

--with-drvpath=/usr/libexec/nut

the drivers will be installed there.

 

1 hour ago, Rysz said:

Regarding the different sizes of the package, I think something is funky with the new package here:

This is because I don't include the doc and man folder (no man available on Unraid).

 

May I ask if something is not working? I use it since yesterday and everything is working fine over here.

44 minutes ago, ich777 said:

Not really.

 

It seems to me that the other package is compiled differently how it should be.

Please look again at my package and go into /usr/libexec/nut (this is the correct path) and you will see all the drivers (at least that's how NUT calls them).

 

I don't know how the other package is compiled but when you use the flag:

--with-drvpath=/usr/libexec/nut

the drivers will be installed there.

 

This is because I don't include the doc and man folder (no man available on Unraid).

 

May I ask if something is not working? I use it since yesterday and everything is working fine over here.

 

I'm getting random USB driver drops here since using the new package, but could be a cable issue.

 

Just out of curiosity, did you build from the current GitHub repo or released 2.8.0 source?

 

Don't get me wrong here, not implying you don't know how to compile a package - on a first glance the amount of differences made me wonder if something went wrong somewhere - just trying to help the user and myself here (trying a new cable this afternoon too) by keeping an open mind.

 

Edited July 27, 20232 yr by Rysz

1 hour ago, Rysz said:

I'm getting random USB driver drops here since using the new package, but could be a cable issue.

I have had theses issue all the time even with the old NUT package (v2.7.4) as well as with 2.8.0 that @SimonF ships with the new package and with my package too.

 

This is for example from a few days ago (with package v2.7.4):

Jul 23 13:34:29 Server usbhid-ups[4779]: nut_libusb_get_interrupt: Input/Output Error.

 

and this is with the new one:

Jul 27 00:16:11 Server usbhid-ups[12858]: nut_libusb_get_interrupt: Input/Output Error

 

I have tried many different cables and it's always the same but I'm not to worried about that since everything is working.

 

Or do you talk about another error? If yes, please post screenshots or the messages.

 

1 hour ago, Rysz said:

Just out of curiosity, did you build from the current GitHub repo or released 2.8.0 source?

Yes, it will also tell you which version I used when you do a:

/etc/rc.d/rc.nut reload

 

You should see something like this:
 

Network UPS Tools upsd 2.8.0-signed
Network UPS Tools upsmon 2.8.0-signed

 

1 hour ago, Rysz said:

Don't get me wrong here, not implying you don't know how to compile a package

No worries, of course not, just answering questions and explaining how I do things.

1 hour ago, Rysz said:

USB driver drops

May I ask if you have the same entries in your syslog or do you have different errors?

25 minutes ago, ich777 said:

May I ask if you have the same entries in your syslog or do you have different errors?

Yes, same ones, I just switched out the cable and so far there's been no more happening.

11 hours ago, SimonF said:

Did you follow just my steps has this looks like the plugin install which will overwrite the package.

 

no,  i uploaded the package to my github clone of nut , and installed from it , so i posted the picture to show that package installed ,but i can try also your way ...

https://github.com/masterwishx/NUT-unRAID/tree/test

This is just to let everyone know, there has been a lot of troubleshooting done on the armac subdriver since last night, and it seems like different devices need different approaches to data collection.

The current state of affairs is that with a frankenstein setup and a custom compiled driver majority of variables are collected fine, though there is strangness related to batery charge/voltage (which is the same on the device display).

The battery at 0W load goes down then up and down (100%, to 72% and now at 85%, while it shows 2.10V from 72V rating), though this may be an RMA for my unit.

Various commands to switch the UPS operation mode are executed correctly though.

 

Thank you all!

 

So far everything's working with the new custom-built package.

 

But I do have a consideration regarding the switching of packages over to NUT 2.8.0. The existing NUT 2.8.0 package in @SimonF's repository already is/was the latest stable NUT 2.8.0 (RC3), it's this one from a reputable source providing tons of other Slackware packages too: https://slackware.pkgs.org/15.0/slackpack-x86_64/nut-2.8.0-x86_64-1gds.txz.html (by https://sotirov-bg.net/slackpack/). It's a bit more than a year old, so this Sotirov's package is probably as well made, stable and tested (by a larger audience) as it gets for NUT 2.8.0 on Slackware - that all sounds good to me.

 

Is it then really a good idea to make the already quite large step from a well tested and stable 2.7.4 to a newer 2.8.0 with a custom-built package when we could be switching to Sotirov's one year tried and tested NUT 2.8.0 (RC3) package, which already presents us with the latest official stable release available?

 

Any additions to the NUT GitHub since the last official 2.8.0 stable release (RC3) one could basically still consider as experimental, since there's been no more official stable releases since RC3 and 2.8.1 (https://networkupstools.org/docs/user-manual.chunked/apis01.html) is still being worked on at the moment (but has not been released yet).

 

I mean none of us here can remotely do so much testing with this new custom-built package that it would supersede Sotirov's package from a year ago in terms of testing and stability. Wouldn't it be better to rely on such a package since stability is the paramount concern rather than having the "latest fix"?

 

To me it makes not so much sense that we waited so long with the upgrade from 2.7.4 to 2.8.0 because of stability concerns and then we switch to a few days old custom-built package when there's another more long-term tested and stable one around.

 

Just throwing this in here for discussion, thanks everyone for the efforts.

 

36 minutes ago, Rysz said:

is/was the latest stable NUT 2.8.0 (RC3), it's this one from a reputable source providing tons of other Slackware packages too: https://slackware.pkgs.org/15.0/slackpack-x86_64/nut-2.8.0-x86_64-1gds.txz.html (by https://sotirov-bg.net/slackpack/). It's a bit more than a year old, so this Sotirov's package is probably as well made, stable and tested (by a larger audience) as it gets for NUT 2.8.0 on Slackware - that all sounds good to me.

This is the location the package came from. I trust @ich777 we as a community are using alot of them from him. Including ones in my plugins.

 

With his plugins we know where they are compiled from and have control.

 

All he has done is compiled based on Unraid libraries etc which the external one would not have been.

20 hours ago, SimonF said:

Did you follow just my steps has this looks like the plugin install which will overwrite the package.

 

Make sure 2.8.0 is installed.

 

Copy the new package to /boot/config/plugins/nut

 

In settings set this to no and apply

 

run the following:

 

cd /var/log/packages
removepkg nut-2.8.0-x86_64-1 
installpkg /boot/config/plugins/nut/nut-2.8.0-x86_64-1.txz 

 

Start ups tools service but change back to yes and apply.

 

 

checked , have same "unknown 2000"

2 minutes ago, Masterwishx said:

 

checked , have same "unknown 2000"

Thanks did know you had updated from own repo.

1 minute ago, SimonF said:

Thanks did know you had updated from own repo.

 

No thats was befor , but now i followed your steps ...

39 minutes ago, Rysz said:

It's a bit more than a year old, so this Sotirov's package is probably as well made, stable and tested (by a larger audience) as it gets for NUT 2.8.0 on Slackware - that all sounds good to me.

But this package is still built wrongly in terms of the drivers since these belong in /usr/libexec/nut/ directory.

 

Also the argument that this package is tested is not really accurate since you don't know if it's really well tested, usually such packages are built. <- no and there is nothing more...

 

40 minutes ago, Rysz said:

Is it then really a good idea to make the already quite large step from a well tested and stable 2.7.4 to a newer 2.8.0

Why is this a big step? Updates are good in general, I really don't like the idea of always staying on a low version to avoid issues for users who have no issues but maybe make it harder for new users with newer UPS units which are maybe supported by the newer version.

 

47 minutes ago, Rysz said:

I mean none of us here can remotely do so much testing with this new custom-built package that it would supersede Sotirov's package from a year ago in terms of testing and stability. Wouldn't it be better to rely on such a package since stability is the paramount concern rather than having the "latest fix"?

May I ask why it should be more unstable if I build it with the same libraries that are used on Unraid? This is a bit confusing for me, there are only two things that could happen:

• It is working
• It is not working

 

I would also recommend that you take a look at the old 2.7.4 package and where things are located, this package was basically built by Slackware and I stick to the Slackware conventions at least in terms how things are built and I can customize them for Unraid but in this case I didn't do it because it is a default package.

 

52 minutes ago, Rysz said:

then we switch to a few days old custom-built package when there's another more long-term tested and stable one around.

But keep in mind that this older package uses maybe older shared libraries which are not fully compatible (will maybe not be not the case) than a newer package which is built for the libraries that Unraid is using.

Just saying to keep that also in consideration.