[Owfs-developers] Surplus Devices

[Mick Sulley]

Hi People,

I have some bits that are of no further use to me and wonder if they may 
be of use to anyone else.


Qty 1 Embedded Data Systems HA7E serial to 1-wire adapter

Qty 2 DS9097U Dallas Maxim Universal 1-Wire COM Port Adapter

Qty 3 Hobby-boards 8 channel I/O Board

All believed to be in working order.  I am in the UK.  Anyone interested?

Cheers

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] How to find 1-wire device names?

[Mick Sulley]

If you have ow-shell installed then owdir should show all the devices on 
the network


Mick

On 08/05/2022 13:11, Chris Green wrote:

I seem to have lost a couple of 1-wire devices, they were working a
while ago but now don't seem to be appearing.  I've tried re-running
owfs but that has done no good.

Is there some sort of debugging mode available and/or a way to list
devices on the 1-wire bus?




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] owfs and BitBang

[Mick Sulley]

I have just set up a Pi zero with a temp sensor following this -

https://www.circuitbasics.com/raspberry-pi-ds18b20-temperature-sensor-tutorial/

It works OK but I am wondering if I can use the owfs modules with this?  
If so what do I set as the server in /etc/owfs.conf


I don't see anything in the docs

Thanks

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Write data with Python3 and pyownet

[Mick Sulley]

Thanks Stefano, that looks much better.

On 14/10/2020 15:13, Stefano Miccoli via Owfs-developers wrote:

A more succinct way would be:

str(x).encode()

In fact the outer call to ‘bytes’ in 'bytes(str.encode(str(x)))' is a 
no-op, and python strings are objects which have an ‘encode' method, 
so no need call the class method ’str.encode’.


Another possible way is

f"{x:d}".encode()

or

"{:d}".format(x).encode()

which is more “defensive”, in the sense that the conversion fails if x 
is not an integer. In fact “str(x)” is defined for almost any 
imaginable object in python, and could return anything. Therefore it 
is better to be a little more verbose, and be explicit on the fact 
that here we are interested in a decimal integer.


Another variant, in which we accept a float value could be

f"{round(x):d}".encode()

or

f"{x:.0f}"

but possibilities are endless.

Bye and thank you for sharing.


Stefano


On 14 Oct 2020, at 15:08, Mick Sulley <mailto:m...@sulley.info>> wrote:


I had a bit of trouble with this and thought it worth sharing the 
solution.


With Python2 and pyownet I could use

    owp.write('/settings/timeout/directory', 60)

but with Python3 that throws an error, TypeError: 'data' argument 
must be binary.  I can use


    owp.write('/settings/timeout/directory', b'60')

but if I want to use a variable for the data the format which works is -

    x = 60
    owp.write('/settings/timeout/directory', bytes(str.encode(str(x

There may be other ways to do it but that works for me.

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Write data with Python3 and pyownet

[Mick Sulley]

I had a bit of trouble with this and thought it worth sharing the solution.

With Python2 and pyownet I could use

    owp.write('/settings/timeout/directory', 60)

but with Python3 that throws an error, TypeError: 'data' argument must 
be binary.  I can use


    owp.write('/settings/timeout/directory', b'60')

but if I want to use a variable for the data the format which works is -

    x = 60
    owp.write('/settings/timeout/directory', bytes(str.encode(str(x

There may be other ways to do it but that works for me.

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Reading latesttemp

[Mick Sulley]

Just looked at it again and all sensors are now reading correctly, so I 
am wondering if there was a bad connection somewhere.  As they are all 
working I will try to see if I can recreate the problem, but not sure I 
will be able to.  I'll get back to you if I discover anything further.


Thanks

Mick

On 08/10/2020 19:47, Mick Sulley wrote:
This is a test setup, all sensors are in a breadboard on the bench, 
power is from a Meanwell unit set to 5.1 volts, which is what I 
measure at the sensors.  So I am pretty confident it is not a wiring 
or power supply problem.


Is there any way to determine if the simultaneous command is getting 
to all of the chips?


I am pretty confident that if I power cycle it all the problem will go 
away and I won't be able to recreate it, so I am trying to investigate 
as much as I can while the situation exists.


Thanks

Mick

On 08/10/2020 17:27, Jan Kandziora wrote:

Am 08.10.20 um 15:07 schrieb Mick Sulley:
But owwrite /simultaneous/temperature 1 should trigger a conversion? 
and

reading latesttemp should then be correct.  Here is another. Latesttemp
returns 85 even after owwrite /simultaneous/temperature 1, but read
temperature12 and it works again.  I don't understand why!


Most likely it's a problem with power. Do you power each chip
separately, or do they all pull, from the same +5V line?



I have a few more in this state at the moment, I am sure I could fix
them all with a single temperature12 read to each and they would 
then be

fine, but I would really like to understand what the problem is


You could try to find out if the simultaneous command is not going
through to all chips (chips never read 85°C on latesttemp) or if you
still get those spurious resets.

But it's only a debugging tool. In a production setup, it would only
ever mask the underlying problem and return a wrong ages-old temperature
instead.


Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Reading latesttemp

[Mick Sulley]

This is a test setup, all sensors are in a breadboard on the bench, 
power is from a Meanwell unit set to 5.1 volts, which is what I measure 
at the sensors.  So I am pretty confident it is not a wiring or power 
supply problem.


Is there any way to determine if the simultaneous command is getting to 
all of the chips?


I am pretty confident that if I power cycle it all the problem will go 
away and I won't be able to recreate it, so I am trying to investigate 
as much as I can while the situation exists.


Thanks

Mick

On 08/10/2020 17:27, Jan Kandziora wrote:

Am 08.10.20 um 15:07 schrieb Mick Sulley:

But owwrite /simultaneous/temperature 1 should trigger a conversion? and
reading latesttemp should then be correct.  Here is another.  Latesttemp
returns 85 even after owwrite /simultaneous/temperature 1, but read
temperature12 and it works again.  I don't understand why!


Most likely it's a problem with power. Do you power each chip
separately, or do they all pull, from the same +5V line?



I have a few more in this state at the moment, I am sure I could fix
them all with a single temperature12 read to each and they would then be
fine, but I would really like to understand what the problem is


You could try to find out if the simultaneous command is not going
through to all chips (chips never read 85°C on latesttemp) or if you
still get those spurious resets.

But it's only a debugging tool. In a production setup, it would only
ever mask the underlying problem and return a wrong ages-old temperature
instead.


Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Reading latesttemp

[Mick Sulley]

On 08/10/2020 12:26, Jan Kandziora wrote:

Am 08.10.20 um 00:31 schrieb Mick Sulley:

On my test system I have 20 DS18B20 temperature sensors (all powered) to
test out various things.  I am setting /simultaneous/temperature waiting
2 seconds then reading latesttemp from all of them.

I have just noticed that several are giving 85 reads. If I look with
owhttpd this is what I see -

owhttpd screen

Also owread /uncached/DHW_Mid_Btm/latesttemp returns 85.  This is after
many cycles of simultaneous/voltage and latesttemp reads.


Reading /uncached//latesttemp reads the contents of the temperature
register from the chip.

It never triggers a temperature conversion.


But owwrite /simultaneous/temperature 1 should trigger a conversion? and 
reading latesttemp should then be correct.  Here is another.  Latesttemp 
returns 85 even after owwrite /simultaneous/temperature 1, but read 
temperature12 and it works again.  I don't understand why!


pi@pi4b:~ $ owread /DHW_Top/latesttemp
  85pi@pi4b:~ $ owread /DHW_Top/latesttemp
  85
pi@pi4b:~ $ owwrite /simultaneous/temperature 1
pi@pi4b:~ $ owread /DHW_Top/latesttemp
  85pi@pi4b:~ $ owread /DHW_Top/latesttemp
  85pi@pi4b:~ $
pi@pi4b:~ $ owread /DHW_Top/temperature12
 13.5625pi@pi4b:~ $ owread /DHW_Top/latesttemp
 13.5625pi@pi4b:~ $
pi@pi4b:~ $

I have a few more in this state at the moment, I am sure I could fix 
them all with a single temperature12 read to each and they would then be 
fine, but I would really like to understand what the problem is




If you read 85°C from latesttemp, it means the latest conversion either
85°C (unlikely) or the chip has been power-cycled since the latest
conversion (likely). As 85°C is the power-on value of that register.



It seems to me that it is a useful safeguard to run a single
temperature12 read on each sensor during the initialisation of the
system.  I cannot see any downside to this but just thought I would ask
for your thoughts.


That doesn't make any sense as you will read back the value from that
initial conversion again and again if your simultaneous trigger isn't
working. You mask the error that way, which is likely not what you want.

If a sensor reports a spurious 85°C, treat that as a power-cycle on that
sensor – check your hardware!

Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Reading latesttemp

[Mick Sulley]

On my test system I have 20 DS18B20 temperature sensors (all powered) to 
test out various things.  I am setting /simultaneous/temperature waiting 
2 seconds then reading latesttemp from all of them.


I have just noticed that several are giving 85 reads. If I look with 
owhttpd this is what I see -


owhttpd screen

Also owread /uncached/DHW_Mid_Btm/latesttemp returns 85.  This is after 
many cycles of simultaneous/voltage and latesttemp reads.


However if I run owread /uncached/DHW_Mid_Btm/temperature12 it returns 
13.4375.  If I then owread /uncached/DHW_Mid_Btm/latesttemp it also 
returns 13.4375 and after that it seems to work as expected.  So it 
seems that reading temperature12 resets it.


I can't reproduce this, as I say, once a temperature12 read resets it it 
works fine.


It seems to me that it is a useful safeguard to run a single 
temperature12 read on each sensor during the initialisation of the 
system.  I cannot see any downside to this but just thought I would ask 
for your thoughts.


Thanks

Mick


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Non related OWFS help with 1-Wire devices.

[Mick Sulley]

Hi Henrik,

I can't answer you questions I'm afraid but I would add a few comments.

I have been using Pi's since they were first released and yes, I have 
had a few problems as well.  The most common problem I have found is 
power supply, always worth using a decent one, I use Meanwell units in 
critical situations.  Second on the list is SD cards, I have had loads 
of failures there and I generally use hard drives recovered from old 
laptops instead of SD cards.


The biggest problem I have had with 1-wire is that it occasionally locks 
up.  I use a Sheepwalk RPi3 adapter to give me 8 channels, that uses the 
DS2482-800 chip.  When a lock-up occurs it needs a power cycle of 
1-wire, reboot does not reset it.  The solution I use for that is to use 
a second Pi which drives a relay (driven via GPIO pins) and 1-wire power 
is routed through a normally closed contact on the relay.  Pi-monitor 
reads a heartbeat file on pi-control and if the heartbeat is more than 
30 seconds old it energises the relay for 10 seconds.  This is 
controlling a solar hot water system, which can easily boil (and has 
several times) if the controls do not function correctly.


Best of luck with your system.

Mick

On 12/09/2020 11:32, Henrik Östman wrote:

Hi!
I have been following the OWFS project for 20+ years and I really 
think it's a marvelous piece of software. It's been run on a Raspberry 
Pi for many years now to control the heating in our house.
However lately my Raspberry Pi has been more and more unstable, 
overheating problems, diskfailure, hanging, owserver unexpectedly 
going down and soo forth. It really got me thinking if my setup is the 
best approche, my wife and kids should not have to be Unix admins and 
be able to SSH to my server and restart the Docker container with 
Owserver just to not freeze when I'm out on a business trip! So in a 
true Unix spirit I'm splitting my Home automation system appart into 
well defined pieces that "do one thing and do it well".
My house is heated by water-based floor heating, and there are three 
floor heating control centers, with relays opening and closing the 
water-valves. Each control center has a DS2408 controlling the relayes 
of 3-5 valves. A made a small circuit board with a commonly used 
Arduino compatible microcontroller that reads the temperature in the 
rooms using DS1820 sensors, then instructs the DS2408 to open/close 
the right valve. There is one circuit board for each control center, 
so if one goes down only a few rooms get affected. There is a 
reset-button on each circuit board that could be used to restart it 
for whatever reason, and since there are no filesystems mounted there 
is no problem with corruption in case of power loss, and restarting 
only takes a second. The Raspberry Pi is now only used for plotting 
graphs, MQTT and other home automation tasks.


Since I no longer use Owserver in my setup, I understand that it may 
be inappropriate to ask for help within this forum. But I know that 
there are some 10+ years skilled developers here with deep knowledge 
of 1-Wire systems so I'm still going to pop the questions, maybe you 
could direct me to a more suitable forum where we could continue the 
discussion?


 The problem I'm having is with the DS2408 devices, I only seem to be 
able to communicate with them using the SKIP-ROM command, if I try to 
address them individually then I only get garbage and errors back. The 
same code works great when addressing DS2423 and DS18(B/S)20 devices, 
so I think the code itself should work. Maybe I have missed something 
when communicating or initializing the DS2408? I tried to read all the 
Maxim specs, and it feels like I'm doing everything right. During 
startup I begin with initializing the DS2408 and set the pins to 
output and to a known state.


void ds2408_reset(DS2480B &ds, onewireNode &node) {
ESP_LOGD(TAG, "Reset DS2408, id: %s.", node.idStr.c_str());
if (existTestMode(ds, node)) {
// Configure RSTZ as STRB output.
//ds.select(node.id ); // reselect last selected device.
ds.write(SKIP_ROM);// HACK, this select all devices on the bus, but we 
should select only this single device. Though I get CRC-errors using 
above line.

ds.write(0xCC);// Issue Write Conditional Search Register command
ds.write(0x8D);// TA1, target address = 8Dh
ds.write(0x00);// TA2, target address = 008Dh
ds.write(0x04);// Write byte to Control/Status Register, RSTZ as STRB 
output

// Verify configuration setting
if (!ds.reset()) {
ESP_LOGW(TAG, "Reset DS2408 failed after non-success configure RSTZ as 
STRB.");

node.errors++;
return;
}
ds.write(RESUME);// reselect last selected device.
ds.write(0xF0);// Issue Read PIO Registers command
ds.write(0x8D);// TA1, target address = 8Dh
ds.write(0x00);// TA2, target address = 008Dh
auto status = ds.read();// Read Control/Status Register and verify
ESP_LOGD(TAG, "DS2408 verify configuration setting: %s.", 
String(status, HEX));

// Set all relays off.
setState(ds, no

[Owfs-developers] /simultaneous/voltage

[Mick Sulley]

I have been doing some more testing of voltage reading, this is what I 
found


Testing on Pi4 with Sheepwalk RPi3 adapter with 2 voltage sensors, a 
DS2437 and a DS2438
Reading voltage from cached takes around 0.06 seconds for each, reading 
from uncached takes around 0.28 seconds for DS2437 and 0.23 seconds for 
DS2438.


I then tested setting the /simultaneous/voltage bit followed by a 1 
second delay


Setting the /simultaneous/voltage bit causes CRC16_errors and 
CRC16_tries both to increase by 6, CRC8_errors remains unchanged, 
CRC8_tries increases by 2
Setting the /simultaneous/voltage bit has no impact on voltage read 
times, so it is not doing what I thought it was supposed to do.


This is on the system that I am also using to test temperature reading, 
with no errors, so I am pretty sure the errors are not caused by a 
hardware problem.


Thoughts?

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Writing to DS2413 Device with Python 3

[Mick Sulley]

Yes I have struggled with that as well.  I have discovered how to do it, 
but I don't really understand why.


The answer seems to be that to write a 1 you need

    owproxy.write('device_id' + '/PIO.BYTE, b'1')

so you need to write the byte value of the string 1, not the byte value 
of the integer 1.  As I say, I don't understand why that is so, I dabble 
with Python, I'm far from expert :)


Hope that helps

Mick

On 27/08/2020 15:18, Dennis Putnam wrote:

Hi Martin,

See embedded comments.

On 8/27/2020 2:56 AM, Martin Patzak wrote:


what does *onOff.to_bytes(1,byteorder=sys.byteorder)) *evaluate to? 
Is that resulting in a byte-value? I am not familiar with this...
This seems to be the crux of the problem. After a lot of testing it 
appears to be a python 3 issue converting an integer to a byte string. 
I am convinced that passing a byte string to the write function is the 
problem. Thanks for everyone's help but this is not an owfs problem.


Things you could try:

  * In the path use the fully qualifying path and add */uncached *and
write a byte-value like this
*owproxy.write('/uncached/3A.0BE14D00/PIO.BYTE',b'0')*
  * writeto the individual outputs PIO.A or PIO.B directly
  * try reading the sensed values***print('sensed.BYTE = ',
owp.read('/uncached/3A.0BE14D00**/sensed.BYTE')*

**
On 26.08.20 21:05, Dennis Putnam wrote:
I have rewritten my code to use pyownet but am now nearly back where 
I started. I have the following code:


*owproxy.write('/3A.'+blower.id_+'/PIO.BYTE',onOff.to_bytes(1,byteorder=sys.byteorder))

*That statement gives me the following error:

*pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid 
transaction: '/3A.0BE14D00/PIO.BYTE'


*The error is meaningless to me. The path is not wrong so is it 
complaining about writing a single byte?


Thanks again.

On 8/24/2020 4:33 PM, Dennis Putnam wrote:
Thanks to everyone that replied. I was not aware of pyownet. I will 
look into that and rewrite my code to use it.


On 8/24/2020 11:47 AM, Martin Patzak wrote:
For python I would highly recommend you use the library *pyownet 
*by Stefano Miccoli

/https://github.com/miccoli/pyownet/

/using Fuse can lead to weird problems... (not saying that it is 
the reason in your specific case)


or you can use the buil-in functions in owserver 
owread/owwrite/owdir instead.







 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>






___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Writing to DS2413 Device with Python 3

[Mick Sulley]

Yes I would second that.  It is a  little ironic that in the owfs suite 
of programs the module called owfs it the only one you really should not 
use.  Basically hte best way is to run owserver which talks to all the 
devices, and then your python code talks to owserver.


I have been using pyownet since I dropped fuse, it really is very good, 
documentation here https://pyownet.readthedocs.io/en/latest/


With python3 you need something like this -

import pyownet

DevAddress = 'enter your device address here'
owp = pyownet.protocol.proxy(persistent=True)
owp.write('/DevAddress/PIO.BYTE',b'0')
print('PIO.BYTE = ', owp.read('/uncached/DevAddress/PIO.BYTE')
print('sensed.BYTE = ', owp.read('/uncached/DevAddress/sensed.BYTE')

With Python3 the value ina write MUST be a byte value, hence b'0' in 
that line, Python2 didn't seem to care, that threw me for a while.


Also from command line you can use the commands from ow-shell, so owdir 
lists all devices, owread 28.A59F9D0B/latesttemp reads the value 
from that device.


Hope that helps.

Mick


On 24/08/2020 16:47, Martin Patzak wrote:
For python I would highly recommend you use the library *pyownet *by 
Stefano Miccoli

/https://github.com/miccoli/pyownet/

/using Fuse can lead to weird problems... (not saying that it is the 
reason in your specific case)


or you can use the buil-in functions in owserver owread/owwrite/owdir 
instead.


On 24.08.20 15:57, Dennis Putnam wrote:

I have the following python 3 code:

*fn='/mnt/1wire/3A.'+blower.id_+'/PIO.BYTE'**
**with open(fn,'wb') as fh:**
**   fh.write(onOff.to_bytes(1,byteorder=sys.byteorder))

*This produces the error:

*OSError: [Errno 22] Invalid argument

*The value of onOff will be either 1 or 0. In this particular case 
the value is 1. The value of blower.id_ is 0BE14D00. This is what 
that OWFS directory contains:


*ls -l /mnt/1wire/3A.0BE14D00*
total 0
-r--r--r-- 1 root root  16 Aug 19 21:17 address
-rw-rw-rw- 1 root root 256 Aug 19 21:17 alias
-r--r--r-- 1 root root   2 Aug 19 21:17 crc8
-r--r--r-- 1 root root   2 Aug 19 21:17 family
-r--r--r-- 1 root root  12 Aug 19 21:17 id
-r--r--r-- 1 root root  16 Aug 19 21:17 locator
-rw-rw-rw- 1 root root   1 Aug 19 21:17 PIO.A
-rw-rw-rw- 1 root root   3 Aug 19 21:17 PIO.ALL
-rw-rw-rw- 1 root root   1 Aug 19 21:17 PIO.B
-rw-rw-rw- 1 root root  12 Aug 19 21:17 PIO.BYTE
-r--r--r-- 1 root root  16 Aug 19 21:17 r_address
-r--r--r-- 1 root root  12 Aug 19 21:17 r_id
-r--r--r-- 1 root root  16 Aug 19 21:17 r_locator
-r--r--r-- 1 root root   1 Aug 19 21:17 sensed.A
-r--r--r-- 1 root root   3 Aug 19 21:17 sensed.ALL
-r--r--r-- 1 root root   1 Aug 19 21:17 sensed.B
-r--r--r-- 1 root root  12 Aug 19 21:17 sensed.BYTE
-r--r--r-- 1 root root  32 Aug 19 21:17 type

I cannot see anything wrong with the code or permissions and the 
error is so generic I don't know to what it refers. Can someone spot 
what is invalid or help me debug this problem? TIA.



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] python code printing /statistics

[Mick Sulley]

Thanks Stefano, I have removed it and reinstalled the owserver raspbian 
packages and it is back again at 3.2p3


Here is what I see on CRC_errors -

pi@pi4B:~/v12_5 $ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyownet
>>> owp = pyownet.protocol.proxy(persistent=True)
>>> owp.read('/statistics/errors/CRC16_errors').decode()
'  16'
>>> owp.write('/simultaneous/temperature', b'1')
>>> owp.read('/statistics/errors/CRC16_errors').decode()
'  16'
>>> owp.write('/simultaneous/voltage', b'1')
>>> owp.read('/statistics/errors/CRC16_errors').decode()
'  24'
>>>

So writing to simultaneous/temperature is fine, but 
/simultaneous/voltage increases the CRC error count by 8



Mick


On 17/08/2020 00:10, Stefano Miccoli via Owfs-developers wrote:


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] python code printing /statistics

[Mick Sulley]

OK I have installed it, I had to use sudo make install as it complained 
that it didn't have permission to created in /opt, but I think it is 
installed now, however


pi@pi4B:~ $ owdir
-bash: owdir: command not found
pi@pi4B:~ $ /opt/owfs/bin/owserver --ver
/opt/owfs/bin/owserver version:
    3.2p2
libow version:
    3.2p2
pi@pi4B:~ $

Is 3.2p2 the correct version?  I thought it should be 3.2p4.

Also I cannot get owdir to work

pi@pi4B:~ $ owdir
-bash: owdir: command not found
pi@pi4B:~ $ /opt/owfs/bin/owdir
pi@pi4B:~ $

I have sensors connected and they were working, have I missed something?

I tried starting the service -

pi@pi4B:~ $ sudo systemctl start owserver
Failed to start owserver.service: Unit owserver.service is masked.
pi@pi4B:~ $ sudo service owserver start
Failed to start owserver.service: Unit owserver.service is masked.
pi@pi4B:~ $



On 16/08/2020 21:46, Martin Patzak wrote:

My CRC16 value goes only up by one for setting /simultanous/voltage to '1'
I only tested with setting this once and read the CRC16 back right 
away without delay.


Here is my personal notes for installing owfs from github - I hope it 
helps you - if you have the code you can of course skip the git-hub part
In this notes I used some special parameters, which you do not have to 
use of course, but it illustrates that you have the ability to 
influence quite a number of things during configure


additionally, you should not run anything as sudo - especially not 
untested patches - so Stefano indicated how to circumvent this easily 
with setting a symlink (see last line)



get owfs

    git clone git://git.code.sf.net/p/owfs/code owfs-code

then cd into owfs-code

    ./bootstrap        # an error appeared and I had to install packages
    # ./bootstrap: 12: ./bootstrap: libtoolize: not found
    # aclocal: not found
    # pkg-config, libtool, automake

    ./configure
    ./configure --disable-swig --prefix=/home/mnm/owfs/ 
--program-suffix=_test85C 
--with-systemdsystemunitdir=/home/mnm/owfs/systemd


    make

    make install

### no more running with sudo !!! ###
link owserver_ to dir /usr/bin so it can be found when 
executing it with sudo


    sudo ls -s /home/mnm/owfs/bin/owserver_/usr/bin/owserver_



On 16.08.20 21:59, Mick Sulley wrote:


First, I noticed a typo in my mail, the CRC value increases by 8, not 
1, when I set /simultaneous/voltage.  My code was setting 
/temperature then /voltage, I wondered if a delay between them may 
help, tried and it did not.  I also tried setting /voltage first then 
/temperature but it still increased CRC on /voltage.


Yes I do have a voltage device, a DS2437.  I only have one, so 
setting /simultaneous/voltage is probably not going to save any time, 
but it seemed the right way to do it.


I looked at issue 55, don't know if that is related on not. I am 
happy to test 3.2p4 but don't know how to do it.


If I download from https://sourceforge.net/projects/owfs/ I get 3.2p1 
which is what I was running anyway.


I download the .zip from https://github.com/owfs/owfs unpacked into a 
new directory and tried to follow the instructions in INSTALL, this 
is what I got -


pi@pi4B:~/owfs/owfs-master $ ls
acinclude.m4    COPYING Makefile.am RELEASE.md
AUTHORS COPYING.LIB man2md release.pl
autom4te.cache  debian  module src
bootstrap   description-pak NEWS   TODO
ChangeLog   Dockerfile.release  README.DEVELOPERS 
update_wiki_manpages

configure.ac    INSTALL README.md
pi@pi4B:~/owfs/owfs-master $ ./configure
-bash: ./configure: No such file or directory
pi@pi4B:~/owfs/owfs-master $

I ran out of knowledge at this point.  If you can tell me how to 
install it I will test it out.


Thanks

Mick


On 16/08/2020 17:29, Stefano Miccoli via Owfs-developers wrote:
The CRC16 error could be related to 
https://github.com/owfs/owfs/issues/55


The version on master is already patched, and will be released in 
3.2p4. If possible check if the current version on master works as 
expected.


Stefano

On 16 Aug 2020, at 18:22, Martin Patzak <mailto:martin.pat...@gmx.de>> wrote:


I tested it and I can confirm that writing to 
/uncached/simultaneous/voltage increases the CRC16_error by one.


Mick, do you have voltage devices on your network? (I hope it is 
not a stupid question)

I don't have such devices, so I cannot test this further...

Greetings,
Marty

On 13.08.20 01:04, Mick Sulley wrote:


I have been doing some more testing and have a couple of issues.  
My code sets simultaneous/temperature, waits a couple of seconds 
then reads latesttemp from each sensor.


 1. Reading latesttemp generally takes 0.07 seconds BUT every 120
seconds every sensor takes 0.75 seconds for a single loop,
then back to 0.07 seconds. (/settings/timeout/presence is set
to 120)
 2. My understanding is that simulta

Re: [Owfs-developers] python code printing /statistics

[Mick Sulley]

First, I noticed a typo in my mail, the CRC value increases by 8, not 1, 
when I set /simultaneous/voltage.  My code was setting /temperature then 
/voltage, I wondered if a delay between them may help, tried and it did 
not.  I also tried setting /voltage first then /temperature but it still 
increased CRC on /voltage.


Yes I do have a voltage device, a DS2437.  I only have one, so setting 
/simultaneous/voltage is probably not going to save any time, but it 
seemed the right way to do it.


I looked at issue 55, don't know if that is related on not.  I am happy 
to test 3.2p4 but don't know how to do it.


If I download from https://sourceforge.net/projects/owfs/  I get 3.2p1 
which is what I was running anyway.


I download the .zip from https://github.com/owfs/owfs  unpacked into a 
new directory and tried to follow the instructions in INSTALL, this is 
what I got -


pi@pi4B:~/owfs/owfs-master $ ls
acinclude.m4    COPYING Makefile.am    RELEASE.md
AUTHORS COPYING.LIB man2md release.pl
autom4te.cache  debian  module src
bootstrap   description-pak NEWS   TODO
ChangeLog   Dockerfile.release  README.DEVELOPERS update_wiki_manpages
configure.ac    INSTALL README.md
pi@pi4B:~/owfs/owfs-master $ ./configure
-bash: ./configure: No such file or directory
pi@pi4B:~/owfs/owfs-master $

I ran out of knowledge at this point.  If you can tell me how to install 
it I will test it out.


Thanks

Mick


On 16/08/2020 17:29, Stefano Miccoli via Owfs-developers wrote:
The CRC16 error could be related to 
https://github.com/owfs/owfs/issues/55


The version on master is already patched, and will be released in 
3.2p4. If possible check if the current version on master works as 
expected.


Stefano

On 16 Aug 2020, at 18:22, Martin Patzak <mailto:martin.pat...@gmx.de>> wrote:


I tested it and I can confirm that writing to 
/uncached/simultaneous/voltage increases the CRC16_error by one.


Mick, do you have voltage devices on your network? (I hope it is not 
a stupid question)

I don't have such devices, so I cannot test this further...

Greetings,
Marty

On 13.08.20 01:04, Mick Sulley wrote:


I have been doing some more testing and have a couple of issues.  My 
code sets simultaneous/temperature, waits a couple of seconds then 
reads latesttemp from each sensor.


 1. Reading latesttemp generally takes 0.07 seconds BUT every 120
seconds every sensor takes 0.75 seconds for a single loop, then
back to 0.07 seconds.  (/settings/timeout/presence is set to 120)
 2. My understanding is that simultaneous/voltage works in the same
way, however when I set it my CRC_errors increases by 8.  Why is
this?

Cheers

Mick




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] python code printing /statistics

[Mick Sulley]

I have been doing some more testing and have a couple of issues. My code 
sets simultaneous/temperature, waits a couple of seconds then reads 
latesttemp from each sensor.


1. Reading latesttemp generally takes 0.07 seconds BUT every 120
   seconds every sensor takes 0.75 seconds for a single loop, then back
   to 0.07 seconds.  (/settings/timeout/presence is set to 120)
2. My understanding is that simultaneous/voltage works in the same way,
   however when I set it my CRC_errors increases by 8. Why is this?

Cheers

Mick


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] python code printing /statistics

[Mick Sulley]

Thanks for that, I just ran your code on my test system -

pi@pi4B:~/v12_5 $ python3 read_stats.py
temp is   24.625
success   934310
tries.0   470429
tries.1    0
tries.2    0
CRC16_tries    11768
CRC16_errors    11768
pi@pi4B:~/v12_5 $

Time to do some reading of the docs...

Mick


On 09/08/2020 10:21, Martin Patzak wrote:

here is a quick python code to read some /statistics

and yes, the owserver has been running for a looong time :-D


from pyownet import protocol
import time

op = protocol.proxy()

try:
    #x = op.read('/uncached/29.1CBF0E00/sensed.ALL')
    #print 'sensed is',x
    x = op.read('/uncached/28.CFB92006/latesttemp')
    print 'temp is',x

    x = op.read('/statistics/read/success')
    print 'success',x

    x = op.read('/statistics/read/tries.0')
    print 'tries.0',x

    x = op.read('/statistics/read/tries.1')
    print 'tries.1',x

    x = op.read('/statistics/read/tries.2')
    print 'tries.2',x

    x = op.read('/statistics/errors/CRC16_tries')
    print 'CRC16_tries',x

    x = op.read('/statistics/errors/CRC16_errors')
    print 'CRC16_errors',x


except Exception as e:
    print str(e)




temp is  57.9375
success    219962160        (why is success higher than tries.0? I do 
not know...)

tries.0    139228047
tries.1 1077                (one thousand re-tries in a couple 
of years reading 25 sensors every 30 seconds)
tries.2    6                    (six second re-tries... not 
bad ey? ;-)

CRC16_tries 81858524
CRC16_errors 1351        (some CRC16 errors were cause by 
writes, hence the discrepancy)





On 09.08.20 10:52, Martin Patzak wrote:

here is some documentation about the values in /statistics:

http://owfs.sourceforge.net/statistics.html

I do not know if there is more about that within the owfs project...

there should be more at Maxim's website about the interface protocol 
which owfs is based upon.


On 08.08.20 19:07, Mick Sulley wrote:


I have just run it again, sleep for 3 seconds after the 
simultaneous/temperature write and sleep 25 seconds at the end of 
the loop.  Presence is at 120 and I see a delay every 130 seconds or 
so.  The delay is on reading whichever parameter is first, so if I 
read present first then that is the 0.7 scan, the other parameters 
are < 0.1, but If I read type first then that is 0.7 sec, etc


I am also reading CR16_errors and CR16_tries, these are the same and 
both increase by 8 each loop.  Is that normal?  Is there any 
documentation on this stuff, I can't find anything.


Mick

On 08/08/2020 08:46, Martin Patzak wrote:

Thanks Mick, great summary.

Let me add to 4), that you only see the 0.7 sec delay, because you 
read in a busy loop.

I read only every 30 seconds and I never see a delay.

But timing your reads is a good practice because this way you catch 
retries and maybe bus or sensor problems.

Additionally you can have a look in /statistics for retries and errors

On 08.08.20 01:04, Mick Sulley wrote:
Update on test findings.  Test setup was 19 - DS18B20 temperature, 
2 - DS2413 IO and 1 - DS2437 Voltage, Raspberry Pi4 with Sheepwalk 
RPi3 Adapter


1) /simultaneous/temperature does work, best to read latesttemp.

2) /settings/timeout/presence cannot be set or read via the 
owhttpd web page, you must use owwrite & owread


3) Reading values (after setting simultaneous) normally takes < 
0.1 seconds


4) After the /settings/timeout/presence interval the next read for 
every device will take around 0.7 seconds.  Note if you read 
multiple fields it is only the first one which takes the increased 
time.


5) The increased time after /settings/timeout/presence interval 
applies to all devices, not just temperature



Mick






___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous - Update

[Mick Sulley]

I have just run it again, sleep for 3 seconds after the 
simultaneous/temperature write and sleep 25 seconds at the end of the 
loop.  Presence is at 120 and I see a delay every 130 seconds or so.  
The delay is on reading whichever parameter is first, so if I read 
present first then that is the 0.7 scan, the other parameters are < 0.1, 
but If I read type first then that is 0.7 sec, etc


I am also reading CR16_errors and CR16_tries, these are the same and 
both increase by 8 each loop.  Is that normal?  Is there any 
documentation on this stuff, I can't find anything.


Mick

On 08/08/2020 08:46, Martin Patzak wrote:

Thanks Mick, great summary.

Let me add to 4), that you only see the 0.7 sec delay, because you 
read in a busy loop.

I read only every 30 seconds and I never see a delay.

But timing your reads is a good practice because this way you catch 
retries and maybe bus or sensor problems.

Additionally you can have a look in /statistics for retries and errors

On 08.08.20 01:04, Mick Sulley wrote:
Update on test findings.  Test setup was 19 - DS18B20 temperature, 2 
- DS2413 IO and 1 - DS2437 Voltage, Raspberry Pi4 with Sheepwalk RPi3 
Adapter


1) /simultaneous/temperature does work, best to read latesttemp.

2) /settings/timeout/presence cannot be set or read via the owhttpd 
web page, you must use owwrite & owread


3) Reading values (after setting simultaneous) normally takes < 0.1 
seconds


4) After the /settings/timeout/presence interval the next read for 
every device will take around 0.7 seconds.  Note if you read multiple 
fields it is only the first one which takes the increased time.


5) The increased time after /settings/timeout/presence interval 
applies to all devices, not just temperature



Mick


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous - Update

[Mick Sulley]

Update on test findings.  Test setup was 19 - DS18B20 temperature, 2 - 
DS2413 IO and 1 - DS2437 Voltage, Raspberry Pi4 with Sheepwalk RPi3 Adapter


1) /simultaneous/temperature does work, best to read latesttemp.

2) /settings/timeout/presence cannot be set or read via the owhttpd web 
page, you must use owwrite & owread


3) Reading values (after setting simultaneous) normally takes < 0.1 seconds

4) After the /settings/timeout/presence interval the next read for every 
device will take around 0.7 seconds.  Note if you read multiple fields 
it is only the first one which takes the increased time.


5) The increased time after /settings/timeout/presence interval applies 
to all devices, not just temperature



Mick


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick Sulley]

No, just tested again and it now delays every 300 seconds.  Not the 
faintest idea why that should be.


I have a couple of I/O and a voltage sensor, so I will set it up again 
tomorrow with those in as well.


What do you use /presence for?  I have never used it before today.

Mick


On 06/08/2020 22:14, Martin Patzak wrote:
I read the 25 powered sensors every 30 seconds and I don't experience 
a delay every 120 seconds (my /presence is at default 120)


I use /presence only when I get an error reading a sensor (happens 
very rarely, but it happens)
Then I wait until the sensor is present again before reading it. I use 
the previous value instead.


I also read 2 IO modules every second. Those are not affected by a 
delay every 120 seconds either.


Let's wait and hear what others say to that attribute.

If you set it to 999 you experience no delays anymore?

On 06.08.20 21:42, Mick Sulley wrote:


I did change to persistent and I didn't see a difference.

//settings/timeout/presence /is what is causing it.  I had tried 
changing it yesterday, via the httpd web page, but this time I 
checked it with owread and that showed it still at 120, so I changed 
it to 20 with owwrite re-ran my Python script and yes it slows every 
20 seconds


What is the purpose of //settings/timeout/presence/? The man page 
says 'Seconds until the /presence/ and bus location of a 1-wire 
device expires in the cache.', but I don't really understand what it 
does.  Surely the presence is confirmed by any read of the sensor.


I have just tried setting it to -1, that is invalid, I thought it may 
disable it.  I set it to 0 and it is slow every time.  I have now set 
it to 999, not sure what the limit would be.


Comments?

Mick

On 06/08/2020 16:48, Martin Patzak wrote:

looks like you are getting close :-)

I checked, and the only timeout of owserver that matches 120 is 
//settings/timeout/presence



/
On 06.08.20 16:21, Mick Sulley wrote:


Well this gets more curious.  I am now measuring the time for each 
read, reading type, power and latesttemp.  Time for all is 
generally < 0.1 seconds, but then when I hit the slow loop the read 
for type is around 0.7 seconds, the others still < 0.1 seconds.  I 
don't really need type so I removed it and re-tested, on slow loops 
the power read is around 0.7 seconds, latesttemp still < 0.1 
seconds.  So I removed power as well, just reading latesttemp, on 
slow loops that is now around 0.7 seconds. So it seems that at some 
point a sensor takes many times longer for its next read, 
irrespective of which field is read.


I have now tested with 19, 11 and 2 sensors and the slow loop 
occurs every 120 seconds.  I am intrigued to know what causes this, 
any ideas?


Thanks

Mick

On 06/08/2020 10:23, Mick Sulley wrote:


OK I will log read times and see what that shows.

You say 'I also log if the error of the 1wire bus changes.' how do 
you do that?


No I don't really need to read that fast, this is just a test 
setup to get a better understanding so I can hopefully fine tune 
my main system.


There should not be anything else running.  I just tried running 
top at the same time, I monitored it at the point of the slow scan 
and didn't see anything else significant.


Mick

On 06/08/2020 09:06, Martin Patzak wrote:

It looks like your timing has improved after all!

in your original Python-code you could time every read for each 
sensor.
I have also powered sensors and a read is usually faster than 0.1 
seconds.
I log in a file if the read took longer than 0.3 seconds, which 
is almost never the case.
I also log in the file if the whole reading loop took longer than 
3 seconds, which again is almost never the case.


I also log if the error of the 1wire bus changes.

I read 25 sensors every full and every half minute, so maybe you 
could implement a delay as well and see if things get more 
consistent.

Do you need to read so fast in a loop for you application?

What else is running on your machine? You could run top in 
parallel to your python loop.






___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick Sulley]

I did change to persistent and I didn't see a difference.

//settings/timeout/presence /is what is causing it.  I had tried 
changing it yesterday, via the httpd web page, but this time I checked 
it with owread and that showed it still at 120, so I changed it to 20 
with owwrite re-ran my Python script and yes it slows every 20 seconds


What is the purpose of //settings/timeout/presence/?  The man page says 
'Seconds until the /presence/ and bus location of a 1-wire device 
expires in the cache.', but I don't really understand what it does.  
Surely the presence is confirmed by any read of the sensor.


I have just tried setting it to -1, that is invalid, I thought it may 
disable it.  I set it to 0 and it is slow every time.  I have now set it 
to 999, not sure what the limit would be.


Comments?

Mick
//

On 06/08/2020 16:48, Martin Patzak wrote:

looks like you are getting close :-)

I checked, and the only timeout of owserver that matches 120 is 
//settings/timeout/presence



/
On 06.08.20 16:21, Mick Sulley wrote:


Well this gets more curious.  I am now measuring the time for each 
read, reading type, power and latesttemp.  Time for all is generally 
< 0.1 seconds, but then when I hit the slow loop the read for type is 
around 0.7 seconds, the others still < 0.1 seconds.  I don't really 
need type so I removed it and re-tested, on slow loops the power read 
is around 0.7 seconds, latesttemp still < 0.1 seconds.  So I removed 
power as well, just reading latesttemp, on slow loops that is now 
around 0.7 seconds.  So it seems that at some point a sensor takes 
many times longer for its next read, irrespective of which field is read.


I have now tested with 19, 11 and 2 sensors and the slow loop occurs 
every 120 seconds.  I am intrigued to know what causes this, any ideas?


Thanks

Mick

On 06/08/2020 10:23, Mick Sulley wrote:


OK I will log read times and see what that shows.

You say 'I also log if the error of the 1wire bus changes.' how do 
you do that?


No I don't really need to read that fast, this is just a test setup 
to get a better understanding so I can hopefully fine tune my main 
system.


There should not be anything else running.  I just tried running top 
at the same time, I monitored it at the point of the slow scan and 
didn't see anything else significant.


Mick

On 06/08/2020 09:06, Martin Patzak wrote:

It looks like your timing has improved after all!

in your original Python-code you could time every read for each sensor.
I have also powered sensors and a read is usually faster than 0.1 
seconds.
I log in a file if the read took longer than 0.3 seconds, which is 
almost never the case.
I also log in the file if the whole reading loop took longer than 3 
seconds, which again is almost never the case.


I also log if the error of the 1wire bus changes.

I read 25 sensors every full and every half minute, so maybe you 
could implement a delay as well and see if things get more consistent.

Do you need to read so fast in a loop for you application?

What else is running on your machine? You could run top in parallel 
to your python loop.






___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick Sulley]

Well this gets more curious.  I am now measuring the time for each read, 
reading type, power and latesttemp.  Time for all is generally < 0.1 
seconds, but then when I hit the slow loop the read for type is around 
0.7 seconds, the others still < 0.1 seconds.  I don't really need type 
so I removed it and re-tested, on slow loops the power read is around 
0.7 seconds, latesttemp still < 0.1 seconds.  So I removed power as 
well, just reading latesttemp, on slow loops that is now around 0.7 
seconds.  So it seems that at some point a sensor takes many times 
longer for its next read, irrespective of which field is read.


I have now tested with 19, 11 and 2 sensors and the slow loop occurs 
every 120 seconds.  I am intrigued to know what causes this, any ideas?


Thanks

Mick

On 06/08/2020 10:23, Mick Sulley wrote:


OK I will log read times and see what that shows.

You say 'I also log if the error of the 1wire bus changes.' how do you 
do that?


No I don't really need to read that fast, this is just a test setup to 
get a better understanding so I can hopefully fine tune my main system.


There should not be anything else running.  I just tried running top 
at the same time, I monitored it at the point of the slow scan and 
didn't see anything else significant.


Mick

On 06/08/2020 09:06, Martin Patzak wrote:

It looks like your timing has improved after all!

in your original Python-code you could time every read for each sensor.
I have also powered sensors and a read is usually faster than 0.1 
seconds.
I log in a file if the read took longer than 0.3 seconds, which is 
almost never the case.
I also log in the file if the whole reading loop took longer than 3 
seconds, which again is almost never the case.


I also log if the error of the 1wire bus changes.

I read 25 sensors every full and every half minute, so maybe you 
could implement a delay as well and see if things get more consistent.

Do you need to read so fast in a loop for you application?

What else is running on your machine? You could run top in parallel 
to your python loop.






___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick Sulley]

OK I will log read times and see what that shows.

You say 'I also log if the error of the 1wire bus changes.' how do you 
do that?


No I don't really need to read that fast, this is just a test setup to 
get a better understanding so I can hopefully fine tune my main system.


There should not be anything else running.  I just tried running top at 
the same time, I monitored it at the point of the slow scan and didn't 
see anything else significant.


Mick

On 06/08/2020 09:06, Martin Patzak wrote:

It looks like your timing has improved after all!

in your original Python-code you could time every read for each sensor.
I have also powered sensors and a read is usually faster than 0.1 seconds.
I log in a file if the read took longer than 0.3 seconds, which is 
almost never the case.
I also log in the file if the whole reading loop took longer than 3 
seconds, which again is almost never the case.


I also log if the error of the 1wire bus changes.

I read 25 sensors every full and every half minute, so maybe you could 
implement a delay as well and see if things get more consistent.

Do you need to read so fast in a loop for you application?

What else is running on your machine? You could run top in parallel to 
your python loop.



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick Sulley]

OK I've done more testing, owhttpd was running and a web page open, I 
closed that and killed owttpd but it didn't seem to make any difference.


From what you write it seems there's another process accessing the
   sensors concurrently. Maybe a kernel driver? Check that first.

I don't think there is anything else accessing them, lsmod|grep w1 
returned nothing but beyond that I don't know how to find out.


I just tried running a shell script
owwrite /simultaneous/temperature 1
sleep 1s
owread /uncached/Temp19/latesttemp
owread /uncached/Temp20/latesttemp
owread /uncached/Temp21/latesttemp
owread /uncached/Temp22/latesttemp
owread /uncached/Temp23/latesttemp
owread /uncached/Temp25/latesttemp
owread /uncached/Temp26/latesttemp
owread /uncached/Temp27/latesttemp
owread /uncached/Temp29/latesttemp
echo
echo 'Time ' $SECONDS

I ran it repeatedly, it mostly takes 1 to 2 seconds, but after around 40 
runs there is one that takes around 9 seconds.


I also ran some tests with Python code and more sensors, again it looks 
to be working fine, but every 110 seconds or so it takes about 4 times 
as long to read.  I looked at the timeout settings but the only one 
close to that was presence at 120, so I changed that to 10 and it made 
no difference, so it is not that.  Any ideas?


Thanks for your help guys, much appreciated.

Mick


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick Sulley]

I based my code on a mail from Jan 13/3/2020 which said the best way was

$ owwrite /simultaneous/temperature 1
$ sleep 1s
$ owread /uncached//latesttemp
$ owread /uncached//latesttemp
$ owread /uncached//latesttemp

I was thinking that the problem may be with my Python code, but I have 
just tried it with a bash script and writing to simultaneous/temperature 
make no difference.  I have tried it reading latesttemp and also 
temperature.


I am really confused now.

Mick


On 05/08/2020 09:15, Martin Patzak wrote:
... actually I checked my current code and I saw, that I do not read 
/latesttemp, but read from /uncached/id/temperature
so reading from /uncached does not trigger a new conversion. Only when 
you read a second time without triggering /simultaneous
I also saw that I increased the wait after issuing /simulataneous 
command to 2 seconds, so I must have had issues at the time...



On 05.08.20 09:23, Martin Patzak wrote:

Hi Mick,

by reading the /uncached value, you are causing a new conversion.
Read only /latesttemp and it should work fine.

here is my test program, when I first tested simultaneous and pyownet:


import time
from pyownet import protocol

op = protocol.proxy("razmaban",port=4304)
error = 0
error_old = None


while True:

    op.write('/simultaneous/temperature', '1')

    time.sleep(1)   # give the sensors time to convert their temps

    print '...'

    sensed = op.read('/28.676A2006/latesttemp')
    print sensed

    sensed = op.read('/28.DD591502/latesttemp')
    print sensed



Marty

On 05.08.20 00:39, Mick Sulley wrote:
Running v3.2p3 on Raspberry Pi,  I have set up some DS18B20 sensors 
on a test system, all of them are powered, but simultaneous does not 
seem to be working


The code is below, when I run it the first loop takes 16 seconds 
then it loops at 3 seconds for a while, then a 16 second etc. so it 
looks like it does slow individual conversions, then uses cached 
values until they expire, then another slow individual conversion, 
etc.  Have I got something wrong here?


Thanks

Mick

#!/usr/bin/python3

# sensor_read.py

import pyownet
import time

def main():
    owp = pyownet.protocol.proxy()
    while True:
    start = time.time()
    owp.write('/simultaneous/temperature', b'1')
    time.sleep(1)
    print('start of sensor_read.py')
    sen_lst = ['Solar_Pnl_1A', 'Solar_Pnl_2A','Solar_Pnl_1B', 
'Pool_Sol_X', 'Pool_CH_X', 'DHW_Mid_Top', 'DHW_Mid_Btm', 
'DHW_Top','Temp5', 'Temp19', 'Temp20','Temp21', 'Temp22', 'Temp23', 
'Temp25', 'Temp26', 'Temp27', 'Temp29',  'Temp30']

    prop_lst =  ['/type', '/power', '/latesttemp']
    for p in prop_lst:
    print('%s  ' %p,  end = '')
    print('')
    for sen in sen_lst:
    print('\n%s ' %sen, end = '')
    for prop in prop_lst:
    try:
    print('%s  ' %(owp.read('/uncached/' + sen + 
prop).decode()),  end = '')

    except:
    print('failed! ',    end = '')
    endt = time.time() - start
    print('\nTime = %f' %endt)

if __name__ == "__main__":
    main()



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Simultaneous not working

[Mick Sulley]

Running v3.2p3 on Raspberry Pi,  I have set up some DS18B20 sensors on a 
test system, all of them are powered, but simultaneous does not seem to 
be working


The code is below, when I run it the first loop takes 16 seconds then it 
loops at 3 seconds for a while, then a 16 second etc. so it looks like 
it does slow individual conversions, then uses cached values until they 
expire, then another slow individual conversion, etc.  Have I got 
something wrong here?


Thanks

Mick

#!/usr/bin/python3

# sensor_read.py

import pyownet
import time

def main():
    owp = pyownet.protocol.proxy()
    while True:
    start = time.time()
    owp.write('/simultaneous/temperature', b'1')
    time.sleep(1)
    print('start of sensor_read.py')
    sen_lst = ['Solar_Pnl_1A', 'Solar_Pnl_2A','Solar_Pnl_1B', 
'Pool_Sol_X', 'Pool_CH_X', 'DHW_Mid_Top', 'DHW_Mid_Btm', 
'DHW_Top','Temp5', 'Temp19', 'Temp20','Temp21', 'Temp22', 'Temp23', 
'Temp25', 'Temp26', 'Temp27', 'Temp29',  'Temp30']

    prop_lst =  ['/type', '/power', '/latesttemp']
    for p in prop_lst:
    print('%s  ' %p,  end = '')
    print('')
    for sen in sen_lst:
    print('\n%s ' %sen, end = '')
    for prop in prop_lst:
    try:
    print('%s  ' %(owp.read('/uncached/' + sen + 
prop).decode()),  end = '')

    except:
    print('failed! ',    end = '')
    endt = time.time() - start
    print('\nTime = %f' %endt)

if __name__ == "__main__":
    main()



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Caching for I/O modules

[Mick Sulley]

Thanks Jan.

On 09/05/2020 20:14, Jan Kandziora wrote:

Am 09.05.20 um 14:42 schrieb Mick Sulley:

I understand how caching works for temperature sensors, use of
simultaneous etc, but how do I/O modules work in that respect?

I am particularly interested in DS2413. Is there any difference between
"owwrite /TestIO/PIO.A 1" and "owwrite /uncached/TestIO/PIO.A 1",


They both write to the chip. No difference.



similarly with reading, is it safer to use "owread
/uncached/TestIO/PIO.A" rather than "owread /TestIO/PIO.A"


Only reading /uncached will give you the current value the chip read
each time. The cached one may be seconds old, depending on when you read
it from the chip last time.


and is there
a performance hit?


Reading a cached value does not introduce any bus transfer.

Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Caching for I/O modules

[Mick Sulley]

I understand how caching works for temperature sensors, use of 
simultaneous etc, but how do I/O modules work in that respect?


I am particularly interested in DS2413. Is there any difference between 
"owwrite /TestIO/PIO.A 1" and "owwrite /uncached/TestIO/PIO.A 1", 
similarly with reading, is it safer to use "owread 
/uncached/TestIO/PIO.A" rather than "owread /TestIO/PIO.A" and is there 
a performance hit?


Thanks

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Surplus Items

[Mick Sulley]

How about £40 for the 3 DS9097Us ?

On 27/04/2020 20:09, Michael Hughes wrote:

On Mon, 27 Apr 2020 19:22:53 +0100
Mick Sulley  wrote:


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

How much do you want for the DS9097Us (all 3)?





___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Surplus Items

[Mick Sulley]

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



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] How to Use Simultaneous

[Mick Sulley]

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]//temperature[X] and
/simultaneous/temperature. Use the latter only in combination with
[/uncached]//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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] How to Use Simultaneous

[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. 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 zeitvertreib.wiss...@web.de:

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] pyownet question

[Mick Sulley]

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 "", line 1, in 
  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 

… 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.00 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 
  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 <mailto:m...@sulley.info>> 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()
Tra

[Owfs-developers] pyownet question

[Mick Sulley]

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 "", line 1, in 
  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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Installing pyownet

[Mick Sulley]

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 <mailto:m...@sulley.info>> 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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Installing pyownet

[Mick Sulley]

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Installing pyownet

[Mick Sulley]

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Installing pyownet

[Mick Sulley]

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Installing pyownet

[Mick Sulley]

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

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

[Mick Sulley]

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 <mailto:m...@sulley.info>> 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
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

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

[Mick Sulley]

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

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

[Mick Sulley]

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.E3377A02/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 = '267E9C3E026E/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./', '/26./', '/01./']
>>> node_a = '/26./alias'
>>> node_b = '/26./alias'
>>> node_c = '/01./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./', '/26./', '/01./']


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 <mailto:m...@sulley.info>> 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.E3377A02/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'
&

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

[Mick Sulley]

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.E3377A02/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./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./temperature')
b'     24.4688'
>>> float(owp.read('/26./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,00,01,rw,01,s,'
>>> owp.read("/structure/26/CA").decode()
'y,00,01,rw,01,s,'

Regards,

Stefano


On 9 Oct 2019, at 22:44, Mick Sulley <mailto:m...@sulley.info>> 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
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

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

[Mick Sulley]

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.E3377A02/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./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./temperature')
b'     24.4688'
>>> float(owp.read('/26./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,00,01,rw,01,s,'
>>> owp.read("/structure/26/CA").decode()
'y,00,01,rw,01,s,'

Regards,

Stefano


On 9 Oct 2019, at 22:44, Mick Sulley <mailto:m...@sulley.info>> 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
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Python2.7 to 3

[Mick Sulley]

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs on Raspberry Buster

[Mick Sulley]

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
rob...@lagus.net  <mailto:rob...@lagus.net>


On Wed, 18 Sep 2019 at 19:51, Nico Bouthoorn via Owfs-developers 
<mailto:owfs-developers@lists.sourceforge.net>> 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

Re: [Owfs-developers] owfs on Raspberry Buster

[Mick Sulley]

rver: 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
rob...@lagus.net  <mailto:rob...@lagus.net>


On Sun, 15 Sep 2019 at 21:08, Mick Sulley <mailto:m...@sulley.info>> 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.a200 crc 13
Sep 15 18:01:27 pi-solar-old kernel: [ 3631.383280]
w1_master_driver w1_bus_master1: Family 0 for 00.a200.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, mailto:m...@sulley.info>> 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
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net  
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs on Raspberry Buster

[Mick Sulley]

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.a200 crc 13
Sep 15 18:01:27 pi-solar-old kernel: [ 3631.383280] w1_master_driver 
w1_bus_master1: Family 0 for 00.a200.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, <mailto:m...@sulley.info>> 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
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] owfs on Raspberry Buster

[Mick Sulley]

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Faulty DS18B20 - Revisited

[Mick Sulley]

A few weeks ago I reported a problem with some DS18B20 sensors, then 
found it was my mistake.  I have just looked at all this again and it is 
not that simple!
Having tidied my desk I found I had a lot of DS18B20 sensors and I have 
been testing them -

11 work as expected
21 work fine when powered but do not work in parasitic mode.  These were 
bought from at least 2 different suppliers, but all have code 1827C4  
+051AG marked on the body.


Test results are at the end if anyone is interested.

In summary the 'new' DS18B20 sensors that I have not only do not support 
parasitic mode, but they actually pull the whole network down when 
connected that way.  I looked on the Maxim site and didn't see any 
reference to problems like this, so I contacted their support.  They 
asked for the id's and body codes of some problem sensors, which they 
then checked and confirmed that these are actually counterfeit.  They 
can do nothing about it as I did not purchase they from an authorised 
supplier.


It amazes me that anyone would bother to counterfeit a device which 
sells for just over £1.00, but it seems that they do!


I have never tested the accuracy of sensors, just assumed that they 
would be sufficiently accurate for my needs, but I now I think I will 
try to test that as well.  I also wonder if these devices my contribute 
to other problems, no reads, 85 reads, etc.


I have just ordered a bunch of sensors from Farnell, one of their 
authorised suppliers in the UK.  It will probably take me a while but I 
will replace all of my temperature sensors and see if I notice any 
difference.  I will also keep records of body markings and id's so I 
have traceability.



Results ---

Testing with Sheepwalk RPi2 adapter, good (old) DS18B20
Connect all 3 pins (powered) Vdd = 5.01V, DQ = 4.53V, working OK, 
displays Power = Yes

Connect Vdd to Gnd  DQ = 4.53V, working OK, displays Power = No

Testing with Sheepwalk RPi2 adapter, suspect (new) DS18B20
Connect all 3 pins (powered) Vdd = 5.01V, DQ = 4.53V, working OK, 
displays Power = Yes
Connect Vdd to Gnd  DQ = 0.73V, Not working & no other sensors working, 
also simultaneous & alarm are not there



Testing with DS9490 USB adapter, good (old) DS18B20
Connect all 3 pins  Vdd =335mV, DQ = 5.04V, Working but 85 on temp 9 & 
10,displays power = No

Connect Vdd to Gnd  DQ = 5.04V, Working OK, displays power = No

Testing with DS9490 USB adapter, suspect (new) DS18B20
Connect all 3 pins  Vdd = 4.32V, DQ = 4.99V, not visible on network but 
other sensors still work
Connect Vdd to Gnd  DQ = 20mV, Not working & no other sensors working, 
also simultaneous & alarm are not there




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New faulty DS18B20 - Solved it

[Mick Sulley]

I will repay him yes.

On 04/08/2019 20:27, Colin Law wrote:

Have you re-paid the first guy? Or did you send them back?

Colin

On Sun, 4 Aug 2019 at 20:09, Mick Sulley  wrote:

It was all very simple.  I was connecting the sensors via breadboard
type connectors.  My old one worked, the new ones didn't.  I just tried
connecting via the screw terminals on a Sheepwalk RPi2 and they all work
fine.  I guess the pins on the new ones must be a bit corroded and that
stopped it making a good connection.

Thanks for your help, sorry it was a bum steer.

Mick

On 04/08/2019 11:16, Jan Kandziora wrote:

Am 04.08.19 um 10:02 schrieb Mick Sulley:

Yes it does.  I also have a DS18S20 inside the test box that I use, that
shows as well.  I have just tried a different DS2401 and get the same
results.


Please take a photo from the label side of the DS18B20, as well as the
front and bottom side so we can check if it's obviously counterfeit.

Kind regards

   Jan



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New faulty DS18B20 - Solved it

[Mick Sulley]

It was all very simple.  I was connecting the sensors via breadboard 
type connectors.  My old one worked, the new ones didn't.  I just tried 
connecting via the screw terminals on a Sheepwalk RPi2 and they all work 
fine.  I guess the pins on the new ones must be a bit corroded and that 
stopped it making a good connection.


Thanks for your help, sorry it was a bum steer.

Mick

On 04/08/2019 11:16, Jan Kandziora wrote:

Am 04.08.19 um 10:02 schrieb Mick Sulley:

Yes it does.  I also have a DS18S20 inside the test box that I use, that
shows as well.  I have just tried a different DS2401 and get the same
results.


Please take a photo from the label side of the DS18B20, as well as the
front and bottom side so we can check if it's obviously counterfeit.

Kind regards

Jan



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Install on Raspbian Buster

[Mick Sulley]

Thanks Colin,  I had forgotten to enable i2c.  It all works now.


On 04/08/2019 12:13, Colin Law wrote:

How are you connecting the devices to the pi?
Have you run raspi-config and enabled/disabled the appropriate sections?

You have to use sudo with systemctl.

Colin

On Sun, 4 Aug 2019 at 11:29, Mick Sulley  wrote:

I'm trying to install on Raspbian Buster and failing!

I did the usual updates, then installed owserver owhttpd ow-shell,  it
has installed 3.2p3

owdir worked, but that was with the fake devices in owfs.conf. Edited
that out and added dtparam=i2c1=on

sudo i2cdetect -y 1

gives me

Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or
directory

Searching suggested adding dtparam=i2c1=on  to /boot/config.txt

I did that and rebooted

I still get   Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1':
No such file or directory

Thought I might need to restart the service but

pi@raspberrypi:~ $ systemctl restart owserver.service
 AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to restart 'owserver.service'.
Authenticating as: root
Password:
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
 AUTHENTICATION FAILED ===
Failed to restart owserver.service: Access denied
See system logs and 'systemctl status owserver.service' for details.
pi@raspberrypi:~ $

I think this is the section of the syslog file, but doesn't mean much to me

Aug  4 11:14:06 raspberrypi OWFS[493]: DEFAULT: ow_arg.c:(127) Cannot
access device /dev/i2c-1
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Failed with
result 'protocol'.
Aug  4 11:14:06 raspberrypi systemd[1]: Failed to start Backend server
for 1-wire control.
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Service
RestartSec=100ms expired, scheduling restart.
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Scheduled
restart job, restart counter is at 5.
Aug  4 11:14:06 raspberrypi systemd[1]: Stopped Backend server for
1-wire control.
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Start request
repeated too quickly.
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Failed with
result 'protocol'.
Aug  4 11:14:06 raspberrypi systemd[1]: Failed to start Backend server
for 1-wire control.
Aug  4 11:15:15 raspberrypi dbus-daemon[276]: [system] Activating via
systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
requested by ':1.9' (uid=1000 pid=501 comm="/usr/bin/pkttyagent
--notify-fd 5 --fallback ")
Aug  4 11:15:15 raspberrypi systemd[1]: Starting Authorization Manager...
Aug  4 11:15:15 raspberrypi polkitd[504]: started daemon version 0.105
using authority implementation `local' version `0.105'
Aug  4 11:15:15 raspberrypi dbus-daemon[276]: [system] Successfully
activated service 'org.freedesktop.PolicyKit1'
Aug  4 11:15:15 raspberrypi systemd[1]: Started Authorization Manager.
Aug  4 11:17:01 raspberrypi CRON[517]: (root) CMD (   cd / && run-parts
--report /etc/cron.hourly)
Aug  4 11:19:37 raspberrypi systemd[1]: Starting Cleanup of Temporary
Directories...
Aug  4 11:19:37 raspberrypi systemd[1]: systemd-tmpfiles-clean.service:
Succeeded.


Any ideas?



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Install on Raspbian Buster

[Mick Sulley]

I'm trying to install on Raspbian Buster and failing!

I did the usual updates, then installed owserver owhttpd ow-shell,  it 
has installed 3.2p3


owdir worked, but that was with the fake devices in owfs.conf. Edited 
that out and added dtparam=i2c1=on


sudo i2cdetect -y 1

gives me

Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or 
directory


Searching suggested adding dtparam=i2c1=on  to /boot/config.txt

I did that and rebooted

I still get   Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': 
No such file or directory


Thought I might need to restart the service but

pi@raspberrypi:~ $ systemctl restart owserver.service
 AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to restart 'owserver.service'.
Authenticating as: root
Password:
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
 AUTHENTICATION FAILED ===
Failed to restart owserver.service: Access denied
See system logs and 'systemctl status owserver.service' for details.
pi@raspberrypi:~ $

I think this is the section of the syslog file, but doesn't mean much to me

Aug  4 11:14:06 raspberrypi OWFS[493]: DEFAULT: ow_arg.c:(127) Cannot 
access device /dev/i2c-1
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Failed with 
result 'protocol'.
Aug  4 11:14:06 raspberrypi systemd[1]: Failed to start Backend server 
for 1-wire control.
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Service 
RestartSec=100ms expired, scheduling restart.
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Scheduled 
restart job, restart counter is at 5.
Aug  4 11:14:06 raspberrypi systemd[1]: Stopped Backend server for 
1-wire control.
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Start request 
repeated too quickly.
Aug  4 11:14:06 raspberrypi systemd[1]: owserver.service: Failed with 
result 'protocol'.
Aug  4 11:14:06 raspberrypi systemd[1]: Failed to start Backend server 
for 1-wire control.
Aug  4 11:15:15 raspberrypi dbus-daemon[276]: [system] Activating via 
systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' 
requested by ':1.9' (uid=1000 pid=501 comm="/usr/bin/pkttyagent 
--notify-fd 5 --fallback ")

Aug  4 11:15:15 raspberrypi systemd[1]: Starting Authorization Manager...
Aug  4 11:15:15 raspberrypi polkitd[504]: started daemon version 0.105 
using authority implementation `local' version `0.105'
Aug  4 11:15:15 raspberrypi dbus-daemon[276]: [system] Successfully 
activated service 'org.freedesktop.PolicyKit1'

Aug  4 11:15:15 raspberrypi systemd[1]: Started Authorization Manager.
Aug  4 11:17:01 raspberrypi CRON[517]: (root) CMD (   cd / && run-parts 
--report /etc/cron.hourly)
Aug  4 11:19:37 raspberrypi systemd[1]: Starting Cleanup of Temporary 
Directories...
Aug  4 11:19:37 raspberrypi systemd[1]: systemd-tmpfiles-clean.service: 
Succeeded.



Any ideas?



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New faulty DS18B20

[Mick Sulley]

Yes it does.  I also have a DS18S20 inside the test box that I use, that 
shows as well.  I have just tried a different DS2401 and get the same 
results.


On 03/08/2019 23:41, Jan Kandziora wrote:

Am 03.08.19 um 22:57 schrieb Mick Sulley:

I recently bought 4 DS18B20 sensors from eBay.  When I received them
they did not work, that is they did not show up on the bus when
connected to a DS9490 USB adapter.  I reported it to the seller and got
a refund.  I then ordered 10 from another seller on eBay, just tested
those and none of them work.  I have tried testing a known good sensor
and that shows up as expected.

Have I just been unlucky?  Has anyone else bought sensors which do not
work?  Can anyone recommend a supplier whose sensors do work?


Does the DS2401 iButton inside the DS9490 adapter show up? Chances are
you blew up the DS9403 protection diode or the EMI choke in the GND line.

Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] New faulty DS18B20

[Mick Sulley]

I recently bought 4 DS18B20 sensors from eBay.  When I received them 
they did not work, that is they did not show up on the bus when 
connected to a DS9490 USB adapter.  I reported it to the seller and got 
a refund.  I then ordered 10 from another seller on eBay, just tested 
those and none of them work.  I have tried testing a known good sensor 
and that shows up as expected.


Have I just been unlucky?  Has anyone else bought sensors which do not 
work?  Can anyone recommend a supplier whose sensors do work?


Thanks

Mick




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 1-wire hubs

[Mick Sulley]

Yes indeed, this was the message

I have a Hobyboards 6 channel hub which has been in my drawer for many 
years.  I did use it but changed over to a Sheepwalk RPi3 ages ago 
because that works directly with a Pi.  I have been meaning to put it on 
eBay but never got around to it, do you want it?


Cheers

Mick

On 22/07/2019 14:20, Jim Duda wrote:

Hi,

Someone sent me a private email regards having an extra hobbyboards hub.
I just happened to notice it got into my spam folder.
I went to respond, but somehow lost the email.

If you are listening, can you try again please?
I am indeed interested.

Regards,

Jim


On 7/20/19 10:52 AM, Jim Duda wrote:

Hello,

I have a 6 port 1-wire HUB that I purchased years ago from hobbyboards.com
I think the device has finally stopped working.
Hobbyboards hasn't come back online yet.

Can anyone offer any advice on any available 1-wire hub devices for sale?

The only one I can find is from unipi.
https://www.unipi.technology/1-wire-8-port-hub-p31

Any advice appreciated.

Regards,

Jim





___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] DS18S20 fault again

[Mick Sulley]

I just had another DS18S20 sensor giving me strange readings, but this 
time it was fairly easy to access, so I was able to physically feel how 
hot it was.


My web page is based upon the latesttemp value.  The pipe it measures 
would be at around 25 degrees give or take a bit.  I saw it go to over 
50 degrees and so removed the insulation and a finger test on the sensor 
showed the expected 25 or so.  I took some screenshots of the owhttpd 
screen over about 2 minutes.


The screenshots show

latesttemp 127.688    8.875    -1.5    127.688

temperature 24.9375    24.0625    23.5625    23.375

So temperature is about right, but latesttemp is wildly out.  I always 
thought that latesttemp was derived from temperature, temperature9, 
temperature10, temperature11, temperature12 on a DS18B20 and just from 
temperature on a DS18S20, but that is not what I am seeing here.


I have always considered the DS18S20 and DS18B20 to be similar enough to 
not really prefer one over the other.  Is that true or is one better in 
terms of accuracy, reliability or any other factor?


Thanks

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] bus interface statistics

[Mick Sulley]

Thank you both for your input.  I agree, I do not like the scheduled 
power cycle option either and I continue to look for the root cause of 
the issue.


The reason I considered a scheduled power cycle is that it seems that 
after a power cycle I do not see any errors, then over a few days or 
weeks I start to see errors, 85 reads, device not found, etc and then I 
get a lockup, although the timing is very variable.


I do have heartbeat file which is monitored by another machine, so I 
will look at using that to power cycle it.


One other thought, I have separate power supplies for 1-wire and the 
Pi.  Can I just power cycle the 1-wire adapter and leave the Pi running?



On 13/07/2019 19:58, Stefano Miccoli via Owfs-developers wrote:



On 11 Jul 2019, at 23:10, Mick Sulley <mailto:m...@sulley.info>> wrote:


The reason for the question is that I still have random bus lockups 
and I am considering creating something to power cycle the system, 
either on a time basis, e.g. 3am each day, or based on some early 
warning detection from the data in interface/statistics if that is 
possible.


Does anyone have an opinion on scheduled power cycle?  Good idea or not?


This make sense only if you are sure that the bus lockups are **not** 
random, but somehow occur only after some time has elapsed from the 
last power cycle, and this time is longer than one day.


On the contrary if the lookups are truly random, then a reboot every 
24h just ensures that the longest down-time is less than 24h. If it is 
impossible to avoid random lookups then the most sensible solution 
would be a watchdog timer. This way you  can ensure that bus down time 
is shorter that the watchdog time interval itself.


Stefano


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] bus interface statistics

[Mick Sulley]

Looking at my system via owhttpd at top level I can see all the devices 
and some other things -


bus.0 seems to mean the bus structure, so in there I can see bus.0 to 
bus.7  In each of these I see just the devices on that bus plus 
interface, simultaneous and alarm, and drilling down into 
interface/statistics there is more data


Is there any documentation on the data in there?

The reason for the question is that I still have random bus lockups and 
I am considering creating something to power cycle the system, either on 
a time basis, e.g. 3am each day, or based on some early warning 
detection from the data in interface/statistics if that is possible.


Does anyone have an opinion on scheduled power cycle?  Good idea or not?

Thanks

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] DS18S20 fault Question

[Mick Sulley]

Yes all of my sensors are powered.  I will do more investigation.  
Thanks for the comments


On 19/06/2019 09:19, Matthias Urlichs via Owfs-developers wrote:

On 19.06.19 09:39, Jan Kandziora wrote:

The 1W host has to supply current to the 1W line to power all the
parasitic powered slave devices.

Well, the solution is to not parasitically power anything.

Of course you can't do that with DS2401 switches or iButtons, but the
other 1wire ICs have Vcc pins for a reason.




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] DS18S20 fault Question

[Mick Sulley]

My system comprises multiple DS18S20, DS18B20 temperature sensors, some 
DS2438 I/O modules and a DS2437 to measure system voltage.


The voltage normally sits at around 5.1 volts, up to maybe 5.15 when no 
outputs are on, down to 4.95 with several outputs on.


A while back I saw the voltage drop to 4.82 and it stayed low even with 
the outputs off.  Power cycle and it was back to normal again.


I have just seen this happen again, but this time I noticed something 
else.  I have a DS18S20 in the loft space and it was reading 63 degrees 
C, but the actual temperature was more like 23 - 24.  Again the voltage 
stayed low even with all outputs off.


I power cycles it and the voltage came back to normal and the DS18S20 in 
the loft space dropped to 23 degrees, which seems correct.


The system takes around 8-10 seconds to run through everything

Looking at the logs I see

21 deg 5.04 volts - all is fine!
85 deg 4.82 volts - read failure
37 deg 4.82 volts - seems to be reading OK but value is high
rises to 50 deg over the next 60 seconds
rises to 60 deg over the next few hours
Power cycle
34 deg 5.14 volts - all seems OK but temp still high
drops to 24 deg over the next 5 minutes, which seems correct

So the question is - is it possible to have a fault on a DS18S20 which 
can cause it to heat up and pull the voltage down?


Thanks

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] DS2437 / DS2438 Question

[Mick Sulley]

I have a humidity sensor which has been running for ages, it has a 
DS2438 chip, at least that is what the Sheepwalk site says and it 
returns that on read so I guess that is right.  I have recently added 
voltage measurement to the system, using a chip which was ordered as a 
DS2438Z and is marked 24381E.  When I read the voltage chip it reports 
as DS2437.


Is it incorrectly marked?  Can anyone shed any light on this?

I guess this does not really matter, but it is confusing.

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Pi Crash Question

[Mick Sulley]

Hi Jan,

Thanks for your help - again!

I started to unplug parts of the network, didn't make any difference, 
then I remembered that I had seen this before, dug back in my emails and 
we had a similar email conversation in 2017.  By default (I think) 
Raspbian starts w1 and that interferes with owfs.  In case anyone else 
picks up this thread this is what I did to prevent w1 from running


edit /boot/config.txt  and comment out the line

    dtoverlay=w1-gpio

reboot

I was seeing that message about every minute.  It is now an hour since I 
made the change and there hasn't been a single one!


A couple of other questions,

 * Could this issue have caused the Pi itself to crash?
 * I know that due to the nature of 1-wire read failures will happen
   occasionally, but what is the expected failure rate roughly?

Thanks

Mick


On 20/04/2019 19:50, Jan Kandziora wrote:

Am 20.04.19 um 16:47 schrieb Mick Sulley:

I just had the Pi on my main control system crash.  Looking through
syslog there are load of entries like -

Apr 20 14:47:35 pi-solar kernel: [1816089.721179] w1_master_driver
w1_bus_master1: Family 0 for 00.c611.3f is not registered.
Apr 20 14:48:00 pi-solar kernel: [1816114.723725] w1_master_driver
w1_bus_master1: Family 0 for 00.2611.d6 is not registered.
Apr 20 14:48:51 pi-solar kernel: [1816165.440416] w1_master_driver
w1_bus_master1: Family 0 for 00.a611.5a is not registered.

I think this is 1-wire related


But not OWFS related. These are messages from within the kernel driver.
It specially complains about unregistered device classes. Which is
connected to some problem with your bus, in this case.

Split the bus into pieces and check when the problems disappear. It may
be some problem with your external power supply.

Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Pi Crash Question

[Mick Sulley]

I just had the Pi on my main control system crash.  Looking through 
syslog there are load of entries like -


Apr 20 14:47:35 pi-solar kernel: [1816089.721179] w1_master_driver 
w1_bus_master1: Family 0 for 00.c611.3f is not registered.
Apr 20 14:48:00 pi-solar kernel: [1816114.723725] w1_master_driver 
w1_bus_master1: Family 0 for 00.2611.d6 is not registered.
Apr 20 14:48:51 pi-solar kernel: [1816165.440416] w1_master_driver 
w1_bus_master1: Family 0 for 00.a611.5a is not registered.


I think this is 1-wire related

My setup is a Sheepwalk RPi3 and splitter, with about 30 DS1820 temp 
sensors and 7 DS2413 I/O boards, Pi and 1-wire are separately powered by 
Meanwell units


I have rebooted and it seems to be running OK, but checking syslog again 
I see


Apr 20 14:17:25 pi-solar kernel: [   20.147355] w1_master_driver 
w1_bus_master1: w1_search: max_slave_count 64 reached, will continue 
next search.


and then there are more like -

Apr 20 15:26:42 pi-solar kernel: [  261.951010] w1_master_driver 
w1_bus_master1: Family 0 for 00.2000.23 is not registered.
Apr 20 15:27:45 pi-solar kernel: [  325.543636] w1_master_driver 
w1_bus_master1: Family 0 for 00.a000.af is not registered.
Apr 20 15:28:23 pi-solar kernel: [  363.463636] w1_master_driver 
w1_bus_master1: Family 0 for 00.6000.65 is not registered.


I confess I don't understand the messages, could they be the cause of 
the crash?  Is there a problem with my 1-wire?


As always, I would be most grateful for any help and guidance.

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] DS2438 Question

[Mick Sulley]

I am using a DS2438 to measure my system +5v line and log it.  As I 
understand it the voltage measurement can be triggered by setting 
/simultaneous/voltage in the same way as for temperature. As I want to 
use both, can I set /simultaneous/voltage and /simultaneous/temperature 
together or should I set one then wait 1 sec before setting the other?


Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Strange read failure

[Mick Sulley]

Ahhh!!!  I always refer to the descriptions on owfs.org, which don't 
show tempres so I hadn't realised that it existed.


So I assume that the resolution comments refer to the DS18B20, but the 
DS18S20 is 12 bit and no possibility to change it.


If I set tempres to say 11, then write to /simultaneous/temperature will 
it then read at 11 bit and update latesttemp and temperature11?


Thanks

Mick

On 10/03/2019 19:24, Jan Kandziora wrote:

Am 10.03.19 um 19:46 schrieb Mick Sulley:

OK, but looking through Jan's checklist again -

* power all sensors
* set the sensor EEPROM to 9 bit default resolution.

         ?? How to do that? Is it just a read temperature9 on DS18B20?
With recent OWFS, you simply write 9 to the sensor's tempres node.



Then, the readout thread is as follows:

1. trigger a 12-bit resolution conversion on each sensor for
initialization.
2. write something to /simultaneous/temperature to trigger all
temperature conversions at the same time.
3. wait a second
4. read /uncached//latesttemp of each sensor
5. If the result for a sensor is not 85°C, store and go to 2.
6. 85°C. Check the resolution. If it is still 12 bit, that's a valid
reading. Store and go to 2.

         ?? How do I check the resolution?


Read the sensor's uncached tempres node.

Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Strange read failure

[Mick Sulley]

OK, but looking through Jan's checklist again -

* power all sensors
* set the sensor EEPROM to 9 bit default resolution.

        ?? How to do that? Is it just a read temperature9 on DS18B20?

Then, the readout thread is as follows:

1. trigger a 12-bit resolution conversion on each sensor for initialization.
2. write something to /simultaneous/temperature to trigger all
temperature conversions at the same time.
3. wait a second
4. read /uncached//latesttemp of each sensor
5. If the result for a sensor is not 85°C, store and go to 2.
6. 85°C. Check the resolution. If it is still 12 bit, that's a valid 
reading. Store and go to 2.


        ?? How do I check the resolution?

7. Power-on-reset. Store an error. Trigger a 12-bit resolution
conversion for that sensor and go to 2.

Thanks

Mick

On 10/03/2019 15:01, Colin Law wrote:

On Sun, 10 Mar 2019 at 14:57, Mick Sulley  wrote:

How do I set the resolution?

I always fetch the data at the maximum resolution.  If you want to
limit it for display purposes then do it when you display it.  There
is no point in throwing away data when you are acquiring it.

Colin


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Strange read failure

[Mick Sulley]

OK I have now reconfigured my system so that all the I/O modules are 
individually powered rather than over the 1- wire cabling, which I am 
hoping will improve reliability.  Also all sensors are powered.  Now to 
get back to the other issues.


How do I set the resolution?  Looking at the DS18B20 manual it says that 
it is done via the scratchpad, but I have no idea how to do that.  My 
code is all python, so I guess I can write the necessary value to the 
scratchpad at startup, but what do I write?  The DS18B20 manual on 
GitHub does not mention the scratchpad.


Thanks

Mick

On 19/02/2019 17:38, Jan Kandziora wrote:

Am 19.02.19 um 14:35 schrieb Mick Sulley:

The failure happened for about 10-20 minutes, reading about every 10
seconds or so, then it recovered and is reading fine again.

All devices are powered.

I could change my code so that it reads fasttemp and if that is 85 it
reads through the others to try to find a good read.  Is that a sensible
thing to do?


What I recommend to do for preparation is:

* power all sensors
* set the sensor EEPROM to 9 bit default resolution.

Then, the readout thread is as follows:

1. trigger a 12-bit resolution conversion on each sensor for initialization.
2. write soemthing to /simultaneous/temperature to trigger all
temperature conversions at the same time.
3. wait a second
4. read /uncached//latesttemp of each sensor
5. If the result for a sensor is not 85°C, store and go to 2.
6. 85°C. Check the resolution. If it is still 12 bit, that's a valid
reading. Store and go to 2.
7. Power-on-reset. Store an error. Trigger a 12-bit resolution
conversion for that sensor and go to 2.


Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] DS9503 Question

[Mick Sulley]

Hi Joe,

Crossed wires I think (forgive the pun).  I believe Paul is talking 
about the Sheepwalk Electronics RPi3 adapter, which is an 8 bus 1-wire 
hat for the Pi, rather than the Pi itself.  It is the RPi3 that I am using.


Mick

On 04/03/2019 23:54, joep wrote:


Hi Paul,

    Like Mick I am not an expert in electronics - just know enough to 
get out of trouble when that happens.


    I've checked several schematics of RaspberryPi 3 boards and could 
not locate any DS9503 on them.


    The DS9490R (USB_to_1-wire adaptor) however does have a DS9503 
protection unit on its single 1-wire channel. So if Mick is using one 
of these he needn't worry about adding one. If he's driving the 1-wire 
bus directly from a microcontroller of some sort then that's a 
different matter.


Regards
Joe P.
On 1/3/19 5:13 am, Paul Everett wrote:

Hi Mick,

I’m not sure if you have any other masters but your RPI3 boards 
already have a DS9503 on each channel.


Paul

On 28 Feb 2019, at 14:14, Mick Sulley <mailto:m...@sulley.info>> wrote:


I know this is a very basic question, but my electronics knowledge 
is not great.


Following on from recent discussions re adding DS9503 to increase 
reliability I am trying to design a PCB for them. Looking at the 
diagram on page 2 of the spec sheet 
(https://datasheets.maximintegrated.com/en/ds/DS9503.pdf)




my understanding is that pin 1 is the signal line out to the 
devices, pin 2 is the ground to devices, pin 5 is the ground to the 
adapter and pin 6 is the signal line to the adapter.


I assume that I need to add the two 5 ohm resistor at pins 1 and 2.  
Also there is no need for a resistor in the 5v line? Like this -




Is that correct?

What power rating resistors are needed?

Thanks

Mick

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] DS9503 Question

[Mick Sulley]

Thanks Paul, that has saved me some work!

On 28/02/2019 18:13, Paul Everett wrote:

Hi Mick,

I’m not sure if you have any other masters but your RPI3 boards 
already have a DS9503 on each channel.


Paul

On 28 Feb 2019, at 14:14, Mick Sulley <mailto:m...@sulley.info>> wrote:


I know this is a very basic question, but my electronics knowledge is 
not great.


Following on from recent discussions re adding DS9503 to increase 
reliability I am trying to design a PCB for them. Looking at the 
diagram on page 2 of the spec sheet 
(https://datasheets.maximintegrated.com/en/ds/DS9503.pdf)




my understanding is that pin 1 is the signal line out to the devices, 
pin 2 is the ground to devices, pin 5 is the ground to the adapter 
and pin 6 is the signal line to the adapter.


I assume that I need to add the two 5 ohm resistor at pins 1 and 2.  
Also there is no need for a resistor in the 5v line? Like this -




Is that correct?

What power rating resistors are needed?

Thanks

Mick

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] DS9503 Question

[Mick Sulley]

I know this is a very basic question, but my electronics knowledge is 
not great.


Following on from recent discussions re adding DS9503 to increase 
reliability I am trying to design a PCB for them. Looking at the diagram 
on page 2 of the spec sheet 
(https://datasheets.maximintegrated.com/en/ds/DS9503.pdf)


https://datasheets.maximintegrated.com/en/ds/DS9503.pdf

my understanding is that pin 1 is the signal line out to the devices, 
pin 2 is the ground to devices, pin 5 is the ground to the adapter and 
pin 6 is the signal line to the adapter.


I assume that I need to add the two 5 ohm resistor at pins 1 and 2.  
Also there is no need for a resistor in the 5v line? Like this -


My circuit

Is that correct?

What power rating resistors are needed?

Thanks

Mick

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Suggestions of Microcontrollers for 1-wire use.

[Mick Sulley]

I have been using Pi's since they started and yes, I have had multiple 
SD failures.  I now run mine from hard drives which I have recovered 
from dead laptops.  The new Pi's can be set to boot from a hard drive, 
the older ones you still need an SD but it is only used at boot to 
redirect to the hard drive.


On 21/02/2019 03:38, joep wrote:


Hi All,

    To some extent this follows from thread: *Reliability and 
Robustness of the DS2482-100 or DS2482-800*


    I've been using a couple of Raspberry Pi's (RPi 1 Model A+) to 
manage the temperature, humidity and lighting in a terrarium since 
2014/2015. One Pi is in active use while the other is used as a 
development platform to try things out on. Overall I'm impressed by 
how much one can do without spending a fortune and I'm quite keen to 
explore further.


    One thing which always bothered me with the Pi's is the SD card. 
I've had a few corruptions (all power supply related). Even with a 
clean and stable supply I am still doubtful if one can achieve 
"industrial grade" reliability if using SD cards. So I'm now looking 
for other microcontroller options to control my 1-wire based system as 
I'm intending to extend management to my greenhouses where reliability 
is more important.


    Options I have looked at so far include the Arduino (Uno, Zero or 
DUE) and the ESP32. Haven't fully explored the latter but it seems to 
have an incredible number of interfaces. I'm quite impressed by the 
Arduino - it's simple, there's a big choice of units and it's easily 
extensible (with a lot of pre-built modules available). My design will 
involve power switching and (ideally) more than one 1-wire bus (so a 
DS2482-100 is likely to be involved). The system will also interface 
to my network for monitoring and management.


    What are your opinions re. suitable microcontrollers where 
reliability and ease of extensibility are requirements.


--
Regards
Joe P.


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Strange read failure

[Mick Sulley]

The failure happened for about 10-20 minutes, reading about every 10 
seconds or so, then it recovered and is reading fine again.


All devices are powered.

I could change my code so that it reads fasttemp and if that is 85 it 
reads through the others to try to find a good read.  Is that a sensible 
thing to do?


Thanks

Mick

On 19/02/2019 12:49, Jan Kandziora wrote:

Am 19.02.19 um 10:39 schrieb Mick Sulley:

My control system has detected a no read (85) on a DS18B20 temp sensor,
however if I look at it via owhttpd I can see temperature, temperature11
and temperature12, but 85 for fasttemp, temperature9 and temperature10.

How can that happen?  The sensor had been working OK.  I am running
3.2p3 on a Raspberry Pi


Each reading of the uncached temperature nodes (but latesttemp) triggers
a new conversion. The browser orders owhttpd to do exactly that. What
you see isn't one conversion but a series of conversions of which some
failed because of a Power-On-Reset during conversion (that's the 85°C
reading) and some failed not.

Check your cabling. Also check if powering the chip helps.

Kind regards

Jan


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Strange read failure

[Mick Sulley]

My control system has detected a no read (85) on a DS18B20 temp sensor, 
however if I look at it via owhttpd I can see temperature, temperature11 
and temperature12, but 85 for fasttemp, temperature9 and temperature10.


How can that happen?  The sensor had been working OK.  I am running 
3.2p3 on a Raspberry Pi


Here is what I see


 uncached/Boiler_Flow


|*up*|    directory
*address*   28C0A9A104F9
*alias* 

*crc8*  F9
*errata*errata 
*family*28
*fasttemp*  85
*id*C0A9A104
*latesttemp*85
*locator*   
*power* YES (1)
*r_address* F904A1A9C028
*r_id*  04A1A9C0
*r_locator* 
*scratchpad*

50054B467FFF0C101C

*temperature*   66.375
*temperature10* 85
*temperature11* 66.375
*temperature12* 66.375
*temperature9*  85
*temphigh*  

*templow*   

*tempres*   

*type*  DS18B20

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Reliability and Robustness of the DS2482-100 or DS2482-800

[Mick Sulley]

So adding a DS9503 in each of the busses on a DS2482-800 should stop 
lock-up problems?



On 17/02/2019 22:13, Alastair D'Silva wrote:

The series resistance within a DS9503 should be sufficient, I hope. It's worth 
using these anyway, for ESD protection.




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] DS18B20 Question

[Mick Sulley]

I had a temperature sensor fail and replaced it but I am seeing strange 
results from the new one.


This is what I see.  Why do Temperature 11 & 12 seem OK but 9, 10 and 
Lasttemp are all 85?  Is it a bad sensor?


*address*   2848999D046C
*alias* 

*crc8*  6C
*errata*errata 

*family*28
*fasttemp*  85
*id*48999D04
*latesttemp*85
*locator*   
*power* YES (1)
*r_address* 6C049D994828
*r_id*  049D9948
*r_locator* 
*scratchpad*

50054B467FFF0C101C

*temperature*   20.4375
*temperature10* 85
*temperature11* 20.4375
*temperature12* 20.4375
*temperature9*  85
*temphigh*  

*templow*   

*tempres*   

*type*  DS18B20

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Power Supply Question

[Mick Sulley]

Hi Jan,

Many thanks for your words of wisdom, I will take them on board.

You say that the DS2482-800 can reset to an unusable state, would the 
same apply to the DS2482-100?  Sheepwalk now make a dual channel RPi2 
and I could stack 2 to get 4 channels and I think I could manage with 
that if the lock up problem is fixed.


Thanks

Mick

On 20/10/2018 18:00, Jan Kandziora wrote:


About the bus lock-up, that's a bug in the DS2482-800, I think. I had
it. Various other people had it. The DS2482-800 seems to be susceptible
to supply undervoltage and slow rising of the supply voltage. It resets
into an unuseable state. Only a complete power-down and quick power-on
will make it useable again.

Kind regards

Jan




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Power Supply Question

[Mick Sulley]

I have a Pi with Sheepwalk RPi3 adapter running multiple temperature and 
I/O.  I get random read failures and bus lock up, read failures every 
day or two, bus lock up every week or so. Currently I have separate 
power supplies (Meanwell units) for the Pi and the 1-wire and they are 
both floating.


Question - Is there an advantage in linking the 0v on the two supplies?  
Also should the 0v be connected to the mains earth?


Thanks

Mick



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 1-wire Capacitors Question

[Mick Sulley]

Thanks for the reply.

Yes the adapter is based upon the DS2482-800.  What value of capacitor 
and should it be at the adapter or the far end of the bus?  Do I just 
need one or one on each bus?


Thanks

Mick


On 04/09/18 00:22, Laurent FAILLIE via Owfs-developers wrote:

Hi,

If the "" is based on DS2482-800, you need an efficient decoupling 
capacitor b/w it'sVcc and GND pins and/or a very stable power supply.


I faced such issue some weeks back (shared on this list), and securing 
my GND path + a decoupling capacitor seem having corrected this issue.


Bye

Laurent



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] 1-wire Capacitors Question

[Mick Sulley]

I have been plagued by a problem with one of my control systems for a 
number of years now and I am still trying to fix it.  I have posted a 
few times before, and following suggestions I have replaced some of the 
cabling and replaced the power supplies with Meanwell MDR-20-5 units


Running 3.1p5 on a Raspberry Pi with Sheepwalk RPi3 adapter and RPi3a 
splitters giving 8 busses, 27 DS1820 temperature sensors, 1 humidity 
sensor and 7 DS2413 based I/O modules, spread over the 8 busses.  All 
devices are powered


The problem I have is that I loose usually 2 of the busses, but 
occasionally all of them, they just stop reading and need a power cycle 
to restart.  It is random, can be a few hours up to a couple of months 
between failures.


I have seen suggestions to add a capacitor to help fix this sort of 
issue, I thought I remembered seeing something in a Maxim document but 
cannot find it now.  Can anyone tell me where I can find information on 
this, what value capacitor, should it be between +5v and Gnd or DQ and 
Gnd, at the adapter or at the far end, on every bus?


Thanks

Mick


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] DS2482-800 reset ?

[Mick Sulley]

Hi Laurent,

I suffered for several years with a similar issue, I have an 8 bus 
system and I would loose 1 or more of the busses, the only way to 
recover was to power cycle.  From what I have read I don't believe that 
there is any other way to reset a DS2482.


Over that time I tried all sorts of things to fix the problem, it was 
random, could be a month or more between failures, could be less than a day.


The good news is that I have finally tracked it down and fixed it 
(fingers crossed as I type this!).  It is a long story, I will post the 
details when I have more time, but the basic problem was mains noise 
caused by a soft start unit on a pump.  I would recommend using good 
quality power supplies, I used Meanwell MDR-20-5 units, not cheap but 
worthwhile if it fixes the problem.


You say it happens from time to time, can you identify anything that may 
have switched on or off at the same time?  Can you put an oscilloscope 
on the mains to check for noise?


Hope this helps, I know how frustrating it can be.

Mick


On 26/07/18 09:07, Laurent FAILLIE via Owfs-developers wrote:

Hello,

Is it a way to issue a reset command to a DS2482-800 ?
I'm driving my home automation using this chips and time to time, I'm 
loosing all my probe.

The chip is still detected by
# i2cdetect -y 2
 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: -- -- -- -- -- -- -- --

The only solution is a power cycle on the chip :(

Thanks


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] System Lock-up again

[Mick Sulley]

Thanks for the replies guys.

I currently use separate power supplies for 1-wire and Pi.  Is it 
considered better to split them?


Colin, can you give me details of you power management board please?

Matthias, I have just looked through the Meanwell site but cannot see 
any that are adjustable (may have missed it there are a lot there), can 
you tell me which one you used please?


Thanks for your help

Mick


On 24/09/17 17:08, Colin Reese wrote:

So many problems come from there. I use a power management board with boost 
converter and lipo for this reason. Deals with outages as well with graceful 
shutdown.

C


On Sep 24, 2017, at 7:56 AM, Matthias Urlichs via Owfs-developers 
 wrote:


On 24.09.2017 12:38, Mick Sulley wrote:
Any suggestions on how I can find out what is causing this.

When I had this problem, the root cause was a flaky power supply.

Get a cap-rail-mounted adjustable 5V power supply (e.g. from Meanwell).
Connect the Pi, then carefully adjust the voltage up to 5.15V. That's
still well within spec (+5% tolerance means 5.25V) but helps a lot when
you have transient problems.

The affected Pi didn't have any more hiccups after I did that.

Also, add a 0.1µF ceramic cap between 5V and ground of the 1wire lines,
close to the Pi, to buffer spikes from out there.

--
-- Matthias Urlichs


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] System Lock-up again

[Mick Sulley]

Several months back I posted about a system lock up problem, Pi 3 
running owserver etc 3.1p5 with Sheepwalk
RPi3 adapter and RPi3a splitters giving me 8 busses. All devices are 
powered, separately from the Pi.  I use python code and pyownet to 
monitor and control a mixture of about 35 DS1820 and DS2413


The problem was that I would loose all busses and it needed a power 
cycle of the 1-wire to get it going again.


After trying a few things to fix it I replaced the longest cable run, 
which had a couple of joints in it.  It then worked, but in order to try 
to tied down exactly what the problem was I set up a second Pi, as near 
as possible just like the first, and used the old suspect cable run.  
Logically one of them should have failed as the fault should still be 
there on one of them.  Neither failed for several months, the second one 
sill hasn't.


Last week the main Pi failed again, I could not investigate at the time 
so power cycles and it ran again.


Today it has failed again, same problem, loose all busses.  This time I 
power cycled the 1-wire but left the Pi running, the fault remained.  I 
then rebooted the Pi without further power cycle of Pi or 1-wire and it 
started up again.


I really have no idea what to do next.  Any suggestions on how I can 
find out what is causing this.  I am considering using another Pi to 
detect the problem and auto power cycle the main one, but this does not 
sound like a good solution so I am open to suggestions


Thanks

Mick


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] 1-wire problem - Again

[Mick Sulley]

Hi People,

Looking for suggestions here.

My system runs on a Raspberry Pi with a Sheepwalk RPi3 adapter and RPi3a 
splitters giving me 8 busses, with about 20 temperature sensors and 6 
I/O modules, all powered.  I was having a few problems loosing one or 
more busses, after some investigation I split the power so I have a 
power supply for the Pi and a separate supply for the 1-wire.


I had been running without any problems for the last couple of weeks, 
until today, when again it locked up, lost all channels. That has 
happened 3 times today.


When it happens running owdir returns the standard /uncached /settings 
/system, etc but no devices.  Reboot makes no difference, power cycle 
and it all works again.


I swapped the RPi3 adapter for a spare after the second failure, so I 
think that is eliminated.  I have checked syslog, nothing significant 
there.  1-wire is running at 4.95v which I would think is OK.


My own logging shows this sort of thing, this is for DHW_Top, it is 
repeated for the other devices


 [Errno 2] legacy - No such 
entity: u'DHW_Top/latesttemp'
 [Errno 1] Startup - command 
line parameters invalid: u'DHW_Top/power'


I don't understand how it can run for about 2 weeks without a fault and 
then have 3 in a few hours.


Any ideas what the problem could be?  How to fault find further?

One further thought, I have one temperature sensor which would work 
sometimes but for periods of sometimes several days I could not read 
it.  Is it possible that that single sensor could bring down hte whole 
network?  I have just disconnected it.


Any suggestions gratefully received

Mick


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] System Lock-up?

[Mick Sulley]

Thanks for your comments Jan, not what I wanted to hear but I'm sure you 
are correct.  The last time I used an oscilloscope I was in college and 
had to wait for the valves to warm up before it would work :)


I do have a spare RPi3 adapter so I will try that first and see what the 
log says then.


Mick


On 27/05/17 17:00, Jan Kandziora wrote:

Am 27.05.2017 um 10:02 schrieb Mick Sulley:

There are loads of messages like this


May 25 08:21:32 pi-solar kernel: [1007793.425520] w1_master_driver
w1_bus_master1: Family 0 for 00.ec8a.82 is not registered.
May 25 08:22:21 pi-solar kernel: [1007842.625340] w1_master_driver
w1_bus_master1: Family 0 for 00.1c8a.f6 is not registered.
May 25 08:23:08 pi-solar kernel: [1007889.965685] w1_master_driver
w1_bus_master1: Family 0 for 00.9c8a.7a is not registered.
May 25 08:23:44 pi-solar kernel: [1007925.365323] w1_master_driver
w1_bus_master1: Family 0 for 00.5c8a.b0 is not registered.


There is no "Family 0". Your setup is broken. Either the kernel is bogus
or your host adaptor.



That is before the problem, but then at the time of the problem it
changes to this

May 26 09:59:23 pi-solar kernel: [74474.176012] w1_master_driver
w1_bus_master1: Family 0 for 00.0060.5a is not registered.


This looks horribly wrong. I doubt there is any chip with that ID out there.



May 26 09:59:23 pi-solar rsyslogd-2007: action 'action 17' suspended,
next retry is Fri May 26 09:59:53 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:00:21 pi-solar kernel: [74532.526719] w1_master_driver
w1_bus_master1: Family 0 for 00.8060.d6 is not registered.


Same here.



May 26 10:00:21 pi-solar rsyslogd-2007: action 'action 17' suspended,
next retry is Fri May 26 10:00:51 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:00:57 pi-solar kernel: [74568.786610] w1_master_driver
w1_bus_master1: Family 0 for 00.4060.1c is not registered.


Same here.



May 26 10:00:57 pi-solar rsyslogd-2007: action 'action 17' suspended,
next retry is Fri May 26 10:01:27 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:01:34 pi-solar kernel: [74605.158192] w1_master_driver
w1_bus_master1: Family 0 for 00.c060.90 is not registered.


Same here.



Any ideas.


This pretty much looks like random jitter on your bus line which is
mistaken for being chip ideas.

Hook up an oscilloscope to your bus line and look for serious jitter.

Kind regards

Jan





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] System Lock-up?

[Mick Sulley]

No usb messaged, but 1-wire is via a Sheepwalk RPi3 adapter and RPi3a 
splitter



On 27/05/17 11:12, Colin Law wrote:

No USB related messages at the time of failure?

Colin

On 27 May 2017 at 09:02, Mick Sulley  wrote:

There are loads of messages like this


May 25 08:21:32 pi-solar kernel: [1007793.425520] w1_master_driver
w1_bus_master1: Family 0 for 00.ec8a.82 is not registered.
May 25 08:22:21 pi-solar kernel: [1007842.625340] w1_master_driver
w1_bus_master1: Family 0 for 00.1c8a.f6 is not registered.
May 25 08:23:08 pi-solar kernel: [1007889.965685] w1_master_driver
w1_bus_master1: Family 0 for 00.9c8a.7a is not registered.
May 25 08:23:44 pi-solar kernel: [1007925.365323] w1_master_driver
w1_bus_master1: Family 0 for 00.5c8a.b0 is not registered.

That is before the problem, but then at the time of the problem it changes
to this

May 26 09:59:23 pi-solar kernel: [74474.176012] w1_master_driver
w1_bus_master1: Family 0 for 00.0060.5a is not registered.
May 26 09:59:23 pi-solar rsyslogd-2007: action 'action 17' suspended, next
retry is Fri May 26 09:59:53 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:00:21 pi-solar kernel: [74532.526719] w1_master_driver
w1_bus_master1: Family 0 for 00.8060.d6 is not registered.
May 26 10:00:21 pi-solar rsyslogd-2007: action 'action 17' suspended, next
retry is Fri May 26 10:00:51 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:00:57 pi-solar kernel: [74568.786610] w1_master_driver
w1_bus_master1: Family 0 for 00.4060.1c is not registered.
May 26 10:00:57 pi-solar rsyslogd-2007: action 'action 17' suspended, next
retry is Fri May 26 10:01:27 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:01:34 pi-solar kernel: [74605.158192] w1_master_driver
w1_bus_master1: Family 0 for 00.c060.90 is not registered.
May 26 10:01:34 pi-solar rsyslogd-2007: action 'action 17' suspended, next
retry is Fri May 26 10:02:04 2017 [try http://www.rsyslog.com/e/2007 ]

The action 17 may be nothing related, don't know.  I have looked at
http://www.rsyslog.com/e/2007 and it didn't help me much.

Any ideas?

Thanks
Mick



On 27/05/17 08:24, Colin Law wrote:

Have a look in /var/log/syslog and see if there are any interesting
messages around the time of failure. If syslog does not go back far
enough look in /var/log/syslog.1

Colin

On 26 May 2017 at 21:35, Mick Sulley  wrote:

Thanks for your comments Matthias.  It happened again today, same
channels I
think.  Could it be temperature related?  The Pi etc is in the loft and
it
was around 40C in there today, so the Pi would be somewhat above that.

Mick



On 09/03/17 10:15, Mick Sulley wrote:

My system is Raspberry Pi 3 running owserver etc 3.1p5 with Sheepwalk
RPi3 adapter and RPi3a splitters giving me 8 channels. All devices are
powered, separately from the Pi.  I use python code and pyownet to
monitor and control a mixture of about 35 DS1820 and DS2413

The system has been running fairly successfully for several years, but
today it failed.  I think I can solve the basic failure, the thing that
puzzles me is that when I rebooted 2 of the 8 channels were missing.  I
rebooted again, checked the cabled, still the same two channels
missing.  I then shut it down and power cycled it and then all channels
were back again.

Is this a known issue?  Is there any way to reset a channel other than
power cycle?

Thanks

Mick




--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.l

Re: [Owfs-developers] System Lock-up?

[Mick Sulley]

There are loads of messages like this


May 25 08:21:32 pi-solar kernel: [1007793.425520] w1_master_driver 
w1_bus_master1: Family 0 for 00.ec8a.82 is not registered.
May 25 08:22:21 pi-solar kernel: [1007842.625340] w1_master_driver 
w1_bus_master1: Family 0 for 00.1c8a.f6 is not registered.
May 25 08:23:08 pi-solar kernel: [1007889.965685] w1_master_driver 
w1_bus_master1: Family 0 for 00.9c8a.7a is not registered.
May 25 08:23:44 pi-solar kernel: [1007925.365323] w1_master_driver 
w1_bus_master1: Family 0 for 00.5c8a.b0 is not registered.


That is before the problem, but then at the time of the problem it 
changes to this


May 26 09:59:23 pi-solar kernel: [74474.176012] w1_master_driver 
w1_bus_master1: Family 0 for 00.0060.5a is not registered.
May 26 09:59:23 pi-solar rsyslogd-2007: action 'action 17' suspended, 
next retry is Fri May 26 09:59:53 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:00:21 pi-solar kernel: [74532.526719] w1_master_driver 
w1_bus_master1: Family 0 for 00.8060.d6 is not registered.
May 26 10:00:21 pi-solar rsyslogd-2007: action 'action 17' suspended, 
next retry is Fri May 26 10:00:51 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:00:57 pi-solar kernel: [74568.786610] w1_master_driver 
w1_bus_master1: Family 0 for 00.4060.1c is not registered.
May 26 10:00:57 pi-solar rsyslogd-2007: action 'action 17' suspended, 
next retry is Fri May 26 10:01:27 2017 [try http://www.rsyslog.com/e/2007 ]
May 26 10:01:34 pi-solar kernel: [74605.158192] w1_master_driver 
w1_bus_master1: Family 0 for 00.c060.90 is not registered.
May 26 10:01:34 pi-solar rsyslogd-2007: action 'action 17' suspended, 
next retry is Fri May 26 10:02:04 2017 [try http://www.rsyslog.com/e/2007 ]


The action 17 may be nothing related, don't know.  I have looked at 
http://www.rsyslog.com/e/2007 and it didn't help me much.


Any ideas?

Thanks
Mick


On 27/05/17 08:24, Colin Law wrote:

Have a look in /var/log/syslog and see if there are any interesting
messages around the time of failure. If syslog does not go back far
enough look in /var/log/syslog.1

Colin

On 26 May 2017 at 21:35, Mick Sulley  wrote:

Thanks for your comments Matthias.  It happened again today, same channels I
think.  Could it be temperature related?  The Pi etc is in the loft and it
was around 40C in there today, so the Pi would be somewhat above that.

Mick



On 09/03/17 10:15, Mick Sulley wrote:

My system is Raspberry Pi 3 running owserver etc 3.1p5 with Sheepwalk
RPi3 adapter and RPi3a splitters giving me 8 channels. All devices are
powered, separately from the Pi.  I use python code and pyownet to
monitor and control a mixture of about 35 DS1820 and DS2413

The system has been running fairly successfully for several years, but
today it failed.  I think I can solve the basic failure, the thing that
puzzles me is that when I rebooted 2 of the 8 channels were missing.  I
rebooted again, checked the cabled, still the same two channels
missing.  I then shut it down and power cycled it and then all channels
were back again.

Is this a known issue?  Is there any way to reset a channel other than
power cycle?

Thanks

Mick



--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] System Lock-up?

[Mick Sulley]

Thanks for your comments Matthias.  It happened again today, same 
channels I think.  Could it be temperature related?  The Pi etc is in 
the loft and it was around 40C in there today, so the Pi would be 
somewhat above that.


Mick


On 09/03/17 10:15, Mick Sulley wrote:

My system is Raspberry Pi 3 running owserver etc 3.1p5 with Sheepwalk
RPi3 adapter and RPi3a splitters giving me 8 channels. All devices are
powered, separately from the Pi.  I use python code and pyownet to
monitor and control a mixture of about 35 DS1820 and DS2413

The system has been running fairly successfully for several years, but
today it failed.  I think I can solve the basic failure, the thing that
puzzles me is that when I rebooted 2 of the 8 channels were missing.  I
rebooted again, checked the cabled, still the same two channels
missing.  I then shut it down and power cycled it and then all channels
were back again.

Is this a known issue?  Is there any way to reset a channel other than
power cycle?

Thanks

Mick


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] System Lock-up?

[Mick Sulley]

My system is Raspberry Pi 3 running owserver etc 3.1p5 with Sheepwalk 
RPi3 adapter and RPi3a splitters giving me 8 channels. All devices are 
powered, separately from the Pi.  I use python code and pyownet to 
monitor and control a mixture of about 35 DS1820 and DS2413

The system has been running fairly successfully for several years, but 
today it failed.  I think I can solve the basic failure, the thing that 
puzzles me is that when I rebooted 2 of the 8 channels were missing.  I 
rebooted again, checked the cabled, still the same two channels 
missing.  I then shut it down and power cycled it and then all channels 
were back again.

Is this a known issue?  Is there any way to reset a channel other than 
power cycle?

Thanks

Mick


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem with compiling of the owfs on a raspberry pi

[Mick Sulley]

I think it is libusb-dev that is missing.

But do you really need 3.1p5  as you can easily get 3.1p4 from the repro 
using the notes that Jan kindly provided -


Edit (or create) your /etc/apt/preferences to contain:
--
Package: *
Pin: release o=Raspbian,a=stable
Pin-Priority: 500

Package: *
Pin: release o=Raspbian,a=testing
Pin-Priority: 300
--
This is important so you keep stable (Jessie) for all packages but the ones
explicitly taken from testing (Stretch).

Then, add a line
--
deb http://mirrordirector.raspbian.org/raspbian/ testing main contrib 
non-free rpi

--
to your /etc/apt/sources.list to get access to the Raspbian testing 
repository.


Do an

$ sudo apt-get update

to read the package metadata, then check

$ sudo apt-cache policy

whether the testing repo is there with priority 300. Then

$ sudo apt-get install -t testing owserver owhttpd ow-shell

That should install all you need, including the startup files and 
systemd units.

Note you have to edit /etc/owfs.conf again to contain (this and only this)
--
!server: server = localhost:4304
server: device=/dev/i2c-1
--
Restart the owserver and owhttpd service after that.




On 09/01/17 18:51, Johan Ström wrote:

Sounds like libusb is not found, but the include is there..
Try a search in the archives if you have not yet done so, I think this 
has been up before.


Johan

On January 9, 2017 6:55:27 PM GMT+01:00, Ritchie  wrote:

Dear all,

I am trying to compile the actual version (owfs-3.1p5) of owfs on a
raspberry pi and get the following error message during "make".

owusbprobe.o: In function `list_usb_devices_iter':
/usr/src/owfs-3.1p5/module/owshell/src/c/owusbprobe.c:149: undefined
reference to `libusb_strerror'
/usr/src/owfs-3.1p5/module/owshell/src/c/owusbprobe.c:159: undefined
reference to `libusb_strerror'
/usr/src/owfs-3.1p5/module/owshell/src/c/owusbprobe.c:154: undefined
reference to `libusb_strerror'
/usr/src/owfs-3.1p5/module/owshell/src/c/owusbprobe.c:132: undefined
reference to `libusb_strerror'
/usr/src/owfs-3.1p5/module/owshell/src/c/owusbprobe.c:135: undefined
reference to `libusb_strerror'
owusbprobe.o:/usr/src/owfs-3.1p5/module/owshell/src/c/owusbprobe.c:182:
more undefined references to `libusb_strerror' follow


Configure shows the following configuration at the end:

Current configuration:

  Deployment location: /opt/owfs

Compile-time options:
USB is enabled
  AVAHI is enabled
I2C is enabled
 W1 is enabled
  Parallel port DS1410E is enabled
 FTDI (LinkUSB) is DISABLED
   Zeroconf/Bonjour is enabled
   Debug-output is enabled
 Mutexdebug is enabled
  Profiling is DISABLED
Tracing memory allocation is DISABLED

Module configuration:
  owlib is enabled
owshell is enabled
   owfs is enabled
owhttpd is enabled
 owftpd is enabled
   owserver is enabled
 owexternal is enabled
  ownet is enabled
   ownetlib is enabled
  owtap is enabled
  owmon is enabled
 owcapi is enabled
   swig is enabled
 owperl is enabled
  owphp is DISABLED
   owpython is enabled
  owtcl is enabled

unit tests are DISABLED

is this a problem ?

checking if libftdi is available... auto (default) configure:
WARNING: libftdi not found, LinkUSB native will be disabled 



I still have done:

apt-get update
apt-get upgrade
apt-get dist-update


Any Idea what is missing ?

Best regards
R.






Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi


Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.s

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Mick Sulley]

I don't know if this will help to explain the operation, but my code 
runs in a continuous loop -


 * Read all temperatures
 * Set the simultaneous/temperature bit
 * Perform logic operations, setting outputs to devices based upon
   temperatures read, etc
 * Log values to database
 * repeat.

OK ignore the first loop.  The logic and logging takes more than 1 
second, so when I read the temperatures they are all converted because 
it was initiated at step 2 on previous loop, no wait time and no 85 
degree readings.


I agree that there is a design fault with the DS1820, but it is nothing 
we can fix here, and Dallas are not going to do anything about it now.


Hope that helps a bit
Mick


On 08/01/17 22:30, Jan Kandziora wrote:

Am 08.01.2017 um 19:39 schrieb Roland Franke:

It's still in there, as Stefano found the real bug causing problems with
.../latesttemp.

But this has also an problem (For me). I will read over OWLIB from the
OWSERVER values out (Let me say the program collectd will read it with
the onewire plugin). I have also not all my sensors (Type 28 = DS18B20)
external powered, so the simultanues read of values will not work.
On this way the value of latesttemp will be only updated, when the sensor
is read on an second way. Only latesttemp will hold his value without any
changes.
So it is not (For me) complete right working as i was suggesting, that the
update of that value will be also made. But this will be never be done.


I'm sorry, I do not understand from the above what your problem is.

Kind regards

Jan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Testing code

[Mick Sulley]

Thanks Jan.  Do you know if there is any way to limit values for IO 
modules?  I have tested with DS2413, fake gives random values, tester 
gives consistent values, but accessing via the owhttpd page any change I 
make is immediately over-written for both configs.

Mick

On 06/12/16 00:01, Jan Kandziora wrote:
> Am 05.12.2016 um 16:39 schrieb Mick Sulley:
>> OK more research and I have made a bit of progress.
>>
>> adding
>>
>> server: fake=10.053C8A010800,10.2AFE89010800,10.90F889010800
>>
>> to owfs.conf creates these devices with random values, different at each
>> read.  They can be split over different lines e.g.
>>
>> server: fake=10.053C8A010800
>> fake=10.2AFE89010800,10.90F889010800
>>
> fake= is a hostadapter option. What you defined here is
>
> * a fake hostadapter with a connected 10.053C8A010800 which can only be
> seen by owserver.
>
> * another fake hostadapter with a connected 10.2AFE89010800 and
> 10.90F889010800 which can be seen by all programs using owlib directly
> (and having -c /etc/owfs.conf on their command line).
>
>
>
>
>> Also you can limit the values -
>>
>> --temperature_low=20.1
>> --temperature_high=22.1
>>
> Again, these are options used by all programs using owlib directly and
> having -c /etc/owfs.conf on their command line.
>
>
>> Is there any way to set individual temperatures for fake devices?
>>
> No. All fake devices share the same static data and do not have
> individual properties.
>
>
>> Using 'tester' in place of 'fake' creates the device with a consistent
>> value, but there does not seem to be any way to control what that value
>> is, --temperature_low=20.1, --temperature_high=22.1 has no effect.  The
>> values seem to be different for each device, but all are many hundreds
>> or thousands of degrees.
>>
> IIRC tester is different from fake only in how the cache is handled.
> Maybe someone else has more insight.
>
>
> Kind regards
>
>   Jan
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Testing code

[Mick Sulley]

OK more research and I have made a bit of progress.

adding

server: fake=10.053C8A010800,10.2AFE89010800,10.90F889010800

to owfs.conf creates these devices with random values, different at each 
read.  They can be split over different lines e.g.

server: fake=10.053C8A010800
fake=10.2AFE89010800,10.90F889010800

Also you can limit the values -

server: fake=10.053C8A010800
fake=10.2AFE89010800,10.90F889010800
--temperature_low=20.1
--temperature_high=22.1

limits the values of all 3 sensors to between 20.1 and 22.1, however

server: fake=10.053C8A010800
--temperature_low=10.1
--temperature_high=12.1
fake=10.2AFE89010800,10.90F889010800
--temperature_low=20.1
--temperature_high=22.1

limits all 3 sensors to between 20.1 and 22.1, it seems that only the 
last restrictions are used for all devices.  The limits must be on 
separate lines, so

server: fake=10.053C8A010800 --temperature_low=10.1 --temperature_high=12.1

does not restrict the temperature at all.

Using 'tester' in place of 'fake' creates the device with a consistent 
value, but there does not seem to be any way to control what that value 
is, --temperature_low=20.1, --temperature_high=22.1 has no effect.  The 
values seem to be different for each device, but all are many hundreds 
or thousands of degrees.

Is there any way to set individual temperatures for fake devices?

Thanks
Mick

On 04/12/16 23:34, Mick Sulley wrote:
> I am trying to test out some code using the tester facility in owfs.conf
>
> If I add
>
> tester=10.053C8A010800
>
> I can see that fake device.  Looking at the documentation there is a way
> to tell it what value e.g. temperature you would like it to read, from
> the documentation (which seems rather confusing) it is
>
> tester=10.053C8A010800 -p 
>
> I have tried a few values at the end and they don't make any difference.
>
> I also found some old mails suggesting maybe 'mock' instead of 'tester'
> and also adding --templow and --temphigh but these don't seem to work
> either.
>
> How can I set the value I would like to see?
>
> Thanks
>
> Mick
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Testing code

[Mick Sulley]

I am trying to test out some code using the tester facility in owfs.conf

If I add

tester=10.053C8A010800

I can see that fake device.  Looking at the documentation there is a way 
to tell it what value e.g. temperature you would like it to read, from 
the documentation (which seems rather confusing) it is

tester=10.053C8A010800 -p 

I have tried a few values at the end and they don't make any difference.

I also found some old mails suggesting maybe 'mock' instead of 'tester' 
and also adding --templow and --temphigh but these don't seem to work 
either.

How can I set the value I would like to see?

Thanks

Mick


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] usb support missing in own compiled owserver ?!?

[Mick Sulley]

I think you also need libusb-dev if you are compiling it

Mick


On 17/09/16 20:02, samuix wrote:

Hi,
I build the owserver with following options:
./bootstrap
./configure --enable-usb
following messages showed up:
checking if usb support is enabled... yes
checking for LIBUSB... no
..
Deployment location: /opt/owfs
Compile-time options:
*USB is DISABLED*
libusb is installed on the system:
ldconfig -p | grep libusb
libusb-1.0.so.0 (libc6,hard-float) => 
/lib/arm-linux-gnueabihf/libusb-1.0.so.0
libusb-0.1.so.4 (libc6,hard-float) => 
/lib/arm-linux-gnueabihf/libusb-0.1.so.4
libusb-0.1.so.4 (libc6,hard-float) => 
/usr/lib/arm-linux-gnueabihf/libusb-0.1.so.4

How can i build the owserver with USB enabled ?
Thanks


--


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Mick Sulley]

Yes I would echo Nigel's comments.  I don't think there is a perfect 
solution but what is suggested sounds good to me.

Mick


On 14/09/16 10:14, Nigel Titley wrote:
>
> On 14/09/16 09:02, Jan Kandziora wrote:
>> Am 14.09.2016 um 07:21 schrieb Johan Ström:
>>> Colin, Jan, Colin, and everyone else: Besides the above, what do you
>>> guys think of the GitHub wiki? Would it be an acceptable way to go
>>> forward? It certainly has a few downsides (mainly lack of structuring,
>>> image uploads), but it's very easy to get started, and no external
>>> hosting required.
>>>
>> I think we should go for it. Having less automation on the github site
>> isn't too bad.
>>
>>
>>> I think I would vote to focus on a single wiki to start with, and
>>> nothing on GH pages besides perhaps welcome-page, very basic info and
>>> pointers to the wiki.. That way we can start to build up all the info on
>>> the wiki, and when we have some nice wiki-pages, we could move it to GH
>>> pages ("the homepage") if we think it makes sense.
>>>
>> Yes, that's the way to go.
>>
>> About the welcome page: Let's start with a page about Onewire in
>> general, then give owfs as *one* of the solutions.
>>
>> A driver hierarchy would help most to structure that page. Not an image,
>> just a table of colored, clickable blocks
>>
>> And are you all okay with a bit uncouth writing style? Because I think
>> it helps loosening up the exact, technical text parts.
>>
>>
> I've been watching this but not saying much because I'm not really a
> developer, but as a user I'd love to see more easily accessible
> documentation. OWFS is by no means the worst documented project out
> there (probably the worst example I've come across is Openhab) but
> anything that can be done would help. I'll even offer to help...
>
> All the best
>
> Nigel
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Mick Sulley]

OK the examples look OK, I don't know how to do it but if this is our 
final solution I will invest the time to find out.


On 11/09/16 21:50, Johan Ström wrote:
> On 11/09/16 22:39, Mick Sulley wrote:
>
>> I just added a new page and it seems pretty easy to me to do that, but I
>> don't see any way to create a page hierarchy, is that possible?  I think
>> we would need to group information to make it easily accessible.
>>
>> btw I think this discussion is a fantastic move in the right direction,
>> currently we have great software with poor documentation.
>>
>> Mick
>>
>>
> Afaik the GH wiki system lacks proper hierarchy system, at least an
> automated one.
> It is however possible to build custom sidebars with "structure", but it
> must be written manually (although once you set some basic main pages,
> it won't change much).
>
> Github has a page where they have "good examples" of wikis:
>
> https://github.com/showcases/projects-with-great-wikis
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Mick Sulley]

I just added a new page and it seems pretty easy to me to do that, but I 
don't see any way to create a page hierarchy, is that possible?  I think 
we would need to group information to make it easily accessible.

btw I think this discussion is a fantastic move in the right direction, 
currently we have great software with poor documentation.

Mick


On 11/09/16 21:10, Martin Patzak (GMX) wrote:
>
> On 09/11/2016 06:18 PM, Johan Ström wrote:
>> On 10/09/16 14:02, Jan Kandziora wrote:
>>> Am 10.09.2016 um 11:22 schrieb Colin Law:
 Is there really a need for two?  Why
 not just have everything in one?

>>> Because of access rights. GitHub only allows full developer access to
>>> anything or no rights at all. Not Wiki-alone.
>>>
>>> We could settle on having an owfs-doc project with a open wiki of course.
>>>
>> For testing, I opened a new owfs-doc repo with a publicly editable wiki.
>> Feel free to try it out, anyone with a Github account should be able to
>> edit:
>>
>> https://github.com/owfs/owfs-doc/wiki
> it works:
> https://github.com/owfs/owfs-doc/wiki/Contribute
>
> Martin
>> --
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers