Discussion:
[Owfs-developers] owserver protocol
Colin Law
2017-03-05 16:51:37 UTC
Permalink
I am trying to debug a problem on the node.js owserver client
node-owfs and am looking for some clarification of the owserver
protocol if possible please.

Referring to [1] in response to a 1-wire read I expect to see a header
with a payload of the size indicated in the header. Very often what I
actually see is a header specifying a payload size of 0 followed by
another header with the expected payload size and valid data. Is that
normal or is there something strange going on?

This is owserver 3.1p4-1 from the raspbian jessie testing repository
on a pi zero.

[1] http://owfs.org/index.php?page=owserver-protocol

Colin
Stefano Miccoli
2017-03-05 18:42:22 UTC
Permalink
What you describe (0-size payload message followed by another valid message) cannot happen.
May be what you really mean is a -1 size payload message? This is a “ping” which owserver sends every 1 second or so when it is still gathering data or under heavy payload.

This is an aspect of the owserver protocol which easily gets unnoticed by implementers: please see https://github.com/miccoli/pyownet/pull/1 <https://github.com/miccoli/pyownet/pull/1> where Johan Ström corrected a similar bug in my pyownet.

S.
Post by Colin Law
I am trying to debug a problem on the node.js owserver client
node-owfs and am looking for some clarification of the owserver
protocol if possible please.
Referring to [1] in response to a 1-wire read I expect to see a header
with a payload of the size indicated in the header. Very often what I
actually see is a header specifying a payload size of 0 followed by
another header with the expected payload size and valid data. Is that
normal or is there something strange going on?
This is owserver 3.1p4-1 from the raspbian jessie testing repository
on a pi zero.
[1] http://owfs.org/index.php?page=owserver-protocol
Colin
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Colin Law
2017-03-05 19:34:57 UTC
Permalink
Can I just check there I not a confusion here, I am talking about comms
between client and owserver, not between server and sensor.
Post by Stefano Miccoli
What you describe (0-size payload message followed by another valid message) cannot happen.
May be what you really mean is a -1 size payload message? This is a “ping”
which owserver sends every 1 second or so when it is still gathering data
or under heavy payload.
This is an aspect of the owserver protocol which easily gets unnoticed by
implementers: please see https://github.com/miccoli/pyownet/pull/1 where Johan
Ström corrected a similar bug in my pyownet.
S.
I am trying to debug a problem on the node.js owserver client
node-owfs and am looking for some clarification of the owserver
protocol if possible please.
Referring to [1] in response to a 1-wire read I expect to see a header
with a payload of the size indicated in the header. Very often what I
actually see is a header specifying a payload size of 0 followed by
another header with the expected payload size and valid data. Is that
normal or is there something strange going on?
This is owserver 3.1p4-1 from the raspbian jessie testing repository
on a pi zero.
[1] http://owfs.org/index.php?page=owserver-protocol
Colin
------------------------------------------------------------
------------------
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
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
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Colin Law
2017-03-05 20:08:35 UTC
Permalink
The extra header contains version: 0, payload: -1, ret: 0, flags: 0,
size: 0, offset: 0
So the element described as size of data element is 0 though that
described as length of payload data is -1.

Colin
Post by Colin Law
Can I just check there I not a confusion here, I am talking about comms
between client and owserver, not between server and sensor.
Post by Stefano Miccoli
What you describe (0-size payload message followed by another valid
message) cannot happen.
May be what you really mean is a -1 size payload message? This is a “ping”
which owserver sends every 1 second or so when it is still gathering data or
under heavy payload.
This is an aspect of the owserver protocol which easily gets unnoticed by
implementers: please see https://github.com/miccoli/pyownet/pull/1 where
Johan Ström corrected a similar bug in my pyownet.
S.
I am trying to debug a problem on the node.js owserver client
node-owfs and am looking for some clarification of the owserver
protocol if possible please.
Referring to [1] in response to a 1-wire read I expect to see a header
with a payload of the size indicated in the header. Very often what I
actually see is a header specifying a payload size of 0 followed by
another header with the expected payload size and valid data. Is that
normal or is there something strange going on?
This is owserver 3.1p4-1 from the raspbian jessie testing repository
on a pi zero.
[1] http://owfs.org/index.php?page=owserver-protocol
Colin
------------------------------------------------------------------------------
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
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
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Stefano Miccoli
2017-03-05 21:41:57 UTC
Permalink
Sorry for the confusione between message payload and message size
 I forgot about this difference: https://github.com/owfs/owfs/blob/d0c3abac8f16d38c0fe5fb9e0c62c57f2e6696fb/module/owlib/src/include/ow_message.h#L45-L63 <https://github.com/owfs/owfs/blob/d0c3abac8f16d38c0fe5fb9e0c62c57f2e6696fb/module/owlib/src/include/ow_message.h#L45-L63>
(but in most cases payload == size, or payload == size+1 to accomodate for a terminating null byte)

So I confirm: headers with payload == -1 are to be discarded and the client should continue waiting for the answer.

S.
Post by Colin Law
The extra header contains version: 0, payload: -1, ret: 0, flags: 0,
size: 0, offset: 0
So the element described as size of data element is 0 though that
described as length of payload data is -1.
Colin
Post by Colin Law
Can I just check there I not a confusion here, I am talking about comms
between client and owserver, not between server and sensor.
Post by Stefano Miccoli
What you describe (0-size payload message followed by another valid
message) cannot happen.
May be what you really mean is a -1 size payload message? This is a “ping”
which owserver sends every 1 second or so when it is still gathering data or
under heavy payload.
This is an aspect of the owserver protocol which easily gets unnoticed by
implementers: please see https://github.com/miccoli/pyownet/pull/1 where
Johan Ström corrected a similar bug in my pyownet.
S.
I am trying to debug a problem on the node.js owserver client
node-owfs and am looking for some clarification of the owserver
protocol if possible please.
Referring to [1] in response to a 1-wire read I expect to see a header
with a payload of the size indicated in the header. Very often what I
actually see is a header specifying a payload size of 0 followed by
another header with the expected payload size and valid data. Is that
normal or is there something strange going on?
This is owserver 3.1p4-1 from the raspbian jessie testing repository
on a pi zero.
[1] http://owfs.org/index.php?page=owserver-protocol
Colin
------------------------------------------------------------------------------
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
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
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
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Colin Law
2017-03-05 21:56:23 UTC
Permalink
OK, I realise what you meant by ping now, it is a holding reply to the
client to prevent it timing out whilst waiting for the data.

Many thanks, it is much easier to debug something when you understand
the data it is being given :)

Colin
Sorry for the confusione between message payload and message size… I forgot
https://github.com/owfs/owfs/blob/d0c3abac8f16d38c0fe5fb9e0c62c57f2e6696fb/module/owlib/src/include/ow_message.h#L45-L63
(but in most cases payload == size, or payload == size+1 to accomodate for a
terminating null byte)
So I confirm: headers with payload == -1 are to be discarded and the client
should continue waiting for the answer.
S.
The extra header contains version: 0, payload: -1, ret: 0, flags: 0,
size: 0, offset: 0
So the element described as size of data element is 0 though that
described as length of payload data is -1.
Colin
Can I just check there I not a confusion here, I am talking about comms
between client and owserver, not between server and sensor.
What you describe (0-size payload message followed by another valid message) cannot happen.
May be what you really mean is a -1 size payload message? This is a “ping”
which owserver sends every 1 second or so when it is still gathering data or
under heavy payload.
This is an aspect of the owserver protocol which easily gets unnoticed by
implementers: please see https://github.com/miccoli/pyownet/pull/1 where
Johan Ström corrected a similar bug in my pyownet.
S.
I am trying to debug a problem on the node.js owserver client
node-owfs and am looking for some clarification of the owserver
protocol if possible please.
Referring to [1] in response to a 1-wire read I expect to see a header
with a payload of the size indicated in the header. Very often what I
actually see is a header specifying a payload size of 0 followed by
another header with the expected payload size and valid data. Is that
normal or is there something strange going on?
This is owserver 3.1p4-1 from the raspbian jessie testing repository
on a pi zero.
[1] http://owfs.org/index.php?page=owserver-protocol
Colin
------------------------------------------------------------------------------
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Gregg Levine
2017-03-05 22:11:37 UTC
Permalink
Hello!
Colin how did you attach your One-Wire device to the Pi Zero? And is
it in much the same style as that from the discussion from last
September?
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."
Post by Colin Law
OK, I realise what you meant by ping now, it is a holding reply to the
client to prevent it timing out whilst waiting for the data.
Many thanks, it is much easier to debug something when you understand
the data it is being given :)
Colin
Sorry for the confusione between message payload and message size… I forgot
https://github.com/owfs/owfs/blob/d0c3abac8f16d38c0fe5fb9e0c62c57f2e6696fb/module/owlib/src/include/ow_message.h#L45-L63
(but in most cases payload == size, or payload == size+1 to accomodate for a
terminating null byte)
So I confirm: headers with payload == -1 are to be discarded and the client
should continue waiting for the answer.
S.
The extra header contains version: 0, payload: -1, ret: 0, flags: 0,
size: 0, offset: 0
So the element described as size of data element is 0 though that
described as length of payload data is -1.
Colin
Can I just check there I not a confusion here, I am talking about comms
between client and owserver, not between server and sensor.
What you describe (0-size payload message followed by another valid
message) cannot happen.
May be what you really mean is a -1 size payload message? This is a “ping”
which owserver sends every 1 second or so when it is still gathering data or
under heavy payload.
This is an aspect of the owserver protocol which easily gets unnoticed by
implementers: please see https://github.com/miccoli/pyownet/pull/1 where
Johan Ström corrected a similar bug in my pyownet.
S.
I am trying to debug a problem on the node.js owserver client
node-owfs and am looking for some clarification of the owserver
protocol if possible please.
Referring to [1] in response to a 1-wire read I expect to see a header
with a payload of the size indicated in the header. Very often what I
actually see is a header specifying a payload size of 0 followed by
another header with the expected payload size and valid data. Is that
normal or is there something strange going on?
This is owserver 3.1p4-1 from the raspbian jessie testing repository
on a pi zero.
[1] http://owfs.org/index.php?page=owserver-protocol
Colin
------------------------------------------------------------------------------
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Colin Law
2017-03-06 08:28:32 UTC
Permalink
Post by Gregg Levine
Hello!
Colin how did you attach your One-Wire device to the Pi Zero? And is
it in much the same style as that from the discussion from last
September?
Hi Greg, I have some using LinkUSB and some, with up to two DS18B20 on
wires of up to a few metres, using direct connect to the GPIO with
pullup. However this issue is not between owserver and the sensor, it
is between the client and owserver. It is using socket.io in node.js
and gets the data from owserver in chunks. It copes if a chunk
consists of a dummy header or if it is an actual data record, but if
it gets one chunk consisting off a dummy header immediately followed
by the data header and data then it gets confused and assumes that the
data header and data combined are the data record for the dummy
record. I shall be submitting a PR against node-owfs today, hopefully.
If anyone is using node-red with node-red-contrib-owfs then they may
be seeing this issue as that node uses node-owfs for the comms.

Cheers

Colin
Colin Law
2017-03-06 21:46:47 UTC
Permalink
I have found and corrected the problem in node-owfs, but whilst
analysing it I noticed that sometimes I get 20 or more per second
dummy headers whilst waiting for the data from owserver. Normally it
is around 1 per second. Any suggestions as to why this might be
happening? It does not seem to cause any ill effects and if I did not
have the debug enabled I would never know it was happening.

Colin
Sorry for the confusione between message payload and message size… I forgot
https://github.com/owfs/owfs/blob/d0c3abac8f16d38c0fe5fb9e0c62c57f2e6696fb/module/owlib/src/include/ow_message.h#L45-L63
(but in most cases payload == size, or payload == size+1 to accomodate for a
terminating null byte)
So I confirm: headers with payload == -1 are to be discarded and the client
should continue waiting for the answer.
S.
The extra header contains version: 0, payload: -1, ret: 0, flags: 0,
size: 0, offset: 0
So the element described as size of data element is 0 though that
described as length of payload data is -1.
Colin
Can I just check there I not a confusion here, I am talking about comms
between client and owserver, not between server and sensor.
What you describe (0-size payload message followed by another valid message) cannot happen.
May be what you really mean is a -1 size payload message? This is a “ping”
which owserver sends every 1 second or so when it is still gathering data or
under heavy payload.
This is an aspect of the owserver protocol which easily gets unnoticed by
implementers: please see https://github.com/miccoli/pyownet/pull/1 where
Johan Ström corrected a similar bug in my pyownet.
S.
I am trying to debug a problem on the node.js owserver client
node-owfs and am looking for some clarification of the owserver
protocol if possible please.
Referring to [1] in response to a 1-wire read I expect to see a header
with a payload of the size indicated in the header. Very often what I
actually see is a header specifying a payload size of 0 followed by
another header with the expected payload size and valid data. Is that
normal or is there something strange going on?
This is owserver 3.1p4-1 from the raspbian jessie testing repository
on a pi zero.
[1] http://owfs.org/index.php?page=owserver-protocol
Colin
------------------------------------------------------------------------------
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Loading...