I'm looking into the best way to handle the ups status that gets returned by NUT. I've had a brief look at the source and it appears that this status is actually a composite of flags, some of which cannot co-exist. In particular I have a UPS that returns both OL and OL TRIM, which seem like reasonable statuses, but encode multiple states. A monitoring client has to know that OL TRIM implies online. I assume that not all combinations of flags exist, but I also understand that the combinations that do are defined by the drivers. To that end it becomes difficult to enumerate them. Are clients therefore supposed to list all possibilities, or split on space to get the flags back? Thoughts appreciated -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20201229/84c5d9fc/attachment.html>
On Tue, 29 Dec 2020, Shakil Shaikh via Nut-upsuser wrote:> I'm looking into the best way to handle the ups status that gets returned by NUT. I've had a brief look at the source and it appears that this status is > actually a composite of flags, some of which cannot co-exist. > > In particular I have a UPS that returns both OL and OL TRIM, which seem like reasonable statuses, but encode multiple states. A monitoring client has to > know that OL TRIM implies online. > > I assume that not all combinations of flags exist, but I also understand that the combinations that do are defined by the drivers. To that end it becomes > difficult to enumerate them. > > Are clients therefore supposed to list all possibilities, or split on space to get the flags back? > > Thoughts appreciatedWhy not let a program like upsmon do this for you? Then all you have to do is say in configuration file upsmon.conf what is to be done for the key events. Roger
On Dec 29, 2020, at 9:54 AM, Shakil Shaikh via Nut-upsuser wrote:> > Are clients therefore supposed to list all possibilities, or split on space to get the flags back? >Clients should split on space. I remember we had a better description of this from the protocol perspective, but that description does not seem to be in the current documentation (which has a description aimed at driver developers). This is the code that builds ups.status for the drivers: https://github.com/networkupstools/nut/blob/v2.7.4/drivers/dstate.c#L850 as suggested in the developer guide: https://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_manipulating_the_data As Roger indicated, upsmon is the canonical example for parsing ups.status. https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.c#L1474