Code:

blueToothSerial.begin(38400);

In most cases you won't have success with the SoftwareSerial class and baud rates higher than 9600, with picky devices even 9600 is too fast. Use the hardware serial to communicate with your Bluetooth device and the SoftwareSerial for debugging, the only drawback: you need another USB2Serial device like the USB2Serial Light from Arduino or an FTDI cable.

Yes, it is possible. Connect GND to the pin labelled BLK, leave the next pin unconnected, next pin 5V, then TX and next RX. The last one is the reset line (normally connected to DTR), as you don't have that line you have to reset the Arduino manually by pressing the reset button immediately before you upload your sketch.

Next problem: Change this part

Code:

    // Run WiServer
    WiServer.server_task();
 
  }
 

to

Code:

  }
  // Run WiServer
  WiServer.server_task();
 

You have to call the networking code often enough. You don't have an operating system on the Arduino which is handling all the low level stuff and allows multi-tasking by switching between tasks and threads but you have to take care for everything in your sketch. And leave the delay() from my first post removed, take care of that wait time by saving the time you requested the temperature reading and checking if the 750ms went over each time you're in the main loop.

I was hoping to use EasyTransfer as I assumed I would be able to more easily change data types and sizes without having to bit-bang the changes through... perhaps I'm over thinking!

This isn't wrong, EasyTransfer makes this a little bit easier. The question is, does this approach make it easier for you in your project.

I suppose I need an I2C primer which is more in-depth than the Arduino references.

Try the introduction of Nick Gammon (a moderator on this forum), it's the only one I know which is Arduino based.
http://www.gammon.com.au/forum/?id=10896

EasyTransfer (imho) still feels like the right, more dynamic solution for communicating to the web-server slave... do you foresee any problems using them together?

No, other than it might guide you again to think about the I2C as a fast version of an UART communication. It was designed to let a processor talk to some devices (chips) and not to let two processors talk to each other. Although this is possible with I2C, it forces you to select one side to be the master while the other side is the slave. In a processor-processor communication it's not always obvious which one should be the master.

This way your doing the graphical stuff on the client. This is possible but still the Arduino with the RN-XV is limited to about 10kB/s because it's communicating over the USART with the Arduino. The libraries folder of RGraph.net is about 1.6 MB. If the client has to pull all the stuff contained there it needs about 3 minutes just to get that from the Arduino. So although your idea is possible it's not practical. If you use another web server and just get the data from the Arduino, you're fine because transferring the data doesn't need that much bandwidth.

Code:

    delay(1000);     // maybe 750ms is enough, maybe not

This line of code is killing the web server. You cannot use delay() while running the web server. Take a look at the blinkWithoutDelay example to see how you can remove the delay() from your code.

To generate graphs the Mega1280 is not equipped with enough RAM. You'll get such things a lot cheaper if you use one of the routers capable of running OpenWRT, there you have all the graphing utilities you need for such stuff and the WiFi for free. If you buy one with an USB port you can connect a simple Arduino (like the UNO) to do the low level stuff.

Also is it even posible for the RN-XV/WiFly to upload data from an SD Card?

Yes, this is possible but it won't be very fast.

If you wanna use your RN-XV, use it only for the data transfer to a web server and do all the graphical stuff there.

Wenn Du die aktuelle Version der DallasTemperatue-Bibliothek (372Beta) einsetzt, dann könnte der folgende Code funktionieren:

Code:

#include <OneWire.h>
#include <DallasTemperature.h>
#include <LiquidCrystal.h>


#define ONE_WIRE_BUS 30  // Temperatursensor pin 30
#define FADE_DELAY 30 // Verzögerung beim Faden
LiquidCrystal lcd(22, 23, 24, 25, 26, 27, 28);
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);

DeviceAddress Sensor[] = {{0x28, 0xCD, 0x9B, 0xDA, 0x03, 0x00, 0x00, 0xF2},
                          {0x28, 0x1F, 0xA3, 0xDA, 0x03, 0x00, 0x00, 0xE2},
                          {0x28, 0x2D, 0xB9, 0xDA, 0x03, 0x00, 0x00, 0xA0},
                          {0x28, 0x37, 0x88, 0xDA, 0x03, 0x00, 0x00, 0x7D}};

int backLight = 29;
uint8_t k[] = {31, 32, 33, 35};   //relais HIGH = Aus; LOW = An

uint8_t knopf1 = 34;
uint8_t buttonState = 0; //knopf
int buttonPushCounter = 0;
uint8_t lastButtonState = 0;

uint32_t previousMillis = 0;
uint32_t interval = 31000;
uint32_t zeit = 31000;

int   mpxPin =  5; //drucksensor
int   mpx;
float pkPa;

uint8_t ledPin = 9; // (kemo)
uint8_t fade;
uint8_t status;

void setup() {
  pinMode(backLight, OUTPUT);
  digitalWrite(backLight, HIGH);
  lcd.begin(20, 4);
  sensors.begin();
  uint8_t i;
  for (i = 0; i < 4; i++) {
    pinMode(k[i], OUTPUT);
    digitalWrite(k[i], HIGH);
  }
  pinMode(knopf1, INPUT);
 
  status=0;
  sensors.setWaitForConversion(false);
  sensors.requestTemperatures();
}

void loop(){
  // check if conversion is done
  if (oneWire.read_bit()) {

    uint8_t i;
    for (i = 0; i < 4; i++) {
      lcd.setCursor(0, i);
      lcd.print("T");
      lcd.print(i+1, DEC);
      lcd.print(":");
      if (sensors.isConnected(Sensor[i])) {
        lcd.print(sensors.getTempC(Sensor[i]));
        lcd.print("C");
      } else {
        lcd.print("AUS   ");
      }
    }
    // start next conversion
    sensors.requestTemperatures();
 
    mpx = analogRead(mpxPin);
    pkPa = (mpx/1023.0-0.04)/0.0018;
    lcd.setCursor(10, 0);
    lcd.print(pkPa);
    lcd.print("mb   ");
  }
   
  buttonState = digitalRead(knopf1);
  if (buttonState != lastButtonState && buttonState == HIGH) {
    buttonPushCounter++;
  }
  lastButtonState = buttonState;
  if (buttonPushCounter % 2 == 0 && status == 0) {
    digitalWrite(k[0], HIGH);
  } else {
    programm1();
  }
}

void programm1() {
  static uint32_t nextMillis = 0;
  static uint32_t thresholdMillis = 0;
  if (sensors.getTempC(Sensor[0]) >= 25.8 && status == 0) {
    digitalWrite(k[0], HIGH);
    status = 1;
    nextMillis = millis() + 60000L;
  } else if (status == 1 && millis() > nextMillis) {
    digitalWrite(k[1], LOW);
    digitalWrite(k[2], LOW);
    digitalWrite(k[3], LOW);
    fade = 0;
    analogWrite(ledPin, fade);
    nextMillis += FADE_DELAY;
    status = 2;
  } else if (status == 2 && millis() > nextMillis) {
    nextMillis += FADE_DELAY;
    analogWrite(ledPin, ++fade);
    if (fade >= 51) {
status = 3;
nextMillis = millis() + 120000L;
}
  } else if (status == 3 && millis() > nextMillis) {
    nextMillis += FADE_DELAY;
    analogWrite(ledPin, ++fade);
    status = 4;
  } else if (status == 4 && millis() > nextMillis) {
    nextMillis += FADE_DELAY;
    analogWrite(ledPin, ++fade);
    if (fade >= 102) {
      status = 5;
      nextMillis = millis() + 180000L;
    }
  } else if (status == 5 && millis() > nextMillis) {
    nextMillis += FADE_DELAY;
    analogWrite(ledPin, ++fade);
    status = 6;
  } else if (status == 6 && millis() > nextMillis) {
    nextMillis += FADE_DELAY;
    analogWrite(ledPin, ++fade);
    if (fade >= 153) {
      status = 7;
      nextMillis = millis() + 240000L;
    }
  } else if (status == 7 && millis() > nextMillis) {
    nextMillis += FADE_DELAY;
    analogWrite(ledPin, ++fade);
    status = 8;
  } else if (status == 8 && millis() > nextMillis) {
    nextMillis += FADE_DELAY;
    analogWrite(ledPin, ++fade);
    if (fade >= 255) {
      status = 9;
    }
  }
  if (sensors.getTempC(Sensor[0]) >= 99.0 && thresholdMillis == 0) {
    digitalWrite(k[1], HIGH);
    thresholdMillis = millis() + 300000L;
  } else if (thresholdMillis && millis() > thresholdMillis) {
    digitalWrite(k[2], HIGH);
    digitalWrite(k[3], HIGH);
    analogWrite(ledPin, 0);
    thresholdMillis = 0;
    nextMillis = 0;
    status = 0;
  }   
}

Hier wird die im Datenblatt beschriebene Möglichkeit ausgenutzt, Read-Slots abzusetzen, nachdem der Convert T-Befehl gesendet wurde. Es sollte erst eine 1 zurückkommen, wenn die Konversion abgeschlossen ist. Damit wird die maximal mögliche Anzahl der Temperatur-Lesungen vorgenommen, ohne die restliche Ausführung merklich zu bremsen.

Sollte obiges Programm nicht wie gewollt funktionieren, kannst Du mal versuchen, die Zeile

Code:

  if (oneWire.read_bit()) {

durch

Code:

  if (sensors.isConversionAvailable(0)) {

zu ersetzen. Das könnte gehen (ist der von der Bibliothek gewählte Weg), ist aber deutlich langsamer (ca. 10ms anstatt 100us) als die erste Variante und widerspricht dem Datenblatt.

Wie hast Du das Display verkabelt? Könnte es sein, dass die Hintergrundbeleuchtung kurz ausschaltet (somit das Display komplett schwarz ist) und nach dem Einschalten die Lichtintensität so gross ist, dass es nur noch als Dunkelgrau erkennbar ist?

Du schreibst nicht, welche Version der Bibliotheken Du verwendest. Die auf www.sainsmart.com verlinkte Version ist es mit Bestimmtheit nicht, dann würde Dein Sketch nämlich nicht kompilieren.

Dein Input wird falsch berechnet. Du willst ja einen Regelkreis erstellen, also muss der Input der Feedback des Systems sein. Da Du kein externes System hast, solltest Du Input = Output setzen und nicht so aggressive Tuning-Werte verwenden.

Code:

PID myPID(&Output, &Output, &Setpoint,1,0.05,0.25, DIRECT);

Kann aber auch sein, dass ich Deine Ziele falsch verstanden habe. Du willst den Taster drücken und der Ausgabewert soll nicht sofort sondern langsam an den Zielwert (durch den Taster definiert) angeglichen werden. Für dieses Problem ist die PID-Bibliothek ein Overkill, das kannst Du deutlich einfacher haben, aber ich denke, Dir geht es hier nur um's Experimentieren und nicht um ein reales Problem.

Upload nur nach vorherigen Ein /-Aussteckens des Arduino Uno r3 (an USB 3.0) möglich, allerdings nur einmalig.
Danach Wiederholung des Ein/-Aussteckens notwendig. Upload über den USB 2.0 Anschluss problemslos möglich.

Nach Deiner Beschreibung würde ich auf ein Treiberproblem für den USB 3.0-Anschluss schliessen. Bei mir läuft der Upload auf einem Ubuntu 12.04 problemlos, allerdings habe ich dort keinen USB 3.0-Anschluss. Kannst Du bis zu einem Treiber-Update nicht einfach den USB 2.0-Anschluss benützen?

The most important fact in I2C communication is that a transfer is always initiated by the master. This is either a write operation (master sends to slave) or a read operation (master receives data from slave).
The master doesn't need an address on the bus because it's always initiating every communication and it's also controlling it (by providing the clock signal).
If you wanna send information from the slave to the master, you have to take care that the master is polling the slave for that information often enough. Although there is no rule how the slave organizes the I2C transfers the most often used scheme is the register based approach. That means the slave defines some registers which the master is able to read and write. Each register has it's address, sequential reads and writes are allowed (auto-incrementing register address). Most I2C devices use this way to communicate because it naturally fits the I2C specification.
In your case for slave 1 I would define two registers, on address 0 (and 1 because it's an integer) you have threshold value, on address 2 (and 3 for the second byte) you have the sensor value. If you wanna save some register addresses you can combine the two because probably the threshold value is only written while the sensor value can only be read. How you organize the byte order (little or big endian) is on you, both have advantages and disadvantages.

What is also confusing me, with regard to EasyTransfer vs standard I2C, is the "number of bytes" when doing a request. How do I make a request to the slave, in the EasyTransfer data structure paradigm?

I wouldn't use the EasyTransfer library in your case. It only makes things more complicated and I don't see the need for dynamically sized transfers on the I2C bus.

Ich nehme mal an, dass die TMP36-Sensoren Platzhalter für die DS18B20 sind. Dann sind diese korrekt angeschlossen. Kannst Du mal testen, was der folgende Code (innerhalb setup()) ausgibt?

Code:

Serial.println(sensors.isParasitePowerMode() ? "Parasite mode" : "Wire powered");

Wenn die Bibliothek den falschen Mode erkennt, wird sie warten, egal ob der Sensor eigentlich sofort Daten liefern könnte.

This solution uses a bluetooth modules for about $40 which has some more functionality than your's. If you think you can do the same with your device, go on and try it.

I'm not the one who always thinks that the more expensive solutions are the better ones but I accept that cheap chinese bluetooth modules has their limitations.

The library is making things easier but you're trying to use it in a manner it is not intended for. It just tries to give an easier interface to the Wire library but it's not able to give the I2C bus capabilities it does not have.

Have you understood the I2C paradigm of master and slave? Your master is still configured as a slave (Wire.begin() call with an address parameter), this way you cannot send commands to the slaves.