[Version 2 Release] RaspberryPints - Digital Taplist Solution

[day_trippr]

As long as the AlaMode is registered to the RPi - any Rpi - at the pin 1/2 end of the IO header, it will work fine. I have two Model 2 systems running with AlaModes.

If you've done the v2.0.1 installation, try stopping the flowmon service before trying to connect to the AlaMode using the Arduino IDE.

$ sudo /etc/init.d/flowmon stop

It may be that the python listener script is getting in the way of the Arduino IDE...

Cheers!

 

[Guper]

Thank you so much for the quick reply. Unfortunately that didn't seem to do the trick. Is it an issue that I'm using my Raspberrypi that was already running raspberypints? Or are all of the other python scripts not likely to get in the way since they aren't attempting to communicate with the alamode? When I attempt to upload I do see a few blinks on the pin 13 LED, but it still seems to not want to upload.

 

[day_trippr]

The only script that communicates with the AlaMode is flow_monitor.py.
Stopping the flowmon service should take care of that.

If you're seeing blinks on the AlaMode then the IDE is talking to it (or trying to). I don't think it would get that far if the IDE thought the port was tied up already.

btw, do you see an AlaMode choice in the IDE?

Cheers!

 

[Guper]

Wow thank you guys so much! After initially not having success with the suggested fix I went ahead and just tried to reboot the pi and stopping the script and uploading the arduino sketch. This time it worked perfectly and my pours are registering! Thanks so much for helping a fella out.

Cheers!

 

[ChrisL_]

Good to see you're making progress.

As for the tvservice thing: I still have a problem returning to the on state; the color is definitely altered from the normal/default such that everything looks slightly neon or "electric". There must be some parameter that's not right for my recent vintage HDMI monitor.

Anyway, that aside, I was hoping to have xscreensaver run the command to shut off the display and have my pir_run turn it back on, but xscreensaver doesn't have the ability to run a program.

So I don't have a way to turn off the screen yet, but I'm thinking I need to figure out how to use the xscreensaver "watch" function with Python...

Cheers!

So I finally got some time to sit down and run a few tests. I found that in fact the fbset -depth 8 and fbset -depth16 after a tvservice -p brought back only a small portion of my screen. So I dug around an little more and found that changing the virtual terminal away from x and then back works reliably.
sudo tvservice -o
sudo tvservice -p
sudo chvt 6
sudo chvt 7

I think "X" is always VT7? Not sure, but using
sudo fgconsole
will give you the current console, which you can store and use to switch back to the correct VT before changing away from it.

Hopefully this helps.

 

[2Kegger]

Hey all,

I've modified my taplist so that I can put the images from my tap handles on my list. It seems some people have trouble figuring out what 1,2,3,4 and 5 mean. I used some code from another user who put pool balls on his, and I'm sorry, I can't remember who that was. Basically, I made images for tap handles (http://www.micromatic.com/draft-keg-beer/tap-handles-pid-C100-4-M.html) and then used the same images for my tap list. I shrunk them down a bit, and number name them 1-Tap, 2-Tap, etc...

Then I do this:
Changing Tap images:

It's a pretty easy change to make. – INDEX.PHP

The original code line just wrote the tap number:
Code:
<span class="tapcircle"><?php echo $i; ?></span>

I added extra code as an image tag to use the tap number plus additional characters to make up the file names (e.g. 1-Tap.jpg, 2-Tap.jpg, etc):
Code:

<img src="img/<?php echo $i; ?>-Tap.jpg" alt="">

 

[DrunkleJon]

Do the pictures update when you change out a keg in RPints or is that more of a manual process?

I was thinking of attempting to dredge up my coding skills to attempt to either add a photo to the description field for this or add another column to the table.

 

[2Kegger]

It's manual. I just make a new image and name it 1-Tap.jpg our whatever I am replacing. I don't need to change any code

 

[froot]

One weakness in the RaspberryPi platform is the sdcard storage scheme. It's not what I would consider robust. I had a card totally die last December, and today the sdcard in my "production" system that runs my tap list, ferm fridge, carb fridge and keezer gagged up a bad block that panicked the kernel on reboot. It needed a fresh format and a re-imaging.

As all four of my RPi systems are now sharing a single sdcard image it only takes the time to write a card again, say 15 minutes, plus a few minutes changing the system name and IP address, to get the system back on the air. But what inevitably gets lost is the current RaspberryPints tap list data, and all of the BrewPi logs and scripts and my temperature logger data.

Out of all that, the one I actually care about is the tap list data. It's a pita to try to re-create the database state to a "best guess" of what and how much is on tap. So at the least, I need a way to copy the running database to a safe location.

On my RPi systems, MySQL databases are stored in /var/lib/mysql.
In that folder there is a raspberrypints folder, which contains all of the forms for the RaspberryPints database.

But the data file is /var/lib/mysql/ibdata1

And as my experiments have shown, it can be cloned, copied, backed-up, restored...whatever. Having a copy of that data file somewhere handy is A Good Thing, and obviously, the more current the better.

While I could fire up WinSCP and pull a copy to my workstation when I remember to do it, instead I will be getting grive running, to automate the back-up of my 'Pints data file, temperature logger and BrewPi data...

Cheers!

I was thinking about this, and the problem is inherently the number of writes to the SD, would it be possible to relocate the Data Base(s) to a networked drive "J linked" as a local drive or even as a folder, that way an SD crash is a very simple job of cloning?

 

[day_trippr]

I was thinking about this, and the problem is inherently the number of writes to the SD, would it be possible to relocate the Data Base(s) to a networked drive "J linked" as a local drive or even as a folder, that way an SD crash is a very simple job of cloning?

I don't know enough about MySQL to know if locating the database on a network share is possible, and for sure don't know how to make that happen. But I think I'd be adverse to creating a real-time dependency on an external resource, anyway.

I ended up cloning the database to a local share as a nightly cron task. Wicked easy to set up and it's clicking away perfectly.

And when you think about this offers better data availability versus just moving the database.
If the relocated database were to get corrupted somehow, you'd be just as screwed as if the database was still resident on the RPi and was never backed up...

Cheers!

 

[crane]

So I finally got some time to sit down and run a few tests. I found that in fact the fbset -depth 8 and fbset -depth16 after a tvservice -p brought back only a small portion of my screen. So I dug around an little more and found that changing the virtual terminal away from x and then back works reliably.
sudo tvservice -o
sudo tvservice -p
sudo chvt 6
sudo chvt 7

I think "X" is always VT7? Not sure, but using
sudo fgconsole
will give you the current console, which you can store and use to switch back to the correct VT before changing away from it.

Hopefully this helps.

I had work off yesterday for the 4th, so I spent some time modifying the pir_run.py script to use tvservice instead of the screensaver. I found that inside a python script xrefresh wasn't happy, so I tried "tvservice -p && chvt 6 && chvt 7" and that works. I also found that after calling os.system(cmd) in the main while loop would break the callback "MOTION" function. The callback function was never getting called as I would never see the print statement that you get upon entering the function. Instead of finding the root cause of this issue I worked around it by remove and re-adding the GPIO event detect.

I have the sleep_threshold set for 60 seconds. This is how long it will sit without seeing any activity before it puts the monitor to sleep.

Give it a try and see if it works for you. Just create a new pir_run.py file with this code and copied it over to the location of the original script and rebooted the pi for it to start using this new script. Also, disable your screensaver.

#!/usr/bin/env python

import pwd, os
import RPi.GPIO as GPIO
import time

cmd_sleep = 'tvservice -o'
#cmd_wakeup = 'tvservice -p && fbset -depth 8 && fbset -depth 16 && xrefresh -d :0'
cmd_wakeup = 'tvservice -p && chvt 6 && chvt 7'

GPIO.setmode(GPIO.BCM)
PIR_PIN=7
GPIO.setup(PIR_PIN, GPIO.IN)

sleep_threshold = 60

def MOTION(PIR_PIN):
	global start_time
	global elapsed_time
	print "motion detected"
        if elapsed_time > sleep_threshold:
		os.system(cmd_wakeup)
	start_time = time.time()
	elapsed_time = 0
        time.sleep(1)

time.sleep(2)
start_time = time.time()
elapsed_time = 0

try:
	GPIO.add_event_detect(PIR_PIN, GPIO.RISING, callback=MOTION)
	while 1:
		print "check if its time to sleep"
		if elapsed_time > sleep_threshold:
			os.system(cmd_sleep)
			GPIO.remove_event_detect(PIR_PIN)
			GPIO.add_event_detect(PIR_PIN, GPIO.RISING, callback=MOTION)
			print "going to sleep"
		else:
			elapsed_time = time.time() - start_time
		time.sleep(10)

except KeyboardInterrupt:
	GPIO.cleanup()

 

[day_trippr]

Well, two thumbs up wrt the python script turning the display on and off.

But the display still comes back all neon-ish. If I switch it to a different HDMI input (cable box) the color is fine, so it's definitely the video engine in the 'Pi that's the issue.

I had this same problem with my original Model B, too, when trying to use tvservice commands, which was one of the reasons I stopped chasing the dragon

Somewhere there's a setting that's not being written with the magical value needed to restore the correct color space...

Cheers!

 

[ChrisL_]

Hey day_trippr. Thanks for taking this on. I will give this a try. Did you happen to notice my post earlier (1205)? I found changing the virtual terminal to say six and then back to X at vt7 refreshes my screen perfectly.

 

[day_trippr]

Are you referring to this:

$ sudo tvservice -o
$ sudo tvservice -p
$ sudo chvt 6
$ sudo chvt 7

As one would expect, the same color problem occurs with the second line.

The third line then initiates a full-screen terminal session splatted across the console display asking for user credentials.
The fourth line restores the desktop to the console display...complete with the neon color map.

No gain on the play...

Cheers!

 

[wbarber69]

Maybe your screen is having problems with Hdmi handshake. Is the color space set to auto. Maybe the cable box is using the one I can't remember when I'm this drunk and the pi is using rgb or vice-versa. I have issues with my projector when switching modes while all components are already on. Changing everything to the same color space fixed the issue.

 

[ChrisL_]

Crane, my apologies. I did not realize you had posted the code and not day_trippr and gave him the thanks. So thanks to you crane! I tested your script and it works like a champ. I really appreciate the effort. (and on the 4rth of July when you should have been drinking beer instead of coding:rockin

@day_trippr. I wonder if you would have any more luck if you changed the order of operations. Maybe try changing to vt6 first, then tvservice -o to power down. Then come back up with tvservice -p and then chvt7 back to X.

My thought is that maybe going to chvt6 may preserve your X settings before taking away the power. Hopefully that helps?

 

[ChrisL_]

Maybe I spoke too soon
If the monitor goes the sleep and I wake it up within a minute or two it is ok, but if I walk away and come back a half an hour later it seems the PI seems to be crashed. The monitor will not wake up and I cannot ping or SSH to the PI.
Crane, have you tested this scenario where you leave it asleep for a little bit longer time?
I have stopped the pir_run.py script and rebooted now just to double confirm that my PI is not crashing for some other strange reason.

Chris

 

[day_trippr]

fwiw, I tried the tvservice -o/-p on the RPi2 that actually runs my keezer/tap list/brewery fridges.
That system has a DVI monitor, and tvservice -o definitely puts it into low power mode (good!).
But tvservice -p won't bring back the display - it comes out of low power mode, but there's just the black screen.

'Pi was still alive and all. Tried power-cycling the monitor, no joy.
The display was kaput until I restarted the system...

Cheers!

 

[crane]

Maybe I spoke too soon
If the monitor goes the sleep and I wake it up within a minute or two it is ok, but if I walk away and come back a half an hour later it seems the PI seems to be crashed. The monitor will not wake up and I cannot ping or SSH to the PI.
Crane, have you tested this scenario where you leave it asleep for a little bit longer time?
I have stopped the pir_run.py script and rebooted now just to double confirm that my PI is not crashing for some other strange reason.

Chris

Yeah I observed the same thing this morning. Not sure what is causing it to crash. I will try to debug it this week.

 

[ChrisL_]

Yeah I observed the same thing this morning. Not sure what is causing it to crash. I will try to debug it this week.

I did a little more digging last night and found that the PI had not crashed. It appears the NIC is going into a sleep mode. The first few pings fail but then it wakes up after a few seconds.

This allowed me to SSH in and using "ps aux | grep pir_run.py" shows the script seems to have stopped running. I have not been able to determine why at this point. At this point, if I manually use the wake up commands they still work.

 

[crane]

I did a little more digging last night and found that the PI had not crashed. It appears the NIC is going into a sleep mode. The first few pings fail but then it wakes up after a few seconds.

This allowed me to SSH in and using "ps aux | grep pir_run.py" shows the script seems to have stopped running. I have not been able to determine why at this point. At this point, if I manually use the wake up commands they still work.

I ran the script in an ssh terminal after disabling it in autostart and it eventually crashed with this.

Traceback (most recent call last):
File "pir_run.py", line 38, in <module>
GPIO.add_event_detect(PIR_PIN, GPIO.RISING, callback=MOTION)
RuntimeError: Failed to add edge detection

So removing and re-adding the call back function to work around another issue has its own side affects. Time for another beer.

 

[day_trippr]

I'm telling y'all, you're in the deepest darkest rathole in all of 'Pidome...

Cheers!

 

[crane]

I'm telling y'all, you're in the deepest darkest rathole in all of 'Pidome...

Cheers!

Yes it appears that way. I tried throwing the GPIO calls into a while loop with a try/catch block but once it fails once it will continuously fail until you exit the script.

 

[eulipion2]

Quick question: installed RPints today (no flow meters), and now I reboot, but it doesn't automatically startup (also, no idea how to enter Chromium's kiosk mode manually). The page shows if I enter the IP address, even from another computer on my network, but no auto-start.

My /etc/xdg/lxsession/LXDE/autostart file contains the following:

@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
@screensaver -no-splash

@xset s off
@xset -dpms
@xset s noblank
@chromium --kiosk localhost

That's the only reference I can find in the installation guide that deals with the actual display portion of things. Can someone give me a hand? Thanks!

 

[ChrisL_]

Quick question: installed RPints today (no flow meters), and now I reboot, but it doesn't automatically startup (also, no idea how to enter Chromium's kiosk mode manually). The page shows if I enter the IP address, even from another computer on my network, but no auto-start.

My /etc/xdg/lxsession/LXDE/autostart file contains the following:

@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
@screensaver -no-splash

@xset s off
@xset -dpms
@xset s noblank
@chromium --kiosk localhost

That's the only reference I can find in the installation guide that deals with the actual display portion of things. Can someone give me a hand? Thanks!

Put the same file contents in /etc/xdg/lxsession/LXDE-pi/autostart (note the -pi after LXDE)

 

[eulipion2]

Put the same file contents in /etc/xdg/lxsession/LXDE-pi/autostart (note the -pi after LXDE)

My hero! Started right up Thank you!

 

[day_trippr]

Yes it appears that way. I tried throwing the GPIO calls into a while loop with a try/catch block but once it fails once it will continuously fail until you exit the script.

Well I wasn't referring to the pir scripting, but the whole notion of achieving a low-power "DPMS-like" state with the RPi.

I've totally lost track of all the different ways I've tried to make that happen (fortunately, they're all written up in my system logs) and sank a hella lot of time into the effort with no joy.

It's my White Whale...

Cheers!

 

[ChrisL_]

EDIT: I had a version of the PIR_RUN.PY script that was running for a while without issue. But something happening to my RPi over night. I don't know if my script could some how be related, but I now cannot get X to load. I get the splash screen and see everything during the "text" portion of the boot. But then when it should load X the screen is blank. I can load other VTs but X is just a totally blank screen :-(
I put an older backup image of on my SD and it is working, so physically the RPi seems ok.

Update. I had taken out a sleep statement when cleaning up the code before posting it. That resulted in /home/pi/.xsession-errors filling up my SD card, which prevents X from running. So I think my script is working, but I am going to test for a couple of days before posting.

 

[hardyhop]

Hello everybody. Just got my alamode soldiered last night and following the directions to get everything up and running. I'm on step 9, and testing the flowmon by typing in:

$ sudo /etc/init.d/flowmon start $ ps aux | grep flow_monitor.py


The directions state that I should get this response.

pi 3508 0.0 0.9 8796 4112 ? S 15:35 0:00 /usr/bin/python /home/pi/raspberrypints/python/flow_monitor.py pi 3558 0.0 0.1 3548 808 pts/0 S+ 15:43 0:00 grep –color=auto flow_monitor.py

I GET NO RESPONSE FROM MY PI...just goes back to the pi@raspberrypi ~$

I'm stuck, not sure what I should do. Any help would be greatly appreciated.

 

[day_trippr]

This sounds suspiciously like you installed the v2.0.0 kit and not the v2.0.1 "hotfix" kit - that actually includes the required flowmon service file as well as the flow_monitor.py listener script.

Do this:

pi@rpints ~ $ ls /var/www/python

You should see this:

flowmon  flow_monitor.py
pi@rpints ~ $

If you don't see both files, then download the v2.0.1 kit from here.

There were other changes getting to v2.0.1, so I'd recommend just blowing the new kit down over your existing kit. Everything should end up in the right place...

Cheers!

[edit] Also, the RaspberryPints root folder may actually be at /var/www/html if the RPi was recently built, so you may need to look in /var/www/html/python for the two files.

Finally, a less ambiguous way to check the flowmon status:

$ sudo /etc/init.d/flowmon status

 

[SilverZero]

Whoops, stupid HBT Android app got me again. This is meant as a reply to day_trippr's post a couple of pages back about SD card corruption.

There are a lot of tutorials out there that show how to put most of the actual system on a USB drive or even a USB hard drive, leaving only the boot code on the SD card. That's the route I'd go, old 60gb laptop drive in a small SATA enclosure. You'd need to power it either with a powered hub or a powered enclosure.

 

[day_trippr]

Leaving aside performance implications, that makes a generalized assumption that the flash memory inside a USB stick is significantly less likely to fail than the flash memory inside an SD card.

I don't think I'd take that bet.

The hard drive thing has an attraction, but it's overkill given simpler alternatives, and being at best a USB2 solution, a performance choke point as well. And then there's the power consumption of spinning media.

Using a USB stick in addition to an SD card would actually lower the total system availability (more things to fail). And if important files aren't being duplicated/archived there's a pretty big exposure to data loss.

In any case, my approach is to automatically archive "volatile" files to a network share, and standardize the SD card image across all four of my RPi systems to simplify the management thereof. Recovery from a whacked card takes a few minutes, and nothing of significance is at risk of loss...

Cheers!

 

[hardyhop]

day_trippr. Thank you for your quick response. I absolutely intially downloaded and installed 2.0.1. I tried the first command:

ls /var/www/python. And got exactly what you stated.
flowmon flow_monitor.py

I then:

$ sudo /etc/init.d/flowmon status

and got

[ok] /var/www/python/flow_monitor.py is running
$

So should I assume all is good to go? My five sf800s are in route.... Just found it discomforting that I did not get the response listed in step 9. Want to be ready to test when they arrive

Thank You So much for your help! Incredibly grateful for your amazing skills and for sharing with other homebrew/gadget enthusiasts!

 

[day_trippr]

Yes, I believe you're in good shape.

I just noticed that the command you tried is actually two commands.

This:

$ sudo /etc/init.d/flowmon start $ ps aux | grep flow_monitor.py

should actually be:

$ sudo /etc/init.d/flowmon start 
$ ps aux | grep flow_monitor.py

I tried the original and got the same "nothing returned" result...

Cheers!

 

[hardyhop]

thank you day_trippr. I tried the commands individually and got it to respond with a similar readout
I think I am ready to hook up the flow meters. Just waiting for them to arrive. hopefully faster that the 15 business days I was quoted.

I appreciate the help!

Cheers!

 

[ChrisL_]

OK, now I am confident my motion detection script enabling HDMI signal enable/disable is working correctly. For the info of anyone not up to date on the thread there have been a few attempts to get the motion sensor to put the monitor in and out of sleep mode when no motion is detected from the sensor. I came up with the script below that has been working for me.

Anyone interested in giving it a try can simply backup the existing pir_run.py script in /home/pi and then paste in the code below.

@ day_trippr. I know you have not had much luck but I am curious is changing the order of the commands would work any better? My theory is changing to another Virtual Terminal before killing the HDMI signal may hopefully save the colour settings for your X session?

Hope this helps others trying to get their monitor in and out of sleep mode via the PIR.

#!/usr/bin/env python
import pwd,os
import time
import RPi.GPIO as GPIO

pir_pin = 7
GPIO.setmode(GPIO.BCM)
GPIO.setup(pir_pin, GPIO.IN)
global start_time
start_time=time.time()
sleep_threshold = 60
monitor_status = 1
cmd_sleep = 'chvt 6 && tvservice -o'
cmd_awake = 'tvservice -p && chvt 7'
time.sleep(10)

while 1:
    time.sleep(10)
    elapsed_time = time.time() - start_time
    print elapsed_time
    print monitor_status

    # turn off monitor after the sleep threshold
    # monitor_status value avoids turning of HDMI signal if it is already off
    if elapsed_time > sleep_threshold and monitor_status == 1:
        print "Turning Off HDMI"
        monitor_status = 0
        os.system(cmd_sleep)

    # turn monitor back on upon detection
    if GPIO.input(pir_pin) and monitor_status == 0:
        os.system(cmd_awake)
        print "Turning on HDMI"
        monitor_status = 1
        time.sleep(10)
        start_time=time.time()

    if GPIO.input(pir_pin):
        start_time=time.time()
        print "Resetting elapsed time to keep monitor on while movement detected"
        time.sleep(10)

 

[hardyhop]

Getting closer to having my raspberrypints functional!

I am having trouble getting the background to change on my taplist. When I upload a picture for the background it is visible when I view my taplist from my iphone and ipad, but from a PC or Mac it just has the standard background.

Anything I am doing wrong?

 

[crane]

Getting closer to having my raspberrypints functional!

I am having trouble getting the background to change on my taplist. When I upload a picture for the background it is visible when I view my taplist from my iphone and ipad, but from a PC or Mac it just has the standard background.

Anything I am doing wrong?

Try clearing the cache on your Web browser

 

[crane]

OK, now I am confident my motion detection script enabling HDMI signal enable/disable is working correctly. For the info of anyone not up to date on the thread there have been a few attempts to get the motion sensor to put the monitor in and out of sleep mode when no motion is detected from the sensor. I came up with the script below that has been working for me.

Anyone interested in giving it a try can simply backup the existing pir_run.py script in /home/pi and then paste in the code below.

@ day_trippr. I know you have not had much luck but I am curious is changing the order of the commands would work any better? My theory is changing to another Virtual Terminal before killing the HDMI signal may hopefully save the colour settings for your X session?

Hope this helps others trying to get their monitor in and out of sleep mode via the PIR.

#!/usr/bin/env python
import pwd,os
import time
import RPi.GPIO as GPIO

pir_pin = 7
GPIO.setmode(GPIO.BCM)
GPIO.setup(pir_pin, GPIO.IN)
global start_time
start_time=time.time()
sleep_threshold = 60
monitor_status = 1
cmd_sleep = 'chvt 6 && tvservice -o'
cmd_awake = 'tvservice -p && chvt 7'
time.sleep(10)

while 1:
    time.sleep(10)
    elapsed_time = time.time() - start_time
    print elapsed_time
    print monitor_status

    # turn off monitor after the sleep threshold
    # monitor_status value avoids turning of HDMI signal if it is already off
    if elapsed_time > sleep_threshold and monitor_status == 1:
        print "Turning Off HDMI"
        monitor_status = 0
        os.system(cmd_sleep)

    # turn monitor back on upon detection
    if GPIO.input(pir_pin) and monitor_status == 0:
        os.system(cmd_awake)
        print "Turning on HDMI"
        monitor_status = 1
        time.sleep(10)
        start_time=time.time()

    if GPIO.input(pir_pin):
        start_time=time.time()
        print "Resetting elapsed time to keep monitor on while movement detected"
        time.sleep(10)

I see you switched from interrupt driven to polling. I will give this a try. Should avoid all the issues I ran into.

The issue day_trippr is experiencing could be a limitation of the monitor. One of my monitors at work is fairly new and I had to disable the low power sleep mode because it couldn't maintain vertical sync after waking up from sleep mode.

@day_tripper have you tried a different monitor? I would also try plugging that monitor into a Windows PC to see if it can wake up properly in that environment.

 

[day_trippr]

As I've said, I have two systems with attached monitors running R'Pints, and neither of them behave well with the tvservice toggle. The 19" DVI LCD perched atop my keezer will go into low power mode with -o, but -p only turns on the backlight (regardless of using the chvt commands or not).

otoh, the 40" HDMI screen on my dev system is the one that has the colors go neon when turning back on. Again, doesn't matter when I use the chvt commands or not.

In both cases I can literally unplug the power to the displays then plug it back in and their symptoms persist. Which is weird...

...because if I hook my office RPi up to one of my 27" computer monitors via DVI, the tvservice commands work perfectly. I can even hook up that monitor in place of the 40" and while the latter was all neon the former looks fine.

It's pretty confusing, but I'm guessing the tvservice is changing the video settings in a way that's subtle enough to work with the computer monitor but not the big tv or the old 19" DVI display.

Not losing sleep over it. It is what it is...

Cheers!