A recent issue concerning Data loss due to RF packets getting corrupted turned out to be due to the packets being read incorrectly because there were no temp sensors installed to an emonTx and the long run of 0 values did not provide any bits for the rfm receiver to synchronize to, so avoiding zero values where possible is highly recommended.
We could just remove unused temp sensor values from sketches but that would mean every user would need to adjust both the sketch, emonhub and emoncms for each application to match the number of sensors used, not ideal!
An alternative is to use a non-zero value for unused temp sensor values, which is easy enough to "set" but again isn't automatic and requires each user to "set" the unused sensors to a parked value, the automatic use of a default out of range value is also possible but will corrupt valid data if the sensor is not detected for any reason
But that out of range value could actually be a bonus, used as an error code it could actually trigger or indicate a warning and if filtered before being written to a feed, data integrity is maintained. Currently when we see a 0 value is it currently 0°C, recently was 0°C, an unused sensor or has it failed ???
What I would like to propose is using a standard approach in all sketches that starts out specifying all temp sensor values to 301°C in setup() regardless of whether they are fitted or not and then in each loop() the previously "found" sensors are set to 300°C before an attempted read. This will effectively then only report actual current temperature or "300" (not read - possible fault) or "301" (circuit not in use) .
This combined with the use of "minus 300", "allow positive" and "add 300" processes at emoncms, prior to logging will ensure only live values below 300°C will be recorded to a feed and an open-circuit temp sensor will not show as 0°C.
The 3 processes could easily be written into a custom "temperture-input" processor for ease of use.
The use of 300 and 301 in this way will allow a simple " if not temp_input-300 " test (eg in events module) to only indicate a fault condition if a previously "found" sensor goes open circuit, unused circuits will not trigger a fault indication.
Any thoughts? I have tried this (as has Ian) it works well and can't think of a better way to keep the current "upto 6 sensors" approach and this adds error indication too. before I submit a pull I thought I would explain the reasoning and ask users opinions first.
Paul
Re: Temp sensor circuit error codes.
I support the idea of a positive indication of a fault condition.