LCDProc 0.5.4-dev
-
stephenw10, great, thanks for the feedback!!
Michele
-
The changes are published on the version "LCDproc 0.5.4 pkg v. 0.7".
Michele,
Just to throw it out there: any reason to settle on lcdproc-0.5.4? Seems like lcdproc-0.5.5 has been out for a couple of months. Maybe before you commit to merging this -dev package to make it official, we could upgrade to the latest and test among ourselves. I have no specific need to upgrade, just trying to get folks to benefits of the latest version. As usual, I'll be happy to provide a 0.5.5 binary of the SDEC driver if needed.
-
The changes are published on the version "LCDproc 0.5.4 pkg v. 0.7".
Michele,
Just to throw it out there: any reason to settle on lcdproc-0.5.4? Seems like lcdproc-0.5.5 has been out for a couple of months. Maybe before you commit to merging this -dev package to make it official, we could upgrade to the latest and test among ourselves. I have no specific need to upgrade, just trying to get folks to benefits of the latest version. As usual, I'll be happy to provide a 0.5.5 binary of the SDEC driver if needed.
you're right! I've just seen that lcdproc-0.5.5 is available in the package directory (http://files.pfsense.org/packages/8/All/), it was uploaded on the 20th of December… on the next release I will use that binaries, at a first sight it should have the same drivers than 0.5.4, so there should not be any change in the package itself...
After that, we can see if we need a new compiled version for the sdelcd driver or not!
Ciao,
Michele -
Tested on the X-Core-E box.
Just offering a suggestion up for a vote: For folks running pfSense on the Watchguard Firebox, would it be better if the driver entry in the web interface was called "Watchguard Firebox w/ SDEC LCD" instead of "sdeclcd"? It seems like the average person might not know (or need to care) that the LCD is from SDEC. Besides, the driver is kind of hard-coded for that implementation already. Just a thought.
-
Tested on the X-Core-E box.
Just offering a suggestion up for a vote: For folks running pfSense on the Watchguard Firebox, would it be better if the driver entry in the web interface was called "Watchguard Firebox w/ SDEC LCD" instead of "sdeclcd"? It seems like the average person might not know (or need to care) that the LCD is from SDEC. Besides, the driver is kind of hard-coded for that implementation already. Just a thought.
I don't know if Watchguard is the only company that use that panel… maybe something like:
"sdeclcd (Watchguard Firebox w/ SDEC LCD, etc)"
would be better, what do you think?
The same could be for all the other panels... would be a little mess to keep them updated. -
- Added the "output led" support for the "CFontz633" driver.
Michele,
Following the hard work of stephenw10, it is now known how to control the LED (just one) on the same Watchguard Fireboxes that we have the SDEC driver for. This LED, labeled "Armed/Disarmed" can be made Red or Green, and be off, on, or blinking. I was thinking of developing an output function in the driver code, trying to mirror the convention of the CFontz driver. Obviously, the output function would have to be called in from the client side, with some logic. Maybe folks can chime in and offer suggestions on how to control the meaning of the LED from the client side. I can focus on the implementation part in the driver.
From you commit, it seems like this code already exists in the client, but specifically for the CFonts driver:
-
LED1: NICs status (green: ok, red: at least one nic down)
-
LED2: CARP status (green: master, red: backup, off: CARP not implemented)
-
LED3: CPU status (green < 50, red > 50%)
-
LED4: Gateway status (green: ok, red: at least one gateway not responding, off: no gateway configured).
Maybe the logic for LED4 is what makes sense here…
-
…
From you commit, it seems like this code already exists in the client, but specifically for the CFonts driver:
Maybe the logic for LED4 is what makes sense here...If you want to implement the same algorithm for the CFontz driver, you can use values frin 0 to 255. Every bit of the byte turns on a led, as follows:
bit 0: first led green
bit 1: second led green
bit 2: third led green
bit 3: fourth led green
bit 4: fifth led red
bit 5: sixth led red
bit 6: seventh led red
bit 7: eight led redif you combine bits, in CFontz, you get "orange" (even if I didn't use that).
The syntax is: output<space>value[0..255]If you are developing the driver, maybe it could have sense to use the same code in order to have only 1 algorithm to mantain… also you can start with one led and add the others when it will be discovered how to control them...
What do you think about that?
Ciao,
Michele</space> -
I don't know if Watchguard is the only company that use that panel… maybe something like:
"sdeclcd (Watchguard Firebox w/ SDEC LCD, etc)"
would be better, what do you think?
The same could be for all the other panels... would be a little mess to keep them updated.This driver is for the SDEC LCD (generic, I guess), but specifically coded for the Watchguard wiring (parallel port with this control bit going to this particular line on the LCD,…). Others could possibly have an SDEC LCD, but there are many possibilities of wiring it, even with a parallel port. Bottom line is that I would not expect this driver to work on any other implementation of an SDEC LCD without reworking some of the code. As far as I know, the only testing that has ever been done is with these Fireboxes. Also, as you know, these boxes came with the SDEC LCD built-in, there is no home-made setups this driver is supposed to support.
At some future point, when the current models of Fireboxes become retired and available in the used market, they will need another driver anyway. I was hoping they would all sort nice like:
Watchguard Firebox w/ SDEC LCD
Watchguard Firebox w/ <new>LCDNo worries, whatever works.</new>
-
if you combine bits, in CFontz, you get "orange" (even if I didn't use that).
If you are developing the driver, maybe it could have sense to use the same code in order to have only 1 algorithm to mantain… also you can start with one led and add the others when it will be discovered how to control them...
That is the general idea, but there is no blink supported in there. I'll have to think of something.
There is no Orange supported on Fireboxes, as far as I know, and only one LED location visible to users.
Well, the actual control of the 2 LEDs is with GPIO. It boils down to simple "out" instructions, but coming up with code that determines the right ports/bits in a portable manner is a bit of a challenge. GPIO is part of the Southbridge device, and a number of different devices have been reported. And with each device, the LEDs were mapped to different bits. Stephenw10 has it all mapped, fortunately, so now it is a matter of coming up with clean code for it. Where would the fun be without a challenge! -
Renaming the menu option as 'Firebox (sdeclcd)' would probably be useful. If only to reduce the number questions on the forum!
The keypad is a Watchguard part it's not on the sdeclcd module so in the unlikely event that someone was using a compatible sdec display it would need a different keypad driver anyway (if it had a keypad).Steve
-
Hi Brak,
lcdexex is not run at all, the package use its own client to interact with LCDproc. Sorry about the question, why do you need it to run?I use a menu I made that runs in LCDExec, it does like reboot commands and stuff. I can't get it to cleanly start up with this package.
Hi Brak,
did it work with the previous version of LCDproc? (I mean, not LCDproc-dev) Just to understand if it's something I made that interfers with your menu.Can I have your lcdd.conf? Just to look which are the changes you need for your menu to work…
Thanks,
MicheleWell, tbh, I can't get the completely default package to work with the example menu if I rename "lcdexec.conf.sample" to "lcdexec.conf" - I checked perms, too. And yes, I had it working with that standalone firebox LCDProc package that was on here. All I did was execute "./lcdexec -c ./lcdexec.conf" after LCDProc was up and running.
Am I missing something to enable LCDExec and for it to run from the lcdexec.conf?
-
Well, tbh, I can't get the completely default package to work with the example menu if I rename "lcdexec.conf.sample" to "lcdexec.conf" - I checked perms, too. And yes, I had it working with that standalone firebox LCDProc package that was on here. All I did was execute "./lcdexec -c ./lcdd.conf" after LCDProc was up and running.
Am I missing something to enable LCDExec and for it to run from the lcdexec.conf?well… I am updating LCDproc to version 0.5.5 (package 0.8, will be released soon), I hope that this will solve your problem. If not please send me the your file lcdd.conf that I try to look what is wrong. Consider that this file changes machine to machine and does not contain any sensitive information.
Thanks,
Michele -
Hello,
I just pushed a new version for the package. The changes are:Updates LCDProc to 0.5.5 (very experimental!)
Rename the sdelcd driver to "Watchguard Firebox w/ SDEC LCD"All feedbacks are welcome!
Michele -
Tested 0.8 on my X-peak box after upgrading it to 2.0.1. Seems to work OK. :)
A couple of small things I noticed, this may have been true of previous versions I'm not sure.
The screen does not appear to be scrolling. I have the uptime screen enabled and it displays "up 12mins, 1 us " where it should say 'user'. Though there are characters available to display that. Perhaps a driver problem?
The service does not start until I go to Status: Services: and click 'start' next to LCDproc. This seems odd to me as the service should be restarted every time the changes are made to the config by the call to 'LCDproc.sh restart'.
Edit: Reading through lcdproc.inc (for the hundredth time!) it will only call for a service restart if lcdproc is already running. If it is not running and changes are made, as is the situation immediately after installation, then there is no call to start it.
This is where I hit trouble trying to make the package firebox only. It's not obvious to me how the start and stop logic works. It looks like the only way to stop the service is to remove the settings rather than uncheck the 'enable LCDproc' tick box. :-\ As I said this is where my skills ran out so I could easily be missing something.
Also there appears to be no point calling for a service restart since start contains stop as it's first command. Calling service start would seem to be sufficient.
Steve
-
The screen does not appear to be scrolling. I have the uptime screen enabled and it displays "up 12mins, 1 us " where it should say 'user'. Though there are characters available to display that. Perhaps a driver problem?
I compiled the driver code in the lcdproc-0.5.5 tree. The resulting file is
https://github.com/downloads/fmertz/sdeclcd/sdeclcd.so
Just in case there is an updated needed from lcdproc-0.5.4 …Feel free to update the driver file itself and restart. If it works better, I'll be happy to open a request with pfSense to make it the default for everyone.
-
Hello Steve,
I try to quote you:Tested 0.8 on my X-peak box after upgrading it to 2.0.1. Seems to work OK. :)
That's great, also on the "sureelect" driver seems to work OK!
A couple of small things I noticed, this may have been true of previous versions I'm not sure.
The screen does not appear to be scrolling. I have the uptime screen enabled and it displays "up 12mins, 1 us " where it should say 'user'. Though there are characters available to display that. Perhaps a driver problem?and again, the same problem is with my driver, so it does not look like something driver related.
But the "widgets" are sent all as "scroller", so I don't know what this is related to… I need to investigate a bit, maybe it is something broken in the package, maybe it's something broken in the LCDproc binaries...The service does not start until I go to Status: Services: and click 'start' next to LCDproc. This seems odd to me as the service should be restarted every time the changes are made to the config by the call to 'LCDproc.sh restart'.
Edit: Reading through lcdproc.inc (for the hundredth time!) it will only call for a service restart if lcdproc is already running. If it is not running and changes are made, as is the situation immediately after installation, then there is no call to start it.well… when you start the box, the service is started (if it's enabled in the package configuration).
Then when you apply some changes to the service settings, the service is restarted. If the service is not running when the changes are applied to the package, the service is not started.
This was the behavour the package had before, and I find it reasonable (if I stopped the service for some reason, it just stay stopped).
Do you agree with that?Also there appears to be no point calling for a service restart since start contains stop as it's first command. Calling service start would seem to be sufficient.
The point is that to apply the changes you make to the configuration, the service must be restarted. Some of the settings and all the "screens" are defined only when the service starts, so if for example you add a new screen, the service must be restarted to apply this change. But there's no need to stop or restart the service manually before applying any change.
I agree that this "stop-restart" is reduntand since in the function "start" there's already a "stop the service" command, this is a bit more "safe" and has been inherited by the previous developer… I think that the previous developer thought to make it safer since for this package there are more than one program running, and in this way he was really SURE that before a start the service was not running anymore. I could simplify it, but I would prefer to keep it "safer" as it is (anyway, if the service is not running when it's called a "start", no code is executed). Consider that the package can be run also from other parts, or from the interface, from a refresh, and so on, this "safe" code avoids to have more than one program running in the background!Ciao,
Michele -
Hi Steve,
about that:The screen does not appear to be scrolling. I have the uptime screen enabled and it displays "up 12mins, 1 us " where it should say 'user'. Though there are characters available to display that. Perhaps a driver problem?
after some investigation I found out that is the "uptime screen" that has a little problem, not the scrolling. If you enable the "interface screen" you will see your panel scrolling… Anyway, I fix that!
Ciao,
Michele -
This was the behaviour the package had before, and I find it reasonable (if I stopped the service for some reason, it just stay stopped).
Do you agree with that?Yes that seems reasonable and expected behaviour.
However I think that most users would expect the service to start if you tick the 'enable LCDproc' check box and then click save.
This is especially true just after installation when you have first setup the variables.
I think either it should instruct users to start the service manually or the service should start automatically.
Perhaps relabel the check box 'Enable LCDproc at boot time'?Consider that the package can be run also from other parts, or from the interface, from a refresh, and so on, this "safe" code avoids to have more than one program running in the background!
I agree. :)
Steve
-
Hi Steve,
Perhaps relabel the check box 'Enable LCDproc at boot time'?
yes, I agree… you will find it the next release!
Ciao,
Michele -
For further reducing user confusion you can include instructions using the <after_install_info>tag in pkg_config.8.xml. E.g.
<after_install_info>Now configure your display in Services: LCDProc: then start the daemon in Status: Services:</after_install_info>
or something like that! ;)
Steve</after_install_info>
-
For further reducing user confusion you can include instructions using the <after_install_info>tag in pkg_config.8.xml. E.g.
<after_install_info>Now configure your display in Services: LCDProc: then start the daemon in Status: Services:</after_install_info>
or something like that! ;)
Steve</after_install_info>yes, that's totally a good idea… you'll find it in the next release...
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? I mean, to release it for real?
Thanks,
Michele -
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
-
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)?
Steveok… 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
-
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…
-
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
-
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 -
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. :-
Steveme 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... -
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
-
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
-
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 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
-
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
-
been running the 0.5.5 pkg for a couple of days now and no issues so far with the picolcd driver…
-
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.
-
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?
-
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.
-
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?
-
- 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.
-
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
-
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