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
-
I hate to pass the buck, but if one temp sensor works and another doesn't, i'm inclined to point the finger at the sensor, or alternatively the DS API. This is because Mango simply treats both as temperature containers. Also, the documentation for that sensor includes this line:
+/- 0.5°C accuracy from -10°C to +85°C
Note the bolding (which i added). This makes me think that the problem is an API initialization thing. It would be great to get the opinion of DS on this. If it's their problem but they won't fix it, Mango could conceivably run a read cycle and throw away the numbers on data source startup.
Speaking of which, what happens if the data source is restarted? Do you get the errant number?
-
... and, yes, i don't really hate passing the buck too much. :wink:
-
Hello,
I have noticed the same. And I am not using mango for 1-wire so it is not mango to blaim. When there is error on the 1-wire network the reading can be 85. I have quite complex 1-wire network and there happens errors every now an then. I am using owfs and a simple script to put the values to mysql, where mango reads the value. In the script the value of 85 is simply skipped so it does not end to the db.
It would be nice also on other purposes to have some error filtering in mango datapoint. Maybe something like invert tolerance value. If the value differs too much from previous(n samples) it is skipped. Or combination of the current mango logging properties(min/max with tolerance) could do the same.
Example: I have one humidity sensor which gives sometimes nonsense (large) values which would be nice to filter. Now I use the interval logging method with minimum value of the period. It works but it causes unneccesary logging. This should work also on the 1-wire error readings. If the interval logging could be combined with tolerance it would be a good solution to this.
Regards
Jokke -
@Jokke said:
If the interval logging could be combined with tolerance it would be a good solution to this.
So you'd like to log the minimum for the interval but only if it differs from the previous interval by more than a tolerance?
Or you'd like a filter on the point value to drop values outside of a certain range?
-
So you'd like to log the minimum for the interval but only if it differs from the previous interval by more than a tolerance?
Or you'd like a filter on the point value to drop values outside of a certain range?
Both would be usable.
I think the first one might be easier to do. (I have't yet taken a look on the code)
The second one could be complicated to implement. I did not mean all values outside range shoud be filtered(maybe that could be a third option and usable for something). I was rather thinking a kind of limiter how fast value is allowed to change.
The second could work the following way.
Let say we have a temperature sensor and want to have the reject tolerance with value 1. The value is read once a minute. The temperature has been around 10 for some time. Then suddenly the value is 12 and it gets rejected. The comparison is done against the last accepted(stored) value.
Next there is 2 options how the skenario continues.
#1 If the next value is again around 10 (+- 1). The value 12 was erroneus and got filtered.
#2 If the value stays at 12 it must be valid. In this case the "reference" needs to be changed from 10 to 12. This can be done with period(or count). After 3 minutes (or when 3 recejects in row) the value is accepted.
This would work with temporary erroneus values in both directions(smaller and larger) when periodical logging with min or max can filter only one direction. Maybe the filter could be formed as "allowed value change in second/minute/hour"(basicly a low-pass filter). There is probably other ways to do same kind of filtering.
Does my description make any sense? :)
Regards
-Jokke -
Actually, the second option as Craig described is much easier to implement than any other option discussed. It is also much easier to understand for the user.
Jokke, your option #2 is intellectually interesting, but i'm not sure of the actual practical value of it. It assumes that the equipment from which you're getting data is highly prone to error, in which case i'd suggest getting better equipment. If you have a real life example of where something like this would be necessary, please describe.
On the other hand, equipment that has particular (and predictable) startup value - like 85 - is conceivably common, and so i've implemented an optional min and max range for the next version, outside of which values will be ignored.
-
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: