LCDproc development and user support list

Text archives Help


[Lcdproc] lcd-nut patches offered; made to work with NUT v2


Chronological Thread 
  • From: a.foss AT f5.com (Andrew Foss)
  • Subject: [Lcdproc] lcd-nut patches offered; made to work with NUT v2
  • Date: Sat Mar 18 14:27:01 2006

It could the priority your client is setting.

In 0.4.5, the priority scale was 0-250, 0 being highest, now it's 0-6, 6
being high. I'd try removing the Priority statements from your client,
let the server give you the default priority, otherwise you can try
PRI_FOREGROUND, etc.

andrew

Dan Foster wrote:
> NUT is the network-based UPS status data reporting and monitoring
> utility. lcd-nut basically fetches data from NUT and dumps it to the
> LCD, nicely formatted and all.
>
> Just as a heads-up:
>
> I've taken Wayne, Flavio, and Kit's excellent work (lcd-nut, perl-LCDd,
> and UPS::Nut, respectively) and modified them to work with NUT v2, along
> with lcdproc (and William/Scott/others' work).
>
> The existing lcd-nut and UPS::Nut code base was already decent, but was
> NUT v1 API-only. NUT introduced major API changes that were enforced
> starting with version 2.0.0.
>
> I had my new CrystalFontz 634XE working great with all this stuff within
> about 24 hours of receiving it, after some lcd-nut/UPS::Nut hacking.
>
> Right now, the LCD is flipping between 'lcdproc K' mode and the lcd-nut
> UPS information mode every 4-6 seconds, to hopefully ward off serious
> LCD screen burn-in. Looks great, too!
>
> I've got this combination working: APC Back-UPS Pro 650, NUT 2.0.0,
> lcd-nut 0.10 + my patch, perl-LCDd 0.03, UPS::Nut 0.04 + my patch,
> lcdproc 0.4.5 and Linux kernel 2.6.15.
>
> A friend with a CFontz 635 got it working with whatever his UPSes are,
> NUT 2.0.0, lcd-nut 0.10 + my patch, perl-LCDd 0.03, UPS::Nut 0.04 + my
> patch, lcdproc from CVS as of yesterday, and Linux kernel 2.6.16.
>
> The only weird issue he is seeing is that he was unable to get 'lcdproc
> K' and lcd-nut to coexist with it flipping between the two every 4-6
> seconds as desired. He can only get one of the two to run at a time.
>
> The only real significant difference is that I am running lcdproc 0.4.5
> and he is running lcdproc with yesterday's CVS code.
>
> He thinks it may be related to priority-related changes in some way, in
> lcdproc. We are continuing to debug this issue; mostly just waiting on
> him to find some free time to poke further at it.
>
> He had to run with the cvs tree to get the 635 driver support, so that's
> why he isn't using 0.4.5. No big deal, should probably be reasonably
> simple to work around this issue, I think.
>
> I'd prefer to release a single version of the patches integrated with
> any mods he makes, once we've looked at it further. So I'm just
> mentioning my mods and recent success, because this is a pretty handy
> tool! I'll send the URL to the patches once finalized.
>
> Much appreciated to the original authors' work, including Wayne, and
> also for him hosting the source trees at his webbastards.com site, along
> with the great lcdproc stuff.
>
> I don't mean to knock any other LCD vendor; they're all good guys, but
> wanted to single out CrystalFontz for extra praise for going the
> distance to make good stuff and support the open source community, too,
> with hardware datasheet, driver contribution, offering Linux and Windows
> tools, stuff that works well, etc. The other mfrs' LCD screens do look
> nice.
>
> My lcd-nut related patches basically ripped out NUT v1 API support and
> put in NUT v2 API support, simply because I don't have NUT v1 handy.
>
> So there's some integration work for Wayne iff he chooses to integrate
> my patches, but wasn't really too many changes, because it was already
> reasonably well written.
>
> I also made local Gentoo overlay ebuilds for perl-LCDd, UPS::Nut, and
> lcd-nut, since they don't already exist in Portage. I'd probably have to
> make a customized lcdproc ebuild to package a particular CVS snapshot.
> Integrated fine with my setup via a Portage overlay.
>
> Local overlay ebuild means that they aren't in the official Gentoo
> Portage tree, but can be trivially set up 'separate' from Portage in a
> way that neither clashes.
>
> It's trivial. One-time edit of /etc/make.conf and untar'ing my tarball
> is all that is required.)
>
> Should be easy to make equivalents with RPM, APT, etc., but I don't have
> these platforms or recent experience in package creation with these.
>
> My two patches alone are about 10K; my Gentoo ebuilds + tarballs are
> about 70K? Nothing big.
>
> I use IRC a bunch (and have for about 15 years), including various
> freenode channels so maybe I'll drop by #LCDproc sometime.
>
> I'm planning on getting a small SBC (single board computer) with at
> least one USB port so I can plug in a CFontz 634XE or CFontz 635 LCD
> display, then plug the SBC into the UPS.
>
> And I'd nail the LCD display to my wooden backboard on the wall, right
> above the network connection, so it's easy to visually monitor status.
>
> That way, I will have constant status display of remaining battery power
> even when running off UPS battery, instead of having to plug my
> power-hungry and non-critical Pentium 4 desktop into the UPS.
>
> I'm looking at either a WRAP or a Soekris SBC system. Looks nice.
>
> lcdproc and the other tools are the perfect and ultimate tools to
> integrate various bits of data and present it in a meaningful and
> useful way!
>
> -Dan
> _______________________________________________
> LCDproc mailing list
> LCDproc AT lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>




Archive powered by MHonArc 2.6.18.

Top of page