Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Andrew Brownsword]

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 longer needed.  I 
suppose I’ll be dropping off this list shortly.

Somebody should fix the fact that OW_init_args() doesn’t call LibStart though — 
that seems like an outright bug?!


> On Nov 17, 2017, at 11:50 AM, Johan Ström  wrote:
> 
> (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 timestamps or 
> at least relative time since last msg... Would be useful in log dumps like 
> this :)
> 
> Johan
> 
> 
>> On 17/11/17 18:12, Andrew Brownsword wrote:
>> Well my usage of owcapi is just OW_get at the root, and then iterate across 
>> each sensor and use OW_get again to retrieve its r_address, temperature, 
>> humidity, vad, and vdd values.  For sensors without a given quantity, OW_get 
>> returns instantly, but for the quantities which actually exist there is a 
>> lengthy delay and a lot of owserver output.
>> 
>> My 1-wire network does have some noise on it (mostly caused by an 
>> unfortunate proximity to some wires carrying PWM signals driving LEDs), but 
>> the OW-SERVER-ENET2’s built-in software does a good job of managing that — 
>> it reads 17-22 sensors on each iteration, and a different mixture each time 
>> so the net effect is that a few of the sensors just update at a slower rate 
>> (up to 10 seconds instead of 1-2 seconds).  At this point I’m leaning 
>> heavily toward getting a second OW-SERVER-ENET2 and continuing to their CSV 
>> interface.  Bifurcating by 1-wire network should isolate the noise problem 
>> to sensors whose update rate doesn’t matter as much.
>> 
>> 
>> A short run produce a few megabytes of debug output, but most of it is looks 
>> like variations on this theme:
>> 
>>   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
>>   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
>>   DEBUG: ow_transaction.c:(399) unpacking
>>   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
>>   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
>>   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(323)  pack=READ
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(274) Ship Packets=2
>>   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
>>   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
>>   DEBUG: ow_transaction.c:(399) unpacking
>>   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
>>   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
>>   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(323)  pack=READ
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(274) Ship Packets=2
>>   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
>>   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
>>   DEBUG: ow_transaction.c:(399) unpacking
>>   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
>>   DEBUG: loop.c:(109) Taking too long, send a keep-alive pulse
>>   DEBUG: to_client.c:(76) payload=-1 size=0, ret=0, sg=0x0 offset=0
>>   DEBUG: to_client.c:(83) Send delay message (ping)
>>   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
>>   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(323)  pack=READ
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(274) Ship Packets=2
>>   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
>>   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
>>   DEBUG: ow_transaction.c:(399) unpacking
>>   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
>>   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
>>   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(323)  pack=READ
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(274) Ship Packets=2
>>   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
>>   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
>>   DEBUG: ow_transaction.c:(399) unpacking
>>   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
>>   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
>>   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(323)  pack=READ
>>   DEBUG: ow_transaction.c:(251) Item added
>>   DEBUG: ow_transaction.c:(274) Ship Packets=2
>>   DEBUG: 

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Johan Ström]

(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 
timestamps or at least relative time since last msg... Would be useful 
in log dumps like this :)


Johan


On 17/11/17 18:12, Andrew Brownsword wrote:

Well my usage of owcapi is just OW_get at the root, and then iterate across 
each sensor and use OW_get again to retrieve its r_address, temperature, 
humidity, vad, and vdd values.  For sensors without a given quantity, OW_get 
returns instantly, but for the quantities which actually exist there is a 
lengthy delay and a lot of owserver output.

My 1-wire network does have some noise on it (mostly caused by an unfortunate 
proximity to some wires carrying PWM signals driving LEDs), but the 
OW-SERVER-ENET2’s built-in software does a good job of managing that — it reads 
17-22 sensors on each iteration, and a different mixture each time so the net 
effect is that a few of the sensors just update at a slower rate (up to 10 
seconds instead of 1-2 seconds).  At this point I’m leaning heavily toward 
getting a second OW-SERVER-ENET2 and continuing to their CSV interface.  
Bifurcating by 1-wire network should isolate the noise problem to sensors whose 
update rate doesn’t matter as much.


A short run produce a few megabytes of debug output, but most of it is looks 
like variations on this theme:

   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
   DEBUG: ow_transaction.c:(399) unpacking
   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(323)  pack=READ
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(274) Ship Packets=2
   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
   DEBUG: ow_transaction.c:(399) unpacking
   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(323)  pack=READ
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(274) Ship Packets=2
   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
   DEBUG: ow_transaction.c:(399) unpacking
   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
   DEBUG: loop.c:(109) Taking too long, send a keep-alive pulse
   DEBUG: to_client.c:(76) payload=-1 size=0, ret=0, sg=0x0 offset=0
   DEBUG: to_client.c:(83) Send delay message (ping)
   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(323)  pack=READ
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(274) Ship Packets=2
   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
   DEBUG: ow_transaction.c:(399) unpacking
   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(323)  pack=READ
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(274) Ship Packets=2
   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
   DEBUG: ow_transaction.c:(399) unpacking
   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(323)  pack=READ
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(274) Ship Packets=2
   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
   DEBUG: ow_transaction.c:(399) unpacking
   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
   DEBUG: ow_transaction.c:(373) pack=(U)DELAYS
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(323)  pack=READ
   DEBUG: ow_transaction.c:(251) Item added
   DEBUG: ow_transaction.c:(274) Ship Packets=2
   DEBUG: ow_tcp_read.c:(63) attempt 4 bytes Time: 0.600 seconds
   DEBUG: ow_tcp_read.c:(113) read: 4 - 0 = 4
   DEBUG: ow_transaction.c:(399) unpacking
   DEBUG: ow_transaction.c:(465) unpacking #0 DELAY
   DEBUG: ow_transaction.c:(425) unpacking #1 READ MODIFY
   

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Johan Ström]

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 the 
OW-SERVER-ENET2’s built-in code (varies from 12-17 of the 22 sensors 
on the 3 1-wire buses), and the rate at which owserver delivers 
responses to my application is terrible — on the order of 1 per second.


That sounds like either a weird usage of owcapi, or bad 1-Wire network. 
Do you experience the same issues when using shell tools owdir/owread etc?
If so, please run owserver with --debug --foreground and see if it says 
something interesting.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Andrew Brownsword]

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 from 12-17 of the 
22 sensors on the 3 1-wire buses), and the rate at which owserver delivers 
responses to my application is terrible — on the order of 1 per second.  Are 
there any configuration options that could improve this?  If not, I’ll just 
have to abandon the notion of using OWFS entirely.


> On Nov 16, 2017, at 8:09 PM, Andrew Brownsword 
>  wrote:
> 
> 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 has 
> become invalid between here and where it is opened shortly before.  There is 
> then a cascading series of failures in the retry attempts, which aren’t very 
> effective as retries because they don’t handle the failed file_descriptor.
> 
> I would be suspicious of the rest of my program (which uses libuv and 
> civetweb), except that a standalone test program that only issues OWCAPI 
> calls in a minimal sequence also fails the same way.  The owserver daemon, 
> however, does *not* fail.
> 
> The call stack at the failure point is:
> 
> tcp_read
> telnet_read
> COM_read
> OWServer_Enet_read
> OWServer_Enet_reopen
> OWServer_Enet_reopen
> OWServer_Enet_setup
> OWServer_Enet_detect
> SetupSingleInboundConnection
> SetupInboundConnections
> LibStart
> setup_from_args
> API_init_args
> OW_init_args_both
> OW_init_args
> 
> 
> 
> Any suggestions from more experienced OWFS users/developers?
> 
> 
> 
> 
> 
>> On Nov 10, 2017, at 7:02 PM, Andrew Brownsword 
>> > wrote:
>> 
>> 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 
>> exception if I’m stepping through the code.  If I let it run past it still 
>> fails somewhere with a failure to talk to the enet device.
>> 
>> 
>>> On Nov 10, 2017, at 11:00 AM, Andrew Brownsword 
>>> > 
>>> wrote:
>>> 
>>> 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, 2017, at 9:38 AM, Andrew Brownsword 
 > 
 wrote:
 
 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 discovered was that the reason my program had no bus.0/ 
 entry was because I neglected to include a first argument that is the 
 program name.  My —enet= option got eaten and ignored as a result… a bit 
 surprising but easily fixed.  So now my program and the test program fail 
 in the same way.
 
 The second thing noticed (and I’ve only started to dive deeper) is it 
 doesn’t appear that a thread was spawned during the init and the OW_get 
 sees a NULL pin pointer, sets a badthread flag and basically bails at that 
 point.  Can anyone illuminate where the thread is supposed to get spawned?
 
 
> On Nov 8, 2017, at 4:37 PM, Justin Brewer  > wrote:
> 
> 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 would be welcome...
> 
> If you're working from a clean git clone, I use this for working with 
> just owcapi:
> 
> $ autoreconf -i
> $ ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs 
> --disable-{zero,ow{perl,python,php,tcl}}
> $ make
> $ make -k install
> 
> This lets me ignore most of the language binding dependencies, and ignore 
> some hardcoded install paths.
> 
>> 
>> 
>> Sent 

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Andrew Brownsword]

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 has become 
invalid between here and where it is opened shortly before.  There is then a 
cascading series of failures in the retry attempts, which aren’t very effective 
as retries because they don’t handle the failed file_descriptor.

I would be suspicious of the rest of my program (which uses libuv and 
civetweb), except that a standalone test program that only issues OWCAPI calls 
in a minimal sequence also fails the same way.  The owserver daemon, however, 
does *not* fail.

The call stack at the failure point is:

tcp_read
telnet_read
COM_read
OWServer_Enet_read
OWServer_Enet_reopen
OWServer_Enet_reopen
OWServer_Enet_setup
OWServer_Enet_detect
SetupSingleInboundConnection
SetupInboundConnections
LibStart
setup_from_args
API_init_args
OW_init_args_both
OW_init_args



Any suggestions from more experienced OWFS users/developers?





> On Nov 10, 2017, at 7:02 PM, Andrew Brownsword 
>  wrote:
> 
> 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 exception 
> if I’m stepping through the code.  If I let it run past it still fails 
> somewhere with a failure to talk to the enet device.
> 
> 
>> On Nov 10, 2017, at 11:00 AM, Andrew Brownsword 
>> > wrote:
>> 
>> 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, 2017, at 9:38 AM, Andrew Brownsword 
>>> > 
>>> wrote:
>>> 
>>> 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 discovered was that the reason my program had no bus.0/ 
>>> entry was because I neglected to include a first argument that is the 
>>> program name.  My —enet= option got eaten and ignored as a result… a bit 
>>> surprising but easily fixed.  So now my program and the test program fail 
>>> in the same way.
>>> 
>>> The second thing noticed (and I’ve only started to dive deeper) is it 
>>> doesn’t appear that a thread was spawned during the init and the OW_get 
>>> sees a NULL pin pointer, sets a badthread flag and basically bails at that 
>>> point.  Can anyone illuminate where the thread is supposed to get spawned?
>>> 
>>> 
 On Nov 8, 2017, at 4:37 PM, Justin Brewer > wrote:
 
 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 would be welcome...
 
 If you're working from a clean git clone, I use this for working with just 
 owcapi:
 
 $ autoreconf -i
 $ ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs 
 --disable-{zero,ow{perl,python,php,tcl}}
 $ make
 $ make -k install
 
 This lets me ignore most of the language binding dependencies, and ignore 
 some hardcoded install paths.
 
> 
> 
> Sent from my iPhone
> 
>> On Oct 31, 2017, at 3:11 PM, Andrew Brownsword 
>> > 
>> wrote:
>> 
>> 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 sensors just fine.  I ran a simple owcapi test program and 
>> it sees one bus and zero sensors.
>> 
>> My program is multi-threaded and the OW_get will be called from a 
>> different thread than the init (but correctly ordered).  As for the test 
>> program, it is just the init and then a get of root.
>> 
>> I’m using the 

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Andrew Brownsword]

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 exception if I’m 
stepping through the code.  If I let it run past it still fails somewhere with 
a failure to talk to the enet device.


> On Nov 10, 2017, at 11:00 AM, Andrew Brownsword 
>  wrote:
> 
> 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, 2017, at 9:38 AM, Andrew Brownsword 
>> > wrote:
>> 
>> 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 discovered was that the reason my program had no bus.0/ 
>> entry was because I neglected to include a first argument that is the 
>> program name.  My —enet= option got eaten and ignored as a result… a bit 
>> surprising but easily fixed.  So now my program and the test program fail in 
>> the same way.
>> 
>> The second thing noticed (and I’ve only started to dive deeper) is it 
>> doesn’t appear that a thread was spawned during the init and the OW_get sees 
>> a NULL pin pointer, sets a badthread flag and basically bails at that point. 
>>  Can anyone illuminate where the thread is supposed to get spawned?
>> 
>> 
>>> On Nov 8, 2017, at 4:37 PM, Justin Brewer >> > wrote:
>>> 
>>> 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 would be welcome...
>>> 
>>> If you're working from a clean git clone, I use this for working with just 
>>> owcapi:
>>> 
>>> $ autoreconf -i
>>> $ ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs 
>>> --disable-{zero,ow{perl,python,php,tcl}}
>>> $ make
>>> $ make -k install
>>> 
>>> This lets me ignore most of the language binding dependencies, and ignore 
>>> some hardcoded install paths.
>>> 
 
 
 Sent from my iPhone
 
> On Oct 31, 2017, at 3:11 PM, Andrew Brownsword 
> > 
> wrote:
> 
> 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 sensors just fine.  I ran a simple owcapi test program and 
> it sees one bus and zero sensors.
> 
> My program is multi-threaded and the OW_get will be called from a 
> different thread than the init (but correctly ordered).  As for the test 
> program, it is just the init and then a get of root.
> 
> I’m using the latest release and running on either an Ubuntu ARM host or 
> on OSX... same behavior either way.
>>> 
>>> I have been working on some issues I've found in libow, and have seen 
>>> similair symptoms. There's some race conditions that, if it doesn't 
>>> outright crash, causes random failures elsewhere. I have a patch that 
>>> resolves these issues here:
>>> 
>>> https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch
>>>  
>>> 
>>> 
>>> I was planning on submitting a pull request in the next day or so, but I 
>>> think this patch help you.
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org ! 
>>> http://sdm.link/slashdot 
>>> ___
>>> Owfs-developers mailing list
>>> Owfs-developers@lists.sourceforge.net 
>>> 
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers 
>>> 
> 

--
Check out the vibrant tech 

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Andrew Brownsword]

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, 2017, at 9:38 AM, Andrew Brownsword 
>  wrote:
> 
> 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 discovered was that the reason my program had no bus.0/ 
> entry was because I neglected to include a first argument that is the program 
> name.  My —enet= option got eaten and ignored as a result… a bit surprising 
> but easily fixed.  So now my program and the test program fail in the same 
> way.
> 
> The second thing noticed (and I’ve only started to dive deeper) is it doesn’t 
> appear that a thread was spawned during the init and the OW_get sees a NULL 
> pin pointer, sets a badthread flag and basically bails at that point.  Can 
> anyone illuminate where the thread is supposed to get spawned?
> 
> 
>> On Nov 8, 2017, at 4:37 PM, Justin Brewer > > wrote:
>> 
>> 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 would be welcome...
>> 
>> If you're working from a clean git clone, I use this for working with just 
>> owcapi:
>> 
>> $ autoreconf -i
>> $ ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs 
>> --disable-{zero,ow{perl,python,php,tcl}}
>> $ make
>> $ make -k install
>> 
>> This lets me ignore most of the language binding dependencies, and ignore 
>> some hardcoded install paths.
>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On Oct 31, 2017, at 3:11 PM, Andrew Brownsword 
 > 
 wrote:
 
 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 sensors just fine.  I ran a simple owcapi test program and it sees 
 one bus and zero sensors.
 
 My program is multi-threaded and the OW_get will be called from a 
 different thread than the init (but correctly ordered).  As for the test 
 program, it is just the init and then a get of root.
 
 I’m using the latest release and running on either an Ubuntu ARM host or 
 on OSX... same behavior either way.
>> 
>> I have been working on some issues I've found in libow, and have seen 
>> similair symptoms. There's some race conditions that, if it doesn't outright 
>> crash, causes random failures elsewhere. I have a patch that resolves these 
>> issues here:
>> 
>> https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch
>>  
>> 
>> 
>> I was planning on submitting a pull request in the next day or so, but I 
>> think this patch help you.
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org ! 
>> http://sdm.link/slashdot 
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers 
>> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Andrew Brownsword]

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 discovered was that the reason my program had no bus.0/ entry 
was because I neglected to include a first argument that is the program name.  
My —enet= option got eaten and ignored as a result… a bit surprising but easily 
fixed.  So now my program and the test program fail in the same way.

The second thing noticed (and I’ve only started to dive deeper) is it doesn’t 
appear that a thread was spawned during the init and the OW_get sees a NULL pin 
pointer, sets a badthread flag and basically bails at that point.  Can anyone 
illuminate where the thread is supposed to get spawned?


> On Nov 8, 2017, at 4:37 PM, Justin Brewer  wrote:
> 
> 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 would be welcome...
> 
> If you're working from a clean git clone, I use this for working with just 
> owcapi:
> 
> $ autoreconf -i
> $ ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs 
> --disable-{zero,ow{perl,python,php,tcl}}
> $ make
> $ make -k install
> 
> This lets me ignore most of the language binding dependencies, and ignore 
> some hardcoded install paths.
> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Oct 31, 2017, at 3:11 PM, Andrew Brownsword 
>>>  wrote:
>>> 
>>> 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 sensors 
>>> just fine.  I ran a simple owcapi test program and it sees one bus and zero 
>>> sensors.
>>> 
>>> My program is multi-threaded and the OW_get will be called from a different 
>>> thread than the init (but correctly ordered).  As for the test program, it 
>>> is just the init and then a get of root.
>>> 
>>> I’m using the latest release and running on either an Ubuntu ARM host or on 
>>> OSX... same behavior either way.
> 
> I have been working on some issues I've found in libow, and have seen 
> similair symptoms. There's some race conditions that, if it doesn't outright 
> crash, causes random failures elsewhere. I have a patch that resolves these 
> issues here:
> 
> https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch
>  
> 
> 
> I was planning on submitting a pull request in the next day or so, but I 
> think this patch help you.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org ! 
> http://sdm.link/slashdot 
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net 
> 
> https://lists.sourceforge.net/lists/listinfo/owfs-developers 
> 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Justin Brewer]

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 the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Justin Brewer]

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 would be welcome...

If you're working from a clean git clone, I use this for working with just 
owcapi:

$ autoreconf -i
$ ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs 
--disable-{zero,ow{perl,python,php,tcl}}
$ make
$ make -k install

This lets me ignore most of the language binding dependencies, and ignore some 
hardcoded install paths.

> 
> 
> Sent from my iPhone
> 
> > On Oct 31, 2017, at 3:11 PM, Andrew Brownsword 
> >  wrote:
> > 
> > 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 sensors 
> > just fine.  I ran a simple owcapi test program and it sees one bus and zero 
> > sensors.
> > 
> > My program is multi-threaded and the OW_get will be called from a different 
> > thread than the init (but correctly ordered).  As for the test program, it 
> > is just the init and then a get of root.
> > 
> > I’m using the latest release and running on either an Ubuntu ARM host or on 
> > OSX... same behavior either way.

I have been working on some issues I've found in libow, and have seen similair 
symptoms. There's some race conditions that, if it doesn't outright crash, 
causes random failures elsewhere. I have a patch that resolves these issues 
here:

https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch

I was planning on submitting a pull request in the next day or so, but I think 
this patch help you.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Justin Brewer]

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:


https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch

I was planning on submitting a pull request in the next day or so, but 
it sounds like it might help you.


As for building, from a clean git clone, I use this for working with 
just owcapi:


$ autoreconf -i && ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs 
--disable-{zero,ow{perl,python,php,tcl}} && make && make -k install


This lets me ignore most of the problematic language binding 
dependencies and hardcoded install paths.


On 11/08/2017 03:51 PM, 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 would be welcome...


Sent from my iPhone


On Oct 31, 2017, at 3:11 PM, Andrew Brownsword  
wrote:

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 sensors just fine.  I 
ran a simple owcapi test program and it sees one bus and zero sensors.

My program is multi-threaded and the OW_get will be called from a different 
thread than the init (but correctly ordered).  As for the test program, it is 
just the init and then a get of root.

I’m using the latest release and running on either an Ubuntu ARM host or on 
OSX... same behavior either way.

And no, I don’t want to rely on owserver.

Any suggestions?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[Jan Kandziora]

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...
> 
I had hoped someone with more experience with enet devices than myself
(== zero) would answer that.

So, if you place an owserver inbetween, it works for obscure reasons? I
would check the owserver code then, if it does something differently
than your code does.

Kind regards

Jan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver and owcapi behave differently with —enet device

[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...


Sent from my iPhone

> On Oct 31, 2017, at 3:11 PM, Andrew Brownsword 
>  wrote:
> 
> 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 sensors just 
> fine.  I ran a simple owcapi test program and it sees one bus and zero 
> sensors.
> 
> My program is multi-threaded and the OW_get will be called from a different 
> thread than the init (but correctly ordered).  As for the test program, it is 
> just the init and then a get of root.
> 
> I’m using the latest release and running on either an Ubuntu ARM host or on 
> OSX... same behavior either way.
> 
> And no, I don’t want to rely on owserver.
> 
> Any suggestions?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] owserver and owcapi behave differently with —enet device

[Andrew Brownsword]

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 sensors just fine.  I 
ran a simple owcapi test program and it sees one bus and zero sensors.

My program is multi-threaded and the OW_get will be called from a different 
thread than the init (but correctly ordered).  As for the test program, it is 
just the init and then a get of root.

I’m using the latest release and running on either an Ubuntu ARM host or on 
OSX... same behavior either way.

And no, I don’t want to rely on owserver.

Any suggestions?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers