Revisiting oneWire I find that something has changed since I last tackled my problem. Theres a new DallasTemperature library so where can I fine a list of commands with explanation?
In Examples/Dallas Temperature/Multiple is found a sketch which can be analysed with some effort but I can't see how to convert from Serial.print information to a assigning usable variable. The four suggested functions are a little confusing I find. I want to read two devices (one inTemp the other outTemp) and use that data'
These are the relevant functions found in the example:
// function to print a device address
void printAddress(DeviceAddress deviceAddress)
{
for (uint8_t i = 0; i < 8; i++)
{
// zero pad the address if necessary
if (deviceAddress < 16) Serial.print("0");
_ Serial.print(deviceAddress*, HEX);_
_ }_
_}_
_//.............................................................._
_// function to print the temperature for a device*_
void printTemperature(DeviceAddress deviceAddress)
{
* float tempC = sensors.getTempC(deviceAddress);*
* Serial.print("Temp C: ");*
* Serial.print(tempC);*
* Serial.print(" Temp F: ");*
* Serial.print(DallasTemperature::toFahrenheit(tempC));*
}
//......................................................................
// function to print a device's resolution
void printResolution(DeviceAddress deviceAddress)
{
* Serial.print("Resolution: ");*
* Serial.print(sensors.getResolution(deviceAddress));*
* Serial.println();*
}
//........................................................................
// main function to print information about a device
void printData(DeviceAddress deviceAddress)
{
* Serial.print("Device Address: ");*
* printAddress(deviceAddress);*
* Serial.print(" ");*
* printTemperature(deviceAddress);*
* Serial.println();*
}
float tempC = sensors.getTempC(deviceAddress);
tempC is the usable variable... no?
You might find it a lot simpler to go here instead.
I'm following up your link Nick_Pyner, thanks.
I recognise the line you quote BulldogLowell, it confused me. Although different by one capital the variable and command are very similar but I see my error. Thanks.
The other matter worrying me is that I want two output connections, one for inside one for outside. So far, it seems that the sensors are randomly selected and in or out may be assigned to either device. How do I ensure that the input/output connection is fixed to a particular sensor?
Adrifran39:
The other matter worrying me is that I want two output connections, one for inside one for outside. So far, it seems that the sensors are randomly selected and in or out may be assigned to either device. How do I ensure that the input/output connection is fixed to a particular sensor?
In order to do that with certainty, you need to know the address of each of the two sensors.
Search "one Wire Address Finder" and you will find a sketch to do just that.
The library has functions that allow you to specify that address, for example:
DeviceAddress indoorAddress = {0x28, 0x94, 0x2B, 0x8E, 0x05, 0x00, 0x00, 0x02};
DeviceAddress outdoorAddress = {0x28, 0xA6, 0xBA, 0x8D, 0x05, 0x00, 0x00, 0x73};
and get temperatures accordingly:
float outdoorTemp = sensors.requestTemperaturesByAddress(outdoorAddress);
Got it. And finally (maybe), there no longer seems to be concern over conversion time. Is this taken care of by the new library or have I missed something else?
That is addressed in the link I posted. The conversion time is determined by the resolution. If you don't specify resolution, it defaults to 12bit and takes 750ms, which is the worst case. I'm not sure this should ever be a practical issue anyway, since
- the operation is in hardware and you don't have to wait for it.
- If you really need readings faster than one per second, you probably shouldn't be using a DS18B20
and if you insist on doing so, you can reduce the resolution and thereby greatly speed up the conversion time. See the data sheet.
About the only time you will see the 85 signifying inadequate conversion time is on startup i a straightforward test, and it simply means you haven't given it time to get the initial reading. This usually goes away by itself as you put more tasks in setup.
The conversion time isn't material to me because it takes more than one second to go right through the entire loop function. So it occurs to me that if I am worried about conversion time, and the previous conversion remains available until a new conversion is requested, then could I not read the old value the next time through void loop() then request a new reading before leaving the function which would be available at the next 'visit'?
What do you think Nick_Pyner?
I don't - and it sounds like gobbledygook. Just read it once per trip round the loop like everybody else does. Doing it twice rather suggests a badly conceived loop. I'm not sure about your logic anyway. Rather than
the previous conversion remains available until a new conversion is requested
i would expect the sensor get on with a new conversion as soon as the old is delivered. I realise that this may start a boring debate about just how up-to-date the reading is, but I will live it.
It was just a suggestion. I can take it then that requesting a new reading initiates a conversion whuch can take up to 750mS. What I am trying to understand is that after requesting a reading, is a wait automatically included or does the procedure move on regardless.
This is what I thought I asked in the first place but maybe I didn't make it clear enough. Is it still necessary to program a wait or is it taken care of in the conversion routine. Sorry if I am not using the correct terminology.
then could I not read the old value the next time through void loop()
Yes, you could as long as you were sure that the time between reads was always long enough and you coded it properly.
However, by default the DallasTemperature library waits for a conversion to finish before returning a value. You can change this behaviour by using the DallasTemperature::setWaitForConversion(bool flag). An argument of false will turn off the wait for delay and then you have to handle the timing yourself.
Pete
At last, Pete! A simple 'by default the DallasTemperature library waits for a conversion to finish before returning a value' would have resulted in my not asking questions which plainly try the patience of experts.
Thank you Pete, take a small VC.
You're welcome 
FYI:
When printed by a OneWire scanner, multiple DS18B20 ROM addresses will usually not be listed in the expected numerical order. Here I give an example of how the DS18B20 addresses are sorted by the DallasTemperature library.
And this gives an example with 9 DS18B20 addresses.
Pete
P.S. When you post code, put it in code tags using the </> icon. Then it won't suddenly turn into italicized code with bits either missing or turned into smileys. It also makes it much easier to cut and paste.
Posting previously, there has been a line of icons above the message space including the one for code. Clearly something is amiss for none of them appear now. I have upgraded to the latest Arduino release maybe that has something to do with it.
I am anxious to post the code I am using to enable two sensors because all of a sudden I get '85' as the reading for both and its not temperature responsive, so how do I bring up these icons?
The 85 is a signal indicating that the sensor has not had time to do the conversion, as described in the link in reply #2, and also in reply#7. Since your loop is >1sec, this really shouldn't be a problem and there should be no need to change the behaviour from the defaults character. As I said, you can pick the 85 up on startup, and you get just that initial reading error. A delay of 750 in Setup will get rid of it, if it doesn't go away by itself - which it often does..
/* Basic 2xDS18B20 code for terminal, bluetooth, Excel or w.h.y.
Derived from Hacktronics.
http://www.hacktronics.com/Tutorials/arduino-1-wire-tutorial.html
Use their address sniffer and substitute your addresses.
Use Hacktronics connections diagram.
Stay away from using parasite power
No resolution command means default to 12 bit
-127C means bad connection
85 means you haven't gotten a read yet, probably insufficient time
or wrong order of commands
*/
#include <OneWire.h>
#include <DallasTemperature.h>
// Data wire is plugged into pin 3 on the Arduino
#define ONE_WIRE_BUS 3
// Setup a oneWire instance to communicate with any OneWire devices
OneWire oneWire(ONE_WIRE_BUS);
// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);
byte Thermo1[8] = {0x28, 0x39, 0xFD, 0x50, 0x04, 0x00, 0x00, 0X69};
byte Thermo2[8] = {0x28, 0x09, 0xA9, 0xC0, 0x03, 0x00, 0x00, 0x95};
float tempC,InTemp,OutTemp;
void setup(){
Serial.begin(9600);
sensors.begin();
delay(750); // settle down
}
void loop() {
sensors.requestTemperatures(); // call readings from the addresses
InTemp = sensorValue(Thermo1);
OutTemp = sensorValue(Thermo2);
Serial.print(" InTemp = ");
Serial.print(InTemp);
Serial.print(" OutTemp = ");
Serial.println(OutTemp);
delay(1000);
}
//sensorValue function
float sensorValue (byte deviceAddress[])
{
tempC = sensors.getTempC (deviceAddress);
return tempC;
}
Your version of Arduino IDE has nothing to do with using this forum in a browser. As I type this, there is a row of icons immediately above, including the infamous </>
When the DS18B20 is powered up, its temperature register is set to 85C. If you get a reading of 85C it means the sensor hasn't done a valid conversion since it was powered up. Once you do a good one, the temperature will change from 85 to something valid (unless, of course, you've stuck the sensor in hot water :)) ) and 85 can only occur again if it is a real value or if the power to the sensor glitched and caused it to reset.
Somehow, your code is requesting a temperature without the proper delay. Post your code again. If you can't see the </> icon just type
[code]
paste the code here and then type
[/code]
Pete
I think I'm getting close to understanding! I do appreciate the amount of patience shown but I would ask you to remember I am 78 and have the memory and understanding of a goldfish these days, perhaps not even as good as that. BUT I am not looking for sympathy, just trying to put off the inevitable. I think I've left it a little late to learn C++ and begin a project that has turned out so much more complex than I imagined it would be.
[code/]
#include <OneWire.h>
#include <DallasTemperature.h>
// For this example the Onewire data is on port 2 on the Arduino
#define ONE_WIRE_BUS 2
#define TEMPERATURE_PRECISION 11 //(9 gives 0,5 deg accuracy. 10 gives 0.25 deg, 11 gives 0.125 deg.
OneWire oneWire(ONE_WIRE_BUS);// Setup a oneWire instance to communicate with all OneWire devices
DallasTemperature sensors(&oneWire); // Pass oneWire reference to Dallas Temperature.
DeviceAddress inTempAddress = {0x28, 0x73, 0xB3, 0xE9, 0x05, 0x00, 0x00, 0x31};
DeviceAddress outTempAddress = {0x28, 0x0C, 0x69, 0xEA, 0x05, 0x00, 0x00, 0xE6};
//float tempIn;
//float tempOut;
//----------------------------------------------------------------------------------------------
void setup()
{
Serial.begin(9600);
sensors.begin();
}
//-----------------------------------------------------------------------------------------------
void loop()
{
heating();
}
//----------------------------------------------------------------------------------------------
void heating()
{
float tempIn = sensors.getTempC(inTempAddress);
float tempOut = sensors.getTempC(outTempAddress);
Serial.print(tempIn);
Serial.print(" ");
Serial.print(tempOut);
Serial.println();
delay(2000);
}
My code is taken from the sketch entitled 'multiple' in the Dallas Temperature examples. I seem to have copied it inexactly.
The other problem remains - where have the icons gone?
Of course, your code Nick_Pyner worked like a dream when I changed the relevant data. Thanks for that. Some day I'll learn that when all else fails take note of what others say.... some day! Thanks.
But what about the absent icons?