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 <[email protected]> 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 <[email protected]
>>>> <mailto:[email protected]>> 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
>>>> [email protected]
>>>> <mailto:[email protected]>
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>> <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> [email protected]
>>> <mailto:[email protected]>
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>>
>>
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> [email protected]
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
> _______________________________________________
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
