Temperature sensing

@ 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())
                for(int i=0; i<8; i++) 
                for(int i=0; i<9; i++) 
                    buf[i] = oneWire.read();

                // result is temperature x16, multiply by 6.25 to convert to temperature x100
            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.

When I trace through the Dallas library, it appears I was wrong. I now think it returns -127 (Device disconnected) for a CRC error. The slightly misleading part is, it appears to return the same value for other faults too.

So it’s true to say that a CRC error is not discriminated in the emonTx sketch, but appears as an out-of-range error, and the previous reading is used.

Discourse is the forum software.

In my browser, I can most certainly recognise it as HTML. The link to the post announcing the release is

<a class="" href="https://community.openenergymonitor.org/t/emonlibcm-version-2-01/9241">EmonLibCM - Version 2.01</a>

And inside that post, the download link is:

<a class="attachment" href="https://community.openenergymonitor.org/uploads/default/original/2X/6/638d9d8c37d12f623c59c6f1d1023c1f99d93f19.zip">emonLibCM.zip <span class="badge badge-notification clicks" title="4 clicks">4</span></a>

Because you have Javascript turned off.

Why one works, but not the other, I don’t know.

No, I have it turned on for this site.

Works fine for me. Discourse is a great platform for community sites. So many key players are using it. My only gripe is that it can be setup differently so, for example, using this site, node-red and HomeAssistant is different (how they link to and make available a list of latest posts). But a vast improvement of some of the older technologies.

However, you really need to use a browser in the ‘mainstream’ manner for it to work. They will never cater for the .001% and you cannot expect them to. Me, I use a load of different browsers, with different settings for different purposes and types of sites but YMMV.

Way OT…

1 Like

Yeah, sorry. And apologies to all; it does look like a regular link (finger trouble late at night) BUT it still tries to create a popup. You have to middle-click on the link (to open in another tab) to see the problem. It doesn’t happen if I left click. It doesn’t happen if I right-click and select Open Link in New Tab. But it reliably occurs with middle-click. I haven’t found any other links where the problem occurs either, so this one appears to be special in some way. It’s the only one I’ve found posted in this particular way with an expandable text within it, so maybe it’s something to do with that. But I can’t be bothered chasing through all the CSS and JS. So we should get back to my original question …

I just tried plugging in a 5V USB PSU instead of the AC adapter but I’m not comfortable with the situation. Firstly the red LED stopped blinking every ten seconds, although emonCMS said it was being updated? And the log of my optical pulse sensor reset to zero, which I wasn’t expecting though isn’t a disaster. The temperature sensor gave some zero values.

The spikes seem to mainly occur at night - around or just after midnight and sometimes around 4 or 5 in the morning. Now those are times when my main power loads are switching - space & water heating - and there’s also a repeatable pattern in the mains voltage around midnight. It goes from very high before midnight (250 V plus) to low after midnight (around 244 V) - some of that may be my power draw but some is the DNO balancing its network I think.

So TL;DR I think the spikes in my temperature readings are induced by fluctuations in the power supply (insufficient filtering/isolation?)

So did the 5v psu make a difference to the spikes?

The led not flashing is due to the firmware (incorrectly) assuming you are running on batteries when the a.c. signal is missing (to extend batt life). If/when you remove the internal a.c. link the led should flash again.

The pulsecount will always reset at power up, when the reset line is gnd’d or at rollover, this is expected and emoncms whaccumulator processing is designed for such behaviour.

The 0 temp values at start up are not ideal and this is a known issue on both the emonth and emontx units.

If using a 5v psu to provide a more stable 3.3v to your temp sensors (via the 3.3v screw term) has not resolved the spikes entirely, try moving the temp sensor power wire to the 5v term (only at 5v when 5v psu used, not via AC or batt). This combats the DC voltage loss in the thin wires and long runs to the ds18b20s, I always power my ds18b20’s at 5v even when the data wire goes to a 3.3v (non 5v safe) io pin, this seems to be more reliable and has never caused any damage for me.

If I recall correctly, the pulse counter and temp sensors are powered by 5v on the emonpi via the rj45.

No idea, sadly. I tried it only briefly because of the perceived problems I mentioned. And it wasn’t at a time of day when spikes were likely.

Thanks for the explanation for the lack of flashes (pretty serious IMHO, since I’ve then got no indication the thing is working, apart from hiking back to the house and checking the screen). And for the annoying zero values. I’m sure I can patch those with my program if anybody could enlighten me on how best to reinsert patched data to a file.

I don’t want to move the temp connection to the RJ45 since that involves yet more wiring. It’s not a wire, it’s a pin on a DS18B20 but consequently there are no long wire drops to be accounted for. Don’t have an emonpi.

edit: and now I’m fairly convinced the spikes are down to power glitches because of hardware design issues, I’m not likely to try messing with the power supply again.

Here’s a couple of screenshots to illustrate what I mean, first an overview of a week and then a detailed view of last night.

I would try a new/different DS18B20 sensor. I would get one that is pre-wired, unless you have excellent fabrication skills. What you are seeing looks more like a connection issue than a real power problem. I have had sensors almost work with the power pin disconnected. They are actually designed to work with parasite power, so they really are very low power and work at 3V3 or 5V without needing big/thick power wires. I have had one or two sensors go bad, but mostly it was because they got disconnected or corroded enough to be almost disconnected.