I have no experience with the DS2413, but if I understand correctly the manual,
here is a list of valid commands:
owproxy.write('device_id' + '/PIO.A, b'1’) # A on
owproxy.write('device_id' + '/PIO.A, b’0’) # A off
owproxy.write('device_id' + '/PIO.B, b'1’) # B on
owproxy.write('device_id' + '/PIO.B, b’0’) # B off
owproxy.write('device_id' + '/PIO.ALL, b’1,1’) # both on
owproxy.write('device_id' + '/PIO.ALL, b’0,0’) # both off
owproxy.write('device_id' + ‘/PIO.BYTE', b’\x03’) # both on
owproxy.write('device_id' + ‘/PIO.BYTE', b’\x00’) # both off
In fact from the Manual page DS2413(3):
PIO.A PIO.B PIO.ALL PIO.BYTE
read-write, yes-no
State of the open-drain output ( PIO ) pin. 0 = non-conducting (off), 1
= conducting (on).
Writing zero will turn off the switch, non-zero will turn on the
switch. Reading the PIO state will return the switch setting. To deter-
mine the actual logic level at the switch, refer to the sensed prop-
erty.
ALL references both channels simultaneously, comma separated.
BYTE references both channels simultaneously as a single byte, with
channel A in bit 0.
If I got this right, then owserver on PIO.A is expecting a single byte, with
character ‘1’ or ‘0’, ascii encoded ( python literals b’1’ or b’0’). PIO.BYTE
instead is a single byte in which bit 0 is channel A, and bit 1 is channel B,
so here I have to transmit a byte with integer values 0, 1, 2, or 3, (python
literals b’\x00’, b’\x01’, b’\x03’, b’\x03’). PIO.ALL should be 3 bytes, e.g.
b’0,1’.
Just to clarify the python3 literals:
>>> b'1' == b'\x31'
True
>>> b'0' == b'\x30'
True
>>> bytes.fromhex('00')
b'\x00'
>>> bytes.fromhex('deadbeef')
b'\xde\xad\xbe\xef'
>>> bytes(range(8))
b'\x00\x01\x02\x03\x04\x05\x06\x07'
Hope this helps.
Stefano
> On 27 Aug 2020, at 19:47, 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/ <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.
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>>>> Virus-free. www.avast.com
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>>>> <x-msg://4/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>>
>>
>>
>> _______________________________________________
>> 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
