Hello Hans,
Those messages with the -1 in the payload spot are the "keep alive"
messages that owserver sends to show that it's still processing the
request. Every 1 second or so, one of these messages will be sent until the
final data can be sent. This allows the client to distinguish a long
response from a dead server. These messages can be safely ignored.
Paul
On Wed, Mar 20, 2013 at 8:33 AM, Hans Erik Busk <[email protected]> wrote:
> Thank you.
>
> I do intend to contribute by a delphi component that can interface with
> owserver, when I think it is reasonable stable and usable :-)
>
> Regarding documentation I feel too challenged right now to dare taking
> on that task, there are too many uncertainties to me ;-(
>
> I did as you suggested, and traced the conversation between owfs and
> owserver, and it did help. However I find it a bit confusing that in
> owfs <-> owserver conversation, I find only one
>
> 0000 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 ................
> 0010 00 00 00 00 00 00 00 00
>
> server package (data part) before the "real message" packet appears;
> While the server respond with such a packet _twice_ when called from my
> delphi project.
> The dataexchange as seen by wireshark has exactly the same datacontent
> coming from delphi.
> I have not looked into the TCP/IP headers though, except for the ACK,
> PSH, SYN, and FIN tags, that are equivalent for each packet - really
> strange.
>
> But at least I can read the temperature now.
>
> It seems that the problem was in the "size" header field from delphi
> that should be set to the same or maybe just a higher value as the
> payload field!
> But in one message from the server the payload is 0x63 but the size is
> 0x62 so it is more or less a guess.
>
> I had seen the documentation at:
> "http://owfs.org/index.php?page=tcp-messages";
> but I found I still miss something, but now it narrows down to the "ret"
> field from the server (and the correct value of "size").
>
> --
> yours
> Hans Erik Busk
>
> On 18-03-2013 18:12, Jerry Scharf wrote:
> > It might be very instructive to set up a connection between an OWFS
> > instance and owserver and watch what it does. So when you want to do a
> > temperature read, do it from owfs first and watch what comes up on your
> > sniffer, them emulate that. I know that's not the same as having a
> > protocol documentation, but it's a way to move forward more quickly.
> >
> > I think most people have viewed the owserver protocol as something that
> > is private to OW apps and have not tried to write their own software to
> > interface to it. SO you are breaking the ground here. I would urge you
> > to take this moment to document the protocol so the next person down the
> > path can have a smoother time. I think this would also be something Paul
> > would be grateful for.
> >
> > I have done exactly this kind of thing for other protocols in the past.
> >
> > jerry
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
