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> 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 > 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