If you are getting a signal on -speaker with the wires clipped, then the boxes aren't configured the way I thought!  Doesn't matter, though, if it's working.

Jim

Confirm assumed internal configuration of speaker boxes first:
1.  Connect 5VDC wall wart outputs to the power terminals (VCC and GND) of the speaker box.
2.  Measure voltage from -speaker to GND
   a)  should be nearly Vcc when button is not pressed
   b)  should be nearly GND when button is pressed (will probably be 0.5V or so).

If you confirm those measurements, then just connect -speaker to an Arduino digital input pin.  Signal will go low when button is pressed, but will otherwise be read as high.

Jim

PS - don't disconnect the speakers unless you put load resistors (10K maybe) in their places.  Otherwise you will short Vcc directly to GND when a button is pressed.

EDIT -- Oops, did not see before I posted that Mike had already responded with an identical suggestion.

With nothing powered on, use your multimeter to check continuity on each speaker unit:

1.  From Vcc to +speaker
2.  From -speaker to GND

I'm guessing that Vcc to +speaker will be a short (no resistance), and -speaker to GND will be open.  It seems likely that the speaker units use a simple NPN transistor (or N-channel FET) between -speaker and GND.  Putting a signal on the base of the NPN, presumably triggered by pressing a doorbell button, causes the NPN to conduct, which connects -speaker to GND.  This completes the circuit and causes the speaker to speak.

When you connected all of the -speakers together, then triggering any one of the NPN transistors would have connected all of the -speakers to GND.  This is what you experienced, right?

To be honest, though, I really have no idea what you are trying to accomplish?

Jim

The only way I could effectively measure the voltage of each doorbell independently was to group the speaker positives - but can that work??

Yes. I thought you already tried this and showed that it worked, right?

Jim

What gives??

The switching transistor for the speaker is in an open collector configuration.  That is, the switch is between -speaker and ground.

Jim

One thing that I did read is that somewhere I should define the port on the Arduino for the connection with the bluetooth? I'm using Linux (11.10) and the Arduino is defined on.../ACM0 but other than that I don't know where to define a specific port for the Arduino to talk to the bluetooth.

I'm not following this.  The Linux box shouldn't be connected to the USB port on your Uno while you are using the RN 42.  So (unless I am missing something) the port setup on your Linux box would be irrelevant.

My suggestion would be to use a stripped-down sketch that does nothing more than flash the LED briefly every time a character is read from Serial.  You might also want to try to establish communication with the Uno/R42 through a BT connection to your Linux box to see if the problem maybe lies with the Android app.

Jim

Sorry for asking the obvious, but are you continuing to send characters from the Android?  Serial.available() will return false once you've emptied the receive buffer.

FWIW, I've gotten the RN-42 to work in a similar situation with an Arduino-compatible board, so I'm confident you'll get this solved.

Jim

I welcome correction, but I believe rewriting two lines of code takes care of the wrapping problem with millis():

Code:

unsigned long blinkTime = 0;           /* When to execute blink()             */

void blink(void)
{  static int x = 0;                   /* Current LED state 0=>off, 1=>on     */
   digitalWrite(13,x ^= 1);            /* Set LED to opposite state           */
   blinkTime = millis();         // ***********************************************************
}
void watch(void)
{  if (millis() - blinkTime >= 250 ) blink();  // *************************************
}
void setup(void)
{  pinMode(13,OUTPUT);                 /* Use on-board LED at pin 13 as O/P   */
}
void loop(void)
{  watch();                            /* Change state whenever it's time     */
}

Jim

I get an infinite clock pulse from SCL while SDA is at GND level. This causes arduino to "freeze"... I think this happens when something goes wrong while trying to read something from the IC. Arduino stick in reading mode since it never reaches the No-ACK (meaning end of data) due to SDA being low.

SCL is constantly at Vcc (5V) and SCL is at GND. I don't have a single clue about this one. SCL being always at Vcc means that something is wrong with arduino, since it is the bus master.

I just worked through a very similar problem.  In my case, after NACK, the Arduino master was unable to generate a stop.  This caused the I2C bus to crap out, and it locked up the Uno.  Your situation sounds really similar.

Turned out that the successful solution for me was a software revision on the slave side.  The slave was not always releasing SDA.  Once in a while it was holding SDA low after NACK, making it impossible for the stop to be generated.

Jim

I'm pretty certain you're supposed to switch hot by code, not neutral - that neutral should never be broken (it's a safety issue); the only time you can switch neutral is if you are switch both at the same time...

I've seen many instances in appliances, specifically espresso makers, where neutral (only) is switched when controlling resistance heating elements.  I don't know why, or even if it is a good idea, but this seems to be the standard practice in that industry.

Jim

Sorry that is incorrect and potentially dangerous,  if it is AC you should be using a Transorb, or if it is an AC switch, a resistor and an X2 capacitor in series across the contacts.
You ONLY put a reversed diode across a low voltage DC feed with a 0.1uf capacitor ,and possibly an inductor in the  Arduno & low voltage control feed.

I should have been more specific, I guess.  I put a 1500W, 171V TVS diode across the AC leads (Littlefuse, 1.5KE200CA-B).  Seems to have helped a little.  At least there were no sparks, smoke, or flames.

I am still looking for a better solution for what I believe are transient spikes resulting from switching off either the pump (piston/spring type driven by coil) or a small solenoid operated valve.  The same switch turns off both, so I can't easily isolate the bad actor.

Jim

Have you tried terminating your output string with \r\n ?  Python might not be recognizing \n alone as the terminator.

Jim

Start here:
http://jtoee.com/2009/12/connecting-multiple-avrarduinos-via-i2ctwi/

Anyone else having trouble getting the slave to work at 1MHz?  Works fine at 4 and 8, but I can't get my UNO and ATtiny2313 to talk when the tiny is running at only 1.

Jim

It looks like your use of the PWM16 library is OK.

I didn't understand this, though.  Looks like cycles will always be 1 when the division is performed?

Code:

tempAverage = tempSum / cycles;
oxyAverage = sumOxy / cycles;
cycles = 0;

Jim

You are welcome to use this library:
http://code.google.com/p/tc4-shield/source/browse/applications/libraries/trunk/libraries#libraries%2FPWM16

It uses timer1 and supports PWM periods up to around 4 seconds.

Jim