Am 09.01.2017 um 16:07 schrieb fl...@franke-prem.de:
> 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 Problemen
> behaftet (Sensorwer
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 ru
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 updat
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,Ro
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 ha
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 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.
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
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 sti
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
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
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" discu
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 chip
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
e
Am 14.07.2013 13:10, schrieb Jan Kandziora:
>
> I see currently owfs is unable to update the scrachpad RAM only, as it
> would be neccessary to implement such a scheme. Paul, what do you think
> about having a node which does the "Write Scratchpad" command, but
> leaves out the "Copy scratchpad" c
Am 13.07.2013 20:21, schrieb Jerry Scharf:
>
> The origin of 85 was that the original sensors were 8 bit and only went
> to 85c and thus all 1s (FF)was an error. When the extended the range to
> 125c and the bits extended, the error value was already set and produces
> the problem you have. Hin
Yes that is effectively what I do.
My system controls my solar heating so it is important that it keeps
going, so I have been looking at ways to make it more fault tolerant.
One thing I am working on it to double up on the important sensors,
DS18X20's are only about £1 each so it doesn't cost m
Wow Jerry, what a comprehensive and coherent answer. Thank you so much.
I think I'll take your strategy of just discarding all 85.000 values - at the
data collection point I'll turn them into a "U" undef which will propagate up
in the software to a missing value.
-dan
--
Daniel,
The origin of 85 was that the original sensors were 8 bit and only went
to 85c and thus all 1s (FF)was an error. When the extended the range to
125c and the bits extended, the error value was already set and produces
the problem you have. Hind sight says they should have used the extra
On Sat, Jul 13, 2013 at 12:05 PM, Daniel MacKay wrote:
> Gregg:
>
> The three wires are:
>
> 1) Power, +5v
> 2) Ground
> 3) Data
>
> On 2013-07-13, at 13:00 , Eloy Paris wrote:
>
>> On 07/13/2013 11:22 AM, Daniel MacKay wrote:
>>
>>> Gregg:
>>>
How are they being powered? What sort of wiring
Gregg:
The three wires are:
1) Power, +5v
2) Ground
3) Data
On 2013-07-13, at 13:00 , Eloy Paris wrote:
> On 07/13/2013 11:22 AM, Daniel MacKay wrote:
>
>> Gregg:
>>
>>> How are they being powered? What sort of wiring method are you using?
>>
>> They're on three wires, "Linear" style:
>>
>
On 07/13/2013 11:22 AM, Daniel MacKay wrote:
> Gregg:
>
>> How are they being powered? What sort of wiring method are you using?
>
> They're on three wires, "Linear" style:
>
> http://www.maximintegrated.com/images/appnotes/148/148Fig01.gif
What is the third wire? The above diagram only shows two
Gregg:
> How are they being powered? What sort of wiring method are you using?
They're on three wires, "Linear" style:
http://www.maximintegrated.com/images/appnotes/148/148Fig01.gif
being driven by a SheepWalk RPI2
http://www.sheepwalkelectronics.co.uk/RPI2.shtml
--
On Sat, Jul 13, 2013 at 11:11 AM, Daniel MacKay wrote:
> I notice my DS18S20 and DS18B20 sensors, if there's a network failure or..
> perhaps a hardware failure from overheating the sensor when I'm soldering
> wires onto the leads, reports "85" as the temperature.
>
> As far as I can tell the "c
I notice my DS18S20 and DS18B20 sensors, if there's a network failure or..
perhaps a hardware failure from overheating the sensor when I'm soldering wires
onto the leads, reports "85" as the temperature.
As far as I can tell the "crc8" value is correct in these instances.
a) why does it do this
everything the same, just a 'umount /1wire' and a './digitemp
-s/dev/ttyS0 -i; ./digitemp -a'
Paul Alfille wrote:
> All with the DS2409 circuit?
>
> On 2/6/07, Chris <[EMAIL PROTECTED]> wrote:
>>
>> Ah, I forgot to say, it works with digitemp in linux and with
>> 1wire-viewer in windows, also wit
All with the DS2409 circuit?
On 2/6/07, Chris <[EMAIL PROTECTED]> wrote:
Ah, I forgot to say, it works with digitemp in linux and with
1wire-viewer in windows, also with not-connected VDD-Pin on the DS18s20.
Paul Alfille wrote:
> I can't test a DS2409 until next week.
>
> You know the VDD (on
Ah, I forgot to say, it works with digitemp in linux and with
1wire-viewer in windows, also with not-connected VDD-Pin on the DS18s20.
Paul Alfille wrote:
> I can't test a DS2409 until next week.
>
> You know the VDD (on the DS18S20) should be powered, or grounded, not
> allowed to float free.
>
I can't test a DS2409 until next week.
You know the VDD (on the DS18S20) should be powered, or grounded, not
allowed to float free.
I wonder if there isn't a problem with power for conversion using a DS2409
hub. It will take some experimentation.
Paul Alfille
On 2/6/07, Chris <[EMAIL PROTECTED
First thing is... I am using owfs 2.6p1 in linux. I have a
ds9097u-adaptor and built myself a small hub based on three ds2409. It
works well and I can connect an LCD and it just works. And now the
problem: When I connect a ds18s20 to the hub it always reads 85°C :(
But it works great when I connect
30 matches
Mail list logo
