EmonPi Temperature Measurement

[glyn.hudson]

@Robert.Wall

If you don’t mind me pointing out flaws in your programming, OK, make it public. But I thought you’d prefer to be told about it first.

No I don’t mind. That’s totally fine. I’ve moved this thread to the emonPi forum.

@pb66

As a general rule we should avoid using “0” as a default value where “0” is a valid value. When a user sees his emonPi returning 0°C for any of the 6 temperature sensors, what does it mean? Was the sensor ever connected properly? Has it disappeared since installation? or is it actually exactly 0°C in here?

Very true, ‘0’ is not a good error value for a temp sensor!

@pb66

The original need for a non-zero value is because the emonTx packets were failing crc checks due to “bitslip” at the receiver due to the long string of 0’s when no temp sensors were used (or they were faulty).

Yup, I remember that.

@pb66

If this is going to be the “OEM convention”, which I thought was already the case, then yes there should be a place to reference this info, but where? Do we have a specific place that defines OEM conventions?

Maybe the learn page: Temperature Sensing Using DS18B20 Digital Sensors — OpenEnergyMonitor 0.0.1 documentation and or as a comment in the sketch.

@pb66

#define UNUSED_TEMPERATURE 300
// this value (300C) is sent if no sensor has ever been detected
#define OUTOFRANGE_TEMPERATURE 301
// this value (301C) is sent if the sensor reports < -55C or > +125C
#define BAD_TEMPERATURE 302
// this value (302C) is sent if no sensor is present or the checksum is bad (corrupted data)
// NOTE: The sensor might report 85C if the temperature is retrieved but the sensor has not been commanded

That sounds good. I would be happy to use this as a convention.

@pb66

However!

On numerous previous occasion when this has been discussed (incl some PM’s) the question over the “85°C” errors has arisen more than once and my opinion is that perhaps an exact reading of 85°C should be flagged as a low level warning that users can choose to include as an error or not. eg 85.000°C = 301, this way in situation where 85° is out of normal range a user can set >300 as an alert level or if 85°C is within normal operating range of the applied application the user could set >301 as an alert level and the cost will simply be that any exactly 85°C reading would be lost so (for example) an increasing temperature trace might go 84.8, 84.9,null,85.1,85.2 etc.

Mmm I would be tempted to ignore 85 deg C as this is very much withing the possible reading range of a DS18B20 and may cause false negatives.

Are DS18B20 sensors errors a big issue? Once up and running I can’t think of any systems that I’ve been involved in that throw errors. I agree it’s best to handle all errors in the best way we can. The most important thing I think is to better handle ‘no sensor connected’ by returning 300 as returning ‘0’ is not good.

I don’t have time this week to work on adding this into the FW. I would gladly accept a PR if anyone fancies.

@pb66

If there are users wanting to record temps outside of -55 to +125 they need a different sensor and therefore most likely a different library and the warnings surrounding those sorts of temperatures will possibly be far more “mission critical” than our use case, so a bespoke setup is going to be needed, they can just not use our “300” system and monitor the full range of temperature thier chosen devices provide. We are trying to provide for the masses not the odd case.

Agree, over 300 deg C is a niche use case and not worth considering. DS18B20 is max 125 deg C usable.

@pb66

Not on a ATmega328p it won’t, but on a faster MCU eg STM32 it might.

We got our SMT32 up and running today using an emontx shield. Very easy to upload to using PlatformIO or Arduino IDE. This is a topic for a different conversation!

GitHub - glynhudson/stm-test: Experiments with ARM SMT specifically:...