Temperature sensing

So I connected a DS18B20 directly to the screw terminal block on one of my emonTx (powered by an AC adapter). It’s generally reporting sensible values, but occasionally, and more often than I’m comfortable with (3 today, one yesterday, 6 the day before …), is reporting high values. Typically single sample spikes, but sometimes the spike persists for multiple samples. The high value are typically over 100°C but sometimes as low as 30°C or so (this is my garage and reality is low single digits) but vary and don’t appear to be ‘magic’ values. So I’m looking for the cause.

My research indicates there can be problems caused by powering down the sensors and not leaving enough time to stabilise the readings. There can be problems from faulty readings that should be caught by the CRC check. And of course there could be a faulty DS18B20 or faulty connection.

But EmonTx V3.4 - OpenEnergyMonitor Wiki doesn’t seem to be clear about whether the sensor power is cut when using an AC power source. And the URL given in the sketch source for the library used to read the sensors resolves to a cloudflare security error page, but poking beyond that leads to a library that doesn’t have the string CRC in it. So can anybody clarify exactly what is the actual situation? Or suggest how to find the source of this problem?

Sorry my estimates of the number of spikes were a gross underestimate, when I expand the graph, there are far more spikes.

Do you know the sensor is good? I’ve got a bad one (one of 6) that exhibits exactly this behaviour.

No as I said, it could be a bad DS18B20, but how do I tell? And is it the most likely problem?

Only way to tell is try a different one.

I’ve no idea how likely it is. I have 6 connected to an EmonTX (modified firmware) and only that one exhibits this behaviour. It could be a bad joint - I’ve never properly investigated as yet. I just do not use the readings.

I’ve had a few spares around for testing and recently had to chuck one because it had stopped working.

I’d think the best way for you to diagnose the issue is to thoroughly check the wiring and then invest in another DS18B20 or two so you can see if it is a faulty sensor.

Simon

The power-on value for the temperature register is 0x0550, which equates to 85°C. If you request the register without commanding the sensor to first convert the temperature, that’s what you’ll get. That could happen if, for example, the power to the sensor fails between sending the command to convert the temperature and sending the request to read the register.

The various OEM sketches can also send values in the 300°C range, to indicate various error conditions, such as checksum error, out-of-range error, sensor-never-seen, etc. You need to look at the appropriate sketch to find the meaning, because the codes used have changed over time.

Generally, the DS18B20 sensors are quite reliable, but they can and do fail. Most example code takes shortcuts in gathering data from the sensor and many times does not provide a method to indicate the data is bad or possibly bad. I have been using them for many years and I typically follow these rules.

Use 5V for power if using long (more than a meter or so) cables. You can still use 3V3 for the pull-up if your MCU isn’t 5V safe.

Never use phantom power mode, ie always use 3 wires with the sensor. They use so little power it probably doesn’t make sense to control the power, unless you have a very tight power budget (ie on a small battery).

Make sure the code checks the checksum.

Make sure a reading of 0 is really 0 and not a data line shorted to ground, ie don’t trust exactly 0.0

Make sure the code waits for the sensor to be ready before reading that data.

Have a valid range for the data and throw out readings that are outside of it.

Make sure the valid range is large enough to cover all the real world scenarios you are using.

Keep track of the number of bad (and good/possibly bad) readings.

Look at the data regularly to catch issues before they get big.

I first started with raw sensors that I wired myself. At the time it was quite a bit cheaper to do it that way. But, none of the ones I wired up survived more that a couple of years. They were also time consuming to make. I then switched to the ones that claim to be waterproof with stainless steel covers, but in my compost pile they only lasted a few times at high temperature. Turns out most of them rely on heat shrink tubing for waterproofing. I now encase the premade sensors in two part epoxy putty. That seems to have done the trick and I have a set that has been going for a long time, but I also always have plenty of spares.

1 Like

Have you tried the emonTx with a known good 5v USB PSU ?

Good thought. I almost jumped right to it, since I have a currently unused 5V PSU (no idea how to know whether its good though, apart from does it work when its plugged in?).

Then I remembered that before plugging in the power supply, I have to remove jumper JP2 according to EmonTx V3.4 - OpenEnergyMonitor Wiki although there’s no such requirement mentioned in the guide + Add Additional emonTx - Guide | OpenEnergyMonitor

And in order to remove JP2, I’ll need to dismatle the emonTx, and before dismantling it I’ll need to unplug the sensors, and before unplugging the CT sensors I’ll need to remove them from the cables they’re clamped around (is it enough to just open the clamps so the iron is open circuit?). In short, a royal pain. It would be nice if it could sense the power supply status and adjust to it automatically.

So I still think the idea is a good one, but what I’ll do is use my house emonTx, since I have to take that apart at least once in order to add a cable that will lead to a string of DS18B20. So I’ll take it apart, add the cable and one DS18B20 and put it all back together. If that shows the same problem it will help to confirm the cause. If it doesn’t, it’s a strong hint the problem is limited to the garage emonTx and/or its sensor. Then I’ll take the house emonTx apart again and remove JP2 and add the USB PSU. That may provide more evidence. Finally I’ll add the rest of the DS18B20 chain and see if that all works.

Then I’ll try some combination of changing the DS18B20 on the garage emonTx or investigating further as indicated.

@ Frogmore42 - thanks, all good advice. Indeed some of it matches my questions, but nobody seems to know whether the emonTx firmware does or does not check the CRC for example.

I’ve written a program that is able to recognize the spikes and remove them, along with the nulls that I get regularly as well from that emonTx. But I haven’t quite figured out the best way to clean data that is a live collection.

Keeping track of the error rate is an excellent suggestion. I’ll add that to my program.

All my sensors are indoors and above ground, so I very much hope waterproofing isn’t an issue for them :slight_smile:

I check it in emonLibCM:

            if (!oneWire.reset())
            {
                result=BAD_TEMPERATURE;
                break;
            }
            else
            {
                oneWire.write(MATCH_ROM);
                for(int i=0; i<8; i++) 
                    oneWire.write(temperatureSensors[j][i]);
                oneWire.write(READ_SCRATCHPAD);
                for(int i=0; i<9; i++) 
                    buf[i] = oneWire.read();
            }

            if(oneWire.crc8(buf,8)==buf[8])
            {
                result=(buf[1]<<8)|buf[0];
                // result is temperature x16, multiply by 6.25 to convert to temperature x100
                result=(result*6)+(result>>2);
            }
            else result=BAD_TEMPERATURE;
            if (result != BAD_TEMPERATURE && (result < -5500 || result > 12500))
                result = OUTOFRANGE_TEMPERATURE;
            temperatures[j] = result;

But at first sight, it’s not checked in the default emonTx sketch - though of course you _could _ check whether I’m right or wrong there.

Thanks, Robert. At some point I should change the firmware in my emonTx-en to the CM sketch to hopefully improve the accuracy a bit, given my diverter’s influence. There are some interesting discrepancies between the various readings I’ve got: taken by hand from the meters, taken from optical sensors and taken by CT. How’s the testing going?

It truly never is easy.

I’ve just spent five days fighting dodgy power supplies on the Emonpi. Everything from dodgy pulse counting to havoc with my irda reader. Took 3 weeks before that to actual determine this was the cause.

As others have said one wire is normally reliable so hopefully it is simple psu or cabling.

Good luck and do let us know if that is the cause.

I’m afraid that’s often the way. And power should be the first thing to check - always. But glitches, spikes and drop-outs can be very hard to pin down.

On the jumper faf, I’m pretty sure if this is just for a test AND you remove the AC adapter, you won’t need to do anything else.
Although all your power reading won’t be accurate for the duration.

I’m not sure why but when I try to open the link to EmonLibCM - Version 2.01 the website tries to open a popup, which my blocker blocks. I may be misinterpreting, but why isn’t it a straightforward link? Also, why do I have to reload the page to get the status (number of unseen posts) to change, whilst it dynamically tells me who’s composing? All seems a bit half-baked.

edit: and the link seems to be to a post that hasn’t been updated for 24 days, so I’m not clear what I’msupposed to be inferring?

That doesn’t happen for me - and nobody else has reported a problem. Is this your own machine or a company-owned or managed one? If the latter, the problem is probably there.

As far as I can tell, it is a straightforward link. If you don’t like Discourse, then I suggest you make your views known on the Discourse forum. Glyn & Trystan made the decision to go with Discourse, and we’ve had a lot less trouble with spammers since moving across, so from a moderator’s point of view, it’s eased the workload.

On 21st November at 7:42 pm, I released emonLibCM V2.01. I’m inferring that you didn’t see that post, which was pinned to the top of the list for a week so that as many people as possible might see it.

It’s my own machine.

I’m sorry but if you look at the source of the page, it’s anything but straightforward HTML and there most certainly is no link with EmonLibCM as part of its text.

I don’t know what Discourse is, nor the Discourse forum?

that’s a good reason for using it, whatever it is. (and yes, I’ll go search in a while)

My memory for dates is very bad. Is that date after we talked about it being in extended testing? i.e. are you saying I should be safe to use it now? In which case I’ll fold it into my dismantling emonTx plans.

Oh, and no, I don’t sit glued to this forum, nor do I look at its front page very often at all.