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>) 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>)
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
_______________________________________________
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
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto: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
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
