owfs-developers — Developer's list for OWFS

[Owfs-developers] Surplus Items

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

Greeting.  I have just had a very overdue tidy up and as a result I have 
some items which are surplus to requirements.

2 X Hobbyboards 8 channel I/O v2.0  (I have soft copy of the schematic 
and user manual)
2 X Maxim DS9097U-009   Universal 1-Wire COM Port Adapter (with id chip)
1 X Maxim DS9097U-S09   Universal 1-Wire COM Port Adapter (without id chip)
1 X Embedded Data Systems HA7E   ASCII 1-Wire Host Adapter
3 X Embedded Data Systems D2P    2 Channel Digital I/O 1-Wire Card 
(solder connections)
3 X Embedded Data Systems D2PC    2 Channel Digital I/O 1-Wire Card 
(screw terminals)

All are used but I believe that they are in working order.

I intend to put them all on eBay but thought I would offer them here 
first.  Anyone interested?

Mick

Re: [Owfs-developers] How to Use Simultaneous

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

OK that's clear.  Thanks Jan

On 24/03/2020 13:08, Jan Kandziora wrote:
> Am 24.03.20 um 11:03 schrieb Mick Sulley:
>> There have been times when using the owhttpd interface page to look at
>> the various temperatures I have seen 85 at some resolutions and
>> apparently valid values at other resolutions.
>>
> 85°C isn't an error value but the power-on value.
>
> If you get bogus 85°C readings, check the power to the sensors, and also
> the bus for shorts.
>
>
>> Does it therefore make
>> sense when reading values within my program to check for a valid read at
>> 12 bit (my normal resolution) and if it is not valid to then check for a
>> valid value at lower resolutions?
>>
>> I do set /simultaneous/temperature and sleep 1 sec at the start of the
>> loop,
>>
> Don't mix [/uncached]/<id>/temperature[X] and
> /simultaneous/temperature. Use the latter only in combination with
> [/uncached]/<id>/latesttemp
>
>
>> Will this increase the robustness of the system or is it just an added
>> complication for no real benefit?
>>
> Mixing both the single-target and the simultaneous method on the same
> bus has no benefit but a negative impact.
>
> The only reason to use the single-target method is when your sensors
> aren't powered.
>
> Kind regards
>
> 	Jan
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] How to Use Simultaneous

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

Am 24.03.20 um 11:03 schrieb Mick Sulley:
> There have been times when using the owhttpd interface page to look at
> the various temperatures I have seen 85 at some resolutions and
> apparently valid values at other resolutions.
>
85°C isn't an error value but the power-on value.

If you get bogus 85°C readings, check the power to the sensors, and also
the bus for shorts.


> Does it therefore make
> sense when reading values within my program to check for a valid read at
> 12 bit (my normal resolution) and if it is not valid to then check for a
> valid value at lower resolutions?
>
> I do set /simultaneous/temperature and sleep 1 sec at the start of the
> loop,
>
Don't mix [/uncached]/<id>/temperature[X] and
/simultaneous/temperature. Use the latter only in combination with
[/uncached]/<id>/latesttemp


> Will this increase the robustness of the system or is it just an added
> complication for no real benefit?
>
Mixing both the single-target and the simultaneous method on the same
bus has no benefit but a negative impact.

The only reason to use the single-target method is when your sensors
aren't powered.

Kind regards

	Jan

Re: [Owfs-developers] How to Use Simultaneous

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

There have been times when using the owhttpd interface page to look at 
the various temperatures I have seen 85 at some resolutions and 
apparently valid values at other resolutions. Does it therefore make 
sense when reading values within my program to check for a valid read at 
12 bit (my normal resolution) and if it is not valid to then check for a 
valid value at lower resolutions?

I do set /simultaneous/temperature and sleep 1 sec at the start of the 
loop, so I assume that to do additional reads I would need to read from 
uncached and there would be a 1sec delay for each read, but it should 
not happen very often.

Will this increase the robustness of the system or is it just an added 
complication for no real benefit?

Thanks

Mick

On 13/03/2020 21:53, Jan Kandziora wrote:
> Am 13.03.20 um 17:05 schrieb zei...@we...:
>> Hello Jan,
>> I'm sorry, you are right.
>> I do not use bash commands, I do read and write operations from a Python3
>> program. I do it step by step, as I'm not used to Python.
>> I had a version with uncached, but there was another program error and I forgot
>> adjusting the file path.
>> PATH = "/mnt/1wire/bus.0/"
>> *initiation of conversion:*
>>
>> while True:         # Hauptprogramm
>>       t1 = time()
>>       fw = open(PATH + "simultaneous" + "/temperature", "w")
>>       fw.write("1")
>>       fw.close()
>> *reading values:*
>>       for i in tempList:
>>           deviceFile = PATH + "uncached/" + temps[i] + "/latesttemp"
>>           f = open(deviceFile, "r")
>>           tempBuffer = float(f.read())
>>           f.close()
>>           if tempBuffer != 85.0:
>>               tempw[i] = tempBuffer
>>           print(temps[i], tempw[i])
>>       break
>> t2 = time()
>> print(t2 - t1)
>> However, now I wonder about very short conversion times, shorter than 700 ms a
>> single 12bit conversion shoul take.
>>
> Writing to /simultaneous/temperature does not wait for the end of
> conversion. You have to do this by hand in case you have nothing better
> to do in your program.
>
> Also, I recommend not to use the FUSE binding of OWFS, as it has
> unfixable race conditions. Use OWFS' owserver and pyownet instead.
>
>
>> Actually there is a problem when installing OWFS on Raspian Buster on PIs. File
>> system an sensors appear in duplicates. I give you a link to the forum of the
>> manufacturer of the used DS2482-100 adapter:
>> https://www.abelectronics.co.uk/forums/thread/303/owfs-duplicates
>>
> Honestly, no idea. May be a FUSE bug.
>
> It's best to forget about the FUSE binding at all.
>
> Kind regards
>
> 	Jan
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] How to Use Simultaneous

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

Am 13.03.20 um 17:05 schrieb zei...@we...:
> Hello Jan,
> I'm sorry, you are right.
> I do not use bash commands, I do read and write operations from a Python3
> program. I do it step by step, as I'm not used to Python.
> I had a version with uncached, but there was another program error and I forgot
> adjusting the file path.
> PATH = "/mnt/1wire/bus.0/"
> *initiation of conversion:*
>
> while True:         # Hauptprogramm
>      t1 = time()
>      fw = open(PATH + "simultaneous" + "/temperature", "w")
>      fw.write("1")
>      fw.close()
> *reading values:*
>      for i in tempList:
>          deviceFile = PATH + "uncached/" + temps[i] + "/latesttemp"
>          f = open(deviceFile, "r")
>          tempBuffer = float(f.read())
>          f.close()
>          if tempBuffer != 85.0:
>              tempw[i] = tempBuffer
>          print(temps[i], tempw[i])
>      break
> t2 = time()
> print(t2 - t1)
> However, now I wonder about very short conversion times, shorter than 700 ms a
> single 12bit conversion shoul take.
>
Writing to /simultaneous/temperature does not wait for the end of
conversion. You have to do this by hand in case you have nothing better
to do in your program.

Also, I recommend not to use the FUSE binding of OWFS, as it has
unfixable race conditions. Use OWFS' owserver and pyownet instead.


> Actually there is a problem when installing OWFS on Raspian Buster on PIs. File
> system an sensors appear in duplicates. I give you a link to the forum of the
> manufacturer of the used DS2482-100 adapter:
> https://www.abelectronics.co.uk/forums/thread/303/owfs-duplicates
>
Honestly, no idea. May be a FUSE bug.

It's best to forget about the FUSE binding at all.

Kind regards

	Jan

Re: [Owfs-developers] How to Use Simultaneous

[Martin P. <Mar...@GM...>]

You are most welcome Heimo.
I am not Stefano, I am Martin - sorry for the misunderstanding.

Stefano is the author of pyownet.

In my software I use python 2.7 and I have very consistent timing of
reading 25 sensors in a loop every 30 seconds.
Every second I read the status of two 8 bit I/O modules.

I do use pyownet and I am very happy with it.

The documentation of pyownet is pretty clean ;-)

https://pyownet.readthedocs.io/en/latest
<https://pyownet.readthedocs.io/en/latest/>


On 13.03.20 19:17, zei...@we... wrote:
> Thanks for the hint, Stephano!
>  
> I had a version with sleep(1) and varying values after fw.close. I
> got  execution times between 1.65 and 2.2 s for a run. Longest
> times at the first run.
>  
> But you address the Python problem. Python2 is outdated, no longer
> offically supported, but there are no libraries offically mentioned
> for Python3. On installation I tried sudo apt-get install  python3-ow.
> It worked without errors. But I did not find a documentation of the
> functions the library provides. For me, documentation is a mess. May
> be a generation problem.
> At the moment I'm happy with simple read an write operations in
> to files provided at /mnt/1wire and subdirectories.
>  
> Regards Heimo
>  
> *Gesendet:* Freitag, 13. März 2020 um 18:26 Uhr
> *Von:* "Martin Patzak" <Mar...@GM...>
> *An:* "OWFS (One-wire file system) discussion and help"
> <owf...@li...>, zei...@we...
> *Betreff:* Re: [Owfs-developers] How to Use Simultaneous
> Hello Heimo,
>
> after writing to "simultaneous" you have to wait one second.
>
> For Python I would recommend you the library *pyownet *by Stefano Miccoli:
>
>  
>
>     The official OWFS bindings are
>      
>     - OW.py, based on SWIG wrapping the C API of libow
>     - ownet.py, pure python owserver client
>      
>     you will find both in debian packages 
>      
>     - python-ow, https://packages.debian.org/buster/python-ow
>     - python-ownet, https://packages.debian.org/buster/python-ownet
>      
>     My advice is to avoid the use of these packages with python3
>     (although python3 versions exist in debian) since they are not
>     actively developed.
>      
>     I’m the author of pyownet, a different package, which does not
>     belong to the official OWFS code base. It is documented at
>     <https://pyownet.readthedocs.io/en/latest/> and is available only
>     on pypi.org <http://pypi.org> since, to my knowledge, it is not
>     packaged by any major linux distribution. 
>      
>     pyownet is actively mantained, and is perfectly compatible with
>     both python3 (up from 3.3) and legacy python2 (2.7 only). 
>      
>     So if you “import pyownet” in your code you have to “pip install
>     pyownet”. The discussion in this thread is whether it is a good
>     practice to “sudo pip install pyownet” along the python packages
>     distributed by debian. In my opinion you should avoid this, and
>     instead use a virtual environment, as I tried to explain in my
>     messages.
>      
>     Bye
>      
>     Stefano
>
>  
> On 13.03.20 17:05, zei...@we... wrote:
>
>     Hello Jan,
>      
>     I'm sorry, you are right.
>     I do not use bash commands, I do read and write operations from a
>     Python3 program. I do it step by step, as I'm not used to Python.
>     I had a version with uncached, but there was another program error
>     and I forgot adjusting the file path.
>      
>     PATH = "/mnt/1wire/bus.0/"
>      
>     *initiation of conversion:*
>
>     while True:         # Hauptprogramm
>         t1 = time()
>         fw = open(PATH + "simultaneous" + "/temperature", "w")
>         fw.write("1")
>         fw.close()
>      
>      
>     *reading values:*
>      
>         for i in tempList:
>             deviceFile = PATH + "uncached/" + temps[i] + "/latesttemp"
>             f = open(deviceFile, "r")
>             tempBuffer = float(f.read())
>             f.close()
>             if tempBuffer != 85.0:
>                 tempw[i] = tempBuffer
>             print(temps[i], tempw[i])
>         break
>     t2 = time()
>     print(t2 - t1)
>      
>     However, now I wonder about very short conversion times, shorter
>     than 700 ms a single 12bit conversion shoul take.
>      
>     1st run:
>      
>     28.0A651B2D1901 26.625
>     28.0A35192D1901 22.875
>     28.0CB479A20003 21.75
>     28.8BE0182D1901 28.875
>     28.80A7112D1901 29.5
>     28.629B082D1901 22.75
>     28.953D062D1901 22.875
>     28.613079A20003 22.25
>     28.CF52142D1901 22.8125
>
>     1.3515775203704834   sec
>      
>     following runs
>      
>     >>> %Run TempLesen.py
>     28.0A651B2D1901 22.9375
>     28.0A35192D1901 22.9375
>     28.0CB479A20003 21.75
>     28.8BE0182D1901 23.125
>     28.80A7112D1901 23.125
>     28.629B082D1901 22.75
>     28.953D062D1901 22.875
>     28.613079A20003 22.25
>     28.CF52142D1901 22.875
>
>     0.6546370983123779   sec
>      
>     no matter whether Thonny or Bash.
>      
>     Is there a Python3 library for RaspberryPi
>      
>     Actually there is a problem when installing OWFS on Raspian Buster
>     on PIs. File system an sensors appear in duplicates. I give you a
>     link to the forum of the manufacturer of the used DS2482-100 adapter: 
>      
>     https://www.abelectronics.co.uk/forums/thread/303/owfs-duplicates
>      
>     Regards
>     H. Wissing
>      
>      
>      
>     Dr. med. habil. Dipl.- Ing. Heimo Wissing
>     Privatdozent, Arzt für Anästhesiologie,
>     Intensivmedizin und Schmerztherapie
>     Bioingenieur / Biomedizinische Technik
>     Neckarweg 1, 69118 Heidelberg
>     Tel.: 06221/801679 FAX: 06221/803738
>     mobil: 0171/4571292
>      
>      
>     *Gesendet:* Freitag, 13. März 2020 um 15:48 Uhr
>     *Von:* "Jan Kandziora" <jj...@gm...>
>     *An:* owf...@li...
>     *Betreff:* Re: [Owfs-developers] How to Use Simultaneous
>     Am 13.03.20 um 15:12 schrieb hwissing:
>     > Hello,
>     >
>     > I think one issue from the primary question is not answered..
>     >
>     > /" If I read from '/temperature' then I get them read in much faster
>     > *but I don't get a fresh conversion each time."*/
>     >
>     This is a very old question, and the mechanism has changed a bit
>     since 2008.
>
>
>
>     >
>     > I have the same issue. First conversion with 8 DS18B20 sensors takes
>     > about 1 sec, immediately following requests take about 40 ms, but
>     > values are not updated. It takes a while till updated values are
>     > acquired, then conversion takes longer.
>     >
>     That is because you read /<ID>/temperature instead of
>     /uncached/<ID>/temperature
>
>     But don't do this either. If you want simultaneos conversions, do
>     instead
>
>     $ owwrite /simultaneous/temperature 1
>     $ sleep 1s
>     $ owread /uncached/<sensor0id>/latesttemp
>     $ owread /uncached/<sensor1id>/latesttemp
>     $ owread /uncached/<sensor2id>/latesttemp
>     $ owread /uncached/<sensor3id>/latesttemp
>     $ owread /uncached/<sensor4id>/latesttemp
>     $ owread /uncached/<sensor5id>/latesttemp
>     $ owread /uncached/<sensor6id>/latesttemp
>     $ owread /uncached/<sensor7id>/latesttemp
>
>     Latesttemp has the resolution of the previous non-simultaneous
>     conversion, or, after power-up of the sensor, the resolution set
>     in the
>     sensor's EEPROM. You can adjust the through /<ID>/tempres.
>
>     See the manpage: https://github.com/owfs/owfs-doc/wiki/DS18B20
>
>     Kind regards
>
>     Jan
>
>
>     _______________________________________________
>     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] How to Use Simultaneous

[Martin P. <Mar...@GM...>]

Hello Heimo,

after writing to "simultaneous" you have to wait one second.

For Python I would recommend you the library *pyownet *by Stefano Miccoli:


> The official OWFS bindings are
>
> - OW.py, based on SWIG wrapping the C API of libow
> - ownet.py, pure python owserver client
>
> you will find both in debian packages 
>
> - python-ow, https://packages.debian.org/buster/python-ow
> - python-ownet, https://packages.debian.org/buster/python-ownet
>
> My advice is to avoid the use of these packages with python3 (although
> python3 versions exist in debian) since they are not actively developed.
>
> I’m the author of pyownet, a different package, which does not belong
> to the official OWFS code base. It is documented at
> <https://pyownet.readthedocs.io/en/latest/> and is available only
> on pypi.org <http://pypi.org> since, to my knowledge, it is not
> packaged by any major linux distribution. 
>
> pyownet is actively mantained, and is perfectly compatible with both
> python3 (up from 3.3) and legacy python2 (2.7 only). 
>
> So if you “import pyownet” in your code you have to “pip install
> pyownet”. The discussion in this thread is whether it is a good
> practice to “sudo pip install pyownet” along the python packages
> distributed by debian. In my opinion you should avoid this, and
> instead use a virtual environment, as I tried to explain in my messages.
>
> Bye
>
> Stefano


On 13.03.20 17:05, zei...@we... wrote:
> Hello Jan,
>  
> I'm sorry, you are right.
> I do not use bash commands, I do read and write operations from a
> Python3 program. I do it step by step, as I'm not used to Python.
> I had a version with uncached, but there was another program error and
> I forgot adjusting the file path.
>  
> PATH = "/mnt/1wire/bus.0/"
>  
> *initiation of conversion:*
>
> while True:         # Hauptprogramm
>     t1 = time()
>     fw = open(PATH + "simultaneous" + "/temperature", "w")
>     fw.write("1")
>     fw.close()
>  
>  
> *reading values:*
>  
>     for i in tempList:
>         deviceFile = PATH + "uncached/" + temps[i] + "/latesttemp"
>         f = open(deviceFile, "r")
>         tempBuffer = float(f.read())
>         f.close()
>         if tempBuffer != 85.0:
>             tempw[i] = tempBuffer
>         print(temps[i], tempw[i])
>     break
> t2 = time()
> print(t2 - t1)
>  
> However, now I wonder about very short conversion times, shorter than
> 700 ms a single 12bit conversion shoul take.
>  
> 1st run:
>  
> 28.0A651B2D1901 26.625
> 28.0A35192D1901 22.875
> 28.0CB479A20003 21.75
> 28.8BE0182D1901 28.875
> 28.80A7112D1901 29.5
> 28.629B082D1901 22.75
> 28.953D062D1901 22.875
> 28.613079A20003 22.25
> 28.CF52142D1901 22.8125
>
> 1.3515775203704834   sec
>  
> following runs
>  
> >>> %Run TempLesen.py
> 28.0A651B2D1901 22.9375
> 28.0A35192D1901 22.9375
> 28.0CB479A20003 21.75
> 28.8BE0182D1901 23.125
> 28.80A7112D1901 23.125
> 28.629B082D1901 22.75
> 28.953D062D1901 22.875
> 28.613079A20003 22.25
> 28.CF52142D1901 22.875
>
> 0.6546370983123779   sec
>  
> no matter whether Thonny or Bash.
>  
> Is there a Python3 library for RaspberryPi
>  
> Actually there is a problem when installing OWFS on Raspian Buster on
> PIs. File system an sensors appear in duplicates. I give you a link to
> the forum of the manufacturer of the used DS2482-100 adapter: 
>  
> https://www.abelectronics.co.uk/forums/thread/303/owfs-duplicates
>  
> Regards
> H. Wissing
>  
>  
>  
> Dr. med. habil. Dipl.- Ing. Heimo Wissing
> Privatdozent, Arzt für Anästhesiologie,
> Intensivmedizin und Schmerztherapie
> Bioingenieur / Biomedizinische Technik
> Neckarweg 1, 69118 Heidelberg
> Tel.: 06221/801679 FAX: 06221/803738
> mobil: 0171/4571292
>  
>  
> *Gesendet:* Freitag, 13. März 2020 um 15:48 Uhr
> *Von:* "Jan Kandziora" <jj...@gm...>
> *An:* owf...@li...
> *Betreff:* Re: [Owfs-developers] How to Use Simultaneous
> Am 13.03.20 um 15:12 schrieb hwissing:
> > Hello,
> >
> > I think one issue from the primary question is not answered..
> >
> > /" If I read from '/temperature' then I get them read in much faster
> > *but I don't get a fresh conversion each time."*/
> >
> This is a very old question, and the mechanism has changed a bit since
> 2008.
>
>
>
> >
> > I have the same issue. First conversion with 8 DS18B20 sensors takes
> > about 1 sec, immediately following requests take about 40 ms, but
> > values are not updated. It takes a while till updated values are
> > acquired, then conversion takes longer.
> >
> That is because you read /<ID>/temperature instead of
> /uncached/<ID>/temperature
>
> But don't do this either. If you want simultaneos conversions, do instead
>
> $ owwrite /simultaneous/temperature 1
> $ sleep 1s
> $ owread /uncached/<sensor0id>/latesttemp
> $ owread /uncached/<sensor1id>/latesttemp
> $ owread /uncached/<sensor2id>/latesttemp
> $ owread /uncached/<sensor3id>/latesttemp
> $ owread /uncached/<sensor4id>/latesttemp
> $ owread /uncached/<sensor5id>/latesttemp
> $ owread /uncached/<sensor6id>/latesttemp
> $ owread /uncached/<sensor7id>/latesttemp
>
> Latesttemp has the resolution of the previous non-simultaneous
> conversion, or, after power-up of the sensor, the resolution set in the
> sensor's EEPROM. You can adjust the through /<ID>/tempres.
>
> See the manpage: https://github.com/owfs/owfs-doc/wiki/DS18B20
>
> Kind regards
>
> Jan
>
>
> _______________________________________________
> 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] How to Use Simultaneous

[<zei...@we...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hello Jan,</div>

<div>&nbsp;</div>

<div>I&#39;m sorry, you are right.</div>

<div>I do not use bash commands, I do read and write operations from a Python3 program. I do it step by step, as I&#39;m not used to Python.</div>

<div>I had a version with uncached, but there was another program error and I forgot adjusting the file path.</div>

<div>&nbsp;</div>

<div>
<div>PATH = &quot;/mnt/1wire/bus.0/&quot;</div>

<div>&nbsp;</div>

<div><strong>initiation of conversion:</strong></div>

<div><br/>
while True: &nbsp; &nbsp; &nbsp; &nbsp; # Hauptprogramm<br/>
&nbsp; &nbsp; t1 = time()<br/>
&nbsp; &nbsp; fw = open(PATH + &quot;simultaneous&quot; + &quot;/temperature&quot;, &quot;w&quot;)<br/>
&nbsp; &nbsp; fw.write(&quot;1&quot;)<br/>
&nbsp; &nbsp; fw.close()</div>
</div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div><strong>reading values:</strong></div>

<div>&nbsp;</div>

<div>&nbsp; &nbsp; for i in tempList:<br/>
&nbsp; &nbsp; &nbsp; &nbsp; deviceFile = PATH + &quot;uncached/&quot; + temps[i] + &quot;/latesttemp&quot;<br/>
&nbsp; &nbsp; &nbsp; &nbsp; f = open(deviceFile, &quot;r&quot;)<br/>
&nbsp; &nbsp; &nbsp; &nbsp; tempBuffer = float(f.read())<br/>
&nbsp; &nbsp; &nbsp; &nbsp; f.close()<br/>
&nbsp; &nbsp; &nbsp; &nbsp; if tempBuffer != 85.0:<br/>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tempw[i] = tempBuffer<br/>
&nbsp; &nbsp; &nbsp; &nbsp; print(temps[i], tempw[i])<br/>
&nbsp; &nbsp; break<br/>
t2 = time()<br/>
print(t2 - t1)</div>

<div>&nbsp;</div>

<div>However, now I wonder about very short conversion times, shorter than 700 ms a single 12bit conversion shoul take.</div>

<div>&nbsp;</div>

<div>1st run:</div>

<div>&nbsp;</div>

<div>28.0A651B2D1901 26.625<br/>
28.0A35192D1901 22.875<br/>
28.0CB479A20003 21.75<br/>
28.8BE0182D1901 28.875<br/>
28.80A7112D1901 29.5<br/>
28.629B082D1901 22.75<br/>
28.953D062D1901 22.875<br/>
28.613079A20003 22.25<br/>
28.CF52142D1901 22.8125</div>

<div><br/>
1.3515775203704834&nbsp; &nbsp;sec</div>

<div>&nbsp;</div>

<div>following runs</div>

<div>&nbsp;</div>

<div>&gt;&gt;&gt; %Run TempLesen.py<br/>
28.0A651B2D1901 22.9375<br/>
28.0A35192D1901 22.9375<br/>
28.0CB479A20003 21.75<br/>
28.8BE0182D1901 23.125<br/>
28.80A7112D1901 23.125<br/>
28.629B082D1901 22.75<br/>
28.953D062D1901 22.875<br/>
28.613079A20003 22.25<br/>
28.CF52142D1901 22.875</div>

<div><br/>
0.6546370983123779&nbsp; &nbsp;sec</div>

<div>&nbsp;</div>

<div>no matter whether Thonny or Bash.</div>

<div>&nbsp;</div>

<div>Is there a Python3 library for RaspberryPi</div>

<div>&nbsp;</div>

<div>Actually there is a problem when installing OWFS on Raspian Buster on PIs. File system an sensors appear in duplicates. I give you a link to the forum of the manufacturer of the used DS2482-100 adapter:&nbsp;</div>

<div>&nbsp;</div>

<div><a href="https://www.abelectronics.co.uk/forums/thread/303/owfs-duplicates">https://www.abelectronics.co.uk/forums/thread/303/owfs-duplicates</a></div>

<div>&nbsp;</div>

<div>Regards</div>

<div>H. Wissing</div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div class="signature">Dr. med. habil. Dipl.- Ing. Heimo Wissing<br/>
Privatdozent, Arzt f&uuml;r An&auml;sthesiologie,<br/>
Intensivmedizin und Schmerztherapie<br/>
Bioingenieur / Biomedizinische Technik<br/>
Neckarweg 1, 69118 Heidelberg<br/>
Tel.: 06221/801679 FAX: 06221/803738<br/>
mobil: 0171/4571292</div>

<div>&nbsp;
<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Freitag, 13. M&auml;rz 2020 um 15:48 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Jan Kandziora&quot; &lt;jj...@gm...&gt;<br/>
<b>An:</b>&nbsp;owf...@li...<br/>
<b>Betreff:</b>&nbsp;Re: [Owfs-developers] How to Use Simultaneous</div>

<div name="quoted-content">Am 13.03.20 um 15:12 schrieb hwissing:<br/>
&gt; Hello,<br/>
&gt;<br/>
&gt; I think one issue from the primary question is not answered..<br/>
&gt;<br/>
&gt; /&quot; If I read from &#39;/temperature&#39; then I get them read in much faster<br/>
&gt; *but I don&#39;t get a fresh conversion each time.&quot;*/<br/>
&gt;<br/>
This is a very old question, and the mechanism has changed a bit since 2008.<br/>
<br/>
<br/>
<br/>
&gt;<br/>
&gt; I have the same issue. First conversion with 8 DS18B20 sensors takes<br/>
&gt; about 1 sec, immediately following requests take about 40 ms, but<br/>
&gt; values are not updated. It takes a while till updated values are<br/>
&gt; acquired, then conversion takes longer.<br/>
&gt;<br/>
That is because you read /&lt;ID&gt;/temperature instead of<br/>
/uncached/&lt;ID&gt;/temperature<br/>
<br/>
But don&#39;t do this either. If you want simultaneos conversions, do instead<br/>
<br/>
&#36; owwrite /simultaneous/temperature 1<br/>
&#36; sleep 1s<br/>
&#36; owread /uncached/&lt;sensor0id&gt;/latesttemp<br/>
&#36; owread /uncached/&lt;sensor1id&gt;/latesttemp<br/>
&#36; owread /uncached/&lt;sensor2id&gt;/latesttemp<br/>
&#36; owread /uncached/&lt;sensor3id&gt;/latesttemp<br/>
&#36; owread /uncached/&lt;sensor4id&gt;/latesttemp<br/>
&#36; owread /uncached/&lt;sensor5id&gt;/latesttemp<br/>
&#36; owread /uncached/&lt;sensor6id&gt;/latesttemp<br/>
&#36; owread /uncached/&lt;sensor7id&gt;/latesttemp<br/>
<br/>
Latesttemp has the resolution of the previous non-simultaneous<br/>
conversion, or, after power-up of the sensor, the resolution set in the<br/>
sensor&#39;s EEPROM. You can adjust the through /&lt;ID&gt;/tempres.<br/>
<br/>
See the manpage: <a href="https://github.com/owfs/owfs-doc/wiki/DS18B20" target="_blank">https://github.com/owfs/owfs-doc/wiki/DS18B20</a><br/>
<br/>
Kind regards<br/>
<br/>
Jan<br/>
<br/>
<br/>
_______________________________________________<br/>
Owfs-developers mailing list<br/>
Owf...@li...<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/owfs-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/owfs-developers</a></div>
</div>
</div>
</div></div></body></html>

Re: [Owfs-developers] How to Use Simultaneous

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

Am 13.03.20 um 15:12 schrieb hwissing:
> Hello,
>
> I think one issue from the primary question is not answered..
>
> /" If I read from '/temperature' then I get them read in much faster
> *but I don't get a fresh conversion each time."*/
>
This is a very old question, and the mechanism has changed a bit since 2008.



>
> I have the same issue. First conversion with 8 DS18B20 sensors takes
> about 1 sec, immediately following requests take about 40 ms, but
> values are not updated. It takes a while till  updated values are
> acquired, then conversion takes longer.
>
That is because you read /<ID>/temperature instead of
/uncached/<ID>/temperature

But don't do this either. If you want simultaneos conversions, do instead

$ owwrite /simultaneous/temperature 1
$ sleep 1s
$ owread /uncached/<sensor0id>/latesttemp
$ owread /uncached/<sensor1id>/latesttemp
$ owread /uncached/<sensor2id>/latesttemp
$ owread /uncached/<sensor3id>/latesttemp
$ owread /uncached/<sensor4id>/latesttemp
$ owread /uncached/<sensor5id>/latesttemp
$ owread /uncached/<sensor6id>/latesttemp
$ owread /uncached/<sensor7id>/latesttemp

Latesttemp has the resolution of the previous non-simultaneous
conversion, or, after power-up of the sensor, the resolution set in the
sensor's EEPROM. You can adjust the through /<ID>/tempres.

See the manpage: https://github.com/owfs/owfs-doc/wiki/DS18B20

Kind regards

	Jan

Re: [Owfs-developers] How to Use Simultaneous

[hwissing <zei...@we...>]

Hello, 

I think one issue from the primary question is not answered..

/" If I read from '/temperature' then I get them read in much faster *but I
don't get a fresh conversion each time."*/


I have the same issue. First conversion with 8 DS18B20 sensors takes about 1
sec, immediately following requests take about 40 ms, but values are not
updated. It takes a while till  updated values are acquired, then conversion
takes longer.

Is there a lock-out time for initiating "simultaneous"? 
I'm only interested in a working file system, not an file server. I stopped
owhttpd.

Regards
H. Wissing




--
Sent from: http://owfs-developers.1086194.n5.nabble.com/

Re: [Owfs-developers] pyownet question

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

Hi Stefano,

Thanks for your reply, I have saved a copy of your notes for future 
reference.  I fixed my problem, or rather problems, I had messed up the 
link to my alias file and also lost power to my adaptor, and the 
combination of the two had me struggling all day.

All fixed and working again now :)

Mick

On 10/11/2019 18:46, Stefano Miccoli via Owfs-developers wrote:
> Strange situation: pyownet is talking to an owserver, all the 
> handshakes go well, but owserver replies with error code 5.
>
> A few handy commands to debug the problem.
>
> 1) identify the process with which pyownet is speaking
>
> from python:
> >>> from pyownet.protocol import proxy
> >>> owp = proxy(host="localhost")
> >>> print(owp)
> owserver at ('127.0.0.1', 4304)
>
> from the shell:
> *$*sudo ss -lpt '( sport = :4304 )'
> State       Recv-Q           Send-Q                     Local 
> Address:Port                      Peer Address:Port
> LISTEN       0                128 0.0.0.0:4304                         
>   0.0.0.0:*     users:(("owserver",pid=318,fd=13))
>
> 2) enable verbose logging
>
> from python:
> >>> owp.verbose = True
> >>> owp.dir('/nonexistent')
> ('127.0.0.1', 59204) -> ('127.0.0.1', 4304)
> -> _ToServerHeader(version=0, payload=13, type=9, flags=0, 
> size=0, offset=0)
> .. b'/nonexistent\x00'
> <- _FromServerHeader(version=0, payload=0, ret=-1, flags=0, 
> size=0, offset=0)
> ('127.0.0.1', 59204) xx ('127.0.0.1', 4304)
> ('127.0.0.1', 59204) XX ('127.0.0.1', 4304)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File 
> "/tmp/pyownet/lib/python3.7/site-packages/pyownet/protocol.py", line 
> 600, in dir
>     raise OwnetError(-ret, self.errmess[-ret], path)
> pyownet.protocol.OwnetError: [Errno 1] Startup - command line 
> parameters invalid: '/nonexistent'
>
> (here I demonstrate how my owserver replies with error code 1 to the 
> attempt of listing a nonexistent node)
> from owserver
>
> from owserver:
> $ sudo systemctl stop owserver
> $ sudo /usr/bin/owserver —debug <your device here>
>
> … lots of debug messages …
>
> DEBUG: from_client.c:(65) FromClient payload=13 size=0 type=9 sg=0x0 
> offset=0
>   DEBUG: from_client.c:(73) FromClient (no servermessage) payload=13 
> size=0 type=9 controlflags=0x0 offset=0
>   DEBUG: ow_tcp_read.c:(63) attempt 13 bytes Time: 10.000000 seconds
>   DEBUG: ow_tcp_read.c:(113) read: 13 - 0 = 13
>   DEBUG: handler.c:(152) START handler /nonexistent
>    CALL: data.c:(103) DataHandler: parse path=/nonexistent
>   DEBUG: ow_parseobject.c:(163) /nonexistent
>    CALL: ow_parsename.c:(174) path=[/nonexistent]
>   DEBUG: ow_regex.c:(53) Not found
>   DEBUG: ow_regex.c:(53) Not found
>   DEBUG: ow_cache.c:(1643) Lookup of nonexistent unsuccessful
>   DEBUG: ow_cache.c:(1601) Finding nonexistent unsuccessful
>   DEBUG: ow_remote_alias.c:(179) Remote alias for /nonexistent not found
>   DEBUG: ow_parsename.c:(234) Set error to 27 <Path - bad path syntax>
>   DEBUG: ow_parsename.c:(133) /nonexistent
>   DEBUG: data.c:(106) DataHandler: OWQ_create failed cm.ret=-1
>   DEBUG: data.c:(207) DataHandler: cm.ret=-1
>   DEBUG: to_client.c:(75) payload=0 size=0, ret=-1, sg=0x0 offset=0
>   DEBUG: to_client.c:(84) No data
>   DEBUG: data.c:(226) Finished with client request
>   DEBUG: handler.c:(134) OWSERVER handler done
>   DEBUG: ow_net_server.c:(259) Normal completion.
>
> Please note here that you can correlate the outgoing packet from pyownet,
>
> -> _ToServerHeader(version=0, payload=13, type=9, flags=0, 
> size=0,offset=0)
> .. b'/nonexistent\x00’
>
> with the incoming packet in owserver, and its subsequent preocessing:
>   DEBUG: from_client.c:(65) FromClient payload=13 size=0 type=9 sg=0x0 
> offset=0
> and the subsequent processing,
>   DEBUG: handler.c:(152) START handler /nonexistent
> which end with error code -1
>   DEBUG: data.c:(207) DataHandler: cm.ret=-1
>
> Similarly you can correlate the outgoing owserver packet to the 
> incoming owserver packet
>   DEBUG: to_client.c:(75) payload=0 size=0, ret=-1, sg=0x0 offset=0
>   DEBUG: to_client.c:(84) No data
> <- _FromServerHeader(version=0, payload=0, ret=-1, flags=0, 
> size=0,offset=0)
>
> 3) try the obivous things: a mix of restart/reboot/voodo magic to see 
> if the problem disappears ;-)
>
>
> By comparing the verbose pyownet log with the owserver one you should 
> be able to pinpoint the problem.
>
> Good luck!
>
> Stefano
>
>> On 9 Nov 2019, at 15:44, Mick Sulley <mi...@su... 
>> <mailto:mi...@su...>> wrote:
>>
>> I am using pyownet on a few Raspberry Pi systems, but one has stopped 
>> working.  I have updated the OS, removed and reinstalled pyownet and 
>> it still fails.  This is what I see -
>>
>> pi@pi3ether:~ $ python3
>> Python 3.7.3 (default, Apr  3 2019, 05:39:12)
>> [GCC 8.2.0] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> from pyownet.protocol import proxy
>> >>> owp = proxy(host='localhost')
>> >>> owp.dir()
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "/usr/local/lib/python3.7/dist-packages/pyownet/protocol.py", 
>> line 600, in dir
>>     raise OwnetError(-ret, self.errmess[-ret], path)
>> pyownet.protocol.OwnetError: [Errno 5] legacy - IO error: '/'
>> >>>
>>
>> If I run owdir from command line I get the sensor listing as 
>> expected.  I have tried with python 2.7 as well with the same 
>> result.  Running the above on another Pi works as expected.
>>
>> I could reinstall Raspbian and start again, but I would like to 
>> understand what has gone wrong.  Any ideas?
>>
>> 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] pyownet question

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

Strange situation: pyownet is talking to an owserver, all the handshakes go well, but owserver replies with error code 5.

A few handy commands to debug the problem.

1) identify the process with which pyownet is speaking

from python:
>>> from pyownet.protocol import proxy
>>> owp = proxy(host="localhost")
>>> print(owp)
owserver at ('127.0.0.1', 4304)

from the shell:
$ sudo ss -lpt '( sport = :4304 )'
State            Recv-Q           Send-Q                     Local Address:Port                      Peer Address:Port           
LISTEN           0                128                              0.0.0.0:4304                           0.0.0.0:*               users:(("owserver",pid=318,fd=13))

2) enable verbose logging

from python:
>>> owp.verbose = True
>>> owp.dir('/nonexistent')
('127.0.0.1', 59204) -> ('127.0.0.1', 4304)
-> _ToServerHeader(version=0, payload=13, type=9, flags=0, size=0, offset=0)
.. b'/nonexistent\x00'
<- _FromServerHeader(version=0, payload=0, ret=-1, flags=0, size=0, offset=0)
('127.0.0.1', 59204) xx ('127.0.0.1', 4304)
('127.0.0.1', 59204) XX ('127.0.0.1', 4304)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/pyownet/lib/python3.7/site-packages/pyownet/protocol.py", line 600, in dir
    raise OwnetError(-ret, self.errmess[-ret], path)
pyownet.protocol.OwnetError: [Errno 1] Startup - command line parameters invalid: '/nonexistent'

(here I demonstrate how my owserver replies with error code 1 to the attempt of listing a nonexistent node)
from owserver 

from owserver:
$ sudo systemctl stop owserver
$ sudo /usr/bin/owserver —debug <your device here>

… lots of debug messages …

  DEBUG: from_client.c:(65) FromClient payload=13 size=0 type=9 sg=0x0 offset=0
  DEBUG: from_client.c:(73) FromClient (no servermessage) payload=13 size=0 type=9 controlflags=0x0 offset=0
  DEBUG: ow_tcp_read.c:(63) attempt 13 bytes Time: 10.000000 seconds
  DEBUG: ow_tcp_read.c:(113) read: 13 - 0 = 13
  DEBUG: handler.c:(152) START handler /nonexistent
   CALL: data.c:(103) DataHandler: parse path=/nonexistent
  DEBUG: ow_parseobject.c:(163) /nonexistent
   CALL: ow_parsename.c:(174) path=[/nonexistent]
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_regex.c:(53) Not found
  DEBUG: ow_cache.c:(1643) Lookup of nonexistent unsuccessful
  DEBUG: ow_cache.c:(1601) Finding nonexistent unsuccessful
  DEBUG: ow_remote_alias.c:(179) Remote alias for /nonexistent not found
  DEBUG: ow_parsename.c:(234) Set error to 27 <Path - bad path syntax>
  DEBUG: ow_parsename.c:(133) /nonexistent
  DEBUG: data.c:(106) DataHandler: OWQ_create failed cm.ret=-1
  DEBUG: data.c:(207) DataHandler: cm.ret=-1
  DEBUG: to_client.c:(75) payload=0 size=0, ret=-1, sg=0x0 offset=0 
  DEBUG: to_client.c:(84) No data
  DEBUG: data.c:(226) Finished with client request
  DEBUG: handler.c:(134) OWSERVER handler done
  DEBUG: ow_net_server.c:(259) Normal completion.

Please note here that you can correlate the outgoing packet from pyownet, 

-> _ToServerHeader(version=0, payload=13, type=9, flags=0, size=0, offset=0)
.. b'/nonexistent\x00’

with the incoming packet in owserver, and its subsequent preocessing:
  DEBUG: from_client.c:(65) FromClient payload=13 size=0 type=9 sg=0x0 offset=0
and the subsequent processing, 
  DEBUG: handler.c:(152) START handler /nonexistent
which end with error code -1
  DEBUG: data.c:(207) DataHandler: cm.ret=-1

Similarly you can correlate the outgoing owserver packet to the incoming owserver packet
  DEBUG: to_client.c:(75) payload=0 size=0, ret=-1, sg=0x0 offset=0 
  DEBUG: to_client.c:(84) No data
<- _FromServerHeader(version=0, payload=0, ret=-1, flags=0, size=0, offset=0)

3) try the obivous things: a mix of restart/reboot/voodo magic to see if the problem disappears ;-)


By comparing the verbose pyownet log with the owserver one you should be able to pinpoint the problem.

Good luck!

Stefano

> On 9 Nov 2019, at 15:44, Mick Sulley <mi...@su...> wrote:
> 
> I am using pyownet on a few Raspberry Pi systems, but one has stopped working.  I have updated the OS, removed and reinstalled pyownet and it still fails.  This is what I see -
> 
> pi@pi3ether:~ $ python3
> Python 3.7.3 (default, Apr  3 2019, 05:39:12)
> [GCC 8.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from pyownet.protocol import proxy
> >>> owp = proxy(host='localhost')
> >>> owp.dir()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/local/lib/python3.7/dist-packages/pyownet/protocol.py", line 600, in dir
>     raise OwnetError(-ret, self.errmess[-ret], path)
> pyownet.protocol.OwnetError: [Errno 5] legacy - IO error: '/'
> >>>
> 
> If I run owdir from command line I get the sensor listing as expected.  I have tried with python 2.7 as well with the same result.  Running the above on another Pi works as expected.
> 
> I could reinstall Raspbian and start again, but I would like to understand what has gone wrong.  Any ideas?
> 
> Thanks
> 
> Mick
> 
> 
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] pyownet question

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

I am using pyownet on a few Raspberry Pi systems, but one has stopped 
working.  I have updated the OS, removed and reinstalled pyownet and it 
still fails.  This is what I see -

pi@pi3ether:~ $ python3
Python 3.7.3 (default, Apr  3 2019, 05:39:12)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
 >>> from pyownet.protocol import proxy
 >>> owp = proxy(host='localhost')
 >>> owp.dir()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/local/lib/python3.7/dist-packages/pyownet/protocol.py", 
line 600, in dir
     raise OwnetError(-ret, self.errmess[-ret], path)
pyownet.protocol.OwnetError: [Errno 5] legacy - IO error: '/'
 >>>

If I run owdir from command line I get the sensor listing as expected.  
I have tried with python 2.7 as well with the same result.  Running the 
above on another Pi works as expected.

I could reinstall Raspbian and start again, but I would like to 
understand what has gone wrong.  Any ideas?

Thanks

Mick

Re: [Owfs-developers] Installing pyownet

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

Hi Stefano,

Thanks for the reply and thank you for developing pyownet and making it 
available.  I have been using it for many years now.

I have always been confused over the use of sudo when installing 
packages, my approach has generally been to not use sudo and see if it 
all works as expected, if it doesn't then try installing with sudo.

The current system I am working on runs on a Raspberry Pi and has 2 
programs, one which sets up the config for owfs alias file, log files 
etc and needs to by run with sudo, but only needs to be run when I have 
changed setup somehow, the other can run as a normal user and runs 
permanently.

I have read through you explanation of installing in a virtual 
environment and I have a few practical concerns.  First I am not sure my 
Linux and/or python skills are up to it.  Second as there will only ever 
be one user on this system I don't think is offers great benefits.  
Third I will only be installing the one package, pyownet, with sudo, so 
I don't think there are any serious security risks.

Thanks for your help

Mick

On 28/10/2019 21:57, Stefano Miccoli via Owfs-developers wrote:
> There is little bit of confusion.
>
> The official OWFS bindings are
>
> - OW.py, based on SWIG wrapping the C API of libow
> - ownet.py, pure python owserver client
>
> you will find both in debian packages
>
> - python-ow, https://packages.debian.org/buster/python-ow
> - python-ownet, https://packages.debian.org/buster/python-ownet
>
> My advice is to avoid the use of these packages with python3 (although 
> python3 versions exist in debian) since they are not actively developed.
>
> I’m the author of pyownet, a different package, which does not belong 
> to the official OWFS code base. It is documented at 
> <https://pyownet.readthedocs.io/en/latest/> and is available only on 
> pypi.org <http://pypi.org> since, to my knowledge, it is not packaged 
> by any major linux distribution.
>
> pyownet is actively mantained, and is perfectly compatible with both 
> python3 (up from 3.3) and legacy python2 (2.7 only).
>
> So if you “import pyownet” in your code you have to “pip install 
> pyownet”. The discussion in this thread is whether it is a good 
> practice to “sudo pip install pyownet” along the python packages 
> distributed by debian. In my opinion you should avoid this, and 
> instead use a virtual environment, as I tried to explain in my messages.
>
> Bye
>
> Stefano
>
>
>> On 28 Oct 2019, at 00:34, Mick Sulley <mi...@su... 
>> <mailto:mi...@su...>> wrote:
>>
>> But that webpage says -
>>
>> To install pyownet:
>>
>> $ pip install pyownet
>>
>>
>>
>> On 27/10/2019 17:09, Martin Patzak wrote:
>>> No, pyownet is not part of ownet.
>>>
>>> Type "man ownet"
>>>
>>> pyownet has to be installed through pypi
>>>
>>> maybe you find more info here:
>>> https://github.com/miccoli/pyownet
>>>
>>>
>>> On 27.10.19 14:54, Mick Sulley wrote:
>>>> I am confused.  pyownet seems to be working with Python3 for me if 
>>>> I install it as
>>>>
>>>> sudo pip3 install pyownet
>>>>
>>>> that is unless there are some features of it that I have not used.  
>>>> Is pyownet included within python3-ownet, or have i misunderstood 
>>>> that?
>>>>
>>>> Also on the pypi site https://pypi.org/project/pyownet/ it says 
>>>> that Python3 is fully supported and to install it use  'pip install 
>>>> pyownet'
>>>>
>>>> I have looked for asyncowfs and cannot find it anywhere.  Can you 
>>>> point me to a web page please?
>>>>
>>>> Thanks
>>>>
>>>> Mick
>>>>
>>>> On 27/10/2019 10:26, Matthias Urlichs via Owfs-developers wrote:
>>>>> Hi,
>>>>>> Debian: "sudo apt install python3-ownet" (or the GUI equivalent).
>>>>> Having just done that …
>>>>>
>>>>> (a) the module is named "ownet" not "pyownet"
>>>>>
>>>>> (b) This module doesn't work with python3. Like, at all. I have 
>>>>> created
>>>>> https://github.com/owfs/owfs/pull/44 to (barely) fix that, and I 
>>>>> sent a
>>>>> bug report to Debian which should eventually show up on
>>>>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=python3-ownet .
>>>>>
>>>>> Personally I use asyncowfs …
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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] Installing pyownet

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

There is little bit of confusion.

The official OWFS bindings are

- OW.py, based on SWIG wrapping the C API of libow
- ownet.py, pure python owserver client

you will find both in debian packages 

- python-ow, https://packages.debian.org/buster/python-ow <https://packages.debian.org/buster/python-ow>
- python-ownet, https://packages.debian.org/buster/python-ownet <https://packages.debian.org/buster/python-ownet>

My advice is to avoid the use of these packages with python3 (although python3 versions exist in debian) since they are not actively developed.

I’m the author of pyownet, a different package, which does not belong to the official OWFS code base. It is documented at <https://pyownet.readthedocs.io/en/latest/ <https://pyownet.readthedocs.io/en/latest/>> and is available only on pypi.org <http://pypi.org/> since, to my knowledge, it is not packaged by any major linux distribution. 

pyownet is actively mantained, and is perfectly compatible with both python3 (up from 3.3) and legacy python2 (2.7 only). 

So if you “import pyownet” in your code you have to “pip install pyownet”. The discussion in this thread is whether it is a good practice to “sudo pip install pyownet” along the python packages distributed by debian. In my opinion you should avoid this, and instead use a virtual environment, as I tried to explain in my messages.

Bye

Stefano


> On 28 Oct 2019, at 00:34, Mick Sulley <mi...@su...> wrote:
> 
> But that webpage says -
> 
> To install pyownet:
> 
> $ pip install pyownet
> 
> 
> 
> On 27/10/2019 17:09, Martin Patzak wrote:
>> No, pyownet is not part of ownet.
>> 
>> Type "man ownet" 
>> 
>> pyownet has to be installed through pypi
>> 
>> maybe you find more info here:
>> https://github.com/miccoli/pyownet <https://github.com/miccoli/pyownet>
>> 
>> 
>> On 27.10.19 14:54, Mick Sulley wrote:
>>> I am confused.  pyownet seems to be working with Python3 for me if I install it as 
>>> 
>>> sudo pip3 install pyownet 
>>> 
>>> that is unless there are some features of it that I have not used.  Is pyownet included within python3-ownet, or have i misunderstood that? 
>>> 
>>> Also on the pypi site https://pypi.org/project/pyownet/ <https://pypi.org/project/pyownet/>  it says that Python3 is fully supported and to install it use          'pip install pyownet' 
>>> 
>>> I have looked for asyncowfs and cannot find it anywhere.  Can you point me to a web page please? 
>>> 
>>> Thanks 
>>> 
>>> Mick 
>>> 
>>> On 27/10/2019 10:26, Matthias Urlichs via Owfs-developers wrote: 
>>>> Hi, 
>>>>> Debian: "sudo apt install python3-ownet" (or the GUI equivalent). 
>>>> Having just done that … 
>>>> 
>>>> (a) the module is named "ownet" not "pyownet" 
>>>> 
>>>> (b) This module doesn't work with python3. Like, at all. I have created 
>>>> https://github.com/owfs/owfs/pull/44 <https://github.com/owfs/owfs/pull/44> to (barely) fix that, and I sent a 
>>>> bug report to Debian which should eventually show up on 
>>>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=python3-ownet <https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=python3-ownet> . 
>>>> 
>>>> Personally I use asyncowfs … 
>>>> 
>>> 
>>> 
>>> _______________________________________________ 
>>> 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] Installing pyownet

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

But that webpage says -

To install pyownet:

$ pip install pyownet



On 27/10/2019 17:09, Martin Patzak wrote:
> No, pyownet is not part of ownet.
>
> Type "man ownet"
>
> pyownet has to be installed through pypi
>
> maybe you find more info here:
> https://github.com/miccoli/pyownet
>
>
> On 27.10.19 14:54, Mick Sulley wrote:
>> I am confused.  pyownet seems to be working with Python3 for me if I 
>> install it as
>>
>> sudo pip3 install pyownet
>>
>> that is unless there are some features of it that I have not used.  
>> Is pyownet included within python3-ownet, or have i misunderstood that?
>>
>> Also on the pypi site https://pypi.org/project/pyownet/ it says that 
>> Python3 is fully supported and to install it use 'pip install pyownet'
>>
>> I have looked for asyncowfs and cannot find it anywhere.  Can you 
>> point me to a web page please?
>>
>> Thanks
>>
>> Mick
>>
>> On 27/10/2019 10:26, Matthias Urlichs via Owfs-developers wrote:
>>> Hi,
>>>> Debian: "sudo apt install python3-ownet" (or the GUI equivalent).
>>> Having just done that …
>>>
>>> (a) the module is named "ownet" not "pyownet"
>>>
>>> (b) This module doesn't work with python3. Like, at all. I have created
>>> https://github.com/owfs/owfs/pull/44 to (barely) fix that, and I sent a
>>> bug report to Debian which should eventually show up on
>>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=python3-ownet .
>>>
>>> Personally I use asyncowfs …
>>>
>>
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

Re: [Owfs-developers] Installing pyownet

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

I am confused.  pyownet seems to be working with Python3 for me if I 
install it as

sudo pip3 install pyownet

that is unless there are some features of it that I have not used.  Is 
pyownet included within python3-ownet, or have i misunderstood that?

Also on the pypi site https://pypi.org/project/pyownet/  it says that 
Python3 is fully supported and to install it use  'pip install pyownet'

I have looked for asyncowfs and cannot find it anywhere.  Can you point 
me to a web page please?

Thanks

Mick

On 27/10/2019 10:26, Matthias Urlichs via Owfs-developers wrote:
> Hi,
>> Debian: "sudo apt install python3-ownet" (or the GUI equivalent).
> Having just done that …
>
> (a) the module is named "ownet" not "pyownet"
>
> (b) This module doesn't work with python3. Like, at all. I have created
> https://github.com/owfs/owfs/pull/44 to (barely) fix that, and I sent a
> bug report to Debian which should eventually show up on
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=python3-ownet .
>
> Personally I use asyncowfs …
>

Re: [Owfs-developers] Installing pyownet

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

Hi,
> Debian: "sudo apt install python3-ownet" (or the GUI equivalent). 

Having just done that …

(a) the module is named "ownet" not "pyownet"

(b) This module doesn't work with python3. Like, at all. I have created
https://github.com/owfs/owfs/pull/44 to (barely) fix that, and I sent a
bug report to Debian which should eventually show up on
https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=python3-ownet .

Personally I use asyncowfs …

-- 
-- Matthias Urlichs

Re: [Owfs-developers] Installing pyownet

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

pyownet is only on pypi, not on debian: you have to use the virtualenv method.

S.

> On 27 Oct 2019, at 01:01, Mick Sulley <mi...@su...> wrote:
> 
> I have a problem with that.  I removed pyownet with
> 
>     sudo pip3 uninstall pyownet
> 
> then I reinstalled with
> 
>     sudo apt install pyownet
> 
> but that gave me
> 
>     E: Unable to locate package pyownet
> 
> so I ran
> 
>     sudo apt install python3-ownet
> 
> which seemed to complete OK, but when I run my code it fails with
> 
>     ModuleNotFoundError: No module named 'pyownet'
> 
> am I missing something here?
> 
> 
> On 26/10/2019 15:24, Matthias Urlichs via Owfs-developers wrote:
>> On 26.10.19 12:53, Mick Sulley wrote:
>>> Question - is it good practice to always install packages like this as
>>> root?
>> On Linux, best practice is to not use "pip" if the distribution already
>> has a package for whatever you need. Debian: "sudo apt install
>> python3-ownet" (or the GUI equivalent).
>> 
> 
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Installing pyownet

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

I have a problem with that.  I removed pyownet with

     sudo pip3 uninstall pyownet

then I reinstalled with

     sudo apt install pyownet

but that gave me

     E: Unable to locate package pyownet

so I ran

     sudo apt install python3-ownet

which seemed to complete OK, but when I run my code it fails with

     ModuleNotFoundError: No module named 'pyownet'

am I missing something here?


On 26/10/2019 15:24, Matthias Urlichs via Owfs-developers wrote:
> On 26.10.19 12:53, Mick Sulley wrote:
>> Question - is it good practice to always install packages like this as
>> root?
> On Linux, best practice is to not use "pip" if the distribution already
> has a package for whatever you need. Debian: "sudo apt install
> python3-ownet" (or the GUI equivalent).
>

Re: [Owfs-developers] Installing pyownet

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

Best practice is to isolate packages downloaded from pypi <https://pypi.org> in a virtual environment, and do not mess with the system wide python installation.

As a general rule always avoid “sudo pip install”, and only install system wide python packages via the distribution package manager (apt for debian, pacman for archlinux, yum and dnf for rpm based distros, etc.).

Of course the number of wonderful python packages on pypi <https://pypi.org> is amazing, so soon or later you will need some python package which is not available in your distro. Moreover sometimes different packages have conflicting requirements, hence the necessity of isolated virtual environments, explained in 
<https://docs.python.org/3/library/venv.html>
<https://packaging.python.org/tutorials/installing-packages/#creating-virtual-environments>

So you should (python == python3 below)

$ python -m venv /opt/XXX
$ source /opt/XXX/bin/activate
$ pip install yyy

Now every user wishing to use the XXX virtual env should simply

$ source /opt/XXX/bin/activate
$ python
>>> import yyy

One question remains open: should you run "python -m venv /opt/XXX” and the subsequent commands as root, or not? Here the matter become complex, as is security is under all Unix systems.

Oversimplifying you have two options. If you blindly trust every package in pypi you can 

$ sudo python -m venv /opt/XXX
$ source /opt/XXX/bin/activate
$ sudo pip install yyy

or if you are a little paranoid (like myself) you should create a user (say Mousebender) just for managing the virtual environments:

$ sudo mkdir /opt/XXX
$ sudo chown Mousebender /opt/XXX
$ sudo -u Mousebender python -m venv /opt/XXX
$ source /opt/XXX/bin/activate
$ sudo -u Mousebender pip install yyy

(There are also other more advanced options, like building with a non privileged user a set of python wheels and installing them as root, but I will not discuss them here.)

I’m not aware of any harmful package on pypi, and I know for sure that most people simply do “sudo pip install” in a virtual environment, but you should be aware that a python source package installation can execute arbitrary code, and that it is usually a bad idea to run foreign code as root, without a security audit first.


Regards,

Stefano

> On 26 Oct 2019, at 12:53, Mick Sulley <mi...@su...> wrote:
> 
> I have just discovered that if I install pyownet with
> 
> pip3 install pyownet
> 
> it works fine for programs that I run under my user, but if I run something with sudo I get
> 
> ModuleNotFoundError: No module named 'pyownet'
> 
> I can overcome this by installing as root with
> 
> sudo pip3 install pyownet
> 
> 
> Question - is it good practice to always install packages like this as root?
> 
> Thanks
> 
> Mick
> 
> 
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Installing pyownet

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

On 26.10.19 12:53, Mick Sulley wrote:
> Question - is it good practice to always install packages like this as
> root? 

On Linux, best practice is to not use "pip" if the distribution already
has a package for whatever you need. Debian: "sudo apt install
python3-ownet" (or the GUI equivalent).

-- 
-- Matthias Urlichs

[Owfs-developers] Installing pyownet

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

I have just discovered that if I install pyownet with

pip3 install pyownet

it works fine for programs that I run under my user, but if I run 
something with sudo I get

ModuleNotFoundError: No module named 'pyownet'

I can overcome this by installing as root with

sudo pip3 install pyownet


Question - is it good practice to always install packages like this as root?

Thanks

Mick

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

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

Thanks for your help on this Stefano.  I will add the null terminator 
when writing strings, but I have also restructured my code so it will 
only happen rarely, so should not be a problem anyway.


On 14/10/2019 21:21, Stefano Miccoli via Owfs-developers wrote:
> There is for sure something broken in the owserver, and it can be very 
> dangerous from a strict security point of view (buffer overflows and 
> so on). However I think that most owserver instances are run in 
> private networks so this should not be a major concern.
>
> For now I would advise you to add a null terminator when you are 
> writing “string” data to owserver (something like the alias name) and 
> let us know if the problem resurfaces again.
>
> The commit in which Paul added the possibility of non null terminated 
> strings on the owserver payload is
> https://github.com/owfs/owfs/commit/379f4e926
> (but let me stress again that it is only my guess that your problem is 
> linked to the null terminator, maybe it is something completely 
> different.)
>
> S.
>
>
>> On 14 Oct 2019, at 00:46, Mick Sulley <mi...@su... 
>> <mailto:mi...@su...>> wrote:
>>
>> 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
>>>
>> _______________________________________________
>> 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...>]

There is for sure something broken in the owserver, and it can be very dangerous from a strict security point of view (buffer overflows and so on). However I think that most owserver instances are run in private networks so this should not be a major concern. 

For now I would advise you to add a null terminator when you are writing “string” data to owserver (something like the alias name) and let us know if the problem resurfaces again.

The commit in which Paul added the possibility of non null terminated strings on the owserver payload is
https://github.com/owfs/owfs/commit/379f4e926 <https://github.com/owfs/owfs/commit/379f4e926>
(but let me stress again that it is only my guess that your problem is linked to the null terminator, maybe it is something completely different.)

S.


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