owfs-developers — Developer's list for OWFS

Re: [Owfs-developers] Python2.7 to 3

[Mick S. <mi...@su...>]

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 without 
error.  I then ran it many more times and it still completed without 
error.  So it would appear that your fix together with a reboot fixes 
the problem :)

Is this something which should be fixed in owserver or should it be a 
discipline on the user to add b'\x00' to any string when writing?

Mick


On 13/10/2019 21:25, Stefano Miccoli via Owfs-developers wrote:
> 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 
> treated in owserver. I clearly remember that when I implemented the 
> write feature I asked on this list if data sent in a write request 
> should be null-terminated. Paul replied that this was not necessary, 
> since the length of the payload is known to owserver.
>
> Therefore the payload for an alias is sent by pyownet as something like
>
> b”/26.123412341234/alias\x00T0”
>
> (where b”\x00” is a null byte in python). This means that on the 
> receiving side the C code has to add a null terminator to the received 
> alias. So I would suggest to test writes likes this
>
> owp.write(addr,  newa + b'\x00')
>
> just to see explicitly adding a null terminator on the sending side 
> mitigates the problem. (Please note that this is just a wild guess, 
> maybe the problem is in another portion of the code.)
>
> Stefano
>

Re: [Owfs-developers] Python2.7 to 3

[Stefano M. <mo...@ic...>]

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 treated in owserver. I clearly remember that when I implemented the write feature I asked on this list if data sent in a write request should be null-terminated. Paul replied that this was not necessary, since the length of the payload is known to owserver.

Therefore the payload for an alias is sent by pyownet as something like

b”/26.123412341234/alias\x00T0”

(where b”\x00” is a null byte in python). This means that on the receiving side the C code has to add a null terminator to the received alias. So I would suggest to test writes likes this

owp.write(addr,  newa + b'\x00')

just to see explicitly adding a null terminator on the sending side mitigates the problem. (Please note that this is just a wild guess, maybe the problem is in another portion of the code.)

Stefano

> On 10 Oct 2019, at 23:48, Mick Sulley <mi...@su...> wrote:
> 
> 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 <mi...@su... <mailto:mi...@su...>> 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 <mi...@su... <mailto:mi...@su...>> 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
>>>>>> Owf...@li... <mailto:Owf...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Owfs-developers mailing list
>>>>> Owf...@li... <mailto:Owf...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Owfs-developers mailing list
>>>> Owf...@li... <mailto:Owf...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owf...@li... <mailto:Owf...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li... <mailto:Owf...@li...>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Python2.7 to 3

[Matthias U. <mat...@ur...>]

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 Urlichs

Re: [Owfs-developers] Python2.7 to 3

[Mick S. <mi...@su...>]

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

Re: [Owfs-developers] Python2.7 to 3

[Stefano M. <mo...@ic...>]

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

Re: [Owfs-developers] Python2.7 to 3

[Mick S. <mi...@su...>]

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

Re: [Owfs-developers] Python2.7 to 3

[Mick S. <mi...@su...>]

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

Re: [Owfs-developers] Python2.7 to 3

[Stefano M. <mo...@ic...>]

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 <mi...@su...> 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
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Python2.7 to 3

[Mick S. <mi...@su...>]

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

Re: [Owfs-developers] owfs on Raspberry Buster

[Robert L. <ro...@la...>]

Ok! - my value hasn't changed between Rpi,2b,3b&4b...

Is there anything else I can do to troubleshoot this issue?

[image: Linkedin] <http://de.linkedin.com/in/rlagus> *Robert Lagus*

+358 (0)40 662 44 99

ro...@la...



On Thu, 19 Sep 2019 at 13:09, Mick Sulley <mi...@su...> wrote:

> The value and position in the grid depends, I think, on the actual adapter
> it detects.
>
> e.g. on a system with a Sheepwalk RPi2 I see
>
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> on a system with a Sheepwalk RPi3 I see
>
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> Both work fine.
>
>
> On 19/09/2019 10:56, Robert Lagus wrote:
>
> Resending, the last got stuck due to an attached image:
>
> robban@sniff:~$ *sudo i2cdetect -y 1*
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> *sudo i2cdetect -r 1*
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-1 using receive byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> So it's the same value using -r & -y, I don't know if that's good or bad?
> I have always only seen 1b, and nothing else when using -y as in guide I
> was following previously (before Buster install).
>
> robban@sniff:~$ *sudo i2cdetect -r 2*
> [sudo] password for robban:
> Error: Could not open file `/dev/i2c-2' or `/dev/i2c/2': No such file or
> directory
> 1 robban@sniff:~$ *sudo i2cdetect -r 3*
> Error: Could not open file `/dev/i2c-3' or `/dev/i2c/3': No such file or
> directory
> 1 robban@sniff:~$ *sudo i2cdetect -F 1*
> Functionalities implemented by /dev/i2c-1:
> I2C                              yes
> SMBus Quick Command              yes
> SMBus Send Byte                  yes
> SMBus Receive Byte               yes
> SMBus Write Byte                 yes
> SMBus Read Byte                  yes
> SMBus Write Word                 yes
> SMBus Read Word                  yes
> SMBus Process Call               yes
> SMBus Block Write                yes
> SMBus Block Read                 no
> SMBus Block Process Call         no
> SMBus PEC                        yes
> I2C Block Write                  yes
> I2C Block Read                   yes
> robban@sniff:~$ *sudo i2cdetect -l*
> i2c-1   i2c             bcm2835 I2C adapter                     I2C adapter
>
>
> [image: Linkedin] <http://de.linkedin.com/in/rlagus> *Robert Lagus*
>
> +358 (0)40 662 44 99
>
> ro...@la...
>
>
>
> On Wed, 18 Sep 2019 at 19:51, Nico Bouthoorn via Owfs-developers <
> owf...@li...> wrote:
>
>> Can you see the ds2482 device on the i2c bus like?:
>>
>> i2cdetect -r 1 ( 2 or 3)
>> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>> I will probe file /dev/i2c-1 using read byte commands.
>> I will probe address range 0x03-0x77.
>> Continue? [Y/n]
>>       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
>> 10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 70: -- -- -- -- -- -- -- --
>>
>>
>> You have to see the 18 for i2c device 0   etc
>>
>>
>> Nico
>>
>> Mick Sulley wrote:
>> > I am having trouble getting owfs to work on Raspbian Buster.  I have
>> posted on the Pi forum
>> >
>> >
>> https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
>> >
>> > Someone said they had the same problem but no suggestions to fix it, so
>> I wonder if anyone here can give me a clue.
>> >
>> > I have just done a fresh install of Buster and updated. I ran
>> raspi-config and enabled 1-wire and i2c.
>> > I have installed owserver ow-shell
>> > At first it worked, I could see devices with owdir, but it has stopped
>> working, owdir returns nothing
>> > I have run "sudo systemctl enable owserver.service"
>> > but I see -
>> >
>> > |pi@pi-solar-old:~ $ sudo systemctl status owserver.service ●
>> owserver.service - Backend server for 1-wire control Loaded: loaded
>> (/lib/systemd/system/owserver.service; enabled; vendor preset: enabled)
>> Active: failed (Result: protocol) since Fri 2019-09-13 21:47:16 BST; 48s
>> ago Docs: man:owserver(1) Main PID: 493 (code=exited, status=0/SUCCESS)
>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Service
>> RestartSec=100ms expired, scheduling Sep 13 21:47:16 pi-solar-old
>> systemd[1]: owserver.service: Scheduled restart job, restart counter is at
>> Sep 13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for 1-wire
>> control. Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Start
>> request repeated too quickly. Sep 13 21:47:16 pi-solar-old systemd[1]:
>> owserver.service: Failed with result 'protocol'. Sep 13 21:47:16
>> pi-solar-old systemd[1]: Failed to start Backend server for 1-wire control.
>> pi@pi-solar-old:~ $ |||
>> >
>> > |I have tried disable, enable, restart for the service, I have removed
>> and reinstalled owserver and ow-shell but nothing helps.|
>> >
>> > |Any ideas?
>> > |
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Owfs-developers mailing list
>> > Owf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> >
>>
>> --
>> 0623391101
>>
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
>
> _______________________________________________
> Owfs-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

Re: [Owfs-developers] owfs on Raspberry Buster

[Mick S. <mi...@su...>]

The value and position in the grid depends, I think, on the actual 
adapter it detects.

e.g. on a system with a Sheepwalk RPi2 I see

      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

on a system with a Sheepwalk RPi3 I see

      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Both work fine.


On 19/09/2019 10:56, Robert Lagus wrote:
> Resending, the last got stuck due to an attached image:
>
> robban@sniff:~$ *sudo i2cdetect -y 1*
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> *sudo i2cdetect -r 1*
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-1 using receive byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> So it's the same value using -r & -y, I don't know if that's good or bad?
> I have always only seen 1b, and nothing else when using -y as in guide 
> I was following previously (before Buster install).
>
> robban@sniff:~$ *sudo i2cdetect -r 2*
> [sudo] password for robban:
> Error: Could not open file `/dev/i2c-2' or `/dev/i2c/2': No such file 
> or directory
> 1 robban@sniff:~$ *sudo i2cdetect -r 3*
> Error: Could not open file `/dev/i2c-3' or `/dev/i2c/3': No such file 
> or directory
> 1 robban@sniff:~$ *sudo i2cdetect -F 1*
> Functionalities implemented by /dev/i2c-1:
> I2C                              yes
> SMBus Quick Command              yes
> SMBus Send Byte                  yes
> SMBus Receive Byte               yes
> SMBus Write Byte                 yes
> SMBus Read Byte                  yes
> SMBus Write Word                 yes
> SMBus Read Word                  yes
> SMBus Process Call               yes
> SMBus Block Write                yes
> SMBus Block Read                 no
> SMBus Block Process Call         no
> SMBus PEC                        yes
> I2C Block Write                  yes
> I2C Block Read                   yes
> robban@sniff:~$ *sudo i2cdetect -l*
> i2c-1   i2c             bcm2835 I2C adapter     I2C adapter
>
>
> Linkedin <http://de.linkedin.com/in/rlagus> *Robert Lagus*
> +358 (0)40 662 44 99
> ro...@la...  <mailto:ro...@la...>
>
>
> On Wed, 18 Sep 2019 at 19:51, Nico Bouthoorn via Owfs-developers 
> <owf...@li... 
> <mailto:owf...@li...>> wrote:
>
>     Can you see the ds2482 device on the i2c bus like?:
>
>     i2cdetect -r 1 ( 2 or 3)
>     WARNING! This program can confuse your I2C bus, cause data loss
>     and worse!
>     I will probe file /dev/i2c-1 using read byte commands.
>     I will probe address range 0x03-0x77.
>     Continue? [Y/n]
>           0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>     00:          -- -- -- -- -- -- -- -- -- -- -- -- --
>     10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
>     20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>     30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>     40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>     50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>     60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>     70: -- -- -- -- -- -- -- --
>
>
>     You have to see the 18 for i2c device 0   etc
>
>
>     Nico
>
>     Mick Sulley wrote:
>     > I am having trouble getting owfs to work on Raspbian Buster.  I
>     have posted on the Pi forum
>     >
>     >
>     https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
>     >
>     > Someone said they had the same problem but no suggestions to fix
>     it, so I wonder if anyone here can give me a clue.
>     >
>     > I have just done a fresh install of Buster and updated. I ran
>     raspi-config and enabled 1-wire and i2c.
>     > I have installed owserver ow-shell
>     > At first it worked, I could see devices with owdir, but it has
>     stopped working, owdir returns nothing
>     > I have run "sudo systemctl enable owserver.service"
>     > but I see -
>     >
>     > |pi@pi-solar-old:~ $ sudo systemctl status owserver.service ●
>     owserver.service - Backend server for 1-wire control Loaded:
>     loaded (/lib/systemd/system/owserver.service; enabled; vendor
>     preset: enabled) Active: failed (Result: protocol) since Fri
>     2019-09-13 21:47:16 BST; 48s ago Docs: man:owserver(1) Main PID:
>     493 (code=exited, status=0/SUCCESS) Sep 13 21:47:16 pi-solar-old
>     systemd[1]: owserver.service: Service RestartSec=100ms expired,
>     scheduling Sep 13 21:47:16 pi-solar-old systemd[1]:
>     owserver.service: Scheduled restart job, restart counter is at Sep
>     13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for
>     1-wire control. Sep 13 21:47:16 pi-solar-old systemd[1]:
>     owserver.service: Start request repeated too quickly. Sep 13
>     21:47:16 pi-solar-old systemd[1]: owserver.service: Failed with
>     result 'protocol'. Sep 13 21:47:16 pi-solar-old systemd[1]: Failed
>     to start Backend server for 1-wire control. pi@pi-solar-old:~ $ |||
>     >
>     > |I have tried disable, enable, restart for the service, I have
>     removed and reinstalled owserver and ow-shell but nothing helps.|
>     >
>     > |Any ideas?
>     > |
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Owfs-developers mailing list
>     > Owf...@li...
>     <mailto:Owf...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>     >
>
>     -- 
>     0623391101
>
>
>     _______________________________________________
>     Owfs-developers mailing list
>     Owf...@li...
>     <mailto:Owf...@li...>
>     https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs on Raspberry Buster

[Robert L. <ro...@la...>]

Resending, the last got stuck due to an attached image:

robban@sniff:~$ *sudo i2cdetect -y 1*
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

*sudo i2cdetect -r 1*
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using receive byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

So it's the same value using -r & -y, I don't know if that's good or bad?
I have always only seen 1b, and nothing else when using -y as in guide I
was following previously (before Buster install).

robban@sniff:~$ *sudo i2cdetect -r 2*
[sudo] password for robban:
Error: Could not open file `/dev/i2c-2' or `/dev/i2c/2': No such file or
directory
1 robban@sniff:~$ *sudo i2cdetect -r 3*
Error: Could not open file `/dev/i2c-3' or `/dev/i2c/3': No such file or
directory
1 robban@sniff:~$ *sudo i2cdetect -F 1*
Functionalities implemented by /dev/i2c-1:
I2C                              yes
SMBus Quick Command              yes
SMBus Send Byte                  yes
SMBus Receive Byte               yes
SMBus Write Byte                 yes
SMBus Read Byte                  yes
SMBus Write Word                 yes
SMBus Read Word                  yes
SMBus Process Call               yes
SMBus Block Write                yes
SMBus Block Read                 no
SMBus Block Process Call         no
SMBus PEC                        yes
I2C Block Write                  yes
I2C Block Read                   yes
robban@sniff:~$ *sudo i2cdetect -l*
i2c-1   i2c             bcm2835 I2C adapter                     I2C adapter


[image: Linkedin] <http://de.linkedin.com/in/rlagus> *Robert Lagus*

+358 (0)40 662 44 99

ro...@la...



On Wed, 18 Sep 2019 at 19:51, Nico Bouthoorn via Owfs-developers <
owf...@li...> wrote:

> Can you see the ds2482 device on the i2c bus like?:
>
> i2cdetect -r 1 ( 2 or 3)
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-1 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
>
> You have to see the 18 for i2c device 0   etc
>
>
> Nico
>
> Mick Sulley wrote:
> > I am having trouble getting owfs to work on Raspbian Buster.  I have
> posted on the Pi forum
> >
> >
> https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
> >
> > Someone said they had the same problem but no suggestions to fix it, so
> I wonder if anyone here can give me a clue.
> >
> > I have just done a fresh install of Buster and updated. I ran
> raspi-config and enabled 1-wire and i2c.
> > I have installed owserver ow-shell
> > At first it worked, I could see devices with owdir, but it has stopped
> working, owdir returns nothing
> > I have run "sudo systemctl enable owserver.service"
> > but I see -
> >
> > |pi@pi-solar-old:~ $ sudo systemctl status owserver.service ●
> owserver.service - Backend server for 1-wire control Loaded: loaded
> (/lib/systemd/system/owserver.service; enabled; vendor preset: enabled)
> Active: failed (Result: protocol) since Fri 2019-09-13 21:47:16 BST; 48s
> ago Docs: man:owserver(1) Main PID: 493 (code=exited, status=0/SUCCESS) Sep
> 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Service
> RestartSec=100ms expired, scheduling Sep 13 21:47:16 pi-solar-old
> systemd[1]: owserver.service: Scheduled restart job, restart counter is at
> Sep 13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for 1-wire
> control. Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Start
> request repeated too quickly. Sep 13 21:47:16 pi-solar-old systemd[1]:
> owserver.service: Failed with result 'protocol'. Sep 13 21:47:16
> pi-solar-old systemd[1]: Failed to start Backend server for 1-wire control.
> pi@pi-solar-old:~ $ |||
> >
> > |I have tried disable, enable, restart for the service, I have removed
> and reinstalled owserver and ow-shell but nothing helps.|
> >
> > |Any ideas?
> > |
> >
> >
> >
> >
> >
> > _______________________________________________
> > Owfs-developers mailing list
> > Owf...@li...
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
> >
>
> --
> 0623391101
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

Re: [Owfs-developers] owfs on Raspberry Buster

[Nico B. <ni...@cu...>]

Can you see the ds2482 device on the i2c bus like?:

i2cdetect -r 1 ( 2 or 3)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


You have to see the 18 for i2c device 0   etc


Nico

Mick Sulley wrote:
> I am having trouble getting owfs to work on Raspbian Buster.  I have posted on the Pi forum
> 
> https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
> 
> Someone said they had the same problem but no suggestions to fix it, so I wonder if anyone here can give me a clue.
> 
> I have just done a fresh install of Buster and updated. I ran raspi-config and enabled 1-wire and i2c.
> I have installed owserver ow-shell
> At first it worked, I could see devices with owdir, but it has stopped working, owdir returns nothing
> I have run "sudo systemctl enable owserver.service"
> but I see -
> 
> |pi@pi-solar-old:~ $ sudo systemctl status owserver.service ● owserver.service - Backend server for 1-wire control Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor preset: enabled) Active: failed (Result: protocol) since Fri 2019-09-13 21:47:16 BST; 48s ago Docs: man:owserver(1) Main PID: 493 (code=exited, status=0/SUCCESS) Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Service RestartSec=100ms expired, scheduling Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Scheduled restart job, restart counter is at Sep 13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for 1-wire control. Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Start request repeated too quickly. Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Failed with result 'protocol'. Sep 13 21:47:16 pi-solar-old systemd[1]: Failed to start Backend server for 1-wire control. pi@pi-solar-old:~ $ |||
> 
> |I have tried disable, enable, restart for the service, I have removed and reinstalled owserver and ow-shell but nothing helps.|
> 
> |Any ideas?
> |
> 
> 
> 
> 
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 

-- 
0623391101

Re: [Owfs-developers] owfs on Raspberry Buster

[Robert L. <ro...@la...>]

Okay, I understand that Buster install is a bit wonky...
I don't really understand why mine is so troublesome.

I have tried to load the right modules but it seems it's hard to get
anything right now..

*/etc/modprobe.d/raspi-blacklist.conf * - empty

*lsmod | grep i2c*
i2c_bcm2708            16384  0
i2c_dev                20480  0
i2c_bcm2835            16384  0

*owfs.conf* - server: device=/dev/i2c-1

*sudo /usr/bin/owserver -c /etc/owfs.conf --debug*
DEBUG MODE
libow version:
        3.2p3
  DEBUG: ow_daemon.c:(170) main thread id = 3070111472
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library
isn't found
   CALL: ow_parsename.c:(174) path=[]
  DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock
adapters)
  DEBUG: ow_regex.c:(24) Reg Ex expression <^$> compiled to 0xb6fa860c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^all$> compiled to 0xb6fa862c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^scan$> compiled to 0xb6fa864c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^\*$> compiled to 0xb6fa866c
  DEBUG: ow_regex.c:(24) Reg Ex expression
<^[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}$>
compiled to 0xb6fa868c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^-?[[:digit:]]+$> compiled to
0xb6fa86ac
]*$> compiled to 0xb6fa86ccg Ex expression <^ *([^ ]+)[
]*$> compiled to 0xb6fa86ecg Ex expression <^ *([^ ]+) *: *([^ ]+)[
]*$> compiled to 0xb6fa870cg Ex expression <^ *([^ ]+) *: *([^ ]+) *: *([^
]+)[
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(100) 0: 0->10 found <></dev/i2c-1><>
  DEBUG: ow_regex.c:(100) 1: 0->10 found <></dev/i2c-1><>
  DEBUG: ow_parse_address.c:(87) Text </dev/i2c-1>
  DEBUG: ow_parse_address.c:(142) First </dev/i2c-1>
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 18
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 18 cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 19
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 19 cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1A
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1A cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1B
  DEBUG: ow_ds2482.c:(516) ok
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1B cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1C
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1C cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1D
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1D cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1E
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1E cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1F
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1F cannot be
reset. Not a DS2482.
  DEBUG: ow_com_close.c:(42) Unimplemented!!!
CONNECT: owlib.c:(145) Cannot detect an i2c DS2482-x00 on /dev/i2c-1
DEFAULT: owlib.c:(52) No valid 1-wire buses found
  DEBUG: ow_exit.c:(17) Exit code = 1
   CALL: ow_lib_close.c:(21) Starting Library cleanup
   CALL: ow_lib_stop.c:(22) Clear Cache
  DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
  DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
  DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
  DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
   CALL: ow_lib_stop.c:(24) Closing input devices
   CALL: ow_lib_stop.c:(26) Closing output devices
   CALL: ow_lib_close.c:(42) Finished Library cleanup
  DEBUG: ow_lib_close.c:(50) Libraries closed


So, is it strange or did I not load the right modules?
the i2c module card I have attached to my raspberry is:
https://en.m.nu/adapters-network-managment/r-pi-i2c-1wire-expansion-module-v11

Let me know your thoughts!
I'm dying to get this network up and working again.
//Robert

[image: Linkedin] <http://de.linkedin.com/in/rlagus> *Robert Lagus*

+358 (0)40 662 44 99

ro...@la...



On Tue, 17 Sep 2019 at 23:31, Stefano Miccoli via Owfs-developers <
owf...@li...> wrote:

>
>
> On 17 Sep 2019, at 14:35, Robert Lagus <ro...@la...> wrote:
>
> I tried to start the ofserver with:
> *sudo systemctl restart owserver*
> Job for owserver.service failed because the service did not take the steps
> required by its unit configuration.
> See "systemctl status owserver.service" and "journalctl -xe" for details.
>
>
> You have two independent problems:
>
> 1) the ds2482 is not found by owserver. You should first debug this
> problem starting owserver manually:
> sudo /usr/bin/owserver -c /etc/owfs.conf --debug
>
> 2) the owserver.service unit file on buster is problematic.
>
>
> I cannot give you advice on 1), but I have solved 2) with a drop-in unit
> configuration file. I run owserver on an headless server with the following
> configuration.
>
> *$* sudo systemctl cat owserver.service
> *# /lib/systemd/system/owserver.service*
> [Unit]
> Description=Backend server for 1-wire control
> Documentation=man:owserver(1)
>
> [Service]
> Type=notify
> NotifyAccess=all
> ExecStart=/usr/bin/owserver -c /etc/owfs.conf
> Restart=on-failure
> #User=Debian-ow
> #Group=Debian-ow
>
> [Install]
> WantedBy=multi-user.target
> Also=owserver.socket
>
> *# /etc/systemd/system/owserver.service.d/override.conf*
> [Service]
> User=Debian-ow
> Group=Debian-ow
> ExecStart=
> ExecStart=/usr/bin/owserver -c /etc/owfs.conf --foreground
>
> [Install]
> Also=
>
>
> A long story short.
>
> /lib/systemd/system/owserver.service is the system file shipped with
> Buster, and it did not work for me out of the box.
> /etc/systemd/system/owserver.service.d/override.conf is an override file,
> that you create with `sudo systemctl edit owserver.service`.
>
> My changes with respect to the shipped configuration.
>
> 1) Do not run the server as root. I use an USB adapter, and I wrote a
> couple of udev rules to change the ttyUSBxx group to Debian-ow and symlink
> it to a persistent /dev node. Skip this if you plan to run owserver with
> root privileges. (I’m not sure, but I think that root privileges are
> necessary to access the i2c bus.)
>
> 2) Add the the --foreground option to the owserver command. This is
> crucial for starting owserver under systemctl without socket activation.
>
> 3) Disable socket activation. I expect the owserver service to start at
> boot, before that the first client connects, so socket activation is not
> needed. I found that in edge conditions socket activation may interfere
> with the correct startup, therefore I prefer to disable it.
>
>
> Bye
>
> S.
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

[Owfs-developers] USB9097

[Robin G. <g8...@gi...>]

Greetings

Can anyone confirm that a USB 9097 is just a CH341 USB to serial chip
connected to a DS2480B ?

Does anyone have a schematic by any chance to determine what other
components there might be ?

Thanks

-- 
Robin Gilks

Re: [Owfs-developers] owfs on Raspberry Buster

[Stefano M. <mo...@ic...>]

> On 17 Sep 2019, at 14:35, Robert Lagus <ro...@la...> wrote:
> 
> I tried to start the ofserver with: 
> sudo systemctl restart owserver
> Job for owserver.service failed because the service did not take the steps required by its unit configuration.
> See "systemctl status owserver.service" and "journalctl -xe" for details.
> 

You have two independent problems: 

1) the ds2482 is not found by owserver. You should first debug this problem starting owserver manually: 
sudo /usr/bin/owserver -c /etc/owfs.conf --debug

2) the owserver.service unit file on buster is problematic.


I cannot give you advice on 1), but I have solved 2) with a drop-in unit configuration file. I run owserver on an headless server with the following configuration.

$ sudo systemctl cat owserver.service
# /lib/systemd/system/owserver.service
[Unit]
Description=Backend server for 1-wire control
Documentation=man:owserver(1)

[Service]
Type=notify
NotifyAccess=all
ExecStart=/usr/bin/owserver -c /etc/owfs.conf
Restart=on-failure
#User=Debian-ow
#Group=Debian-ow

[Install]
WantedBy=multi-user.target
Also=owserver.socket

# /etc/systemd/system/owserver.service.d/override.conf
[Service]
User=Debian-ow
Group=Debian-ow
ExecStart=
ExecStart=/usr/bin/owserver -c /etc/owfs.conf --foreground

[Install]
Also=


A long story short. 

/lib/systemd/system/owserver.service is the system file shipped with Buster, and it did not work for me out of the box.
/etc/systemd/system/owserver.service.d/override.conf is an override file, that you create with `sudo systemctl edit owserver.service`.

My changes with respect to the shipped configuration.

1) Do not run the server as root. I use an USB adapter, and I wrote a couple of udev rules to change the ttyUSBxx group to Debian-ow and symlink it to a persistent /dev node. Skip this if you plan to run owserver with root privileges. (I’m not sure, but I think that root privileges are necessary to access the i2c bus.)

2) Add the the --foreground option to the owserver command. This is crucial for starting owserver under systemctl without socket activation.

3) Disable socket activation. I expect the owserver service to start at boot, before that the first client connects, so socket activation is not needed. I found that in edge conditions socket activation may interfere with the correct startup, therefore I prefer to disable it.


Bye

S.

Re: [Owfs-developers] owfs on Raspberry Buster

[Jan K. <jj...@gm...>]

Am 17.09.19 um 20:58 schrieb Robert Lagus:
> That worked!  I changed to "server: w1"- And owserver starts, however...
> I'm not seeing any sensors:
> *owdir*
> /bus.0
> /uncached
> /settings
> /system
> /statistics
> /structure
>
> Is this a result of using the module from userspace and not accessing it
> directly on the i2c bus?
>
As soon you use the --w1 option to owserver (or the w1 config option),
it doesn't care if there is any onewire hardware connected. That's now
the task of the kernel. What you are seeing there is a blank listing.
That one /bus.0 is the owserver itself.

Please check if the ds2482 module is loaded. If it is loaded and there
are slaves connected to the DS2482, they should appear at
/sys/bus/w1/devices. You don't need to run owserver for checking that.

Kind regards

	Jan

Re: [Owfs-developers] owfs on Raspberry Buster

[Robert L. <ro...@la...>]

That worked!  I changed to "server: w1"- And owserver starts, however...
I'm not seeing any sensors:
*owdir*
/bus.0
/uncached
/settings
/system
/statistics
/structure

Is this a result of using the module from userspace and not accessing it
directly on the i2c bus?

While I run "owdir" in one terminal the log output shows this:

sudo /usr/bin/owserver -c /etc/owfs.conf --debug >> owserver.log
  DEBUG: ow_daemon.c:(170) main thread id = 3069947632
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library
isn't found
   CALL: ow_parsename.c:(174) path=[]
  DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock
adapters)
  DEBUG: ow_w1_list.c:(53) Sending w1 bus master list message
  DEBUG: ow_net_server.c:(76) ServerAddr: [localhost] [4304]
  DEBUG: ow_w1_send.c:(131) Netlink send -----------------
  DEBUG: ow_w1_send.c:(142) NETLINK sent seq=1
  DEBUG: ow_w1_dispatch.c:(172) Dispatch loop
  DEBUG: ow_w1_parse.c:(112) Wait to peek at message
  DEBUG: ow_tcp_read.c:(63) attempt 24 bytes Time: 10.000000 seconds
  DEBUG: ow_tcp_read.c:(113) read: 24 - 0 = 24
  DEBUG: from_client.c:(65) FromClient payload=2 size=0 type=7 sg=0x10A
offset=0
  DEBUG: from_client.c:(73) FromClient (no servermessage) payload=2 size=0
type=7 controlflags=0x10A offset=0
  DEBUG: ow_tcp_read.c:(63) attempt 2 bytes Time: 10.000000 seconds
  DEBUG: ow_tcp_read.c:(113) read: 2 - 0 = 2
  DEBUG: handler.c:(152) START handler /
   CALL: data.c:(103) DataHandler: parse path=/
  DEBUG: ow_parseobject.c:(163) /
   CALL: ow_parsename.c:(174) path=[/]
   CALL: data.c:(163) Directory message (all at once)
  DEBUG: dirall.c:(65) OWSERVER Dir-All SpecifiedBus=0 path = /
  DEBUG: ow_dir.c:(80) path=/
   CALL: ow_dir.c:(104) path=/
  DEBUG: ow_cache.c:(853) Looking for directory 00 00 00 00 00 00 00 00
  DEBUG: ow_cache.c:(866) Get from cache sn 00 00 00 00 00 00 00 00
pointer=0xb6f80bb8 extension=0
  DEBUG: ow_cache.c:(895) Dir not found in cache
   CALL: ow_parsename.c:(174) path=[/bus.0]
  DEBUG: ow_regex.c:(24) Reg Ex expression <^bus\.([[:digit:]]+)/?>
compiled to 0xb6f8073c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^settings/?> compiled to
0xb6f8075c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^statistics/?> compiled to
0xb6f8077c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^structure/?> compiled to
0xb6f8079c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^system/?> compiled to
0xb6f807bc
  DEBUG: ow_regex.c:(24) Reg Ex expression <^interface/?> compiled to
0xb6f807dc
  DEBUG: ow_regex.c:(24) Reg Ex expression <^text/?> compiled to 0xb6f807fc
  DEBUG: ow_regex.c:(24) Reg Ex expression <^json/?> compiled to 0xb6f8081c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^uncached/?> compiled to
0xb6f8083c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^unaliased/?> compiled to
0xb6f8085c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^alarm?> compiled to 0xb6f8087c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^simultaneous/?> compiled to
0xb6f8089c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^thermostat/?> compiled to
0xb6f808bc
  DEBUG: ow_regex.c:(24) Reg Ex expression <^/bus\.[[:digit:]]+/?> compiled
to 0xb6f808dc
  DEBUG: ow_regex.c:(24) Reg Ex expression <\.> compiled to 0xb6f808fc
  DEBUG: ow_regex.c:(24) Reg Ex expression <\.all$> compiled to 0xb6f8091c
  DEBUG: ow_regex.c:(24) Reg Ex expression <\.byte$> compiled to 0xb6f8093c
  DEBUG: ow_regex.c:(24) Reg Ex expression <\.[[:digit:]]+$> compiled to
0xb6f8095c
  DEBUG: ow_regex.c:(24) Reg Ex expression <\.[[:alpha:]]$> compiled to
0xb6f8097c
  DEBUG: ow_regex.c:(100) 0: 0->5 found <><bus.0><>
  DEBUG: ow_regex.c:(100) 1: 4->5 found <bus.><0><>
  DEBUG: ow_regex.c:(100) 0: 0->6 found <></bus.0><>
  DEBUG: ow_regex.c:(24) Reg Ex expression
<^([[:xdigit:]]{2})\.?([[:xdigit:]]{12})\.?([[:xdigit:]]{2}){0,1}$>
compiled to 0xb6f809a0
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_parsename.c:(133) /bus.0
   CALL: ow_parsename.c:(174) path=[/uncached]
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_parsename.c:(133) /uncached
   CALL: ow_parsename.c:(174) path=[/settings]
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_parsename.c:(133) /settings
   CALL: ow_parsename.c:(174) path=[/system]
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_parsename.c:(133) /system
   CALL: ow_parsename.c:(174) path=[/statistics]
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_parsename.c:(133) /statistics
   CALL: ow_parsename.c:(174) path=[/structure]
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_parsename.c:(133) /structure
  DEBUG: ow_dir.c:(199) ret=0
  DEBUG: ow_parsename.c:(133) /
  DEBUG: data.c:(193) DataHandler: FS_ParsedName_destroy done
  DEBUG: data.c:(207) DataHandler: cm.ret=0
  DEBUG: to_client.c:(75) payload=58 size=57, ret=0, sg=0x10A offset=0
  DEBUG: data.c:(226) Finished with client request
  DEBUG: handler.c:(134) OWSERVER handler done
  DEBUG: ow_net_server.c:(259) Normal completion.



Thanks for all your help!

[image: Linkedin] <http://de.linkedin.com/in/rlagus> *Robert Lagus*

+358 (0)40 662 44 99

ro...@la...



On Tue, 17 Sep 2019 at 16:54, Jan Kandziora <jj...@gm...> wrote:

> Am 17.09.19 um 08:52 schrieb Robert Lagus:
> >
> > *ofws.conf:*
> > ! server: server = localhost:4304
> > server: i2c = /dev/i2c-1
> >
> Please check if you have the ds2482 kernel module loaded.
>
> What you are doing here is accessing the ds2482 directly from user
> space. This is ok, but it creates a mess on the I²C bus if the ds2482
> module is loaded, as that module access the ds2482 at the same time.
>
> So either unload and blacklist that module, or change the owfs.conf line to
>
> server: w1
>
> This makes owserver use the kernel modules instead of accessing the I²C
> hardware by itself.
>
> Kind regards
>
>         Jan
>

Re: [Owfs-developers] owfs on Raspberry Buster

[Jan K. <jj...@gm...>]

Am 17.09.19 um 08:52 schrieb Robert Lagus:
>
> *ofws.conf:*
> ! server: server = localhost:4304
> server: i2c = /dev/i2c-1
>
Please check if you have the ds2482 kernel module loaded.

What you are doing here is accessing the ds2482 directly from user
space. This is ok, but it creates a mess on the I²C bus if the ds2482
module is loaded, as that module access the ds2482 at the same time.

So either unload and blacklist that module, or change the owfs.conf line to

server: w1

This makes owserver use the kernel modules instead of accessing the I²C
hardware by itself.

Kind regards

	Jan

Re: [Owfs-developers] owfs on Raspberry Buster

[Robert L. <ro...@la...>]

Hi, Thanks for your email!

I changed to your proposed owfs.conf with the same error messages:

*sudo /usr/bin/owserver -c /etc/owfs.conf --debug*
DEBUG MODE
libow version:
        3.2p3
  DEBUG: ow_daemon.c:(170) main thread id = 3069234928
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library
isn't found
   CALL: ow_parsename.c:(174) path=[]
  DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock
adapters)
  DEBUG: ow_regex.c:(24) Reg Ex expression <^$> compiled to 0xb6ed260c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^all$> compiled to 0xb6ed262c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^scan$> compiled to 0xb6ed264c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^\*$> compiled to 0xb6ed266c
  DEBUG: ow_regex.c:(24) Reg Ex expression
<^[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}$>
compiled to 0xb6ed268c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^-?[[:digit:]]+$> compiled to
0xb6ed26ac
]*$> compiled to 0xb6ed26ccg Ex expression <^ *([^ ]+)[
]*$> compiled to 0xb6ed26ecg Ex expression <^ *([^ ]+) *: *([^ ]+)[
]*$> compiled to 0xb6ed270cg Ex expression <^ *([^ ]+) *: *([^ ]+) *: *([^
]+)[
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(100) 0: 0->10 found <></dev/i2c-1><>
  DEBUG: ow_regex.c:(100) 1: 0->10 found <></dev/i2c-1><>
  DEBUG: ow_parse_address.c:(87) Text </dev/i2c-1>
  DEBUG: ow_parse_address.c:(142) First </dev/i2c-1>
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 18
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 18 cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 19
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 19 cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1A
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1A cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1B
  DEBUG: ow_ds2482.c:(516) ok
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1B cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1C
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1C cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1D
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1D cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1E
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1E cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1F
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1F cannot be
reset. Not a DS2482.
  DEBUG: ow_com_close.c:(42) Unimplemented!!!
CONNECT: owlib.c:(145) Cannot detect an i2c DS2482-x00 on /dev/i2c-1
DEFAULT: owlib.c:(52) No valid 1-wire buses found
  DEBUG: ow_exit.c:(17) Exit code = 1
   CALL: ow_lib_close.c:(21) Starting Library cleanup
   CALL: ow_lib_stop.c:(22) Clear Cache
  DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
  DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
  DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
  DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
   CALL: ow_lib_stop.c:(24) Closing input devices
   CALL: ow_lib_stop.c:(26) Closing output devices
   CALL: ow_lib_close.c:(42) Finished Library cleanup
  DEBUG: ow_lib_close.c:(50) Libraries closed

*systemctl status owserver*
● owserver.service - Backend server for 1-wire control
   Loaded: loaded (/lib/systemd/system/owserver.service; disabled; vendor
preset: enabled)
   Active: failed (Result: protocol) since Tue 2019-09-17 09:32:09 EEST; 5h
53min ago
     Docs: man:owserver(1)
  Process: 24451 ExecStart=/usr/bin/owserver -c /etc/owfs.conf
(code=exited, status=0/SUCCESS)
 Main PID: 24451 (code=exited, status=0/SUCCESS)

*sudo systemctl enable owserver*
Synchronizing state of owserver.service with SysV service script with
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable owserver
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_CTYPE = "UTF-8",
        LC_TERMINAL = "iTerm2",
        LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_CTYPE = "UTF-8",
        LC_TERMINAL = "iTerm2",
        LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
Created symlink
/etc/systemd/system/multi-user.target.wants/owserver.service →
/lib/systemd/system/owserver.service.
Created symlink /etc/systemd/system/sockets.target.wants/owserver.socket →
/lib/systemd/system/owserver.socket.

I tried to start the ofserver with:
*sudo systemctl restart owserver*
Job for owserver.service failed because the service did not take the steps
required by its unit configuration.
See "systemctl status owserver.service" and "journalctl -xe" for details.

meanwhile this is what */var/logs/syslog *sent as output:
Sep 17 15:29:44 sniff systemd[1]: Starting Backend server for 1-wire
control...
Sep 17 15:29:44 sniff OWFS[7081]: DEFAULT: ow_daemon.c:(144) Entered
background mode, quitting.
Sep 17 15:29:44 sniff systemd[1]: owserver.service: Failed with result
'protocol'.
Sep 17 15:29:44 sniff systemd[1]: Failed to start Backend server for 1-wire
control.
Sep 17 15:29:44 sniff systemd[1]: owserver.service: Service
RestartSec=100ms expired, scheduling restart.
Sep 17 15:29:44 sniff systemd[1]: owserver.service: Scheduled restart job,
restart counter is at 1.
Sep 17 15:29:44 sniff systemd[1]: Stopped Backend server for 1-wire control.
Sep 17 15:29:44 sniff systemd[1]: Starting Backend server for 1-wire
control...
Sep 17 15:29:45 sniff OWFS[7101]: DEFAULT: ow_daemon.c:(144) Entered
background mode, quitting.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Supervising process
7101 which is not our child. We'll most likely not notice when it exits.
Sep 17 15:29:45 sniff OWFS[7101]: DEFAULT: owlib.c:(52) No valid 1-wire
buses found
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Main process exited,
code=exited, status=1/FAILURE
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Failed with result
'exit-code'.
Sep 17 15:29:45 sniff systemd[1]: Failed to start Backend server for 1-wire
control.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Service
RestartSec=100ms expired, scheduling restart.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Scheduled restart job,
restart counter is at 2.
Sep 17 15:29:45 sniff systemd[1]: Stopped Backend server for 1-wire control.
Sep 17 15:29:45 sniff systemd[1]: Starting Backend server for 1-wire
control...
Sep 17 15:29:45 sniff OWFS[7115]: DEFAULT: ow_daemon.c:(144) Entered
background mode, quitting.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Failed with result
'protocol'.
Sep 17 15:29:45 sniff systemd[1]: Failed to start Backend server for 1-wire
control.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Service
RestartSec=100ms expired, scheduling restart.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Scheduled restart job,
restart counter is at 3.
Sep 17 15:29:45 sniff systemd[1]: Stopped Backend server for 1-wire control.
Sep 17 15:29:45 sniff systemd[1]: Starting Backend server for 1-wire
control...
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Failed with result
'protocol'.
Sep 17 15:29:45 sniff systemd[1]: Failed to start Backend server for 1-wire
control.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Service
RestartSec=100ms expired, scheduling restart.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Scheduled restart job,
restart counter is at 4.
Sep 17 15:29:45 sniff systemd[1]: Stopped Backend server for 1-wire control.
Sep 17 15:29:45 sniff systemd[1]: Starting Backend server for 1-wire
control...
Sep 17 15:29:45 sniff OWFS[7138]: DEFAULT: ow_daemon.c:(144) Entered
background mode, quitting.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Failed with result
'protocol'.
Sep 17 15:29:45 sniff systemd[1]: Failed to start Backend server for 1-wire
control.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Service
RestartSec=100ms expired, scheduling restart.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Scheduled restart job,
restart counter is at 5.
Sep 17 15:29:45 sniff systemd[1]: Stopped Backend server for 1-wire control.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Start request repeated
too quickly.
Sep 17 15:29:45 sniff systemd[1]: owserver.service: Failed with result
'protocol'.
Sep 17 15:29:45 sniff systemd[1]: Failed to start Backend server for 1-wire
control.

Thanks Mick for all your input!
Unfortunately, unless I missed something my problem is stubborn and
persists.

Any other ideas of figuring out what may cause this behaviour?
Thanks for all your inpus!

//Robert





On Tue, 17 Sep 2019 at 15:12, Mick Sulley <mi...@su...> wrote:

> In owfs.conf I have
>
> server: device=/dev/i2c-1
> rather than "server: i2c = /dev/i2c-1"  don't know if that is sigificant.
>
> What do you see with
>
> systemctl status owserver
>
> If that shows an error you could try
>
> sudo systemctl enable owserver
>
> or
>
> sudo systemctl restart owserver
>
> also look in /var/logs/syslog  there may be owserver messages in there
>
>
> On 17/09/2019 07:52, Robert Lagus wrote:
>
> I have a very similar problem.
> Rpi4 & Buster.
>
> After Micks emails, I did try to remove & purge my ow-shell and owserver,
> the only thing that starts is the fake sensors.
> I have not been able to access my sensors on my Buster install, I don't
> understand what's wrong and how I can get it working again.
>
> I did have a thunder strike that grilled my Raspberry Pi (3?) but the
> 1wire board and the RPI is brand new.
>
> Does anyone have any ideas how I can access my sensors again?
>
> *ls /dev/i2c**
> /dev/i2c-1
>
> *ofws.conf:*
> ! server: server = localhost:4304
> server: i2c = /dev/i2c-1
> http: port = 2121
> ftp: port = 2120
> server: port = localhost:4304
>
> *sudo /usr/bin/owserver -c /etc/owfs.conf --debug*
> DEBUG MODE
> libow version:
>         3.2p3
>   DEBUG: ow_daemon.c:(170) main thread id = 3069411056
> CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library
> isn't found
>    CALL: ow_parsename.c:(174) path=[]
>   DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock
> adapters)
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^$> compiled to 0xb6efd60c
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^all$> compiled to 0xb6efd62c
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^scan$> compiled to 0xb6efd64c
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^\*$> compiled to 0xb6efd66c
>   DEBUG: ow_regex.c:(24) Reg Ex expression
> <^[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}$>
> compiled to 0xb6efd68c
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^-?[[:digit:]]+$> compiled to
> 0xb6efd6ac
> ]*$> compiled to 0xb6efd6ccg Ex expression <^ *([^ ]+)[
> ]*$> compiled to 0xb6efd6ecg Ex expression <^ *([^ ]+) *: *([^ ]+)[
> ]*$> compiled to 0xb6efd70cg Ex expression <^ *([^ ]+) *: *([^ ]+) *: *([^
> ]+)[
>   DEBUG: ow_regex.c:(53) Not found
>   DEBUG: ow_regex.c:(53) Not found
>   DEBUG: ow_regex.c:(100) 0: 0->10 found <></dev/i2c-1><>
>   DEBUG: ow_regex.c:(100) 1: 0->10 found <></dev/i2c-1><>
>   DEBUG: ow_parse_address.c:(87) Text </dev/i2c-1>
>   DEBUG: ow_parse_address.c:(142) First </dev/i2c-1>
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 18
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 18 cannot be
> reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 19
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 19 cannot be
> reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1A
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1A cannot be
> reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1B
>   DEBUG: ow_ds2482.c:(516) ok
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1B cannot be
> reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1C
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1C cannot be
> reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1D
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1D cannot be
> reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1E
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1E cannot be
> reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1F
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1F cannot be
> reset. Not a DS2482.
>   DEBUG: ow_com_close.c:(42) Unimplemented!!!
> CONNECT: owlib.c:(145) Cannot detect an i2c DS2482-x00 on /dev/i2c-1
> DEFAULT: owlib.c:(52) No valid 1-wire buses found
>   DEBUG: ow_exit.c:(17) Exit code = 1
>    CALL: ow_lib_close.c:(21) Starting Library cleanup
>    CALL: ow_lib_stop.c:(22) Clear Cache
>   DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
>   DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
>   DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
>   DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
>    CALL: ow_lib_stop.c:(24) Closing input devices
>    CALL: ow_lib_stop.c:(26) Closing output devices
>    CALL: ow_lib_close.c:(42) Finished Library cleanup
>   DEBUG: ow_lib_close.c:(50) Libraries closed
>
> I'm able to see the i2c device:
> sudo i2cdetect -y 1
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> ....
>
> I had it working on my last install with a Rpi3 with this conf:
> (cropping commented lines)
>
> ! server: server = localhost:4304
> server: i2c = ALL:ALL
> http: port = 2121
> ftp: port = 2120
> server: port = localhost:4304
>
> Any ideas are welcome!
> Thanks!
>
> [image: Linkedin] <http://de.linkedin.com/in/rlagus> *Robert Lagus*
>
> +358 (0)40 662 44 99
>
> ro...@la...
>
>
>
> On Sun, 15 Sep 2019 at 21:08, Mick Sulley <mi...@su...> wrote:
>
>> Many thanks Colin.
>>
>> The log had many lines like
>>
>> Sep 15 18:01:27 pi-solar-old kernel: [ 3631.364529] w1_master_driver
>> w1_bus_master1: Attaching one wire slave 00.a20000000000 crc 13
>> Sep 15 18:01:27 pi-solar-old kernel: [ 3631.383280] w1_master_driver
>> w1_bus_master1: Family 0 for 00.a20000000000.13 is not registered.
>> After a bit of head scratching I looked at /etc/owfs.config and that did
>> not make much sense, so I deleted it and created a new one.  It is now
>> working!
>>
>> What I don't understand is how owfs.conf gets created in the first
>> place.  I uninstalled and purged owserver and ow-shell, but owfs.conf was
>> still there so I deleted it.  I then reinstalled but it didn't create
>> owfs.conf, don't understand why.
>>
>> Anyway, now I can get back to testing :)
>>
>> Mick
>>
>> On 15/09/2019 16:57, Colin Law wrote:
>>
>> Check in the owserver log (likely /var/log/syslog) to see if it is
>> showing errors.
>>
>> Colin
>>
>> On Sun, 15 Sep 2019, 12:08 Mick Sulley, <mi...@su...> wrote:
>>
>>> I am having trouble getting owfs to work on Raspbian Buster.  I have
>>> posted on the Pi forum
>>>
>>>
>>> https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
>>>
>>> Someone said they had the same problem but no suggestions to fix it, so
>>> I wonder if anyone here can give me a clue.
>>>
>>> I have just done a fresh install of Buster and updated. I ran
>>> raspi-config and enabled 1-wire and i2c.
>>> I have installed owserver ow-shell
>>> At first it worked, I could see devices with owdir, but it has stopped
>>> working, owdir returns nothing
>>> I have run "sudo systemctl enable owserver.service"
>>> but I see -
>>>
>>> pi@pi-solar-old:~ $ sudo systemctl status owserver.service
>>> ● owserver.service - Backend server for 1-wire control
>>>    Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor preset: enabled)
>>>    Active: failed (Result: protocol) since Fri 2019-09-13 21:47:16 BST; 48s ago
>>>      Docs: man:owserver(1)
>>>  Main PID: 493 (code=exited, status=0/SUCCESS)
>>>
>>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Service RestartSec=100ms expired, scheduling
>>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Scheduled restart job, restart counter is at
>>> Sep 13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for 1-wire control.
>>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Start request repeated too quickly.
>>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Failed with result 'protocol'.
>>> Sep 13 21:47:16 pi-solar-old systemd[1]: Failed to start Backend server for 1-wire control.
>>> pi@pi-solar-old:~ $
>>>
>>> I have tried disable, enable, restart for the service, I have removed
>>> and reinstalled owserver and ow-shell but nothing helps.
>>>
>>> Any ideas?
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>>
>>
>> _______________________________________________
>> Owfs-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
>
> _______________________________________________
> Owfs-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

Re: [Owfs-developers] owfs on Raspberry Buster

[Mick S. <mi...@su...>]

In owfs.conf I have

server: device=/dev/i2c-1
rather than "server: i2c = /dev/i2c-1"  don't know if that is sigificant.

What do you see with

systemctl status owserver

If that shows an error you could try

sudo systemctl enable owserver

or

sudo systemctl restart owserver

also look in /var/logs/syslog  there may be owserver messages in there


On 17/09/2019 07:52, Robert Lagus wrote:
> I have a very similar problem.
> Rpi4 & Buster.
>
> After Micks emails, I did try to remove & purge my ow-shell and 
> owserver, the only thing that starts is the fake sensors.
> I have not been able to access my sensors on my Buster install, I 
> don't understand what's wrong and how I can get it working again.
>
> I did have a thunder strike that grilled my Raspberry Pi (3?) but the 
> 1wire board and the RPI is brand new.
>
> Does anyone have any ideas how I can access my sensors again?
>
> *ls /dev/i2c**
> /dev/i2c-1
>
> *ofws.conf:*
> ! server: server = localhost:4304
> server: i2c = /dev/i2c-1
> http: port = 2121
> ftp: port = 2120
> server: port = localhost:4304
>
> *sudo /usr/bin/owserver -c /etc/owfs.conf --debug*
> DEBUG MODE
> libow version:
>         3.2p3
>   DEBUG: ow_daemon.c:(170) main thread id = 3069411056
> CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd 
> library isn't found
>    CALL: ow_parsename.c:(174) path=[]
>   DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock 
> adapters)
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^$> compiled to 0xb6efd60c
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^all$> compiled to 0xb6efd62c
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^scan$> compiled to 0xb6efd64c
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^\*$> compiled to 0xb6efd66c
>   DEBUG: ow_regex.c:(24) Reg Ex expression 
> <^[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}$> 
> compiled to 0xb6efd68c
>   DEBUG: ow_regex.c:(24) Reg Ex expression <^-?[[:digit:]]+$> compiled 
> to 0xb6efd6ac
> ]*$> compiled to 0xb6efd6ccg Ex expression <^ *([^ ]+)[
> ]*$> compiled to 0xb6efd6ecg Ex expression <^ *([^ ]+) *: *([^ ]+)[
> ]*$> compiled to 0xb6efd70cg Ex expression <^ *([^ ]+) *: *([^ ]+) *: 
> *([^ ]+)[
>   DEBUG: ow_regex.c:(53) Not found
>   DEBUG: ow_regex.c:(53) Not found
>   DEBUG: ow_regex.c:(100) 0: 0->10 found <></dev/i2c-1><>
>   DEBUG: ow_regex.c:(100) 1: 0->10 found <></dev/i2c-1><>
>   DEBUG: ow_parse_address.c:(87) Text </dev/i2c-1>
>   DEBUG: ow_parse_address.c:(142) First </dev/i2c-1>
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 18
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 18 cannot 
> be reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 19
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 19 cannot 
> be reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1A
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1A cannot 
> be reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1B
>   DEBUG: ow_ds2482.c:(516) ok
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1B cannot 
> be reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1C
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1C cannot 
> be reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1D
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1D cannot 
> be reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1E
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1E cannot 
> be reset. Not a DS2482.
> CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1F
> CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1F cannot 
> be reset. Not a DS2482.
>   DEBUG: ow_com_close.c:(42) Unimplemented!!!
> CONNECT: owlib.c:(145) Cannot detect an i2c DS2482-x00 on /dev/i2c-1
> DEFAULT: owlib.c:(52) No valid 1-wire buses found
>   DEBUG: ow_exit.c:(17) Exit code = 1
>    CALL: ow_lib_close.c:(21) Starting Library cleanup
>    CALL: ow_lib_stop.c:(22) Clear Cache
>   DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
>   DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
>   DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
>   DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
>    CALL: ow_lib_stop.c:(24) Closing input devices
>    CALL: ow_lib_stop.c:(26) Closing output devices
>    CALL: ow_lib_close.c:(42) Finished Library cleanup
>   DEBUG: ow_lib_close.c:(50) Libraries closed
>
> I'm able to see the i2c device:
> sudo i2cdetect -y 1
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> ....
>
> I had it working on my last install with a Rpi3 with this conf:
> (cropping commented lines)
>
> ! server: server = localhost:4304
> server: i2c = ALL:ALL
> http: port = 2121
> ftp: port = 2120
> server: port = localhost:4304
>
> Any ideas are welcome!
> Thanks!
> Linkedin <http://de.linkedin.com/in/rlagus> *Robert Lagus*
> +358 (0)40 662 44 99
> ro...@la...  <mailto:ro...@la...>
>
>
> On Sun, 15 Sep 2019 at 21:08, Mick Sulley <mi...@su... 
> <mailto:mi...@su...>> wrote:
>
>     Many thanks Colin.
>
>     The log had many lines like
>
>     Sep 15 18:01:27 pi-solar-old kernel: [ 3631.364529]
>     w1_master_driver w1_bus_master1: Attaching one wire slave
>     00.a20000000000 crc 13
>     Sep 15 18:01:27 pi-solar-old kernel: [ 3631.383280]
>     w1_master_driver w1_bus_master1: Family 0 for 00.a20000000000.13
>     is not registered.
>
>     After a bit of head scratching I looked at /etc/owfs.config and
>     that did not make much sense, so I deleted it and created a new
>     one.  It is now working!
>
>     What I don't understand is how owfs.conf gets created in the first
>     place.  I uninstalled and purged owserver and ow-shell, but
>     owfs.conf was still there so I deleted it. I then reinstalled but
>     it didn't create owfs.conf, don't understand why.
>
>     Anyway, now I can get back to testing :)
>
>     Mick
>
>     On 15/09/2019 16:57, Colin Law wrote:
>>     Check in the owserver log (likely /var/log/syslog) to see if it
>>     is showing errors.
>>
>>     Colin
>>
>>     On Sun, 15 Sep 2019, 12:08 Mick Sulley, <mi...@su...
>>     <mailto:mi...@su...>> wrote:
>>
>>         I am having trouble getting owfs to work on Raspbian Buster. 
>>         I have posted on the Pi forum
>>
>>         https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
>>
>>         Someone said they had the same problem but no suggestions to
>>         fix it, so I wonder if anyone here can give me a clue.
>>
>>         I have just done a fresh install of Buster and updated. I ran
>>         raspi-config and enabled 1-wire and i2c.
>>         I have installed owserver ow-shell
>>         At first it worked, I could see devices with owdir, but it
>>         has stopped working, owdir returns nothing
>>         I have run "sudo systemctl enable owserver.service"
>>         but I see -
>>
>>         |pi@pi-solar-old:~ $ sudo systemctl status owserver.service ●
>>         owserver.service - Backend server for 1-wire control Loaded:
>>         loaded (/lib/systemd/system/owserver.service; enabled; vendor
>>         preset: enabled) Active: failed (Result: protocol) since Fri
>>         2019-09-13 21:47:16 BST; 48s ago Docs: man:owserver(1) Main
>>         PID: 493 (code=exited, status=0/SUCCESS) Sep 13 21:47:16
>>         pi-solar-old systemd[1]: owserver.service: Service
>>         RestartSec=100ms expired, scheduling Sep 13 21:47:16
>>         pi-solar-old systemd[1]: owserver.service: Scheduled restart
>>         job, restart counter is at Sep 13 21:47:16 pi-solar-old
>>         systemd[1]: Stopped Backend server for 1-wire control. Sep 13
>>         21:47:16 pi-solar-old systemd[1]: owserver.service: Start
>>         request repeated too quickly. Sep 13 21:47:16 pi-solar-old
>>         systemd[1]: owserver.service: Failed with result 'protocol'.
>>         Sep 13 21:47:16 pi-solar-old systemd[1]: Failed to start
>>         Backend server for 1-wire control. pi@pi-solar-old:~ $ |||
>>
>>         |I have tried disable, enable, restart for the service, I
>>         have removed and reinstalled owserver and ow-shell but
>>         nothing helps.|
>>
>>         |Any ideas?
>>         |
>>
>>         _______________________________________________
>>         Owfs-developers mailing list
>>         Owf...@li...
>>         <mailto:Owf...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>>
>>     _______________________________________________
>>     Owfs-developers mailing list
>>     Owf...@li...  <mailto:Owf...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/owfs-developers
>     _______________________________________________
>     Owfs-developers mailing list
>     Owf...@li...
>     <mailto:Owf...@li...>
>     https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs on Raspberry Buster

[Robert L. <ro...@la...>]

I have a very similar problem.
Rpi4 & Buster.

After Micks emails, I did try to remove & purge my ow-shell and owserver,
the only thing that starts is the fake sensors.
I have not been able to access my sensors on my Buster install, I don't
understand what's wrong and how I can get it working again.

I did have a thunder strike that grilled my Raspberry Pi (3?) but the 1wire
board and the RPI is brand new.

Does anyone have any ideas how I can access my sensors again?

*ls /dev/i2c**
/dev/i2c-1

*ofws.conf:*
! server: server = localhost:4304
server: i2c = /dev/i2c-1
http: port = 2121
ftp: port = 2120
server: port = localhost:4304

*sudo /usr/bin/owserver -c /etc/owfs.conf --debug*
DEBUG MODE
libow version:
        3.2p3
  DEBUG: ow_daemon.c:(170) main thread id = 3069411056
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library
isn't found
   CALL: ow_parsename.c:(174) path=[]
  DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock
adapters)
  DEBUG: ow_regex.c:(24) Reg Ex expression <^$> compiled to 0xb6efd60c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^all$> compiled to 0xb6efd62c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^scan$> compiled to 0xb6efd64c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^\*$> compiled to 0xb6efd66c
  DEBUG: ow_regex.c:(24) Reg Ex expression
<^[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}$>
compiled to 0xb6efd68c
  DEBUG: ow_regex.c:(24) Reg Ex expression <^-?[[:digit:]]+$> compiled to
0xb6efd6ac
]*$> compiled to 0xb6efd6ccg Ex expression <^ *([^ ]+)[
]*$> compiled to 0xb6efd6ecg Ex expression <^ *([^ ]+) *: *([^ ]+)[
]*$> compiled to 0xb6efd70cg Ex expression <^ *([^ ]+) *: *([^ ]+) *: *([^
]+)[
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(100) 0: 0->10 found <></dev/i2c-1><>
  DEBUG: ow_regex.c:(100) 1: 0->10 found <></dev/i2c-1><>
  DEBUG: ow_parse_address.c:(87) Text </dev/i2c-1>
  DEBUG: ow_parse_address.c:(142) First </dev/i2c-1>
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 18
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 18 cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 19
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 19 cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1A
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1A cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1B
  DEBUG: ow_ds2482.c:(516) ok
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1B cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1C
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1C cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1D
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1D cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1E
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1E cannot be
reset. Not a DS2482.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1F
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1F cannot be
reset. Not a DS2482.
  DEBUG: ow_com_close.c:(42) Unimplemented!!!
CONNECT: owlib.c:(145) Cannot detect an i2c DS2482-x00 on /dev/i2c-1
DEFAULT: owlib.c:(52) No valid 1-wire buses found
  DEBUG: ow_exit.c:(17) Exit code = 1
   CALL: ow_lib_close.c:(21) Starting Library cleanup
   CALL: ow_lib_stop.c:(22) Clear Cache
  DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
  DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
  DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
  DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
   CALL: ow_lib_stop.c:(24) Closing input devices
   CALL: ow_lib_stop.c:(26) Closing output devices
   CALL: ow_lib_close.c:(42) Finished Library cleanup
  DEBUG: ow_lib_close.c:(50) Libraries closed

I'm able to see the i2c device:
sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
....

I had it working on my last install with a Rpi3 with this conf:
(cropping commented lines)

! server: server = localhost:4304
server: i2c = ALL:ALL
http: port = 2121
ftp: port = 2120
server: port = localhost:4304

Any ideas are welcome!
Thanks!

[image: Linkedin] <http://de.linkedin.com/in/rlagus> *Robert Lagus*

+358 (0)40 662 44 99

ro...@la...



On Sun, 15 Sep 2019 at 21:08, Mick Sulley <mi...@su...> wrote:

> Many thanks Colin.
>
> The log had many lines like
>
> Sep 15 18:01:27 pi-solar-old kernel: [ 3631.364529] w1_master_driver
> w1_bus_master1: Attaching one wire slave 00.a20000000000 crc 13
> Sep 15 18:01:27 pi-solar-old kernel: [ 3631.383280] w1_master_driver
> w1_bus_master1: Family 0 for 00.a20000000000.13 is not registered.
> After a bit of head scratching I looked at /etc/owfs.config and that did
> not make much sense, so I deleted it and created a new one.  It is now
> working!
>
> What I don't understand is how owfs.conf gets created in the first place.
> I uninstalled and purged owserver and ow-shell, but owfs.conf was still
> there so I deleted it.  I then reinstalled but it didn't create owfs.conf,
> don't understand why.
>
> Anyway, now I can get back to testing :)
>
> Mick
>
> On 15/09/2019 16:57, Colin Law wrote:
>
> Check in the owserver log (likely /var/log/syslog) to see if it is showing
> errors.
>
> Colin
>
> On Sun, 15 Sep 2019, 12:08 Mick Sulley, <mi...@su...> wrote:
>
>> I am having trouble getting owfs to work on Raspbian Buster.  I have
>> posted on the Pi forum
>>
>>
>> https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
>>
>> Someone said they had the same problem but no suggestions to fix it, so I
>> wonder if anyone here can give me a clue.
>>
>> I have just done a fresh install of Buster and updated. I ran
>> raspi-config and enabled 1-wire and i2c.
>> I have installed owserver ow-shell
>> At first it worked, I could see devices with owdir, but it has stopped
>> working, owdir returns nothing
>> I have run "sudo systemctl enable owserver.service"
>> but I see -
>>
>> pi@pi-solar-old:~ $ sudo systemctl status owserver.service
>> ● owserver.service - Backend server for 1-wire control
>>    Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor preset: enabled)
>>    Active: failed (Result: protocol) since Fri 2019-09-13 21:47:16 BST; 48s ago
>>      Docs: man:owserver(1)
>>  Main PID: 493 (code=exited, status=0/SUCCESS)
>>
>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Service RestartSec=100ms expired, scheduling
>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Scheduled restart job, restart counter is at
>> Sep 13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for 1-wire control.
>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Start request repeated too quickly.
>> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Failed with result 'protocol'.
>> Sep 13 21:47:16 pi-solar-old systemd[1]: Failed to start Backend server for 1-wire control.
>> pi@pi-solar-old:~ $
>>
>> I have tried disable, enable, restart for the service, I have removed and
>> reinstalled owserver and ow-shell but nothing helps.
>>
>> Any ideas?
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
>
> _______________________________________________
> Owfs-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

Re: [Owfs-developers] owfs on Raspberry Buster

[Mick S. <mi...@su...>]

Many thanks Colin.

The log had many lines like

Sep 15 18:01:27 pi-solar-old kernel: [ 3631.364529] w1_master_driver 
w1_bus_master1: Attaching one wire slave 00.a20000000000 crc 13
Sep 15 18:01:27 pi-solar-old kernel: [ 3631.383280] w1_master_driver 
w1_bus_master1: Family 0 for 00.a20000000000.13 is not registered.

After a bit of head scratching I looked at /etc/owfs.config and that did 
not make much sense, so I deleted it and created a new one.  It is now 
working!

What I don't understand is how owfs.conf gets created in the first 
place.  I uninstalled and purged owserver and ow-shell, but owfs.conf 
was still there so I deleted it.  I then reinstalled but it didn't 
create owfs.conf, don't understand why.

Anyway, now I can get back to testing :)

Mick

On 15/09/2019 16:57, Colin Law wrote:
> Check in the owserver log (likely /var/log/syslog) to see if it is 
> showing errors.
>
> Colin
>
> On Sun, 15 Sep 2019, 12:08 Mick Sulley, <mi...@su... 
> <mailto:mi...@su...>> wrote:
>
>     I am having trouble getting owfs to work on Raspbian Buster.  I
>     have posted on the Pi forum
>
>     https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
>
>     Someone said they had the same problem but no suggestions to fix
>     it, so I wonder if anyone here can give me a clue.
>
>     I have just done a fresh install of Buster and updated. I ran
>     raspi-config and enabled 1-wire and i2c.
>     I have installed owserver ow-shell
>     At first it worked, I could see devices with owdir, but it has
>     stopped working, owdir returns nothing
>     I have run "sudo systemctl enable owserver.service"
>     but I see -
>
>     |pi@pi-solar-old:~ $ sudo systemctl status owserver.service ●
>     owserver.service - Backend server for 1-wire control Loaded:
>     loaded (/lib/systemd/system/owserver.service; enabled; vendor
>     preset: enabled) Active: failed (Result: protocol) since Fri
>     2019-09-13 21:47:16 BST; 48s ago Docs: man:owserver(1) Main PID:
>     493 (code=exited, status=0/SUCCESS) Sep 13 21:47:16 pi-solar-old
>     systemd[1]: owserver.service: Service RestartSec=100ms expired,
>     scheduling Sep 13 21:47:16 pi-solar-old systemd[1]:
>     owserver.service: Scheduled restart job, restart counter is at Sep
>     13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for
>     1-wire control. Sep 13 21:47:16 pi-solar-old systemd[1]:
>     owserver.service: Start request repeated too quickly. Sep 13
>     21:47:16 pi-solar-old systemd[1]: owserver.service: Failed with
>     result 'protocol'. Sep 13 21:47:16 pi-solar-old systemd[1]: Failed
>     to start Backend server for 1-wire control. pi@pi-solar-old:~ $ |||
>
>     |I have tried disable, enable, restart for the service, I have
>     removed and reinstalled owserver and ow-shell but nothing helps.|
>
>     |Any ideas?
>     |
>
>     _______________________________________________
>     Owfs-developers mailing list
>     Owf...@li...
>     <mailto:Owf...@li...>
>     https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs on Raspberry Buster

[Colin L. <cl...@gm...>]

Check in the owserver log (likely /var/log/syslog) to see if it is showing
errors.

Colin

On Sun, 15 Sep 2019, 12:08 Mick Sulley, <mi...@su...> wrote:

> I am having trouble getting owfs to work on Raspbian Buster.  I have
> posted on the Pi forum
>
>
> https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228
>
> Someone said they had the same problem but no suggestions to fix it, so I
> wonder if anyone here can give me a clue.
>
> I have just done a fresh install of Buster and updated. I ran raspi-config
> and enabled 1-wire and i2c.
> I have installed owserver ow-shell
> At first it worked, I could see devices with owdir, but it has stopped
> working, owdir returns nothing
> I have run "sudo systemctl enable owserver.service"
> but I see -
>
> pi@pi-solar-old:~ $ sudo systemctl status owserver.service
> ● owserver.service - Backend server for 1-wire control
>    Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor preset: enabled)
>    Active: failed (Result: protocol) since Fri 2019-09-13 21:47:16 BST; 48s ago
>      Docs: man:owserver(1)
>  Main PID: 493 (code=exited, status=0/SUCCESS)
>
> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Service RestartSec=100ms expired, scheduling
> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Scheduled restart job, restart counter is at
> Sep 13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for 1-wire control.
> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Start request repeated too quickly.
> Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Failed with result 'protocol'.
> Sep 13 21:47:16 pi-solar-old systemd[1]: Failed to start Backend server for 1-wire control.
> pi@pi-solar-old:~ $
>
> I have tried disable, enable, restart for the service, I have removed and
> reinstalled owserver and ow-shell but nothing helps.
>
> Any ideas?
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

[Owfs-developers] owfs on Raspberry Buster

[Mick S. <mi...@su...>]

I am having trouble getting owfs to work on Raspbian Buster.  I have 
posted on the Pi forum

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=251702&p=1536228#p1536228

Someone said they had the same problem but no suggestions to fix it, so 
I wonder if anyone here can give me a clue.

I have just done a fresh install of Buster and updated. I ran 
raspi-config and enabled 1-wire and i2c.
I have installed owserver ow-shell
At first it worked, I could see devices with owdir, but it has stopped 
working, owdir returns nothing
I have run "sudo systemctl enable owserver.service"
but I see -

|pi@pi-solar-old:~ $ sudo systemctl status owserver.service ● 
owserver.service - Backend server for 1-wire control Loaded: loaded 
(/lib/systemd/system/owserver.service; enabled; vendor preset: enabled) 
Active: failed (Result: protocol) since Fri 2019-09-13 21:47:16 BST; 48s 
ago Docs: man:owserver(1) Main PID: 493 (code=exited, status=0/SUCCESS) 
Sep 13 21:47:16 pi-solar-old systemd[1]: owserver.service: Service 
RestartSec=100ms expired, scheduling Sep 13 21:47:16 pi-solar-old 
systemd[1]: owserver.service: Scheduled restart job, restart counter is 
at Sep 13 21:47:16 pi-solar-old systemd[1]: Stopped Backend server for 
1-wire control. Sep 13 21:47:16 pi-solar-old systemd[1]: 
owserver.service: Start request repeated too quickly. Sep 13 21:47:16 
pi-solar-old systemd[1]: owserver.service: Failed with result 
'protocol'. Sep 13 21:47:16 pi-solar-old systemd[1]: Failed to start 
Backend server for 1-wire control. pi@pi-solar-old:~ $ |||

|I have tried disable, enable, restart for the service, I have removed 
and reinstalled owserver and ow-shell but nothing helps.|

|Any ideas?
|