can anyone make an PHP version of it?!
Peter Kropf escreveu:
> Hi -
>
> I've committed to CVS the first draft of a new python module called
> ownet. It allows for interaction with a remote owserver without the
> need to have the core ow libraries and servers built on the local
> system. The code i
I disagree. 85 is a valid reading since the chip can read from -10 to +125 and
nowhere in the spec document does it state that 85 cannot be a valid reading.
It
just states that 85 is the power-on reset value.
I think it would have been better for Dallas to have the power-on value
something on
You can't.
So instead if I see an 85C result, I issue the fix code and read again.
It's inconsequential in the scheme of things.
Eric Vickery wrote:
> An 85 is returned if the temperature conversion had a problem or is not
> finished
> yet. The problem is how can you tell when it is a good rea
An 85 is returned if the temperature conversion had a problem or is not
finished
yet. The problem is how can you tell when it is a good reading of 85.
Eric
Darryl wrote:
> On 12/5/06, Mark Richards <[EMAIL PROTECTED]> wrote:
>> Dallas had an issue with 18B20, 18S20, 18B20-PAR, and 18S20-PAR dev
On 12/5/06, Mark Richards <[EMAIL PROTECTED]> wrote:
> Dallas had an issue with 18B20, 18S20, 18B20-PAR, and 18S20-PAR devices,
> known famously as the "C3" Die problem, some time ago. It is
> characterized, as I am told, by repeated 85C readings returned from the
> device caused by a failure of t
Dallas had an issue with 18B20, 18S20, 18B20-PAR, and 18S20-PAR devices,
known famously as the "C3" Die problem, some time ago. It is
characterized, as I am told, by repeated 85C readings returned from the
device caused by a failure of the chip to properly POR. The fix
involves issuing an "ex
85 (the AA00 bit pattern) is apparently one of the error modes of the chip.
We repeat the measurement if it occurs. Then return the value (it COULD be
correct). I don't know how to improve. Perhaps power issues? Purely a guess.
Paul
On 12/5/06, Darryl <[EMAIL PROTECTED]> wrote:
> Unless what y
> Unless what you have here is a failure to wait for a conversion to
> complete... but it's unimaginable that 1WFS would fail in this manner.
>
> /mark
>
>
> Darryl wrote:
> > Paul,
> >
> > Actually 2.4p8 has been running great for some time so I have not upgraded.
> >
> > I just pulled cvs to see
Paul,
Actually 2.4p8 has been running great for some time so I have not upgraded.
I just pulled cvs to see how it goes(older box takes quite a while
to compile...)
-darryl
On 12/5/06, Paul Alfille <[EMAIL PROTECTED]> wrote:
> If that was the newest from the CVS, can you pull again and retry
If that was the newest from the CVS, can you pull again and retry?
On 12/5/06, Darryl <[EMAIL PROTECTED]> wrote:
Hello,
I have some ds18s20 sensors which have been working flawlessly for
months with a hobby-boards 'hub'.
Today I added an additional ds18s20 to my garage and now I
occasionally
Hello,
I have some ds18s20 sensors which have been working flawlessly for
months with a hobby-boards 'hub'.
Today I added an additional ds18s20 to my garage and now I
occasionally get 85 as the reading on two of my sensors.
Any clues what the cause may be?
Thanks,
darryl
--
http://randomthou
I have been toying with the idea of doing something similar for my devices.
Kind
of an extension of the tagging "standard" that Dallas came up with. I have a
few
devices now that could use it and some on the drawing board that will really
need something like this to make them easier to use. Th
Currently, the only aggregate we support is the TAI-8570 barometer, which
uses 2 DS2406. In that case, the DS2406 memory is used to point to the
partner chip, so the aggregate can be "autodiscovered". There is certainly
an appeal to autodiscovery. The barrier to entry and use is much lower.
(That
On 12/5/06, Paul Alfille <[EMAIL PROTECTED]> wrote:
> Good question, Gregg.
>
> There str lots of "third party" 1-wire devices. Based on Dallas chips for
> the most part. I only own a fraction of them, and have to base support on
> interences, or reports from other users.
>
> Take a look at
> http:
On 5 Dec 2006 at 14:30, Paul Alfille wrote:
> A volunteer! To help with specification and testing.
heh
>
> I propose we start with owrest and then decide if it's function should be
> folded into owserver.
but I am confused.
REST is just a symantic for how to use HTTP verbs. So, why have a dis
Am Dienstag, 5. Dezember 2006 18:31 schrieb Gregg C Levine:
> Hello!
> That series of issues with the LCD display device that Hobby Boards
> developed independently of Maxim brought to mind an interesting issue.
>
> For example what boards made by them are directly supported? And what
> boards are
Hi -
I've committed to CVS the first draft of a new python module called
ownet. It allows for interaction with a remote owserver without the
need to have the core ow libraries and servers built on the local
system. The code is very much in an alpha state so expect things to
break. And if they do,
A volunteer! To help with specification and testing.
I propose we start with owrest and then decide if it's function should be
folded into owserver.
So:
1. What is the format of the returned object?
2. What is a collection list (the actual formatting would help).
3. Do you want XML or JSON? If X
On 5 Dec 2006 at 13:19, Paul Alfille wrote:
> This is very close to what owhttpd does now.
Are you talking about changing owhttpd, or owserver?
I'd be pleased with a true REST owhttpd that returned XML or JSON data, and
properly treated GET on adapters as returning a collection list, etc.
--
This is very close to what owhttpd does now.
After reading the background, I need some help with implementation:
1. I presume the "nouns" are the URL including the OWFS path
2. "GET" would be the default action -- either a directory list or an object
value (like temperature) (Again this is what
Good question, Gregg.
There str lots of "third party" 1-wire devices. Based on Dallas chips for
the most part. I only own a fraction of them, and have to base support on
interences, or reports from other users.
Take a look at http://www.owfs.org/index.php?page=3rd-party-devices which is
a partia
>
> On a related topic, I was thinking about using URL's to access sensors
> and fields. Something that would follow a REST
> (http://en.wikipedia.org/wiki/Representational_State_Transfer) style
> interface. Like http://host:port/10.B7B64D000800/temperature to read a
> temperature. Using this style
Hello!
That series of issues with the LCD display device that Hobby Boards
developed independently of Maxim brought to mind an interesting issue.
For example what boards made by them are directly supported? And what boards
are an inference? Consider this, the company (Hobby Boards) makes a gizmo
Yup, works now!
Thanks!
Ben
On 12/5/06, Paul Alfille <[EMAIL PROTECTED]> wrote:
Fixed. Even more sorry.
The problem was an internal change in a function syntax that only
triggered with powered temperature chips. I cought the DS18B20 and DS1822,
but not the DS18S20, until you pointed it out.
P
On 12/5/06, Paul Alfille <[EMAIL PROTECTED]> wrote:
> I like it.
>
> Should it completely replace owpython? The disadvantage is that it requires
> owserver to be running. We could support both (with a different name).
I don't think it should replace owpython. I like the idea of providing
both so t
I like it.
Should it completely replace owpython? The disadvantage is that it requires
owserver to be running. We could support both (with a different name).
One advantage of this approach is that you can have different owpython
objects, pointing to different owservers.
Object initialization sh
On 12/5/06, chris <[EMAIL PROTECTED]> wrote:
> On Tuesday 05 December 2006 06:19, Peter Kropf wrote:
> > I was poking around the owserver protocol from Python
>
> is that with socket or are you using higher level modules?
> can you show a demo script?
And here's a version that actually works: You
Fixed. Even more sorry.
The problem was an internal change in a function syntax that only triggered
with powered temperature chips. I cought the DS18B20 and DS1822, but not the
DS18S20, until you pointed it out.
Paul
On 12/5/06, Ben Griffith <[EMAIL PROTECTED]> wrote:
Still the same here :-(
Am Dienstag, 5. Dezember 2006 14:31 schrieb Jan Kandziora:
> Dear all,
>
> as scanning the onewire using the "SEARCH ROM" command is still expensive,
> I thought about different functions for detecting "plug-in" and "pull"
> events for a lock in my program.
>
Another idea: Is the "Read ROM" command
Still the same here :-(
After a cvs update didn't seem to fix it I wiped out my owfs cvs directory
and fetched the whole thing over again, but still no luck.
On 12/5/06, Paul Alfille <[EMAIL PROTECTED]> wrote:
Fixed. Sorry.
On 12/4/06, Ben Griffith <[EMAIL PROTECTED]> wrote:
>
> Thanks Paul!
On 12/5/06, chris <[EMAIL PROTECTED]> wrote:
> On Tuesday 05 December 2006 06:19, Peter Kropf wrote:
> > I was poking around the owserver protocol from Python
>
> is that with socket or are you using higher level modules?
> can you show a demo script?
Here's the code I'm playing with. Note that i
Fixed! owphp is now not configured in.
Paul
On 12/5/06, Christian Magnusson <[EMAIL PROTECTED]> wrote:
I might have fixed the problem… I guess the conditional values were set
in set too early in the configure.ac, and that caused problems for some
autoconf versions.
/Christian
Fixed. Sorry.
On 12/4/06, Ben Griffith <[EMAIL PROTECTED]> wrote:
Thanks Paul! It works! Now I know my wiring was correct after all.
But... I think something might be broken with reading temperatures from
DS18S20s. With version 2.5p7 I can read temperatures fine, but with the
CVS version if
I might have fixed the problem
I guess the conditional values were set in
set too early in the configure.ac, and that caused problems for some
autoconf versions.
/Christian
_
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Christian
Magnusson
Skickat: den 5 december 2006 14:
Accoording to your include-paths, ENABLE_OWPHP is set and PHPINC is NOT set
for some reason!?!
This should not be possible
since configure.ac sets ENABLE_OWPHP=false if
PHPINC is empty.
PHPINC is normally set to something like
PHPINC = -I/usr/include/php I/usr/include/php/main I/usr/inc
Just tested. I fingered the wrong man!
It's PHP that get's confused by zend.
Making all in php
make[3]: Entering directory `/home/paul/owfs/module/swig/php'
if /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I../../../src/include-fexceptions -I.. -I../../../src/i
Dear all,
as scanning the onewire using the "SEARCH ROM" command is still expensive, I
thought about different functions for detecting "plug-in" and "pull" events
for a lock in my program.
If the host thinks a certain key -- which was detected before by usual
scanning -- is plugged in a lock,
Directory listing is a little different. It sends multiple messages back.
One for each directory entry plus one for a null stop. (and a potential nop
one in case the directory is taking too long).
The good part is that this lowers latency -- you can start processing
directory entries while more a
On Tuesday 05 December 2006 06:19, Peter Kropf wrote:
> I was poking around the owserver protocol from Python
is that with socket or are you using higher level modules?
can you show a demo script?
-
Take Surveys. Earn Cash
Fixed in the current CVS version.
Thanks!
Serg.
Jan Kandziora wrote:
> Am Montag, 4. Dezember 2006 18:59 schrieb Jan Kandziora:
> Schnipp
> I found another bug in owtcl. If an invalid request is forwarded to owlib, it
> doesn't change the reply buffer pointer at all, not even to NULL.
>
40 matches
Mail list logo
