[As Good As Solved!] Watchguard Firebox Arm/Disarm LED
-
I took the file that you attached on your reply #59 in this thread and now the output looks alot better.
I am not physical close to it now so can not check bet still output looks promising:[2.0.1-RELEASE][root@host.box]/usr/local/bin(11): ./WGXepc2
Found Firebox X-Core
WGXepc Version 0.3 17:2:2011
WGXepc can accept two arguments:
-f (fan) will return the current fan speed or if followed
by a number in hex, 00-FF, will set it.
-l (led) will set the arm/disarm to the second argument:
red, green, red_flash, green_flash, off
Not all functions are supported by all models
[2.0.1-RELEASE][root@host.box]/usr/local/bin(12): ./WGXepc2 -l green
Found Firebox X-Core
[2.0.1-RELEASE][root@host.box]]/usr/local/bin(13):;D
-
-
I took the file that you attached on your reply #59 in this thread and now the output looks alot better.
I am not physical close to it now so can not check bet still output looks promising:[2.0.1-RELEASE][root@host.box]/usr/local/bin(11): ./WGXepc2
Found Firebox X-Core
WGXepc Version 0.3 17:2:2011
WGXepc can accept two arguments:
-f (fan) will return the current fan speed or if followed
by a number in hex, 00-FF, will set it.
-l (led) will set the arm/disarm to the second argument:
red, green, red_flash, green_flash, off
Not all functions are supported by all models
[2.0.1-RELEASE][root@host.box]/usr/local/bin(12): ./WGXepc2 -l green
Found Firebox X-Core
[2.0.1-RELEASE][root@host.box]]/usr/local/bin(13):;D
This did work… for future reference..
Just my bubu renaming an old version, still do NOT know how that happened, but again thank U Steve for all your help..
-
I have managed to resurrect my X-Core box after bending the chassis straight(er) and sticking bits back on with tape.
Since it's now up and running I decided to further investigate the LED states since it is possible to set it to 'dark' in the bios.
So carrying on from where we left off I investigated the remaining possible GPIO states:Experimental findings of ICH2 IO space; 0x4080-0x4083 Set pins as gpio or native functions. 1=gpio Default 1a003180 0001 1010 0000 0000 0011 0001 1000 0000 Found 1a203180 0001 1010 0010 0000 0011 0001 1000 0000 0x4084-0x4087 Set gpios as input or output. 1=Input Default 0000ffff Found 0000ffff bit 1 is input. Possible outputs are 0000 0000 0000 0000 1111 1111 1111 1111 1 1 1 1 (set as gpio & set as output) 0x408c-0x408f GPIO Levels Default 1f1f0000 Found 09bf0000 0000 1001 1011 1111 Therefore we have 4 possible bits with 16 possible states LED state 1 1 1 1 Address: 408f 408e Value: 019f 0000 0001 1001 1111 Red fast flash * 01bf 0000 0001 1011 1111 Red fast flash * 039f 0000 0011 1001 1111 Red fast flash * 03bf 0000 0011 1011 1111 Red fast flash * 099f 0000 1001 1001 1111 Red Steady * 09bf 0000 1001 1011 1111 Red Steady * 0b9f 0000 1011 1001 1111 Red Steady * 0bbf 0000 1011 1011 1111 Red Steady * 119f 0001 0001 1001 1111 Green flash fast * 11bf 0001 0001 1011 1111 Green flash fast * 139f 0001 0011 1001 1111 Green flash fast * 13bf 0001 0011 1011 1111 Green flash fast * 199f 0001 1001 1001 1111 Green Steady * 19bf 0001 1001 1011 1111 Green Steady * 1b9f 0001 1011 1001 1111 Green Steady * 1bbf 0001 1011 1011 1111 Green Steady *It's clear from those results that some of the GPIO bits we had previously identified as being set to both GPIO mode and to output are not doing anything useful. Also I failed to find OFF.
With nothing to loose I entered some large sweeping numbers and found a different bit that plays a part but should not!
I am at a loss to explain why this is so but can report some new results. I imagine I have suffered a logic failure some where but I cannot see it.
Anyway:Actual observed relevant bits are in fact different. Therefore 3 bits giving 8 possible states. LED state 1 1 1 Address: 408f 408e Value: 013f 0000 0001 0011 1111 Off * 01bf 0000 0001 1011 1111 Red fast flash * 093f 0000 1001 0011 1111 Red slow flash * 09bf 0000 1001 1011 1111 Red steady * 113f 0001 0001 0011 1111 Off * 11bf 0001 0001 1011 1111 Green fast flash * 193f 0001 1001 0011 1111 Green slow flash * 19bf 0001 1001 1011 1111 Green steady *So we have all states. It's clear that, on the X-Core at least, there is some other bit of electronics between the GPIO pins and the LED. It makes me wonder about the other boxes, perhaps I stopped testing too soon. ::)
Whilst fmertz is working to include LED support in the LCD driver I have included this new data into the WGXepc program. Find it attached along with the source. As before remove the .png extension and set the permissions. Any feedback welcome. :)
Steve
-
Thanks for the hard work. At this point, in terms of integrating this LED code into the main LCD driver, I am facing this dilemma:
-
For ease of use from a client perspective, the driver needs to provide a unified set of capabilities so all Fireboxes export the same capabilities.
-
Some boxes support just LED on or off, some do blink, some fast blink.
-
If we want to support blink and fast blink, we need to provide a software implementation for boxes that do not have it in hardware.
-
In addition, what about blinking red and green together, like R-R-G-R-R-G, etc?
I guess I am leaning towards a basic software implementation for blinking using just the GPIO pins to turn the LEDs on or off, and give up on hardware blinking.
Thoughts welcome.
-
-
I agree, now we have red, green and off for all the boxes it would be best to do anything else in software.
I think for most people simply having the LED go green at boot time will be sufficient. Anything else can be done with a separate lcdproc client that only controls the led.Another completely different idea would be to follow JimP's suggestion and have a separate FreeBSD led driver. This allows for all sorts of interesting possibilities, you can send data to /dev/led directly and have it flash a message in morse code for example. :) It's how the LEDs on the ALIX box are handled.
Steve
-
Anything else can be done with a separate lcdproc client that only controls the led.
separate FreeBSD led driver.
Maybe we can talk mdima into adding calls to output() in the existing php client. That client captures a range of things as it is.
Going down the driver path throws portability out the window. The code becomes FreeBSD only, and a completely separate implementation would be required for Linux. I have done neither, but, in the end, the purpose is to learn.
-
I hadn't considered portability.
Looking at the geode led driver they use the oem_bios function to indentify the different models. I guess this might be FreeBSD only.Steve
-
Just realised I posted the most recent version of this in the X700 thread and forgot to include it here.
Same as previous versions but includes an option to switch the LCD backlight if you aren't running LCDproc with the firebox driver.
Find it attached with the source.[2.0.1-RELEASE][root@pfsense.fire.box]/conf(8): ./WGXepc Found Firebox X-Peak WGXepc Version 0.5 13:2:2012 stephenw10 WGXepc can accept two arguments: -f (fan) will return the current fan speed or if followed by a number in hex, 00-FF, will set it. -l (led) will set the arm/disarm led state to the second argument: red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off -b (backlight) will set the lcd backlight to the second argument: on or off. Do not use with LCD driver. Not all functions are supported by all modelsSteve
-
More good work. What is anyone using for a fan speed setting? I have upgraded to the SL7EG CPU, run powerd and still have the original fans in my X750E.
Thanks!
Mike -
I'm using 64. However my test box is rarely loaded at all and it's sat on my desk not in a hot rack.
I have run them at 16 with no problems and barely any detectable temperature rise.
You can test it with cpuburn and mbmon.Steve
-
There is a new version of WGXepc.
Find it attached to this thread along with the source code.
As before remove the .png extension and chmod it 0755 once it's on the box.It now supports the XTM5 series boxes with LED and fan control (of sorts!).
I have tested it on all the known boxes with 2.0.x and 2.1beta but my testing is limited, let me know if it misbehaves.[2.0.3-RELEASE][root@pfsense.fire.box]/root(7): /conf/WGXepc Found Firebox X-Peak WGXepc Version 0.8 14/5/2013 stephenw10 WGXepc can accept two arguments: -f (fan) will return the current and minimum fan speed or if followed by a number in hex, 00-FF, will set it. -l (led) will set the arm/disarm led state to the second argument: red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off -b (backlight) will set the lcd backlight to the second argument: on or off. Do not use with LCD driver. Not all functions are supported by all modelsSteve
-
I added an option to read the cpu temperature sensor on the X-e box since it was trivial to do and mbmon seemed to giving some errors.
[2.1-RC0][root@pfsense.localdomain]/conf(3): ./WGXepc Found Firebox XTM5 WGXepc Version 0.9 28/6/2013 stephenw10 WGXepc can accept two arguments: -f (fan) will return the current and minimum fan speed or if followed by a number in hex, 00-FF, will set it. -l (led) will set the arm/disarm led state to the second argument: red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off -b (backlight) will set the lcd backlight to the second argument: on or off. Do not use with LCD driver. -t (temperature) shows the current CPU temperature reported by the SuperIO chip. X-e box only. Not all functions are supported by all modelsSteve
-
I added an option to read the cpu temperature sensor on the X-e box since it was trivial to do and mbmon seemed to giving some errors.
[2.1-RC0][root@pfsense.localdomain]/conf(3): ./WGXepc Found Firebox XTM5 WGXepc Version 0.9 28/6/2013 stephenw10 WGXepc can accept two arguments: -f (fan) will return the current and minimum fan speed or if followed by a number in hex, 00-FF, will set it. -l (led) will set the arm/disarm led state to the second argument: red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off -b (backlight) will set the lcd backlight to the second argument: on or off. Do not use with LCD driver. -t (temperature) shows the current CPU temperature reported by the SuperIO chip. X-e box only. Not all functions are supported by all modelsSteve
I used your latest Ver 0.9 and edited the /usr/local/www/includes/functions.inc.php file (find and modify these entries in the file):
function has_temp() {
/* no known temp monitors available at present */
/* should only reach here if there is no hardware monitor /
/ return false; */
return true;
}function get_temp() {
$temp_out = "";
exec("/conf/WGXepc -t | /usr/bin/awk 'NR==3{print;exit}'", $dfout);
$temp_out = trim($dfout[0]);return $temp_out;
}Now the temp displays on the Dashboard pulling from WGXepc.
Tested on Firebox X550e
-
Nice. :)
Let me know if it seems stable. It should be identical to mbmon but like I said another user found mbmon giving bad numbers after several days. Also mbmon has 0.5°C accuracy but I didn't both reading that register so it's only 1°C accurate. ::)Steve
-
Sweet, thanks for the code, it worked like a charm, appears within 2 degrees of mbmon at any one point. Looks like I need to throw some arctic silver on the heatsink. This is fan at 32
-
Sweet, thanks for the code, it worked like a charm, appears within 2 degrees of mbmon at any one point. Looks like I need to throw some arctic silver on the heatsink. This is fan at 32
I had my fan set at 52 on a Pentium M 735 and at 37C. On high load, it will come up to 50. Im not worried about the $7 processor so much as having the system lock up when I am away. lol
-
Very nice, many thanks!
-
-
Only one parameter at a time. My coding skills very limited. ;)
I use the shellcmd package instead of an RC script. It is stored in configuration file so it survives a firmware update.Steve
