LCDProc 0.5.4-dev

mdima

I would suggest we run both in parallel at least until 2.1 is released. At that point the package system is changing so work would be required to the old package which seems pointless if the dev package is relatively bug free.
Perhaps ask Seth Mos(databeestje)?
Steve

ok… I know that we are adding a lot of new features, but the "basic" features of lcdproc seem to be quite stable (I am running the service since days and days, with 1 second as refresh and it never hangs, while lcdproc 0.5.3.1 was hanging only after few days with a 5 seconds refresh). Actually I have no need to release it, but it would be great if also the other users could take advantage of this version, even if I don't have any number about the people that are using the package and their feedbacks.

Btw, before starting to put some work on the package, I tried to contact Seth Mos but the email was returning... but of course I will contact again before releasing the package on the "main" version...

Michele

fmertz

@mdima:

just a question (to you and to all): when do you think that we could replace the lcdproc package with the new lcdproc-dev package?

What is this package released against? A production pfSense release, or a development pfSense release? If it is development, I would say release it soon. This way, you can catch problems from users of other drivers before the package becomes production…

stephenw10

It would be very interesting to know how many people are using it.
I don't think we can ever hope to test everything before declaring it 'ready'.

I'm not sure really. :-\

Steve

mdima

@fmertz:

@mdima:

just a question (to you and to all): when do you think that we could replace the lcdproc package with the new lcdproc-dev package?

What is this package released against? A production pfSense release, or a development pfSense release? If it is development, I would say release it soon. This way, you can catch problems from users of other drivers before the package becomes production…

Hi fmertz,
I ment to release in production (replace the "lcdproc" package with the "lcdproc-dev" package)…

opinions opinions! ;)

Thanks,
Michele

mdima

@stephenw10:

It would be very interesting to know how many people are using it.
I don't think we can ever hope to test everything before declaring it 'ready'.
I'm not sure really. :-
Steve

me too… but also on the previous package, I think that there were a lot of "it works for me" parts of the code, and people has been using it for years (working)...
I would prefer that with a fresh install most people would use the "-dev" package in order to test it on as many systems as possible, but I really don't know how stable it is out of my environment...

stephenw10

I have found the strange behaviour from my box running v0.8 on pfSense 2.0.1.
Twice now I have found myself unable to log into the box either via http or ssh (ssh can login but then I get no console menu or command prompt).
Both times the problem has resolved itself when my WAN connection cycled causing packages to be reloaded.
It's hard to say at this point what is causing it, whether LCDproc is a cause or a symptom of something else.

What is certainly true is that I believe the php lcdproc client needs some better timeout code because when I look at the logs to try to determine what's happening all I see is:

Jan 13 08:37:43 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:42 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:32 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:30 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:20 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:19 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:09 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:08 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:57 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:56 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:46 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)

The standard lcdproc client will timeout after 3 or 4 attempts and quit.
What do you think?

Steve

power_matz

Hi,

first I want to thank you for the great effort you made on this project.
It was very annoying installing the LCDproc manually every time after an update.

I am using a FireBox. I am wondering why the backlight isn't staying on. I configured that in the control panel and also with the buttons on the hardware.

Can you tell me what the correct way is?
I was using the SDEC driver some time ago. There you had to set this in the conf file.
But I think you write this with the control panel, right?

Matthias

stephenw10

The newest driver for the sdeclcd no longer gives you that option. This is because the lamp in the display has a half life of just 3000 hours! You do not want it on all the time.
However if enough people want it it could be reinstated I guess.

Steve

fmertz

@power_matz:

I am using a FireBox. I am wondering why the backlight isn't staying on. I configured that in the control panel and also with the buttons on the hardware.

The initial driver had the option of setting the backlight timer to zero to leave the light always on. I read the spec of the SDEC LCD and it mentions a "Half Lift" (not my typo) of "3,000 HR.". I am not a component engineer, but I read this to mean that if a sufficiently large number of these LCDs are turned on at a given time, half of them will be off (and dead) after 3,000 Hours, or 17 weeks. It seemed like a good enough reason to keep the light off as much as possible, unless someone was "there" to look at it. Barring the availability of a proximity sensor, I coded it so it stays on for 30 sec after a key is pressed. If another key is pressed, the light stays on for another 30 seconds. From memory, someone posted on this forum that his backlight was dead. I figured these boxes have seen some use before we get them, so who knows how much life is left in that light. Also, with the high fan noise level these boxes make, I figured most of them will be stashed somewhere where the LCD would not be directly visible. This is my reasoning, and why I am reluctant to give folks an option to kill that light prematurely.

The original thread for the code is here: http://forum.pfsense.org/index.php/topic,7920.0.html

stephenw10

Further to my previous post.
I again found that LCDd had crashed out though this time the box was still responsive. Nothing useful in the logs as they are completely filled with the lcdproc php client error.
However I restarted the service and:


Jan 14 01:11:52 pfsense LCDd: LCDd version 0.5.5 starting
Jan 14 01:11:52 pfsense LCDd: Using Configuration File: /usr/local/etc/LCDd.conf
Jan 14 01:11:52 pfsense LCDd: Listening for queries on 127.0.0.1:13666
Jan 14 01:11:53 pfsense LCDd: Connect from host 127.0.0.1:57448 on socket 11
Jan 14 01:11:54 pfsense LCDd: Connect from host 127.0.0.1:10311 on socket 13
Jan 14 01:11:55 pfsense LCDd: Connect from host 127.0.0.1:27771 on socket 14

There now seem to be three copies of the php client so it isn't correctly being killed by the rc file.

Steve

Cino

been running the 0.5.5 pkg for a couple of days now and no issues so far with the picolcd driver…

power_matz

@stephenw10:

The newest driver for the sdeclcd no longer gives you that option. This is because the lamp in the display has a half life of just 3000 hours! You do not want it on all the time.
However if enough people want it it could be reinstated I guess.

Steve

I was using a Firebox x700 over 1,5 years with the LCD light on. No issues.
I was using a Cobalt Raq 3i for 3 years. There the light is on by default all the time. No issues.

Where do you have this information. Is it really a LAMP? No LED?

ADD:

OK, I looked up the specs myself. There a two versions: EL and LED backlight.

If the backlight is a LED then the half life (means half the brightness as a new one) is 50.000 h. Thats over 5 years!

So, I don't see here an issue to enable the permanet backlight on, if it is made by LED.

fmertz

@power_matz:

Where do you have this information.

The code is based on this spec:

http://www.ktechs.net/pvt_filz/lcdproc/LMC-S2D20-01.pdf

A re-read shows both 3,000 hrs for the "EL" part, and 30,000 hrs for the "LED" part. The block diagram seems to show a LED back light. 30,000 Hrs is less than 3.5 years. Folks like us typically get these Fireboxes used, so knowing nothing of the Watchguard software, I have to assume these lights could have been on for the better part of their life. Therefore, little time may be left. I am trying to keep it safe here, I guess. What length of time would you prefer?

fmertz

Looks like the vbars were upside down (my goof). The driver with a fix is here:

https://github.com/downloads/fmertz/sdeclcd/sdeclcd.so

Anyone can test on pfSense? Seems to work on Linux…

If this works, I'll open a ticket with pfSense on github. Thanks.

power_matz

@fmertz:

What length of time would you prefer?

What will it "cost" to let the user decide if he wants the BL on permanantly or only for 30 sec after a button was pressed?

fmertz

@mdima:

Added the "output led" support for the "CFontz633" driver.

I am getting around to coding the LED support in the SDEC driver for Fireboxes. At the moment, it runs on Linux for the X-Core-e boxes. The code can get the I/O ports for the GPIO out of the PCI configuration by reading /sys. This is not available in any of the *BSDs, so additional coding is required to make it work in pfSense. In the meantime, here is the (proposed) interface for the "output" function:


#define SDEC_OUTPUT_RED		0x0001
#define SDEC_OUTPUT_GREEN	0x0010
#define SDEC_OUTPUT_RED_BLINK	0x0100
#define SDEC_OUTPUT_GREEN_BLINK	0x1000

This means a client can issue "output 1" to turn the "Armed/Disarmed" to red, or "output 256" to make it blink red. Unused bits are masked off.

I guess at this point, feedback would be welcome regarding what we want to see driving the LEDs. mdima has already a number of things coded in the client. Maybe what was proposed for LED4 would work, but maybe with more feature as we have the blink function.

In addition, and outside of the client, do we want the driver itself to set these LEDs? What about a setting in LCDd.conf to set one of the LED at startup? Thoughts welcome.

stephenw10

Yes I like your proposal.
Have an option in LCDd.conf for an initial state on boot up. For most people this will be sufficient.

Go to (some other state) on gateway down is intersting. Another suggestion was go red when there is a warning in the GUI.

My X-Peak box LCD is still crashing in less than 24hours. It's interesting to note though that LCDd displays the "thankyou for using pfSense" message so presumably it doesn't crash out hard but rather shuts down or is killed.

I'll try the new driver.

Steve

stephenw10

This can't be right. :-\


[2.0.1-RELEASE][root@pfsense.fire.box]/root(7): ps aux | grep lcdproc
root    5983  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   22313  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   23243  0.0  3.4 47452 17184  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   25113  0.0  0.3  3656  1400  ??  IN   11:27PM   0:00.01 /bin/sh /usr/local/etc/rc.d/lcdproc.sh start
root   32258  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   59818  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php

Steve

fmertz

Brave souls:

Test SDEC driver with LED support:

Code ported from Linux, basic testing under FreeBSD, with hard coded support for X-e boxes only for now:

https://github.com/downloads/fmertz/sdeclcd/sdeclcd_led.so

Rename the file to sdeclcd.so
Restart LCDd
telnet <pfsense box="" ip="">13666
"hello"
"info"
"output 1" <– Red on
"output 16" <-- Green on
"output 256" <-- Red blinking

Again X-Core-e only for now. Feedback welcome. Thanks.</pfsense>

mdima

@stephenw10:

This can't be right. :-\


[2.0.1-RELEASE][root@pfsense.fire.box]/root(7): ps aux | grep lcdproc
root    5983  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   22313  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   23243  0.0  3.4 47452 17184  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   25113  0.0  0.3  3656  1400  ??  IN   11:27PM   0:00.01 /bin/sh /usr/local/etc/rc.d/lcdproc.sh start
root   32258  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   59818  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php

Steve

Hi Steve,
yes, this can't be right!!

What do you think if I add to the stop script something like:

ps auxw |awk '/lcdproc_client/ {print $2}'|xargs kill

Thanks,
Michele