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
> <andrew.e.brownsw...@gmail.com> 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
> <calling program>
>
>
> Any suggestions from more experienced OWFS users/developers?
>
>
>
>
>
>> On Nov 10, 2017, at 7:02 PM, Andrew Brownsword
>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>> 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
>>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>>
>>> 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
>>>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>>
>>>> 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 <justin.bre...@vertivco.com
>>>>> <mailto:justin.bre...@vertivco.com>> 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
>>>>>>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>>
>>>>>>> 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
>>>>>
>>>>> <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://slashdot.org/>!
>>>>> http://sdm.link/slashdot <http://sdm.link/slashdot>
>>>>> _______________________________________________
>>>>> Owfs-developers mailing list
>>>>> Owfs-developers@lists.sourceforge.net
>>>>> <mailto:Owfs-developers@lists.sourceforge.net>
>>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>>> <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
