Yeah, coming at this cold the debug info isn’t especially useful. For me it’s
moot now though — I just ordered a second enet2 box and that will give me up to
44 sensors via their nice, simple, compact and fast http query format. Since
my software already handles this quite well, owfs is no
(cc back to list)
I've never used this ENET2 master, so I don't really know what to expect
from the communication, so hard to say what's happning.. Hopefully
someone else on the list have used it and might shed some light on it.
One thing which would be useful to add to owfs debug output is
On 17/11/17 16:10, Andrew Brownsword wrote:
Decided to try owcapi through owserver with my application (I had
opted against owserver because it seems quite flakey at startup when
the system reboots), just to see how it works. Unfortunately it
appears to discover even fewer of the sensors than
Decided to try owcapi through owserver with my application (I had opted against
owserver because it seems quite flakey at startup when the system reboots),
just to see how it works. Unfortunately it appears to discover even fewer of
the sensors than the OW-SERVER-ENET2’s built-in code (varies
Further follow up on this issue — the COM_write_once failure seems spurious as
it only happens while stepping in the debugger. The later failure, however,
happens debugging or not. The select() call in tcp_read() is always failing
with an invalid argument, which looks like the file_descriptor
With the LibStart() call inserted (or using OW_init without the program name as
a first argument), I can now step into the connection process. Unfortunately
it fails in COM_write_once during a write() call. It is trying to write 50
bytes, and the write of the first pipe causes a SIGPIPE
I noticed that OW_init_args() doesn’t appear to call LibStart(NULL), while
OW_init() does. Is this by design? By inserting the LibStart(NULL) call
things proceed much further, and although it is still having issues
communicating with my enet device, at least now it is trying!
> On Nov 10,
Thanks Justin and Jan, your replies help enormously. I can now step into the
libowcapi code, at least, and therefore can make forward progress. Might I
suggest that the libowcapi man page(s) be supplemented to contain this
information as well? I couldn’t find it.
The first thing I
Sorry for the multiple replies. I thought my messages weren't going out,
but really there's just a 1h+ delay...
On 11/08/2017 06:37 PM, Justin Brewer wrote:
...snip...
--
Check out the vibrant tech community on one of
On Wed, Nov 08, 2017 at 01:51:49PM -0800, Andrew Brownsword wrote:
> Nothing but crickets — is anyone out there?
>
> I’ve been poking at the code to try and figure out how to enable my debugger
> to step into the libowcapi/libow code, but the make process is obscure enough
> that some advice
I have been working with libowcapi recently, and have seen similair
symptoms. There's a race condition in libow that, if it doesn't outright
crash, causes problems with directory listings. I have a patch for this
issue here:
Am 08.11.2017 um 22:51 schrieb Andrew Brownsword:
> Nothing but crickets — is anyone out there?
>
> I’ve been poking at the code to try and figure out how to enable my
> debugger to step into the libowcapi/libow code, but the make process
> is obscure enough that some advice would be welcome...
>
Nothing but crickets — is anyone out there?
I’ve been poking at the code to try and figure out how to enable my debugger to
step into the libowcapi/libow code, but the make process is obscure enough that
some advice would be welcome...
Sent from my iPhone
> On Oct 31, 2017, at 3:11 PM,
Hello,
I have an EDS ETH-OWSERVER v2, and I am trying to talk to it using the owcapi
library. The init with arts function returns success but when I try to OW_get,
I don’t see any buses or sensors (just the meta directories). If I run
owserver, it sees the enet device and it’s 3 buses and 22
14 matches
Mail list logo
