A few questions about lcdproc-clients

[4C3T]

Hi. I installed OpenWRT a while ago, and as I was browsing through "Software" that is installed, or can be, I found this "lcdproc-clients" and that got me thinking of that serial port that exists on the main board of my router (Yes, actual router, not PC), and how cool it would be to use an LCD or TFT to display stuff.

Now, I'm not out to make a big deal out of this, but as I was searching for it, I ended up at the SourceForge page, and later https://openwrt.org/packages/pkgdata_owrt19_7/lcdproc-clients but it doesn't say explicitly what it does other than LCDProc is a daemon and clients for displaying system information\\ on various LCD displays\\ \\ This package contains the clients distributed by the official lcdproc\\ project: \\ * lcdproc -- displays system information\\ * lcdexec -- displays a menu structure to execute commands\\ * lcdvc -- shows the content of the system console\\ \\
and it just goes on about different ARM-structures and other rather useless information.

I'm curious, this software, which is downloadable from within OpenWRT's software manager, and as I currently have no display to use, nor do I have any serial interface (I suppose it's possible to hook up an Arduino to manage this communication or whatnot), but I'd like to know what to expect that can be done with this client software.
How is it configured to retrieve data? Is there any templates/examples somewhere for this?

I'm currently on the market for a new(er) router and I thought that I perhaps could make some experiments with the old one to see if it works and I could perhaps upgrade the newer one in the future.

[haraldg]

Hi! I'm one of the maintainers of the OpenWRT package. Thanks for your feedback about the package description. We should improve that.

lcdproc support a really wide variety of displays / protocols. There is no limit to serial and parallel ports at all. Rather there is support for some displays on I2C, USB, TCP/IP too. Also the clients and the display driver need not run on the same machine. You could have the client running on our router and the display could even be the ncurses (or X11) driver running on your work station. That's especially handy to just try things.

Since your already found the upstream project here on github you can find the man pages of the clients here in the docs directory and the example config file in clients/lcdproc.

Also most Linux and BSD distributions have lcdproc included. If you are on Linux or one of the BSDs (including OS X), you can install the lcdproc package including full documentation and user guide on your normal computer. It's usually easier to just try things there and once it is working, copy it over to the OpenWRT device.

[4C3T]

Ok. I had a look around, but I didn't see anything pertaining to OpenWRT, or I was looking in the wrong places.

In OpenWRT (Web browser when configuring the router), I only see the package that can be installed.
Will it have a menu entry after it's installed so that it can be configured?
I haven't tried installing it since I don't have any display to show it on.
I was merely curious in general to find documentation about it, specifically for OpenWRT.
I saw tons of CLI-commands for Linux and such for lcdproc, but nothing that, again, pertains to OpenWRT.

[willfe]

Will it have a menu entry after it's installed so that it can be configured?

No. At least not anything provided by the LCDproc project. It'd be up to the OpenWRT maintainers to work out some kind of mechanism to handle configuration through their web UI. LCDproc itself is configured via text file and command-line arguments.

I haven't tried installing it since I don't have any display to show it on.

I'm not sure why you'd want to install it in that case. You can run the LCDproc server configured so it just spits out a "virtual" display to the console, and connect to it with clients as you normally would, but without real display hardware it's not all that exciting or useful.

I was merely curious in general to find documentation about it, specifically for OpenWRT.

Have you asked about this over at the OpenWRT Forums? There might be folks there who have some experience setting things up who can help you quicker than we can.

I saw tons of CLI-commands for Linux and such for lcdproc, but nothing that, again, pertains to OpenWRT.

OpenWRT is Linux-based. It's very stripped-down (on purpose) so it can fit in the very limited storage space available on the devices it targets, but it's most certainly running Linux under the hood. You can SSH into a device running OpenWRT (assuming you've configured it to allow that) and talk straight to a command line with it, and you're interacting with a real (albeit stripped down) userland.

[haraldg]

Indeed for lcdproc OpenWRT is just any linux without special considerations.

The OpenWRT package currently is not integrated with the OpenWRT web interface. It would be quite easy to do for the client showing system information. Less so for the other clients and the display driver. So over all it didn't seem worthwhile to pursue. You will need ssh access to test or setup LCDproc on OpenWRT.

[4C3T]

No. At least not anything provided by the LCDproc project. It'd be up to the OpenWRT maintainers to work out some kind of mechanism to handle configuration through their web UI. LCDproc itself is configured via text file and command-line arguments.

Ok, something that'll probably never happen I suppose.

I'm not sure why you'd want to install it in that case. You can run the LCDproc server configured so it just spits out a "virtual" display to the console, and connect to it with clients as you normally would, but without real display hardware it's not all that exciting or useful.

I'm merely gathering information at this point. It would be nice to add a display to the router.

Have you asked about this over at the OpenWRT Forums? There might be folks there who have some experience setting things up who can help you quicker than we can.

No, this was the first stop since the web-search led to this place, and I thought it prudent to ask someone that is involved with this project rather than ask over there since they're not focused on one specific software and its problems.

OpenWRT is Linux-based. It's very stripped-down (on purpose) so it can fit in the very limited storage space available on the devices it targets, but it's most certainly running Linux under the hood. You can SSH into a device running OpenWRT (assuming you've configured it to allow that) and talk straight to a command line with it, and you're interacting with a real (albeit stripped down) userland.

Yes, that much I've figured out. I did connect via dropbear and I had a brief look around as I'm exploring mounted USB flash drives and was trying to run a piece of software.

[willfe]

@4C3T Ah okay, I see what you mean. I agree with your assessment that the OpenWRT folks probably aren't going to develop a UI of any kind to configure/manage LCDproc directly; it's probably a fair bit out of scope for them. TBH I'm not sure it's even (currently) possible to extend the OpenWRT UI to support configuring a third-party package. Come to think of it, that might make for an interesting side project (in my copious free time 🤣). That doesn't solve your immediate goal though.

Note that whichever option below you go with, you'll still need to run the client on the router itself since that's what grabs information from your sources (hardware info, performance metrics, etc.) to send to an LCDproc server (which is responsible for actually driving the LCD itself to display what clients send it). The client and server can both easily run on the same system (even on low-spec systems like routers), so don't worry about that. Our installation documentation discusses the general architecture in more detail and shows how to configure a basic system (including the client).

So as far as getting a display working with your hardware, depending on its physical ports, you have a couple of options: physically connect a compatible USB LCD or VFD, or set up another system to host the display itself (and the LCDproc server to drive it and listen for clients that want to display things on it).

Physical Device Connected to the Router

LCDproc does support a variety of USB devices, most of which are bus-powered (meaning they don't need an external power supply -- they're just "plug in and go"). It looks like they've gone to some effort to include a good number of LCDproc's device drivers.

I'm a bit out of the loop on the latest drivers that have been added to LCDproc, but two names I recognize in that list are CrystalFontz and Matrix Orbital, long-time supporters of the project. Support for their hardware is among the most mature in LCDproc. I wrote the first release specifically focusing on a Matrix Orbital serial LCD, in fact. Any of their USB-connected alphanumeric displays should be fine.

At any rate, pretty much any alphanumeric LCD (or VFD) that connects via USB that has an LCDproc driver should technically work with your OpenWRT router so long as it has a physical USB port. LCDproc is intended for alphanumeric displays, not graphical ones (it sends strings of text to be displayed, not full-screen images). There could be graphical displays out there that also provide an alphanumeric interface, but I'm not up-to-date on that so I'm not 100% sure. Alphanumerics are far less expensive anyway.

For this approach, you'll use a supported USB display plugged directly into the router's USB port (I wouldn't recommend using a hub unless it's got its own power supply, since most routers will only provide the minimum-required power output -- usually 500mAh at most) and then set up the LCDproc server to talk to it by writing a config file for it and spinning it up. There's a sample LCDd.conf in our project repo you can start with. From the looks of it, the OpenWRT lcdproc-server package expects the config file to be named /etc/LCDd.conf.

Physical Device on Another System

This gives you a lot more flexibility, though of course it means your router isn't actually driving a display itself. Configuration is basically the same, except you point the client at the server's IP/hostname instead of using localhost and only the client runs on the router itself.

[4C3T]

Ok. Nice. I'll have a go at those dox in a bit.

Too bad there's no support for graphical displays. I was thinking of using an Arduino to interface with since I do have an 2½" display lying around (3.3V, no other interface than SPI-interface) that I was thinking of using, maybe.

Maybe there's some code-samples out there to emulate a display interface so that it can be output to display via an Arduino. Most likely there are some. Something for me to look into.

I'm also thinking of getting an OLED-display to get it down to a more appropriate size if I want it in the front panel.
But I first have to see if it works of course.

Still got a lot of thoughts as I'm thinking, both high & low what to build. I'm currently aiming for a Linksys WRT3200ACM on an auction, and I hope I'll get it, but it's starting to get expensive. The bastard is probably made somewhere between 2015-2016 at least, and current bid is about ~$100, roughly.

Anyway, I was thinking, display aside, that I would be able to use the on-board serial port (used for programming) so that it wouldn't occupy the USB-port. This might differ between the crap I have now (Netgear WNDR3700v2) and the Linksys, but since they're both (capable of) running OpenWRT, I don't think it should be that much of a difference when it comes to connectivity. They're both computers, and they're serial ports, and should work the same, I hope. Could be that they're sort of special, given that they can be used to unbrick the routers and may be governed by another micro processor, but seeing as how it's used for eg. telnet, so it should work for other things too.

The Netgear router's USB-port accepts a USB-hub and I did some experiments with a cheap Chinese one (7-ports, but only 5 are working, so yeah...) with an USB-PSU, and I was able to mount a bunch of flash drives, just for "fun".
So, that's another option if the serial port option fails.