Thanks for your help on this Stefano. I will add the null terminator
when writing strings, but I have also restructured my code so it will
only happen rarely, so should not be a problem anyway.
On 14/10/2019 21:21, Stefano Miccoli via Owfs-developers wrote:
There is for sure something broken
There is for sure something broken in the owserver, and it can be very
dangerous from a strict security point of view (buffer overflows and so on).
However I think that most owserver instances are run in private networks so
this should not be a major concern.
For now I would advise you to add
Hi Stefano,
I ran test.py and it completed without error. I then ran it again and
it failed at B9, I ran it several times more and it failed at B9 each time.
I then made the change you suggested and ran it again, it still failed
at B9. I then rebooted and ran it again and it completed witho
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 tr
On 09.10.19 22:44, Mick Sulley wrote:
> I can get around this by appending .decode('utf-8) and .encode('utf-8)
> to the read and write functions
That's the idea. Separating strings and bytes was necessary because it
ultimately caused too many interesting hard-to-debug problems …
--
-- Matthias U
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 r
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:4
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
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
>>
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
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
makin
11 matches
Mail list logo
