Some way to test if owserver is busy still initializing would be helpful.
Maybe a flag for owserver that will cause it just to return its status?
If I try to start owfs before owserver has come on line, things fail.
Is there a better way then what I have been using?
Bruce
echo -ne "Starting owserver."
/opt/owfs/bin/owserver -u -p 3000
owd=$( ./owdir )
owl=${#owl}
while [ $owl -lt 1 ]
do
echo -ne "."
owd=$( ./owdir )
owl=${#owd}
done
echo "ok"
echo "Starting owfs..."
/opt/owfs/bin/owfs -s 3000 /mnt/1wire
From: Paul Alfille
Sent: Saturday, August 20, 2011 12:28 AM
To: OWFS (One-wire file system) discussion and help
Subject: Re: [Owfs-developers] errno in owcapi
This discussion is helpful. Would you add or modify the following feedback
through error code proposal?
Paul
A. Initialization
B. Closure
C. Directory
D. Read
E. Write
--------------
A. Configuration problems should a be separate errorspace (at the time of
initialization):
0. Success
1. invalid command line options
2. no 1-wire source (bus master) specified
3. no 1-wire source (bus master) available
4. insufficient permission from operating system
99. Unknown error
B. Closing should be a separate errorspace
0. Success
99. Unknown error
(D) Read and (C)Directory should be a combined errorspace (because "get" can be
either) and we might as well combine (E)Write since there is considerable
overlap:
0. Success
1. Uninitialized
2. Directory (not appropriate)
3. Not a directory (not appropriate)
4. Read not supported
5. Write not supported
6. Read-only
7. Invalid path
8. Invalid device (CRC wrong)
9. Invalid device (alias error?)
10. Bus does not exist
11. Bus is not working
12 Bus is wrong type
13 Bus short
14. Not an array
15. Array out of bounds
16. Not a scalar
17. Not a bitfield
18. 1-wire error
99. Unknown error
On Fri, Aug 19, 2011 at 1:27 PM, Mark Richards <mark.richa...@massmicro.com>
wrote:
On 8/19/2011 12:43, ekgnkb3d wrote:
Paul Alfille-2 wrote:
Do you have an idea of what information you want from the error code?
I would like to distinguish between errors in:
- The application: like a typo in the path which is is nonsens (e.g.
"uncaxxched/", or "temperature21" in a DS18B20)
- The configuration: like accessing a invalid device (e.g. CRC is not valid,
wrong format "/28.7A00.0E" or "/28.7X20Z&010000.0E"
- The hardware: like non reachable devices (e.g. devices never been
connected, temporarily unavailable, shorted bus)My 0,002 c, which may help the
discussion, maybe..
1. It seems to me that "application errors" would be confined to:
- bad path (device path not present or typo error)
- bad configuration information (ow_init)
- invalid request (asking the API to do something that cannot be done)
2. Configuration errors would fall within (1) as they relate to ow_init.
Both 1 and 2 seem to be already covered in the API.
New items (?):
3. Bus or device errors
- CRC fail on read/write/scan/convert, etc
- Bus short
- Adapter connected but not responding
* owfs presumably knows when an adapter has connected and somehow
determines that it has disconnected.
It may be impossible to distinguish a disconnected adapter from
an adapter that is connected but unresponsive.
This is particularly true with the DS2490 which locks up during a
bus short condition and can only be recovered by
cycling power to the DS2490 (and bus, if a powered bus).
4. Bus events (not errors)
- Adapter connected/removed
- Device connected/removed
Bus or Device Errors:
* expose a single global bit state indicating:
- an error on a device
- an error on a bus
- an adapter error
* elaborate on error within the end-structure of the specific owfs
device, in the case of a device error, or the root in the case of an adapter.
./CRC_error (retry count)
./error_desc (string)
In the case of a missing device (where your application has stored the
address, the device is taken off the bus, and your application does not know
this fact) OWFS will also return EINVALID. I am not certain that it's possible
to distinguish the difference. However, it would be nice to have an event
fired (or queued and available by interrogation via the API) when a device is
added or removed. This would allow the user application to remain in sync.
In my case I will just re-scan the entire owfs network anyway, so a single
event saying "changed" is sufficient.
/m
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
--------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
