Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[fli4l]

Hallo Jan,ich arbeite im Projekt FLI4l (Ein Softwarerouter)in Verbindung mit OWFS.Auf dem Router läuft nun zur Datenerfassung diverser Werte auch nochdie Erfassungssoftware collectd (www.collectd.org) mit dem darin vorhandenenplugin "onewire".Dieses Plugin arbeitet direkt mit OWLIB zusammen und ruft die Werte der Sensoren ab. Diese Abfrage ist bisher über die Variable "temperature"gelaufen. Da diese Abfrage nun sehr häufig stattfindet, gibt es da mit dem wandeln der Werte (Speziell da ich hier auch noch eine Mischbestückung zwischen Parasite-Power und External-Power betreibe) immer mit Problemenbehaftet (Sensorwerte werden oft nicht gelesen (Kein Wert und nicht 85°)).Jetzt hatte ich im Zusammenhang mit der "Latesttemp" Variable gehofft, dassich das Timing-Problem damit umgehen kann, da dieser Wert je bestehen bleibt, bis ein neuer Wert vom Sensor gemeldet wurde.Allerdings greift vermutlich die Abfrage über OWLIB so tiefgreifend in das Ganze System ein, dass eben keine neue Wandlung der Messwerte getriggertund somit der Wert in latesttemp immer auf den Ursprungswert bleibt.Wenn ich dann an der Konsole oder per FTP den zugehörigen Wert von temperature auslese, wird dieser dann auch bei latesttemp aktualisiert.Ich hoffe, dass diese Erklärung nun verständlicher ist.Gruß Roland Jan Kandziora  hat am 9. Januar 2017 um 14:02 geschrieben:Am 09.01.2017 um 09:33 schrieb fl...@franke-prem.de:Hello,sorry for the confusion.The reading by me has nothing to do with the 85 degree values.It was only the hint, when readout values with the OWLIB Connection,that then the values by reading with only "latesttemp" will be not updated.Erklärs mir bitte auf Deutsch. Vielleicht verstehe ich das Problem dann.Mit freundlichem GrußJan--Check out the vibrant tech community on one of the world's mostengaging tech sites, SlashDot.org! http://sdm.link/slashdot___Owfs-developers mailing listOwfs-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/owfs-developers
 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Jan Kandziora]

Am 09.01.2017 um 09:33 schrieb fl...@franke-prem.de:
> Hello,
> sorry for the confusion.
> The reading by me has nothing to do with the 85 degree values.
> It was only the hint, when readout values with the OWLIB Connection,
> that then the values by reading with only "latesttemp" will be not updated.
>
Erklärs mir bitte auf Deutsch. Vielleicht verstehe ich das Problem dann.

Mit freundlichem Gruß

Jan


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[fli4l]

Hello,but the "simultanues/temperature bit" Need  external powered sensors as i suggest.So what is when you have sensors with paratite-power?And i suggest that you will Trigger the simultaneous/temperature bit manually in your external application. Not directly inside the OWFS code.Best regards,Roland Mick Sulley  hat am 9. Januar 2017 um 00:46 geschrieben:I don't know if this will help to explain the operation, but my code runs in a continuous loop -Read all temperaturesSet the simultaneous/temperature bitPerform logic operations, setting outputs to devices based upon temperatures read, etcLog values to databaserepeat.OK ignore the first loop.  The logic and logging takes more than 1 second, so when I read the temperatures they are all converted because it was initiated at step 2 on previous loop, no wait time and no 85 degree readings.I agree that there is a design fault with the DS1820, but it is nothing we can fix here, and Dallas are not going to do anything about it now.Hope that helps a bit Mick  On 08/01/17 22:30, Jan Kandziora wrote:Am 08.01.2017 um 19:39 schrieb Roland Franke:
It's still in there, as Stefano found the real bug causing problems with
.../latesttemp.
But this has also an problem (For me). I will read over OWLIB from the
OWSERVER values out (Let me say the program collectd will read it with
the onewire plugin). I have also not all my sensors (Type 28 = DS18B20)
external powered, so the simultanues read of values will not work.
On this way the value of latesttemp will be only updated, when the sensor
is read on an second way. Only latesttemp will hold his value without any
changes.
So it is not (For me) complete right working as i was suggesting, that the
update of that value will be also made. But this will be never be done.

I'm sorry, I do not understand from the above what your problem is.

Kind regards

 Jan

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
 --Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___Owfs-developers mailing listOwfs-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/owfs-developers
 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[fli4l]

Hello,sorry for the confusion.The reading by me has nothing to do with the 85 degree values.It was only the hint, when readout values with the OWLIB Connection,that then the values by reading with only "latesttemp" will be not updated.This is the Problem by me.Best regards,Roland Jan Kandziora  hat am 8. Januar 2017 um 23:30 geschrieben:Am 08.01.2017 um 19:39 schrieb Roland Franke:>It's still in there, as Stefano found the real bug causing problems with.../latesttemp.But this has also an problem (For me). I will read over OWLIB from theOWSERVER values out (Let me say the program collectd will read it withthe onewire plugin). I have also not all my sensors (Type 28 = DS18B20)external powered, so the simultanues read of values will not work.On this way the value of latesttemp will be only updated, when the sensoris read on an second way. Only latesttemp will hold his value without anychanges.So it is not (For me) complete right working as i was suggesting, that theupdate of that value will be also made. But this will be never be done.I'm sorry, I do not understand from the above what your problem is.Kind regardsJan--Check out the vibrant tech community on one of the world's mostengaging tech sites, SlashDot.org! http://sdm.link/slashdot___Owfs-developers mailing listOwfs-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/owfs-developers
 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Ekkehard Pofahl]

Thanks for all the replies.

*Suggestion :*

*IF *reading == 85 *then *ignore reading

I will now implement something like this for each reading of the OWFS
server.

Most probably I will add the following else branch :

*else *reading = last_reading

Even if there is a valid 85 degree measurement, I don't expect this reading
do repeat that often. I expect something like 84,9x and 85,xx readings
nearby, as typically temperature readings change,

Eventually I will log, how often I see 85 degree readings on the sensors to
have an idea, how stable the 1-wire installation is. I did that, before I
used OWFS.

If this is never implemented in OWFS : I do it in my code. I never see 85
degrees again in my algorithm.

If the feature *85_ignore* is implemented in OWFS : no problem. Better
filter the problem twice than never.

This will make me happier, regardless whether the 85 degree readings are
because of :

- timing error of the OWFS code
- 4,7 k instead of 1.5 k
- power-on reset routine
- instable power supply
- 85°C readout is a feature rather than a bug
- Period.
- incorrect settings of simultaneous/temperature bit
- unfortunate instellar constellation

Maybe, but only maybe, I will investigate deeper, why I see what I reported
in my original post.

Happy programming
Ekkehard


2017-01-09 0:46 GMT+01:00 Mick Sulley :

> I don't know if this will help to explain the operation, but my code runs
> in a continuous loop -
>
>- Read all temperatures
>- Set the simultaneous/temperature bit
>- Perform logic operations, setting outputs to devices based upon
>temperatures read, etc
>- Log values to database
>- repeat.
>
> OK ignore the first loop.  The logic and logging takes more than 1 second,
> so when I read the temperatures they are all converted because it was
> initiated at step 2 on previous loop, no wait time and no 85 degree
> readings.
>
> I agree that there is a design fault with the DS1820, but it is nothing we
> can fix here, and Dallas are not going to do anything about it now.
> Hope that helps a bit
> Mick
>
>
>
> On 08/01/17 22:30, Jan Kandziora wrote:
>
> Am 08.01.2017 um 19:39 schrieb Roland Franke:
>
> It's still in there, as Stefano found the real bug causing problems with
> .../latesttemp.
>
> But this has also an problem (For me). I will read over OWLIB from the
> OWSERVER values out (Let me say the program collectd will read it with
> the onewire plugin). I have also not all my sensors (Type 28 = DS18B20)
> external powered, so the simultanues read of values will not work.
> On this way the value of latesttemp will be only updated, when the sensor
> is read on an second way. Only latesttemp will hold his value without any
> changes.
> So it is not (For me) complete right working as i was suggesting, that the
> update of that value will be also made. But this will be never be done.
>
>
> I'm sorry, I do not understand from the above what your problem is.
>
> Kind regards
>
>   Jan
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing 
> listOwfs-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Mick Sulley]

I don't know if this will help to explain the operation, but my code 
runs in a continuous loop -


 * Read all temperatures
 * Set the simultaneous/temperature bit
 * Perform logic operations, setting outputs to devices based upon
   temperatures read, etc
 * Log values to database
 * repeat.

OK ignore the first loop.  The logic and logging takes more than 1 
second, so when I read the temperatures they are all converted because 
it was initiated at step 2 on previous loop, no wait time and no 85 
degree readings.


I agree that there is a design fault with the DS1820, but it is nothing 
we can fix here, and Dallas are not going to do anything about it now.


Hope that helps a bit
Mick


On 08/01/17 22:30, Jan Kandziora wrote:

Am 08.01.2017 um 19:39 schrieb Roland Franke:

It's still in there, as Stefano found the real bug causing problems with
.../latesttemp.

But this has also an problem (For me). I will read over OWLIB from the
OWSERVER values out (Let me say the program collectd will read it with
the onewire plugin). I have also not all my sensors (Type 28 = DS18B20)
external powered, so the simultanues read of values will not work.
On this way the value of latesttemp will be only updated, when the sensor
is read on an second way. Only latesttemp will hold his value without any
changes.
So it is not (For me) complete right working as i was suggesting, that the
update of that value will be also made. But this will be never be done.


I'm sorry, I do not understand from the above what your problem is.

Kind regards

Jan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Jan Kandziora]

Am 08.01.2017 um 19:39 schrieb Roland Franke:
>>
>> It's still in there, as Stefano found the real bug causing problems with
>> .../latesttemp.
> 
> But this has also an problem (For me). I will read over OWLIB from the
> OWSERVER values out (Let me say the program collectd will read it with
> the onewire plugin). I have also not all my sensors (Type 28 = DS18B20)
> external powered, so the simultanues read of values will not work.
> On this way the value of latesttemp will be only updated, when the sensor
> is read on an second way. Only latesttemp will hold his value without any
> changes.
> So it is not (For me) complete right working as i was suggesting, that the
> update of that value will be also made. But this will be never be done.
> 
I'm sorry, I do not understand from the above what your problem is.

Kind regards

Jan

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Roland Franke]

Hello,

>>> ...
>>> This has all been taken care for already, OWFS repeats a
>>> .../temperature triggered conversion for the case 85°C is the result.
>>> When you still have stray 85°C readings, it means your power failures
>>> are so serious you should check your hardware setup.
>>
>> Is that still the case? I thought there was some discussion here
>> recently about whether that code is in fact desirable and whether it
>> should be removed.  Perhaps I misunderstood the conversation.
>>
> It's still in there, as Stefano found the real bug causing problems with
> .../latesttemp.

But this has also an problem (For me). I will read over OWLIB from the
OWSERVER values out (Let me say the program collectd will read it with
the onewire plugin). I have also not all my sensors (Type 28 = DS18B20)
external powered, so the simultanues read of values will not work.
On this way the value of latesttemp will be only updated, when the sensor
is read on an second way. Only latesttemp will hold his value without any
changes.
So it is not (For me) complete right working as i was suggesting, that the
update of that value will be also made. But this will be never be done.

Best regards,
Roland 


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Colin Reese]

If there is no way to distinguish 85 error/power up from 85 valid, you cannot 
filter it. Period. It must all be done on the other side of owfs, and the user 
strategy for this depends on application and expected results. 

You could add flags like last_was_85, or a time stamp last_non_85, but this is 
trivial to do elsewhere. 

> On Jan 8, 2017, at 5:54 AM, Ekkehard Pofahl  wrote:
> 
> Hello,
> 
> I am using OWFS since more than two years in different versions on a Raspi 2. 
> This alone shows, that I think it is a very good program.
> 
> From time to time there is the "85 degree" discussion. It is a clear design 
> flaw of the DS 18xxx chips to sent out a valid temperature reading, when an 
> error code should be sent out.
> 
> Everybody should be aware of the 85 degree flaw and mask it out,
> 
> Previously I thought, 85 degree is only happening, if the power supply is 
> insufficient, or shortly after power-on.
> 
> BUT it seems, that within OWFS there are other ways to read 85 degrees.
> 
> E.g. reading temperature value to quick after conversion command. This has 
> been reported on also Arduino 1-wire software. Or something else ?
> 
> I see the issue with OWFS Version 3.1p1 and 3.1p5. I did not check for other 
> versions or parasite powered DS chips.
> 
> Observation : the error code "85 Grad" is transmitted frequently with the 
> DS18B20.  Only two participants on the bus, stable power supply, no parasite 
> power.
> 
> Open OWFS issues :
> 
> 1) make sure wrong timing is not provoking 85 degree readings on the OWFS 
> server
> 2) filter out 85 degree "somewhere" in OWFS. Otherwise every user of the OWFS 
> server needs to do that filtering.
> 3) do statistics on 85 degree reading
> 
> 
> pi@hsx03:~ $ date
> Thu  5 Jan 17:20:33 CET 2017
> pi@hsx03:~ $ sudo /opt/owfs/bin/owfs --version
> /opt/owfs/bin/owfs version:
> 3.1p5
> libow version:
> 3.1p5
> 
> 
> owhttpd readings :
> 
> 
> top   highest level   directory
> 28.28DBA701   28.28DBA701 directory
> 26.9D46F500   26.9D46F500 directory
> bus.0 bus.0   directory
> 
> uncached version
> updirectory
> address   2828DBA701A3
> alias 
> 
> crc8  A3
> errataerrata
> family28
> fasttemp  85
> id28DBA701
> latesttemp85
> locator   
> power YES (1)
> r_address A301A7DB2828
> r_id  01A7DB28
> r_locator 
> scratchpad
> 50054B467FFF0C101C
> temperature   21.6875
> temperature10 85
> temperature11 21.75
> temperature12 21.6875
> temperature9  85
> temphigh  
> 
> templow   
> 
> tempres   
> 
> type  DS18B20
> 
> 
> 
> temperature   23.0625
> temperature10 85
> temperature11 23.125
> temperature12 23.0625
> temperature9  85
> temphigh  
> 
> templow   
> 
> type  DS18B20
> 
> 
> temperature   23.1875
> temperature10 85
> temperature11 23.1875
> temperature12 23.1875
> temperature9  85
> temphigh  
> 
> templow   
> 
> tempres   
> 
> type  DS18B20
> 
> Sometimes everything is o.k. : 
> 
> scratchpad
> 72014B467FFF0E1057
> temperature   23.125
> temperature10 23.25
> temperature11 23.25
> temperature12 23.125
> temperature9  23.5
> 
> 
> I don't observe this on a DS18S20 :
> 
> 
> scratchpad
> 2E004B460D10C4
> temperature   22.9375
> temphigh  
> 
> templow   
> 
> type  DS18S20
> 
> 
> Best regards
> Ekkehard
> 
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Jan Kandziora]

Am 08.01.2017 um 17:05 schrieb Colin Law:
> 
> It is surely undeniable that this is a design flaw in the chip.  Much
> more sensible would have been to make it default to full scale (or
> full negative scale), then it would have been much easier to program
> around.
> 
Full scale values mean there is a temperature above or below the
temperature which can be sampled. Not just a single spot in the middle.

What's really missing is a distinct POR flag as the DS2408 has it.


>> ...
>> This has all been taken care for already, OWFS repeats a
>> .../temperature triggered conversion for the case 85°C is the result.
>> When you still have stray 85°C readings, it means your power failures
>> are so serious you should check your hardware setup.
> 
> Is that still the case? I thought there was some discussion here
> recently about whether that code is in fact desirable and whether it
> should be removed.  Perhaps I misunderstood the conversation.
> 
It's still in there, as Stefano found the real bug causing problems with
.../latesttemp.


Kind regards

Jan

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Colin Law]

On 8 January 2017 at 14:59, Jan Kandziora  wrote:
> Am 08.01.2017 um 14:54 schrieb Ekkehard Pofahl:
>>
>> I am using OWFS since more than two years in different versions on a Raspi
>> 2. This alone shows, that I think it is a very good program.
>>
>> From time to time there is the "85 degree" discussion. It is a clear design
>> flaw of the DS 18xxx chips to sent out a valid temperature reading, when an
>> error code should be sent out.
>>
> Ekkehard, I repeat this again and again and again and again…
>
> The 85°C readout isn't an error message. 85°C is default value which is
> in the temperature register after power-on.

It is surely undeniable that this is a design flaw in the chip.  Much
more sensible would have been to make it default to full scale (or
full negative scale), then it would have been much easier to program
around.

> ...
> This has all been taken care for already, OWFS repeats a
> .../temperature triggered conversion for the case 85°C is the result.
> When you still have stray 85°C readings, it means your power failures
> are so serious you should check your hardware setup.

Is that still the case? I thought there was some discussion here
recently about whether that code is in fact desirable and whether it
should be removed.  Perhaps I misunderstood the conversation.

>
> When you want to check for this particular problem, set the default
> resolution of the chip to some resolution you never use by writing it to
> .../tempres. After a conversion with a *different* resolution, and
> encountering a 85°C reading, check whether the ../tempres value has been
> reset to the default value.
>
> This is a poor man's POR flag. The chip lacks one, that's a design flaw.
>
> .../tempres is writeable since owfs-3.1p4

That is a good plan, thanks for that.

Colin

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Jan Kandziora]

Am 08.01.2017 um 14:54 schrieb Ekkehard Pofahl:
> 
> I am using OWFS since more than two years in different versions on a Raspi
> 2. This alone shows, that I think it is a very good program.
> 
> From time to time there is the "85 degree" discussion. It is a clear design
> flaw of the DS 18xxx chips to sent out a valid temperature reading, when an
> error code should be sent out.
> 
Ekkehard, I repeat this again and again and again and again…

The 85°C readout isn't an error message. 85°C is default value which is
in the temperature register after power-on.

What happens during a conversion is the following.

1. You read the .../temperature node of the chip. OWFS sends a
"Convert T" command to the chip. It then waits up to 1s for completion.

2. OWFS sends a "Read Scratchpad" command to the chip. The returned
scratchpad has the current value of the temperature register inside.
Which e.g. is 20.5°C.

3. OWFS returns 20.5 to the calling program


When you have a power failure on the DS18B20 during conversion:

1. You read the .../temperature node of the chip. OWFS sends a
"Convert T" command to the chip. It then waits up to 1s for completion.

2. POWER FAILURE. Conversion on the chip is stopped, and the scratchpad
is loaded with the power-on value: 85°C. OWFS is unaware of this.

3. OWFS sends a "Read Scratchpad" command to the chip. The returned
scratchpad has the current value of the temperature register inside.
Which is 85°C now.

4. OWFS returns 85 to the calling program


> 
> BUT it seems, that within OWFS there are other ways to read 85 degrees.
> 
> E.g. reading temperature value to quick after conversion command. This has
> been reported on also Arduino 1-wire software. Or something else ?
> 
This is perfectly expectable. As long the first conversion isn't
successfully completeted, the scratchpad value is still 85°C. When
someone has constant power failures, he may never been able to complete
a conversion.

Please understand that a lot of people are copying the 4.7k pullup
resistor from the datasheet without thinking too much about it. That
4.7k is a very ambitious value, meant to save as much power as possible.
It isn't possible to power the chip through this resistor during
conversion so you need either

a powered DS18B20

or

a strong pullup during the whole conversion time.

Most people simply miss those requirements and wonder why it doesn't
work. My advice always is to

replace the 4.7k pullup by a 1.5k one.

That way you *never* encounter power failures, even if your program is
not controlling the strong pullup as it should.


> 
> 1) make sure wrong timing is not provoking 85 degree readings on the OWFS
> server
>
Wrong timing doesn't provoke anything like this. The scratchpad always
contains the value from the previous conversion. It's only 85°C in the
case there wasn't a previous conversion.


> 2) filter out 85 degree "somewhere" in OWFS. Otherwise every user of the
> OWFS server needs to do that filtering.
> 3) do statistics on 85 degree reading
> 
No. This has all been taken care for already, OWFS repeats a
.../temperature triggered conversion for the case 85°C is the result.
When you still have stray 85°C readings, it means your power failures
are so serious you should check your hardware setup.


When you want to check for this particular problem, set the default
resolution of the chip to some resolution you never use by writing it to
.../tempres. After a conversion with a *different* resolution, and
encountering a 85°C reading, check whether the ../tempres value has been
reset to the default value.

This is a poor man's POR flag. The chip lacks one, that's a design flaw.

.../tempres is writeable since owfs-3.1p4

Kind regards

Jan

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers