Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
1-Wire DS18B20 problem only at startup
-
BTW, did anyone try this out?
Speaking of which, what happens if the data source is restarted? Do you get the errant number?
I.e. stopped and started.
-
Matthew,
Sorry for the delay - I have been out of town on business. Got to pay the bills you know.......
I have tried to make this errant data point by disable and enable data point and disable and enable data source. No error.
The errant data point only occurs each time at the startup of Tomcat/Mango and only for the DS18B20 sensor.
I just got some other samples from Dallas/maxim and will be playing around in the next few weeks with DS2450 4x A/D converter, a DS2408 8x switch, and some other temp sensors. I'll let you know the results after I learn to properly solder a SOIC chip with old eyes. Out comes the large magnifier............
Mike
-
Sounds good Mike. Let me know how that goes.
Also, v1.8.0 is out now, which has the configurable min/max settings for logging. You might give that a go too.
-
I was doing some work implementing a 1-wire driver on an XMOS device recently, and saw 85degC value occasionally. This was due to a value read inside the driver being out of range and being limited to 85.
I forget the details, but I thought at the time that an exception should have been raised and the whole packet discarded.
Probably the best approach is to detect 85 and flag it as an error for a re-read, but I don't know your plug-in architecture yet, to be more concrete.
-
Flagging the value "85" for a specific device in a specific data source is a bit too, well... specific. I suppose it could be done in the data source itself, so if someone wants to contribute some code... ...?
But, that's what the value limiting was for. You can set limits for your points such that values like this will be discarded.
-
Yes, it's an ugly situation.
limiting misses the point, really.
In the examples higher up the thread, the 85 value should not really be limited to some value, and presented as if a real value, but treated as 'point could not be read' and discarded, or shown out-of-band of the normal temp curve.
-
Sorry, what's the difference between "limiting" and "discarding due to out of band"?
-
{I still have not studied mango's plug-in infrastructure, so I my terminology may be sub-optimal.}
OK, so pasting from above, let's get some data....
23.0 °C Dec 03 23:06
23.0 °C Dec 03 23:05
23.0 °C Dec 03 23:04
23.0 °C Dec 03 23:03
85.0 °C Dec 03 23:02
23.0 °C Dec 03 23:01
...Let's first assume that at 23:02 there was a real temperature excursion to 100 Deg C, which was limited to 85 internally in the sensor, and reported as 85, the device's maximum value.
Assume that the mango source also had its maximum value limited to 85.
The data in the db would reflect 85 for 23:02, and this information would be correct, within the limits of the system.
In the context we could say that the temperature at that time was 85 degrees or above. Real and useful information.
Now let's assume instead that there was an error in the device or the driver at 23:02. This may have occurred due to low voltage on the line, or a bug, whatever, but we know that these 85 degree values are highly suspect.
In this case, putting the value 85 in the database would be misleading. We actually have no idea what the temperature was. If we were able, we should say so, by storing what I called an 'out-of-band' point. This could be a datapoint with a flag attached saying that an error occurred. Then this point would not be used for display, or for controlling air-con equipment. Or we simply ignore the point. That is better than taking action on data that we suspect is nonsense.
A practical approach in this case might be to configure the upper limit to 84 degrees, and configure/code the driver to ignore/or raise exceptions on sensor values of 85 degrees.
Finally, a comment on smoothing temperature values, or limiting the rate of change. My thought is that in this case this would make matters worse. First of all it's hard to know the excursion rates that are normal, and to express those values in a general way. It's hard to process the data, and we need to query the last n values each time a new value comes in. IMHO, for this sensor, with its specific behavior of sending 85 out-of-the-blue, one should simply treat it as a device that reads to 84.xx degrees, and treat 85 degrees as bad data.
-
The problem is that, in you example data, you'll never know what the 85 represents (i.e. flaky system or an actual out of range value) without manual research, so you could never use such values for control (since the research happens after the fact). Plus, now you would need an interface to locate the errant value and annotate it appropriately, not to mention code the rest of the system to deal with the annotation. A lot of work for an avoidable problem.
I call it avoidable because if you can reasonably expect your temperature to reach 100 °C and your equipment can only read up to 85 °C, you are most surely using the wrong equipment.
-
I finally got around to loading the newest version of Mango (1.8.2 I think). I enabled the option to discard what I consider bad data for the DS18B20 and this works just fine for me. No more flaky charts when i restart my 1-wire network! Thanks a bunch! For my latest version of my public page see: