Multiple DS18B20 with Photon

FiDel · October 17, 2017, 3:38pm

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?

BulldogLowell · October 17, 2017, 4:40pm

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

@LukeUSMC posted a library with CRC checking.

something to consider…

ScruffR · October 17, 2017, 4:41pm

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

BulldogLowell · October 17, 2017, 4:46pm

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!

FiDel · October 17, 2017, 9:31pm

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

FiDel · October 17, 2017, 9:42pm

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

BulldogLowell · October 17, 2017, 9:50pm

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

FiDel · October 17, 2017, 10:20pm

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?

FiDel · October 17, 2017, 10:21pm

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!

BulldogLowell · October 17, 2017, 10:52pm

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.

Ric · October 18, 2017, 12:31am

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

ScruffR · October 18, 2017, 3:50am

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

FiDel · October 18, 2017, 8:27am

I was targeting v0.6.2
Should I aim lower?

FiDel · October 18, 2017, 8:36am

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?

ScruffR · October 18, 2017, 8:37am

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.

FiDel · October 18, 2017, 8:57am

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?

FiDel · October 18, 2017, 9:18am

@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:

ScruffR · October 18, 2017, 10:16am

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.

FiDel · October 18, 2017, 10:50am

Very useful, thanks @ScruffR!

BulldogLowell · October 18, 2017, 10:59am

@FiDel,

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

Topic		Replies	Views
ds18b20 on multiple pins? General	6	4062	December 24, 2016
DS18B20 and OneWire lib just plain buggy? Troubleshooting	17	2085	January 23, 2020
DS18B20 in an array. OneWire.h spark-dallas-temperature/spark-dallas-temperature.h Libraries	9	4873	April 25, 2016
DS18B20 - working on 4 separate pins D0 to D3 Hardware	0	432	July 30, 2019
Troubleshooting DS18B20 temperature sensor Troubleshooting photon	9	1383	May 10, 2019

Multiple DS18B20 with Photon

Related Topics