Hi Guys,
I’m pretty “late to the party” but In April this year I upgraded my RPi to the
latest Debian packages to read all my DS28EA00 sensors and ran into issues with
some of the sensor subfields had disappeared, namely “temphigh” And “templow”
and needed to patch the source code and rebuild the package and then it was all
good again.
You might want to just double check that you can do read/write commands to the
PIO.BYTE using the shell command line tools (owdir owread, owwrite) to make
sure its not a owfs core issue.
HTH
Alex Shepherd
Sent from my iPad
>> On 28/08/2020, at 5:48 AM, Mick Sulley <m...@sulley.info> wrote:
>
> Yes I have struggled with that as well. I have discovered how to do it, but
> I don't really understand why.
>
> The answer seems to be that to write a 1 you need
>
> owproxy.write('device_id' + '/PIO.BYTE, b'1')
>
> so you need to write the byte value of the string 1, not the byte value of
> the integer 1. As I say, I don't understand why that is so, I dabble with
> Python, I'm far from expert :)
>
> Hope that helps
>
> Mick
>
> On 27/08/2020 15:18, Dennis Putnam wrote:
>> Hi Martin,
>>
>> See embedded comments.
>>
>>> On 8/27/2020 2:56 AM, Martin Patzak wrote:
>>>
>>> what does onOff.to_bytes(1,byteorder=sys.byteorder)) evaluate to? Is that
>>> resulting in a byte-value? I am not familiar with this...
>> This seems to be the crux of the problem. After a lot of testing it appears
>> to be a python 3 issue converting an integer to a byte string. I am
>> convinced that passing a byte string to the write function is the problem.
>> Thanks for everyone's help but this is not an owfs problem.
>>>
>>> Things you could try:
>>> In the path use the fully qualifying path and add /uncached and write a
>>> byte-value like this
>>> owproxy.write('/uncached/3A.0BE14D000000/PIO.BYTE',b'0')
>>> write to the individual outputs PIO.A or PIO.B directly
>>> try reading the sensed values print('sensed.BYTE = ',
>>> owp.read('/uncached/3A.0BE14D000000/sensed.BYTE')
>>>
>>> On 26.08.20 21:05, Dennis Putnam wrote:
>>>> I have rewritten my code to use pyownet but am now nearly back where I
>>>> started. I have the following code:
>>>>
>>>> owproxy.write('/3A.'+blower.id_+'/PIO.BYTE',onOff.to_bytes(1,byteorder=sys.byteorder))
>>>>
>>>> That statement gives me the following error:
>>>>
>>>> pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid transaction:
>>>> '/3A.0BE14D000000/PIO.BYTE'
>>>>
>>>> The error is meaningless to me. The path is not wrong so is it complaining
>>>> about writing a single byte?
>>>>
>>>> Thanks again.
>>>>
>>>>> On 8/24/2020 4:33 PM, Dennis Putnam wrote:
>>>>> Thanks to everyone that replied. I was not aware of pyownet. I will look
>>>>> into that and rewrite my code to use it.
>>>>>
>>>>>> On 8/24/2020 11:47 AM, Martin Patzak wrote:
>>>>>> For python I would highly recommend you use the library pyownet by
>>>>>> Stefano Miccoli
>>>>>> https://github.com/miccoli/pyownet/
>>>>>>
>>>>>> using Fuse can lead to weird problems... (not saying that it is the
>>>>>> reason in your specific case)
>>>>>>
>>>>>> or you can use the buil-in functions in owserver owread/owwrite/owdir
>>>>>> instead.
>>>>
>>>>
>>>> Virus-free. www.avast.com
>>
>>
>>
>>
>> _______________________________________________
>> 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
https://lists.sourceforge.net/lists/listinfo/owfs-developers
