Any thoughts on making it a pollable daemon that's always listening for that info?
The data is already always there on the dev file. The application is just a parser that converts the bytes into meaningful data. Making it a pollable daemon? What would be the value? What are you trying to achieve that you cannot already do?
"Always available" data + the ability to shut things down would eliminate my personal need for NUT.
You can already do that. I am currently working on shutting down remote systems.
EDIT: Also support for arm32 (eg: rpizero).
Try removing trimming as well. I will see if I can make compilation for arm part of my default workflow and include ready executables in the releases.
Thanks for the tip. I'll keep it in mind. In this case, we need sudo for shutdown anyway
Lately I have been playing a lot with UPS devices. Both using NUT and APCUPSD, but also trying to do my own work.
The result of some personal experimentation was my own tool called sups (simple ups)
Using it is as simple as extracting the executable (ideally somewhere in your path) and then running it like
sudo ./sups
https://preview.redd.it/zh0zasdw193c1.png?width=454&format=png&auto=webp&s=6b9058095c87fcb9714055063c632e2bf7f04496
sudo is probably required because more than likely the dev file is owned by root
The application looks on its own for HID compatible devices under /dev and tries to connect to the first one that it finds.
You can define your own device using the --port argument
sudo ./sups --port /dev/usb/hiddev1
If you want to shutdown the local machine below a certain battery level, you can use the --monitoring argument. The default threshold is 50% as this is the minimum safe level for cheap lead acid batteries. But you can also define your own threshold using the argument --threshold and passing the percentage. Like
sudo sups --monitoring --threshold 30
There is no daemon or service mode, so for automated shutdown the application has to be run through root's cron using something like
* * * * * sups --monitoring --threshold 45
The application does not support any low level communication with the device drivers. This was a deliberate choice. It restricts communication with fancy UPS functions, but also allows the application to be written in a higher level language that is easier to follow and maintain.
So far the app is only tested with only a few UPS devices that I have access to
So I would appreciate any feedback or corrections
You can use the --debug argument to see more information about what data was received from the device and how it was parsed.
The reasoning behind the app was to create a tool that is functionally complete but simple to use with 0 configuration even with multiple UPS devices, while at the same time being easy to maintain.
You can find the code and the executable, along with detailed instructions about the application and HID in general, under the github repo