Multiple DS18B20 with Photon

#122

Above sketch is working great: 6 temperatures of a hot water boiler can be monitored in order to decide when to pump excess (solar or woodfire) energy to another boiler.

But as you can see, the sampling rate is every 5’ and now and then (interval = 4 - 10 h) an “odd” value is read:

This makes the system unreliable…
In order to mitigate these errors, I have constrained the values within fixed minimum/maximum margins in the loop() function of above sketch:

``````void loop()
{
getTemperatures(0);

// Constrain the 6 temperatures between 20 - 80:
TopH = constrain(TopH, 20, 80);
TopL = constrain(TopL, 20, 80);
MidH = constrain(MidH, 20, 80);
MidL = constrain(MidL, 17, 80);
BotH = constrain(BotH, 17, 80);
BotL = constrain(BotL, 17, 80);
// TO DO: Limit or ignore the incorrect readings! For example: Constrain the temperatures between + and - 1 degree from previously known correct value... How can this be done in this sketch? (The Particle.publish function will publish them anyway...???

// Calculate the average temperature in each of the 5 zones:
Av1 = (TopH + TopL)/2;
Av2 = (TopL + MidH)/2;
Av3 = (MidH + MidL)/2;
Av4 = (MidL + BotH)/2;
Av5 = (BotH + BotL)/2;

// Calculate the "spare" energy in each of the 5 zones:
Q1 = (Av1-Tmin)*110*1.163/1000; // Spare energy in 110 liter top zone (kWh)
Q2 = (Av2-Tmin)*90*1.163/1000; // Spare energy in 90 liter top/mid zone (kWh)
Q3 = (Av3-Tmin)*90*1.163/1000; // Spare energy in 90 liter middle zone (kWh)
Q4 = (Av4-Tmin)*90*1.163/1000; // Spare energy in 90 liter mid/bottom zone (kWh)
Q5 = (Av5-Tmin)*110*1.163/1000; // Spare energy in 110 liter bottom zone (kWh)
Qtot = Q1+Q2+Q3+Q4+Q5; // Total spare energy in Buffer (kWh)

// Constrain Qtot between 0 - 30:
Qtot = constrain(Qtot, 0, 30);

delay(5000);
}

``````

Still, the values fluctuate too much at times. And of course, I can not constrain the values more than the ‘normal’ values we can expect to read…

Does anyone know a simple method I could use in above (yesterday’s) sketch to NOT publish any of the temperatures to the “Particle.variables” if one of the 6 is more than 1 degree higher or lower than the previous correct value?

PS: I found a few related threads like this one: LINK1 by @ethelder or LINK2 by @mdma but don’t know which the best practice to follow…

Anybody with experience in filtering DS18x20 data?

#123

Aside from the obvious electronic reasons that you may be getting bad reads, have you thought about implementing CRC checking?

something to consider…

#124

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

#125

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!

#126

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:

• Must allow MANY sensors (DS18B20 and DS18S20 versions mixed) on the same I/O pin (around 25…)
• The sensors, with known hex addresses, should ALWAYS keep the same (double variable) NAME (= “hardwired” sensor addresses!) => So, no “searching” for sensors!

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:

• You must run another sketch to identify the sensor addresses before being able to use it “hardwired”
• No CRC checking is used, to filter out stray values

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…

#127

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…

#128

The only 2 disadvantages of this sketch I see:

• You must run another sketch to identify the sensor addresses before being able to use it “hardwired”
• No CRC checking is used, to filter out stray values

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!!!

#129

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?

#130

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!

#131

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{
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.

#132

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).

#133

I guess you are not targeting a system version greater 0.5.2 in Web IDE.

#134

I was targeting v0.6.2
Should I aim lower?

#135

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?

#136

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.

#137

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?

#138

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:

#139

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.

#140

Very useful, thanks @ScruffR!

#141

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;
};

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);
}

{
static const int MAXRETRY = 3;
double _temp;
int i = 0;

do {
} while (!ds18b20.crcCheck() && MAXRETRY > i++);

if (i < MAXRETRY)
{
//celsius = _temp;
//fahrenheit = ds18b20.convertToFahrenheit(_temp);
Serial.println(_temp);
}
else
{
_temp = NAN;
//celsius = fahrenheit = NAN;
``````Zone* Top = &tempSensor[0];