I’m using the DS18B20 library (based on @LukeUSMC’s library) that I tweaked for multi sensor support and better reliability. I only sample my data once ever 15 minutes but I didn’t have a single stray reading for weeks in a row.
https://build.particle.io/libs/DS18B20/0.1.6/tab/example/ds18b20_MultiDrop.ino
Which also features CRC check
Also, @FiDel, you may still wish to consider some software filtering, even with the CRC checking. The dallas sensor is notorious for these weird readings.
I missed the opportunity to mention that… belt and suspenders!
Thanks @ScruffR and @BulldogLowell for your tips!
Indeed, I am aware of the electronic vulnerability of the one-wire system: Manufacturer’s site
Also, I knew some libraries use this CRC mechanism to filter out stray values.
It would be fantastic if this could be integrated in the final sketch I am using right now: LINK
You can see I joined this thread in march 2016 with very specific requirements for my projects:
Many sketches with different libraries were tried but did not fulfill my wishes, until @ric developed a beautifully complete solution. That was simplified even more last weekend, and I really love it for the clarity, simplicity and reliability it offers.
The only 2 disadvantages of this sketch I see:
So, if some of you see the possibility to add this CRC checking to this sketch, it would make it more reliable!
On top of that, you are right @BulldogLowell, I will try to add a filtering method, checking the “continuity” of the data along these lines:
I check temperatures every 10 seconds or so.
And the water temperature won’t change quickly.
So, for each value, I must check if it is less than 1°C bigger or smaller than the previous value.
If yes, I will replace the variable with the new value.
If not, I will keep it the same.
Only, I’m not sure if I have already enough experience to develop that in a simple way…
Sounds great @ScruffR, thanks for sharing this link!
It is certainly worth checking it against my requirements (see previous post).
I have just tried it first in the Web IDE and I got this error message:
Actually, I got this every time I compile a sketch using OneWire library in the Web IDE…
I tried it in ParticleDev with your library and with the OneWire library. It compiles and uploads OK.
Although I adapted the sensor pin to D3 and number of sensors to 6 for my current setup, I got only 2 values of which one seems wrong:
I don’t know what I am doing wrong, but never mind:
I believe this is a great tool to “discover” a number of sensors and publish their value, but it (probably) will be a big job again to adapt it to both my above requirements…
Good night…
The only 2 disadvantages of this sketch I see:
I get it, you need to know which sensors are which.
most libraries, while including searching method, should allow you to hardcode the unique addresses when reading.
the better libraries include CRC checking, because of the known issues (which you are well aware).
While @Ric did a great job organizing your code, I’d still go the extra step of creating an object oriented approach as to greatly simplify your code and organize your data. But that is another lesson!
I’ve watched this thread for a while, I’m rooting for you to get this perfected!!!
Thanks @BulldogLowell, I see you are with me!
I guess that’s right, but I am so happy with @Ric’s solution that I would prefer to refine that one further with CRC checking rather than to try all over again starting with another library. Let me know if you don’t agree and which one gives us a better solution… 
Concerning the extra “filtering” needed:
I remembered another exercise with @Ric, developing a “filtering method”: LINK
Probably that’s an even better way than my previous idea…
What do you think?
Do you mean with arrays?
More simplification would be great, but usability is more important for my applications. The requirements in my earlier post are vital!
sounds like the gauntlet has been thrown… I’m sure @Ric is up to the task.
I’d create a struct like this for the pairs of sensors:
struct Zone{
byte highAddress[8]; // high sensor
byte lowAddress[8]; // low sensor
double highTemp;
double lowTemp;
double averageTemp;
double energy;
};
void doSomethingWith(Zone* zone);
and an array of those objects like this:
Zone tempSensor[]{
{{0x28,0xFF,0x0D,0x4C,0x05,0x16,0x03,0xC7}, {0x28,0xFF,0x25,0x1A,0x01,0x16,0x04,0xCD}},
{{0x28,0xFF,0x89,0x19,0x01,0x16,0x04,0x57}, {0x28,0xFF,0x21,0x9F,0x61,0x15,0x03,0xF9}},
{{0x28,0xFF,0x16,0x6B,0x00,0x16,0x03,0x08}, {0x28,0xFF,0x90,0xA2,0x00,0x16,0x04,0x76}}
};
you can assign names to them as you did in @Ric 's code:
Zone* Tank1 = &tempSensor[0];
Zone* Tank2 = &tempSensor[1];
Zone* Tank3 = &tempSensor[2];
Zone* myTanks[] = {Tank1, Tank2, Tank3};
then call a function on the objects:
for (auto& eachTank : myTanks)
{
doSomethingWith(eachTank);
}
maybe a bit tricky to grasp, but there are (in this example) three tank objects each that retain two temperatures, their average and the energy… kind-of-thing.
I might be in a couple of days, but I don’t want to try to write code on my phone ( I’m in Yosemite park right now).
I guess you are not targeting a system version greater 0.5.2 in Web IDE.
I was targeting v0.6.2
Should I aim lower?
Sounds interesting, but indeed it’s over my head…
As far as I’m concerned I’m fine with @Ric 's final sketch (without library!) as it is easy to use and very reliable.
What would improve with the way you suggest here?
Hmm, that’s surprising.
When I USE THIS EXAMPLE ds18b20-multidrop.ino in Web IDE as is I only get this error when targeting a version 0.5.2 or before.
You may be mistaking the installed version on the device (v0.6.2) in the bottom right corner in Web IDE as the target version.
The actual target version is set in the target drawer (third icon up on the left hand bar) and I guess when you open the device info (chevron >) next to your device you’ll see you are not targeting 0.6.2.
Yes, that’s what I thought it was…
Indeed, it was targeting a lower version!
I set it to v0.6.2 and Hoopla it compiles!
Thanks for pointing that out @ScruffR
All my other Particle devices have v0.6.2 targeted… How did it change back on this device?
Q: Do we need to set this target version manually for each device or will it be set sometimes by Particle?
@Ric : Don’t worry and enjoy your adventure @Yosemite!
I believe the QSORT filtering you described earlier (LINK) will really perfect your sketch (without library)
It’s probably all we need to filter out all stray values. Isn’t it?
This is how the recording for one boiler (6 sensors) looks currently:
This is a per device setting and will not be adapted by Particle (deliberately - but glitches might occure).
The only “exception” to this is when you chose Default (x.y.z) (currently Default (0.6.2)) as target. This instructs Web IDE to keep targeting the most recent official release.
This is intended, since some projects (for particlular devices) might rely on some “glitches” of older versions and if Particle would mess with your settings, you’d not be too happy if a fine running project suddenly threw up unexpectedly.
This uses @ScruffR 's library that includes CRC checking. I introduced the object-oriented approach I mentioned before.
Of course, i cannot test it but you would have to check that the top, mid and bot sensors were the correct addresses.
#include <DS18B20.h>
struct Zone{
char sensorName[4];
uint8_t hiSensor[8];
uint8_t loSensor[8];
double hiTemp;
double loTemp;
double avgTemp;
double energy;
};
void readSensorSet(Zone* zone);
double getTemp(uint8_t addr[8]);
Zone tempSensor[]{
{"Top", {0x28,0xFF,0x0D,0x4C,0x05,0x16,0x03,0xC7}, {0x28,0xFF,0x25,0x1A,0x01,0x16,0x04,0xCD}},
{"Mid", {0x28,0xFF,0x89,0x19,0x01,0x16,0x04,0x57}, {0x28,0xFF,0x21,0x9F,0x61,0x15,0x03,0xF9}},
{"Bot", {0x28,0xFF,0x16,0x6B,0x00,0x16,0x03,0x08}, {0x28,0xFF,0x90,0xA2,0x00,0x16,0x04,0x76}}
};
Zone* Top = &tempSensor[0];
Zone* Middle = &tempSensor[1];
Zone* Bottom = &tempSensor[2];
Zone* sensorSet[] = {Top, Middle, Bottom};
double Qtot;
const int pinOneWire = D2;
const int pinLED = D7;
DS18B20 ds18b20(pinOneWire);
void setup()
{
Serial.begin(9600);
for (auto set : tempSensor)
{
Particle.variable(String(set.sensorName) + "H", set.hiTemp);
Particle.variable(String(set.sensorName) + "L", set.loTemp); // EDIT fixed typo
}
Particle.variable("ECO-Qtot", Qtot);
}
void loop()
{
double accumulatedEnergy = 0;
for (auto& set : tempSensor)
{
set.hiTemp = getTemp(set.hiSensor);
set.loTemp = getTemp(set.loSensor);
set.avgTemp = (set.hiTemp + set.loTemp) / 2;
set.energy = (set.avgTemp - set.loTemp) * 110 * 1.163 / 1000;
accumulatedEnergy += set.energy;
}
Qtot = accumulatedEnergy;
delay(5000);
}
double getTemp(uint8_t addr[8])
{
static const int MAXRETRY = 3;
double _temp;
int i = 0;
do {
_temp = ds18b20.getTemperature(addr);
} while (!ds18b20.crcCheck() && MAXRETRY > i++);
if (i < MAXRETRY)
{
//celsius = _temp;
//fahrenheit = ds18b20.convertToFahrenheit(_temp);
Serial.println(_temp);
}
else
{
_temp = NAN;
//celsius = fahrenheit = NAN;
Serial.println("Invalid reading");
}
return _temp;
}
i’m not using:
Zone* Top = &tempSensor[0];
Zone* Middle = &tempSensor[1];
Zone* Bottom = &tempSensor[2];
Zone* sensorSet[] = {Top, Middle, Bottom};
Thanks for this effort @BulldogLowell!
I will certainly come back later to this possible alternative when I have more time for experimenting AND when I’m close to the Photon used for this (I’m living one hour drive from there and cannot use serial output. That’s why I use Particle.variables instead)
First I prefer to further “polish” the sketch from @Ric, integrating another of his good ideas: QSORT “median filtering”. I believe that combination will do exactly what I need, even without CRC checks.
Also, I’d like to see the clear benefits of your proposed approach first.
For my home project it is a very essential application, as it will finally be running on 10+ Photons (and also 2 Electrons later)
When comparing the application size, it is not an advantage:
Your application (sketch + library)
Total = 7350 bytes => vs @Ric’s sketch Total = 2121 bytes
To be continued…
I included the Particle Variables, just as you have.
adding filtering to this is somewhat trivial.
either fits fine on a Photon and neither are doing things that may affect stability in the long term.
i feel that it is: