Paul and Eloy,
I don't have an opinion whether the external devices should be added to
the main list in the long run, but given the potential cost of doing an
directory listing, this may be a wise precaution. Having an /external
directory for these may be the right way to go until we learn more
Hi Paul,
On 02/28/2012 10:17 PM, Paul Alfille wrote:
> Ok, these are the design notes so far:
> http://owfs.org/index.php?page=external-sensor-design
>
> I'm only so-so happy with the "external" name for the program
> (owexternal) and directory (/external).
What about using different "buses" for
here is some data format... we could use owfs format...
http://owfs.org/index.php?page=structure-directory
owread /structure/10/temperature
check that we could call a program... PROGRAM READ /structure/10/temperature
we could use the same parameters of owread and owwrite...
t,00,01,ro,000
i have some ideas, maybe could not work maybe could...
i was reading http://owfs.org/index.php?page=external-sensor-design
Configuration will be by text files
Two layers of config
First layer has the list of devices (unique names)
Second layer describes the device's family
i was thi
don´t forget to allow owhttpd work with it too
it´s very nice the idea of making a modbus program and interface it
directly with owhttp allowing a json interface to javascript
Em 29 de fevereiro de 2012 00:33, Roberto Spadim
escreveu:
> very very nice!!!
> maybe we could use json or another
very very nice!!!
maybe we could use json or another language to send and receive informations?
maybe a txt or csv or xml(i don´t like xml... txt and csv can run in
any bash program, json is more usable in php,perl,python scripts)
do you have any idea about the implemention?
Em 29 de fevereiro d
Ok, these are the design notes so far:
http://owfs.org/index.php?page=external-sensor-design
I'm only so-so happy with the "external" name for the program (owexternal)
and directory (/external).
All the configuration files are a bit of a nuisance, but we really have two
things:
Family types (defi
Paul Alfille-2 wrote:
>
> Interesting idea. I've been tempted to build a special owserver that has
> plug-in sensor code -- owexternal.
>
> The plug-in would get a separate mane space (perhaps
> /external/sensor43/humidity) and have to report a few properties like
> length, type, read/write and
On 02/27/2012 09:13 PM, Paul Alfille wrote:
> Interesting idea. I've been tempted to build a special owserver that has
> plug-in sensor code -- owexternal.
>
> The plug-in would get a separate mane space (perhaps
> /external/sensor43/humidity) and have to report a few properties like
> length, typ
Interesting idea. I've been tempted to build a special owserver that has
plug-in sensor code -- owexternal.
The plug-in would get a separate mane space (perhaps
/external/sensor43/humidity) and have to report a few properties like
length, type, read/write and volatility.
Plugins could be written
Hi all,
beside using 1-Wire devices I would like to use other sensors as well.
Currently I play with an temp-sensor getting data very simple by a serial
port.
So writing all this polling, retry, alias, fuse (and a lot of other
functionality) again is a lot of effort - so maybe there is a way to e
11 matches
Mail list logo
