I do not know exactly how the “85” is decided by 1-wire, I had heard of it, but never experienced it or read up on it so I couldn’t agree or disagree with how it’s done except for “why have a valid value as a fault value?” I do not know how accurate or reliable it is, Adn for that matter, on the surface I don’t no how it functions with 3 wires! if either the power wires are broken it’s game over, and if the signal wire is broken it cannot tell you. so I have my doubts on it’s ability, but that is an uninformed position, I would hope that all these points are covered in it’s design.
However the element of uncertainty would make me want to air on the side of caution and not specify the “!=85” part to avoid spikes of 300°C during any transition between 84°c and 86°c and back. But given we rarely use the temp sensing in that range it probably doesn’t matter, although I think it would still be clearer if “300” meant a reading outside the normal range and didn’t include whatever 1-wire brings to the party in the form of a perceived error.
I’ll leave it to you, it’s a small point that possibly won’t matter either way, but if I were forced to decide I would say let the “85” work as intended. If it was a non-valid value I might include a 302 = “1-wire reported” error code just for "85"s but I still see 84.8 → 84.9 → 302 → 85.1 → 85.2 as a potential issue
I agree with the point about a slow transition from 84.9 to 85.1, but from the data sheet - the footnote to Table 1 on page 4: “The power-on reset value of the temperature register is +85°C” (this is also the upper limit of the device’s ±0.5°C accuracy band - maybe not a coincidence?) so I read that as meaning that 85 is returned if there isn’t a problem reading the sensor’s register but there was a problem filling it.
It seems amazing that they chose a value within the operational range as the default value, thereby prohibiting the sort of scheme we want to adopt, but we’ve got to live with it.
If the sensor is on a water pipe or tank, I can see a potential problem. If it’s monitoring room temperatures, I can’t believe that there’s a problem.
[EDIT]
Here’s what I’ve now got. In practical terms, it appears to give me:
300 = sensor known, data or GND has become disconnected, or reading out-of-range
301 = sensor absent (=not detected at power-on)
302 = sensor known, power has become disconnected
int get_temperature(byte sensor)
{
float temp=(sensors.getTempC(allAddress[sensor]));
if (temp==85.0) // if reading is '85.00' = power-on value, return value = 302 - device error
return 3020;
else if (temp<125.0 && temp>-55.0 && temp!=85.0) // else if reading is within range for the sensor convert float to int ready to send via RF
return(temp*10);
else // else return value = 300 ('Faulty sensor')
return 3000;
}
The more I think about it the less I like it, your code will no doubt give you what I understand to be what you are aiming for, but the cost of possibly providing a slightly better error reporting, is an implementation that definitely cannot report a temp of 85°C even when it is accurate, thus reducing the upper usable “spikeless” operating limit from +125°C to +84.9°C.
I was sorta hoping you were going to reveal some clever library code that ensured the normal operation through 85°C was maintained somehow. but forcing all "85"s to be “302” isn’t something I’m likely to find myself recommending I’m afraid.
I think we are restrained by Maxim’s decision to use “85” as the power-on reset value of the temperature register. I can’t see an easy or reliable way out of it. 85 is either a genuine value or it isn’t, but there’s no foolproof means that I can think of that will tell us which of the two it is. You can probably affirm that a run of values that are exactly 85 mean a fault, and that 85 surrounded by values that are near to it is genuine, or that if you interpolate between the values either side and that comes to 85 or nearly, then it’s genuine, and you can come up with any number of similar schemes. But none offer certainty. At least with 300, it’s obvious that it cannot be a real temperature, even though it might mask a genuine 85°C, so it offers the possibility of screening it out further up the chain. As I inferred earlier, context is extremely important in deciding how to handle this.
I had also suggested with the adoption of the positive fault indication we should also create a emoncms process specifically for temperature sensors, the idea at the time was a simple “if >= 300 do not persist to feed” so that the error values didn’t skew any min, max or average etc it would just be visible on the inputs page and/or could be used to trigger an event.
Such a process could also ask “is it really 85°C” by one of methods you mention without having to delay the current reading by an interval or 2 in order to confirm it’s a valid temp as a sketch would and it would also have the unique advantage of being able to edit/correct a previous datapoint too.
As you say we are stuck with this as it is the way maxim have done it, perhaps different applications can include or exclude it depending on expected scope of readings, likelihood of a failure, the receiving software and “realtime” necessity.
For now I would be much happier living with the position imposed by maxim that means a hopefully rare fault is assumed to be a valid temp, than being responsible for developing a software that cannot report a valid temp of 85°C and could trigger false fault indications when correctly sensing a temp of 85°C.
In or out, it doesn’t matter right now, if it causes an issue either way down the line it can be resolved. The important thing right now is that completely missing sensors do not result in a zero value, which had my original edit to the get_temperature() function been implemented would be the case. It wasn’t easy getting a partial implementation, a full implementation may now be possible as this fault has identified the need, but trying for an extended implementation may well prove too much and prevent any progress.
If it were a library function (or when it becomes a library function?), it seems reasonable to re-evaluate this question. My guess is the best method would be, on a per-sensor basis, either to pass on the 85°C reading or to block it, as determined by the user. Given the restricted capability of the sketch (in relation to emoncms, that is) I think it’s much more reasonable to pass the problem upwards where it can be handled more intelligently.
OK, I’ve installed libraries and downloaded the .ino; I’ve got the arduino IDE running and opened the discrete_sampling .ino.
I’m connected to the serial port of the the emonTx which is reporting readings as I would expect.
I compile - it reports
In file included from C:\Users\Richard Palmer-Jones\Documents\Arduino\oem\emontx\emonTxV3_4_DiscreteSampling_rpj\emonTxV3_4_DiscreteSampling_rpj.ino:37:0:
C:\Users\Richard Palmer-Jones\Documents\Arduino\libraries\jeelib/RF69_compat.h:9:2: error: #error This file must be included BEFORE the “RF12.h” header file!
#error This file must be included BEFORE the “RF12.h” header file!
Multiple libraries were found for “Ports.h”
Used: C:\Users\Richard Palmer-Jones\Documents\Arduino\libraries\jeelib
Not used: C:\Users\Richard Palmer-Jones\Documents\Arduino\libraries\RFu_jeelib
exit status 1
Error compiling for board Arduino/Genuino Uno.
I moved
I suspect you’ve got some libraries in the wrong place, but you shouldn’t need to move anything in the sketch, as published it is known to compile correctly. Which Windoze version are you using, and have you got the structure of your libraries correct?
Sorry to come in very late, but could this be related to the RFM firmware / Jeelib changes that I had a problem with in the emonSD forum? V2.6 is “bad” and revertiung to V2.5 restores the connection - I also continued to see the emonTH input fine.
This value is hard-coded into the DS18B20 sensor and is loaded into the temperature register on power-up. It is overwritten when the sensor is instructed to and completes a temperature measurement (“conversion” in Maxim’s terminology). The value in the temperature register is requested and retrieved by the JeeLib library as a separate follow-up operation.
Therefore, the value 85 °C is returned when power is applied to the sensor and the temperature register is read, without the sensor being asked to do, or without it successfully completing, the measure and convert step.
An intermittent power supply or a programming error are therefore likely causes.