Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Jan Kandziora
Hi,

I just committed the "latesttemp" node we have been talking about
recently. It's function: provide a way to read the temperature value
from scratchpad *without triggering a conversion*.

This is especially useful in conjunction with simultaneous conversions.

$ owwrite /simutaneous/temperature 1
$ sleep 1
$ owread /uncached/10.AE9C54020800/latesttemp
    19.6875
$ owread /uncached/10.9EFD53020A00/latesttemp
       21.5
...

Please pull from the git archive and test.

Kind regards

        Jan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Stefano Miccoli
I do not like the  /simultaneous/temperature interface.

As a general rule, owserver operations are synchronous: if you read say /uncached/10.AE9C54020800/temperature, you get a reply when the requested data is available.

On the contrary a write to  /simultaneous/temperature is asynchronous, since it will return *before* data is available.
IMHO for consistency also a write to /simultaneous/temperature should *block* until all conversions are performed. I.e. ‘simultaneous’ ops should be synchronous: by doing so there is no need for the 'sleep 1’ before the owread commands.

Moreover what happens if process A writes to  /simultaneous/temperature and process B reads from /uncached/10.AE9C54020800/temperature before the 1.0s for the conversion are over? Will this result in a race condition? Maybe all operations involving temperature should be blocked during the simultaneous conversion.

Finally we have different temperature resolutions.

/structure/22/temperature                't,000000,000001,ro,000012,v,'
/structure/22/temperature10              't,000000,000001,ro,000012,v,'
/structure/22/temperature11              't,000000,000001,ro,000012,v,'
/structure/22/temperature12              't,000000,000001,ro,000012,v,'
/structure/22/temperature9               't,000000,000001,ro,000012,v,'

which one will be returned by latesttemp? Wouldn’t it be better to have

/structure/22/last/temperature                't,000000,000001,ro,000012,v,'
/structure/22/last/temperature10              't,000000,000001,ro,000012,v,'
/structure/22/last/temperature11              't,000000,000001,ro,000012,v,'
/structure/22/last/temperature12              't,000000,000001,ro,000012,v,'
/structure/22/last/temperature9               't,000000,000001,ro,000012,v,'

instead of a catchall /structure/22/latesttemp ?
Even if the simultaneous conversion is valid for only a single resolution, I would still prefer a single /22/last/temperatureXX instead of a  /22/latesttemp node.
S.

On 02 Feb 2016, at 01:18, Jan Kandziora <[hidden email]> wrote:

Hi,

I just committed the "latesttemp" node we have been talking about
recently. It's function: provide a way to read the temperature value
from scratchpad *without triggering a conversion*.

This is especially useful in conjunction with simultaneous conversions.

$ owwrite /simutaneous/temperature 1
$ sleep 1
$ owread /uncached/10.AE9C54020800/latesttemp
   19.6875
$ owread /uncached/10.9EFD53020A00/latesttemp
      21.5
...

Please pull from the git archive and test.

Kind regards

Jan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

jerry scharf
Hi,

This would break my code. I send out simultaneous on each bus I have then come back around and read the values.

jerry

On 02/02/2016 04:06 PM, Stefano Miccoli wrote:
I do not like the  /simultaneous/temperature interface.

As a general rule, owserver operations are synchronous: if you read say /uncached/10.AE9C54020800/temperature, you get a reply when the requested data is available.

On the contrary a write to  /simultaneous/temperature is asynchronous, since it will return *before* data is available.
IMHO for consistency also a write to /simultaneous/temperature should *block* until all conversions are performed. I.e. ‘simultaneous’ ops should be synchronous: by doing so there is no need for the 'sleep 1’ before the owread commands.

Moreover what happens if process A writes to  /simultaneous/temperature and process B reads from /uncached/10.AE9C54020800/temperature before the 1.0s for the conversion are over? Will this result in a race condition? Maybe all operations involving temperature should be blocked during the simultaneous conversion.

Finally we have different temperature resolutions.

/structure/22/temperature                't,000000,000001,ro,000012,v,'
/structure/22/temperature10              't,000000,000001,ro,000012,v,'
/structure/22/temperature11              't,000000,000001,ro,000012,v,'
/structure/22/temperature12              't,000000,000001,ro,000012,v,'
/structure/22/temperature9               't,000000,000001,ro,000012,v,'

which one will be returned by latesttemp? Wouldn’t it be better to have

/structure/22/last/temperature                't,000000,000001,ro,000012,v,'
/structure/22/last/temperature10              't,000000,000001,ro,000012,v,'
/structure/22/last/temperature11              't,000000,000001,ro,000012,v,'
/structure/22/last/temperature12              't,000000,000001,ro,000012,v,'
/structure/22/last/temperature9               't,000000,000001,ro,000012,v,'

instead of a catchall /structure/22/latesttemp ?
Even if the simultaneous conversion is valid for only a single resolution, I would still prefer a single /22/last/temperatureXX instead of a  /22/latesttemp node.
S.

On 02 Feb 2016, at 01:18, Jan Kandziora <[hidden email]> wrote:

Hi,

I just committed the "latesttemp" node we have been talking about
recently. It's function: provide a way to read the temperature value
from scratchpad *without triggering a conversion*.

This is especially useful in conjunction with simultaneous conversions.

$ owwrite /simutaneous/temperature 1
$ sleep 1
$ owread /uncached/10.AE9C54020800/latesttemp
   19.6875
$ owread /uncached/10.9EFD53020A00/latesttemp
      21.5
...

Please pull from the git archive and test.

Kind regards

Jan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Jan Kandziora
In reply to this post by Stefano Miccoli
Am 03.02.2016 um 01:06 schrieb Stefano Miccoli:
>
> On the contrary a write to  /simultaneous/temperature is
> asynchronous, since it will return *before* data is available. IMHO
> for consistency also a write to /simultaneous/temperature should
> *block* until all conversions are performed.
>
There is no way to ensure this. A broadcast command may reach a chip or
it may not. That's hard-wired into the term "broadcast".

So if you are using /simultaneous, you have to accept you are fully on
your own. Synchronizing and error handling is all your own business. I
don't think it is useful to have owfs doing a "fake" synchronization,
making users unaware of the implications of using a broadcast command.


>
> I.e. ‘simultaneous’ ops
> should be synchronous: by doing so there is no need for the 'sleep 1’
> before the owread commands.
>
> Moreover what happens if process A writes to
> /simultaneous/temperature and process B reads from
> /uncached/10.AE9C54020800/temperature before the 1.0s for the
> conversion are over? Will this result in a race condition?
>
As far as I've tested it, the scratchpad is updated in an atomic
fashion, so you would either read the old or the new value, never a
mixture of both. IIRC I asked Paul the same years ago and he tested it,
too (as the datasheet says nothing about it) and found that it is.

For using /simultaneous, there should be only one process triggering
these conversions. In fact, with "latesttemp" we can finally fix all
these RRD problems users reported:

RRD cooking recipe:
==================================================================
Run this:
------------------------------------------------------------------
#!/bin/sh
while : ; do owwrite /simultaneous/temperature 1 ; sleep 1 ; done
------------------------------------------------------------------

Then tell your RRD tool to read "latesttemp" instead of "temperature".
You'll get a nice chart of temperatures updated every second without
those stupid lockup problems.
==================================================================

I even postulate most people want temperature sampling to be
asynchronous, as temperatures are very very seldom sampled in regard to
a certain trigger condition but continously instead.

And even if we had a certain trigger, e.g. monitoring how temperature is
changing after turning on a burner, people would just oversample it and
correlate the trigger later on. The long time constants of heat
dissipation usually allow that.


> Maybe all
> operations involving temperature should be blocked during the
> simultaneous conversion.
>
That would make the temperature conversion code even more complicated
and error-prone and /simultaneous/temperature less useful. Plus, it's a
fake.


>
> Finally we have different temperature resolutions.
>
> /structure/22/temperature
> 't,000000,000001,ro,000012,v,' /structure/22/temperature10
> 't,000000,000001,ro,000012,v,' /structure/22/temperature11
> 't,000000,000001,ro,000012,v,' /structure/22/temperature12
> 't,000000,000001,ro,000012,v,' /structure/22/temperature9
> 't,000000,000001,ro,000012,v,'
>
> which one will be returned by latesttemp?
>
The value from the scratchpad. That is, the lastest resolution you've
set on the chip. Power-up-default is 12 bits, but that's programable,
though OWFS lacks an interface to do that. Yet.


> /structure/22/last/temperature
> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature10
> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature11
> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature12
> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature9
> 't,000000,000001,ro,000012,v,'
>
That would require to have OWFS keep track of the different values,
which again makes the temperature conversion code even more complicated
and error-prone. Plus, I doubt anyone ever needs that bug.


Did I mention you always have to check for power-up? You cannot just
read a conversion result and take for granted it's valid. That's the
infamous 85°C reading. OWFS takes some measures against this, but it's
only heuristics. The only safe way to check for power-up is to never do
12-bit conversions and then test whether the resolution has changed back
to 12-bit since the last conversion trigger. (Or setup the EEPROM for
another default and check for this.) Reading temperature and resolution
is atomic, fortunately.


If I had to decide, I would implement this safe, atomic 85°C reading
tomorrow and throw out the heuristics completely. Hardly anyone needs
the 12-Bit resolution, that's less than 0.2°C, even with the chip being
calibrated your mounting certainly is not and I doubt anyone using OWFS
has a setup to calibrate it. You'd need a physics lab to do that. Better
than 1°C accuracy is 99% fake.



My opinion: "latesttemp" is simple and stupid, that's why it "just
works". It gives you the cooked value you could also read from the
undocumented "scratchpad" node. Nothing more.


Kind regards

        Jan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Johan Ström-3
In reply to this post by jerry scharf
+1, I'm using my 1wire bus for more than temperature sensors, blocking on something that does not need to block would ruin my setup (polling alarms every 0.2s)

On 03/02/16 01:43, Jerry Scharf wrote:
Hi,

This would break my code. I send out simultaneous on each bus I have then come back around and read the values.

jerry

On 02/02/2016 04:06 PM, Stefano Miccoli wrote:

On the contrary a write to  /simultaneous/temperature is asynchronous, since it will return *before* data is available.
IMHO for consistency also a write to /simultaneous/temperature should *block* until all conversions are performed. I.e. ‘simultaneous’ ops should be synchronous: by doing so there is no need for the 'sleep 1’ before the owread commands.




------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Stefano Miccoli
In reply to this post by Jan Kandziora
OK I agree… mine was a misguided suggestion (due to the lack of understanding of what a write to /simultaneous/temperature actually does.)

If I got it right, everything boils down to these points.

- By simultaneous conversion, we mean a broadcast that tells all sensors to start a temperature conversion. The single sensors do not report back when and if the conversion was done.

- There is no way from the client side to have the owserver lock the 1-wire bus and avoid that during the background temperature conversion other clients start conflicting operations on the 1-wire bus. The assumption here is that you have complete control of all owserver clients: due to the lack of owserver synchronisation/lock primitives, everything has to be done with IPC primitives client side.

- Due to the atomic nature of the scratchpad update, race conditions cannot occur: a very loose client synchronisation is enough for most applications.

A section 4 manpage (src/man/man4/owfs.man) would be very useful to document the bunch of special nodes in the OWFS tree, and their use. Docs about the working of the special nodes (like /simultaneous/temperature) is a little bit scattered and not easily accessible. (Sorry I do not volunteer for writing this manpage, because my understanding of the inner working of owfs is a little weak, as my posts demonstrate.)

Stefano



> On 03 Feb 2016, at 02:07, Jan Kandziora <[hidden email]> wrote:
>
> Am 03.02.2016 um 01:06 schrieb Stefano Miccoli:
>>
>> On the contrary a write to  /simultaneous/temperature is
>> asynchronous, since it will return *before* data is available. IMHO
>> for consistency also a write to /simultaneous/temperature should
>> *block* until all conversions are performed.
>>
> There is no way to ensure this. A broadcast command may reach a chip or
> it may not. That's hard-wired into the term "broadcast".
>
> So if you are using /simultaneous, you have to accept you are fully on
> your own. Synchronizing and error handling is all your own business. I
> don't think it is useful to have owfs doing a "fake" synchronization,
> making users unaware of the implications of using a broadcast command.
>
>
>>
>> I.e. ‘simultaneous’ ops
>> should be synchronous: by doing so there is no need for the 'sleep 1’
>> before the owread commands.
>>
>> Moreover what happens if process A writes to
>> /simultaneous/temperature and process B reads from
>> /uncached/10.AE9C54020800/temperature before the 1.0s for the
>> conversion are over? Will this result in a race condition?
>>
> As far as I've tested it, the scratchpad is updated in an atomic
> fashion, so you would either read the old or the new value, never a
> mixture of both. IIRC I asked Paul the same years ago and he tested it,
> too (as the datasheet says nothing about it) and found that it is.
>
> For using /simultaneous, there should be only one process triggering
> these conversions. In fact, with "latesttemp" we can finally fix all
> these RRD problems users reported:
>
> RRD cooking recipe:
> ==================================================================
> Run this:
> ------------------------------------------------------------------
> #!/bin/sh
> while : ; do owwrite /simultaneous/temperature 1 ; sleep 1 ; done
> ------------------------------------------------------------------
>
> Then tell your RRD tool to read "latesttemp" instead of "temperature".
> You'll get a nice chart of temperatures updated every second without
> those stupid lockup problems.
> ==================================================================
>
> I even postulate most people want temperature sampling to be
> asynchronous, as temperatures are very very seldom sampled in regard to
> a certain trigger condition but continously instead.
>
> And even if we had a certain trigger, e.g. monitoring how temperature is
> changing after turning on a burner, people would just oversample it and
> correlate the trigger later on. The long time constants of heat
> dissipation usually allow that.
>
>
>> Maybe all
>> operations involving temperature should be blocked during the
>> simultaneous conversion.
>>
> That would make the temperature conversion code even more complicated
> and error-prone and /simultaneous/temperature less useful. Plus, it's a
> fake.
>
>
>>
>> Finally we have different temperature resolutions.
>>
>> /structure/22/temperature
>> 't,000000,000001,ro,000012,v,' /structure/22/temperature10
>> 't,000000,000001,ro,000012,v,' /structure/22/temperature11
>> 't,000000,000001,ro,000012,v,' /structure/22/temperature12
>> 't,000000,000001,ro,000012,v,' /structure/22/temperature9
>> 't,000000,000001,ro,000012,v,'
>>
>> which one will be returned by latesttemp?
>>
> The value from the scratchpad. That is, the lastest resolution you've
> set on the chip. Power-up-default is 12 bits, but that's programable,
> though OWFS lacks an interface to do that. Yet.
>
>
>> /structure/22/last/temperature
>> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature10
>> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature11
>> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature12
>> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature9
>> 't,000000,000001,ro,000012,v,'
>>
> That would require to have OWFS keep track of the different values,
> which again makes the temperature conversion code even more complicated
> and error-prone. Plus, I doubt anyone ever needs that bug.
>
>
> Did I mention you always have to check for power-up? You cannot just
> read a conversion result and take for granted it's valid. That's the
> infamous 85°C reading. OWFS takes some measures against this, but it's
> only heuristics. The only safe way to check for power-up is to never do
> 12-bit conversions and then test whether the resolution has changed back
> to 12-bit since the last conversion trigger. (Or setup the EEPROM for
> another default and check for this.) Reading temperature and resolution
> is atomic, fortunately.
>
>
> If I had to decide, I would implement this safe, atomic 85°C reading
> tomorrow and throw out the heuristics completely. Hardly anyone needs
> the 12-Bit resolution, that's less than 0.2°C, even with the chip being
> calibrated your mounting certainly is not and I doubt anyone using OWFS
> has a setup to calibrate it. You'd need a physics lab to do that. Better
> than 1°C accuracy is 99% fake.
>
>
>
> My opinion: "latesttemp" is simple and stupid, that's why it "just
> works". It gives you the cooked value you could also read from the
> undocumented "scratchpad" node. Nothing more.
>
>
> Kind regards
>
> Jan
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Mick Sulley
In reply to this post by Johan Ström-3
Agreed.  My code sets simultaneous after reading all the values, then carries on doing all its control stuff, then when it gets back to reading again all the values are there.  Having a simultaneous block would just introduce a delay for no benefit.

On 03/02/16 07:00, Johan Ström wrote:
+1, I'm using my 1wire bus for more than temperature sensors, blocking on something that does not need to block would ruin my setup (polling alarms every 0.2s)

On 03/02/16 01:43, Jerry Scharf wrote:
Hi,

This would break my code. I send out simultaneous on each bus I have then come back around and read the values.

jerry

On 02/02/2016 04:06 PM, Stefano Miccoli wrote:

On the contrary a write to  /simultaneous/temperature is asynchronous, since it will return *before* data is available.
IMHO for consistency also a write to /simultaneous/temperature should *block* until all conversions are performed. I.e. ‘simultaneous’ ops should be synchronous: by doing so there is no need for the 'sleep 1’ before the owread commands.





------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Jan Kandziora
In reply to this post by Stefano Miccoli
Am 03.02.2016 um 09:53 schrieb Stefano Miccoli:

> OK I agree… mine was a misguided suggestion (due to the lack of
> understanding of what a write to /simultaneous/temperature actually
> does.)
>
> If I got it right, everything boils down to these points.
>
> - By simultaneous conversion, we mean a broadcast that tells all
> sensors to start a temperature conversion. The single sensors do not
> report back when and if the conversion was done.
>
Yes. It's just "Reset, 0xCC, 0x44" put on the bus. That was it. A chip
may do something upon receiving that sequence or it may ignore it. The
temperature sensor chips start their A/D conversion cycle with the
resolution stored in their scratchpad[4].

You can start a simultaneous conversion for a single bus, for an
owserver or for all buses known.


> - There is no way from the client side to have the owserver lock the
> 1-wire bus and avoid that during the background temperature
> conversion other clients start conflicting operations on the 1-wire
> bus. The assumption here is that you have complete control of all
> owserver clients: due to the lack of owserver synchronisation/lock
> primitives, everything has to be done with IPC primitives client
> side.
>
You don't have this safety against conflicting operations for any other
function either. One client may turn a PIO and assume it stays in the
direction it was set. However, another client may turn the very same PIO
a blink later.

In general, there is no safe way to have multiple applications access
the same hardware without doing a logical partitioning first. So far, we
rely on applications being cooperative and properly configured to
coexist with each other.


> - Due to the atomic nature of the scratchpad update, race conditions
> cannot occur: a very loose client synchronisation is enough for most
> applications.
>
Yes. For temperature conversions, as stated, there is no need for bus
locking as the update of the sampled temperature value inside the chip
is atomic. The only reason OWFS helds the transaction open for single
temperature conversions is to expose the "ready" function the chips
have. You can sample the bus line for end of conversion. But then again,
this is limited to the folks who power their sensors.


> A section 4 manpage (src/man/man4/owfs.man) would be very useful to
> document the bunch of special nodes in the OWFS tree, and their use.
> Docs about the working of the special nodes (like
> /simultaneous/temperature) is a little bit scattered and not easily
> accessible. (Sorry I do not volunteer for writing this manpage,
> because my understanding of the inner working of owfs is a little
> weak, as my posts demonstrate.)
>
Ah, yes, documentation is sparse. But I don't think manpages help much,
being scattered is their nature.

I'm up to write a recipe book with lots of useful information how to
build a reliable OWFS based process control system, hardware and
software. As I did this myself and sell such machines with some success,
I feel able to do so.

Writing a comprehesive documentation about OWFS is another task which I
don't want to do yet.


Kind regards

        Jan



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Stefano Miccoli

On 03 Feb 2016, at 16:29, Jan Kandziora <[hidden email]> wrote:

Ah, yes, documentation is sparse. But I don't think manpages help much,
being scattered is their nature.

I suggested a man page because it is the only documentation that is bundled with the SW itself.

I'm up to write a recipe book with lots of useful information how to
build a reliable OWFS based process control system, hardware and
software. As I did this myself and sell such machines with some success,
I feel able to do so.

So do not forget my wonderful pyownet ;-))

Stefano


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Jan Kandziora
Am 03.02.2016 um 17:44 schrieb Stefano Miccoli:
>
>> On 03 Feb 2016, at 16:29, Jan Kandziora <[hidden email]> wrote:
>>
>> Ah, yes, documentation is sparse. But I don't think manpages help much,
>> being scattered is their nature.
>
> I suggested a man page because it is the only documentation that is bundled with the SW itself.
>
Ah, okay. We have to change that.


>> I'm up to write a recipe book with lots of useful information how to
>> build a reliable OWFS based process control system, hardware and
>> software. As I did this myself and sell such machines with some success,
>> I feel able to do so.
>
> So do not forget my wonderful pyownet ;-))
>
Had the idea to ask people to write about their own pieces, too, with me
being the editor of these sections only. Thus, "recipe book".


Kind regards

        Jan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Henrik Östman
In reply to this post by Jan Kandziora
Thanks Jan!

It's working great for me, I never got my old "echo 1 > /simultaneous,
read /temperature"-loop working as it should. The readings where never
done simultaneous.
But now with "latesttemp" I'm in full control of how the readings are
done and I see a much improved performance when reading lots of sensors.

Can we expect a "latestvoltage" in the future also?
Anyway, I am more than happy with the current support for the moment.

// Henrik


Den 2016-02-02 kl. 01:18, skrev Jan Kandziora:

> Hi,
>
> I just committed the "latesttemp" node we have been talking about
> recently. It's function: provide a way to read the temperature value
> from scratchpad *without triggering a conversion*.
>
> This is especially useful in conjunction with simultaneous conversions.
>
> $ owwrite /simutaneous/temperature 1
> $ sleep 1
> $ owread /uncached/10.AE9C54020800/latesttemp
>      19.6875
> $ owread /uncached/10.9EFD53020A00/latesttemp
>         21.5
> ...
>
> Please pull from the git archive and test.
>
> Kind regards
>
> Jan
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Matthias Urlichs-3
On 08.02.2016 07:17, Henrik Östman wrote:
> Can we expect a "latestvoltage" in the future also?

Seconded. (I actually need that, come to think of it.)

-- Matthias


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introducing a new "latesttemp" node on the DS18B20, DS18S20, DS1822, DS1825, and DS28AE00.

Jan Kandziora
In reply to this post by Henrik Östman
Am 08.02.2016 um 07:17 schrieb Henrik Östman:
>
> Can we expect a "latestvoltage" in the future also?
>
Done for the DS2450. Also added "latesttemp" for the DS2438. The voltage
sampling on the DS2438 is different however, and doesn't react to
/simultaneous/voltage at all.

Kind regards

        Jan

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers