I had no time to stress test my installation, but let me add some thoughts here.
The fact that failures are sporadic, and that a reboot makes the system more
resilient, makes me guess that there is a memory leak in owserver.
I suspect that this could be linked to the way in which strings are treated in
owserver. I clearly remember that when I implemented the write feature I asked
on this list if data sent in a write request should be null-terminated. Paul
replied that this was not necessary, since the length of the payload is known
to owserver.
Therefore the payload for an alias is sent by pyownet as something like
b”/26.123412341234/alias\x00T0”
(where b”\x00” is a null byte in python). This means that on the receiving side
the C code has to add a null terminator to the received alias. So I would
suggest to test writes likes this
owp.write(addr, newa + b'\x00')
just to see explicitly adding a null terminator on the sending side mitigates
the problem. (Please note that this is just a wild guess, maybe the problem is
in another portion of the code.)
Stefano
> On 10 Oct 2019, at 23:48, Mick Sulley <m...@sulley.info> wrote:
>
> I have tested a bit more and I can sort of reproduce the problem.
>
> I wrote some code that takes 2 sensors and writes to the alias with a letter,
> A or B and an incrementing number. It loops through from A0 and B0 to A99
> and B99. When I run the code first time it works as expected. If I then run
> it again it fails at B9 and consistently fails at B9.
>
> I have set this up on 2 Pi's, both behaved the same at first, however one of
> them doesn't fail any more after a reboot.
> Just checked my versions and they are the same as yours and also running on
> Buster. I think I will review my plans and see if I can avoid writing to
> alias, although it does make me wonder how stable other writes are....
> This is the code -
>
> #!/usr/bin/python3
>
> #test.py
>
> import pyownet
> def main():
> owp = pyownet.protocol.proxy()
> for x in range(0, 100):
> addr = '28.E3377A020000/alias' #temperature
> print('initial read returns %s' %owp.read(addr).decode())
> newa = bytes(('T' + str(x)), 'utf-8')
> owp.write(addr, newa) # write it to the alias
> now = owp.read(addr).decode()
> print('read now returns %s' %now)
> if now != newa.decode('utf-8'):
> print('Temp - they are different!!! %s <> %s' %(now, newa))
> exit()
> addr = '267E9C3E0200006E/alias' #voltage
> print('read returns %s' %owp.read(addr).decode())
> newa = bytes(('V' + str(x)), 'utf-8')
> owp.write(addr, newa)
> now = owp.read(addr).decode()
> print('read now returns %s' %now)
> if now != newa.decode():
> print('Volts - they are different!!! %s <> %s' %(now, newa))
> exit()
> if __name__ == "__main__":
> main()
>
>
> On 10/10/2019 21:36, Stefano Miccoli via Owfs-developers wrote:
>> In the past I tried to use the alias feature, but I gave up, since I found
>> it very unstable; but this was a lot of time ago…
>>
>> So here some tests on a buster rasbian (version 10.1) with it’s stock
>> owserver (version 3.2p3+dfsg1-2) I have running at home.
>>
>> Python 3.7.4 (default, Jul 14 2019, 18:10:41)
>> [Clang 10.0.0 (clang-1000.11.45.5)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import pyownet.protocol
>> >>> pyownet.__version__
>> '0.10.0.post1'
>> >>> ow = pyownet.protocol.proxy(“myhost”)
>> >>> ow.read('/system/configuration/version')
>> b’3.2p3'
>> >>> ow.dir()
>> ['/26.xxxxxxxxxxxx/', '/26.yyyyyyyyyyyy/', '/01.zzzzzzzzzzzz/']
>> >>> node_a = '/26.xxxxxxxxxxxx/alias'
>> >>> node_b = '/26.yyyyyyyyyyyy/alias'
>> >>> node_c = '/01.zzzzzzzzzzzz/alias'
>> >>> ow.write(node_a, b'T0')
>> >>> ow.write(node_b, b'T1')
>> >>> ow.write(node_c, b'X0')
>> >>> ow.dir()
>> ['/T0/', '/T1/', '/X0/']
>> >>> ow.read(node_a)
>> b'T0'
>> >>> ow.read(node_b)
>> b'T1'
>> >>> ow.read(node_c)
>> b'X0'
>> >>> ow.read('/T0/temperature')
>> b' 28.9062'
>> >>> ow.read('/T1/temperature')
>> b' 20.75'
>> >>> ow.write(node_a, b'')
>> >>> ow.write(node_b, b'')
>> >>> ow.write(node_c, b'')
>> >>> ow.dir()
>> ['/26.xxxxxxxxxxxx/', '/26.yyyyyyyyyyyy/', '/01.zzzzzzzzzzzz/']
>>
>>
>> So everything working fine here at home… Of course this is not a stress
>> test, but at least basic functionality is working as expected.
>>
>> Stefano
>>
>>> On 10 Oct 2019, at 19:44, Mick Sulley <m...@sulley.info
>>> <mailto:m...@sulley.info>> wrote:
>>>
>>> This is getting more weird. Tried a few more things, I can write X0 (ex
>>> zero) to the alias, and I can then write T0 to it?!?! If I write T99 to it
>>> I then cannot write T0 again. My head is starting to hurt! Can anyone
>>> explain this behaviour?
>>> On 10/10/2019 16:17, Mick Sulley wrote:
>>>> Thanks Stefano, that makes it a bit clearer. However I have been playing
>>>> around writing to an alias and I really don't understand what is happening.
>>>>
>>>> For some reason I cannot write 'T0' (that's tee zero) to the alias. I
>>>> don't understand why. Here is what I have seen -
>>>>
>>>> >>> import pyownet
>>>> >>> owp = pyownet.protocol.proxy()
>>>> >>> addr = '28.E3377A020000/alias'
>>>> >>> owp.read(addr).decode()
>>>> 'xx'
>>>> >>> owp.write(addr, 'T0'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'xx'
>>>> >>> owp.write(addr, 'T0'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'xx'
>>>> >>> owp.write(addr, 'T0x'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'T0x'
>>>> >>> owp.write(addr, 'T0'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'T0x'
>>>> >>> owp.write(addr, 'T01'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'T01'
>>>> >>> owp.write(addr, 'T0'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'T01'
>>>> >>> owp.write(addr, 'T'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'T'
>>>> >>> owp.write(addr, 'T0'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'T'
>>>> >>> owp.write(addr, 'T00'.encode())
>>>> >>> owp.read(addr).decode()
>>>> 'T00'
>>>> >>>
>>>>
>>>> On 10/10/2019 15:04, Stefano Miccoli via Owfs-developers wrote:
>>>>> I think that this is the correct place to ask, so I'll give a brief
>>>>> answer.
>>>>>
>>>>> In python2 you had "strings" and "unicode strings". Python2 "strings"
>>>>> were 1-byte sequences, so it was impossibile to represent UNICODE code
>>>>> points beyond the few ASCII ones; therefore the "unicode string" was
>>>>> introduced. Strings could be used both for binary data, as well as for
>>>>> text.
>>>>>
>>>>> This confusion was deprecated, and in python3 there is a strict
>>>>> distinction between text and binary data. Strings (see
>>>>> <https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str
>>>>> <https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str>>)
>>>>> are sequences of UNICODE code points, and therefore are multi-byte
>>>>> sequences; 1-byte (8 bit) sequences are called "bytes" (see
>>>>> <https://docs.python.org/3/library/stdtypes.html#bytes-objects
>>>>> <https://docs.python.org/3/library/stdtypes.html#bytes-objects>>) and are
>>>>> used for binary data.
>>>>>
>>>>> A very common mapping from python2 to python3 datatypes is
>>>>>
>>>>> str() → byte()
>>>>> unicode() → str()
>>>>>
>>>>> or if you prefer
>>>>>
>>>>> "abc" → b"abc"
>>>>> u"àèì" → "àèì"
>>>>>
>>>>> I regard pyownet as a low-level library, so I like to speak binary to the
>>>>> owserver, i.e. read and writes are bytes in python3 and str in python2.
>>>>> It is responsibility of the user to decode/encode the messages sent and
>>>>> received from owserver. OWFS node names (similarly to
>>>>> path names on a file system) instead are considered "non binary", and
>>>>> therefore are represented by strings.
>>>>>
>>>>> As what regards the practicality of using pyownet.
>>>>>
>>>>> - some nodes contain binary data: e.g. '/26.xxxxxxxxxxxx/pages/page.ALL',
>>>>> no decoding needed
>>>>>
>>>>> - numeric values can be converted directly, without the need of decoding:
>>>>> if owp is a proxy object you have e.g.
>>>>>
>>>>> >>> owp.read('/26.xxxxxxxxxxxx/temperature')
>>>>> b' 24.4688'
>>>>> >>> float(owp.read('/26.xxxxxxxxxxxx/temperature'))
>>>>> 24.4688
>>>>>
>>>>> (this is because the float() class accepts both strings and bytes as
>>>>> input.)
>>>>>
>>>>> - text values should be decoded, but usually you can omit the encoding
>>>>> (which should be 'utf-8' or better 'ascii'):
>>>>>
>>>>> >>> owp.read("/structure/26/CA")
>>>>> b'y,000000,000001,rw,000001,s,'
>>>>> >>> owp.read("/structure/26/CA").decode()
>>>>> 'y,000000,000001,rw,000001,s,'
>>>>>
>>>>> Regards,
>>>>>
>>>>> Stefano
>>>>>
>>>>>
>>>>>> On 9 Oct 2019, at 22:44, Mick Sulley <m...@sulley.info
>>>>>> <mailto:m...@sulley.info>> wrote:
>>>>>>
>>>>>> I am updating my python code from 2.7 to 3.7, using pyownet to
>>>>>> communicate with 1-wire.
>>>>>>
>>>>>> Reads and writes were strings in 2.7 but it seems they are binary in
>>>>>> 3.7. I can get around this by appending .decode('utf-8) and
>>>>>> .encode('utf-8) to the read and write functions, but I feel that I am
>>>>>> making hard work of this. Is there a better way to move reads and
>>>>>> writes to Python3?
>>>>>>
>>>>>> I don't understand why the change has occurred, but I guess that is not
>>>>>> a question for this group.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Mick
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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>
>>> _______________________________________________
>>> 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>
>>
>>
>>
>>
>> _______________________________________________
>> 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>
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
