Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-09 Thread Henrik Östman 

Den 2016-01-07 kl. 10:11, skrev Stefano Miccoli:

On 06 Jan 2016, at 12:32, Henrik Östman  wrote:


And that's it. Just one thread to not confuse the bus and the good thing is that I no 
longer experience the "found 0 devices"-problem I had before when running 
multiple thread and doing a bus scan. Probably the threads was lock too long in Owserver 
so somekind of timeout was reached as you suggested.

While writing my python owserver client I encountered a similar problem, see 
https://github.com/miccoli/pyownet/pull/1

A not well documented feature of owserver is that it sends keep-alive packets 
to the client when an operation takes longer than a given amount of time. The 
client has to discard these packets and keep waiting. (This is a common 
pitfall, see http://sourceforge.net/p/owfs/mailman/message/34211145/ )

Thanks that's good to know. However the developers of jowfsclient have 
already implemented that as far as I can see:


public String read(String path) throws IOException, OwfsException {
ResponsePacket response;
RequestPacket request = new 
RequestPacket(Enums.OwMessageType.READ, OWNET_DEFAULT_DATALEN, 
config.getFlags(), path);

sendRequest(request);
do {
response = readPacket();
// Ignore PING messages (i.e. messages with payload length -1)
} while (response.getHeader().getPayloadLength() == -1);

disconnectIfConfigured();
return response.getPayload();
}


However I still having problem getting the simultaneous reading of temperature 
devices to work. I disconnected my whole 1-wire network from the Abiowire-card 
and solder on two DS18S20 on a short 10 cm cable, with 5v power, and connected 
it to the card. Just to rule out long cables and faulty soldering from the 
equation. I run my above program and recorded the times between each of these 
steps:

2016-01-05 21:30:33,973 [owfsAdapter-mainloop-1410803762] DEBUG 
se.liquidbytes.jel.owfs.OwfsAdapter - Mainloop execution statistics: command 
0ms, simultaneous 147ms, fastdevices 0ms, temperaturedevices 1280ms, 
voltagedevices 0ms, busscan 0ms.

Many of the above steps reported 0 ms since there was no queued command, no 
other devices was present except temperaure-sensors, and no bus scan occured. 
Writing to /simultaneous/temperature took 147 ms, reading from the sensors took 
1230 ms.


If I got it right, when owserver returns from the write to 
/simultaneous/temperature, fresh temp values can be read from the cache. If you 
read from /uncached, you trigger a fresh conversion.

- write to /simultaneous/temperature
- immediately read temperatures from the cache (and not from /uncached)

S.M.

Yes I found out that too. Reading from /uncached always seems to trigger 
a single conversion. Reading the cached one was the way to go, however 
it's a bit "dangerous" since if I forget to write to simultaneous or 
that code for some reason does not work I will get an old(15 secs) 
cached reading. For my purpose it is better if the fallback was to 
/uncached.




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


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-08 Thread Martin Patzak (GMX) 



On 01/08/2016 01:07 AM, Stefano Miccoli wrote:


On 07 Jan 2016, at 14:45, Martin Patzak (GMX) > wrote:


I am using the pyownet library to communicate to a local owserver.
I have 25 temp-sensors and 2 io 2408 modules on one powered bus with 
an usb-link as master.


I do use simultaneous to read all 25 sensors every 30 seconds as well 
(see below)
From a seperate task I am reading the state of the 1-wire IOs every 
second.
Another task lets a LED flash, that is connected to one of the 
Outputs, also every second (as an indicator of the state of the system)


The system runs 24/7 and is mainly busy running the heating system in 
our house.


I agree: since owserver is multi-threaded by design there is nothing 
wrong with multiple client tasks/threads accessing it concurrently. 
One should just avoid clogging the server wit an excessive number of 
requests.

ok good you can confirm that...



In this case it is the same sensor that takes longer to read in 
consequent reads for 7 times.
When a read takes longer, than it is quite often, that the same 
sensor takes longer to read soon again.

And it can be any sensor, in the beginning, in the end, anywhere.
Then it can be weeks until this sensor makes a problem again.

Could this be cause by asynchronous and parallel requests to owserver?


Sorry, no idea: this question is for the OWFS gurus

did anybody expierience similar issues?
I did upgrade to 3.1 and it still is the same.
With the new version I have the debug functionality back, which was 
missing in 2.9p8, so I will have to send the debug of owserver to a file 
and put the result up here if this would help finding the problem...






Stefano, would it be possible to have a max timeout while issuing a 
read command? How will I know that sometimes it won't take even longer?




In pyownet.protocol there is a 2 second timeout on the socket 
operations, see


https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L117
https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L310

this means that if the owserver crashes or the network connection is 
somehow interrupted the pyownet operation will fail with a 
pyownet.protocol.ConnError exception.
yes, that works fine. I did some tests before changing over to your 
library and found it very behaved in all sorts of special situations...




In your case, since the read takes longer than 2s (4 seconds and 
more), owserver is sending it’s keep-alive packets back to pyownet, so 
no socket timeout. This situation is handled below line

https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L347
As you can see, as long as owserver keeps sending it’s -1 payload 
frames, pyownet will block indefinitely. However this should not 
happen in practice, because owserver aborts the connection after 30 
seconds or so.


Here it could be possible to start a timer, and abort the connection 
pyownet side after a user configurable amount of time; or simply count 
the number of frames received and abort after a user configurable 
amount of frames.


I don’t know which is the correct strategy: fortunately these long 
reads are very rare events: maybe the present code is OK. pyownet 
simply trusts owserver and patiently keeps waiting as long as owserver 
tells him to do so.
I would say, it would be nice to have, but as you said not urgently 
necessary.
So far I have seen only one sensor with a delayed read-out at a time, so 
it is acceptable.
For some sensors however it is important that they will be read every 30 
seconds, and with a timeout I could ensure to match that interval, and 
to give up reading when it takes too long and just use the extrapolated 
value from the last couple of readings instead.



Cheers

Martin

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

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-08 Thread Martin Patzak (GMX) 


On 01/08/2016 02:26 AM, Jan Kandziora wrote:
> Am 08.01.2016 um 01:07 schrieb Stefano Miccoli:
>> I agree: since owserver is multi-threaded by design there is nothing
>> wrong with multiple client tasks/threads accessing it concurrently.
>> One should just avoid clogging the server wit an excessive number of
>> requests.
>>
> All is fine as long as you are not insisting on the order in which
> requests are served. That is because the owserver protocol is based on
> TCP, so the order of requests is only honoured per-socket. As soon there
> are multiple sockets, messages stuck in them are handled as the
> scheduler decides. And this isn't round-robin and not sorted by arriving
> time either. It's a complicated scheme based on throughput.
Thanks for giving more insight to the inner workings of owserver...
>
> So if you require to control the order of commands -as with
> synchronizing /simultaneous/temperature triggers to readouts of the
> chips-, you have to stuff them into the same socket on owserver side.
Ok, that is understood.


Cheers

Martin


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

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-07 Thread Stefano Miccoli 

> On 07 Jan 2016, at 14:45, Martin Patzak (GMX)  wrote:
> 
> I am using the pyownet library to communicate to a local owserver.
> I have 25 temp-sensors and 2 io 2408 modules on one powered bus with an 
> usb-link as master.
> 
> I do use simultaneous to read all 25 sensors every 30 seconds as well (see 
> below)
> From a seperate task I am reading the state of the 1-wire IOs every second.
> Another task lets a LED flash, that is connected to one of the Outputs, also 
> every second (as an indicator of the state of the system)
> 
> The system runs 24/7 and is mainly busy running the heating system in our 
> house.

I agree: since owserver is multi-threaded by design there is nothing wrong with 
multiple client tasks/threads accessing it concurrently. One should just avoid 
clogging the server wit an excessive number of requests.

> In this case it is the same sensor that takes longer to read in consequent 
> reads for 7 times.
> When a read takes longer, than it is quite often, that the same sensor takes 
> longer to read soon again.
> And it can be any sensor, in the beginning, in the end, anywhere.
> Then it can be weeks until this sensor makes a problem again.
> 
> Could this be cause by asynchronous and parallel requests to owserver?

Sorry, no idea: this question is for the OWFS gurus

> 
> Stefano, would it be possible to have a max timeout while issuing a read 
> command? How will I know that sometimes it won't take even longer?
> 

In pyownet.protocol there is a 2 second timeout on the socket operations, see

https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L117 

https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L310 


this means that if the owserver crashes or the network connection is somehow 
interrupted the pyownet operation will fail with a pyownet.protocol.ConnError 
exception. 

In your case, since the read takes longer than 2s (4 seconds and more), 
owserver is sending it’s keep-alive packets back to pyownet, so no socket 
timeout. This situation is handled below line 
https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L347 

As you can see, as long as owserver keeps sending it’s -1 payload frames, 
pyownet will block indefinitely. However this should not happen in practice, 
because owserver aborts the connection after 30 seconds or so.

Here it could be possible to start a timer, and abort the connection pyownet 
side after a user configurable amount of time; or simply count the number of 
frames received and abort after a user configurable amount of frames.

I don’t know which is the correct strategy: fortunately these long reads are 
very rare events: maybe the present code is OK. pyownet simply trusts owserver 
and patiently keeps waiting as long as owserver tells him to do so.


> Occasionally reading a temp-sensor fails completely with the error:
> 
> 1452093633.364 16:20:33 HC-Temp-Log error from owt.RD_Temp: -1, [Errno 1] 
> Startup - command line parameters invalid: '28.CF791502/temperature'
> 1452093633.610 16:20:33 HC-Monitor 28.CF791502 is not present
> 1452093636.839 16:20:36 HC-Monitor 28.CF791502 is now present, setting OK 
> to True
> 
> 
> In that case, it looks like the sensor is not connected to the bus!?!
> The task that reads the temps sets a flag, that a particular sensor has a 
> problem, and continues reading the other sensors.
> Meanwhile a seperate monitoring task picks up the flag and checks for the 
> sensor at a certain interval. As you can see the sensor is actually not 
> present, only to be present at the next check-interval 3 seconds later. Where 
> was the sensor in the meantime - out for a quck smoke???
> 
> And very rarely an IO-read or write fails, which looks like so:
> 
> 1452093530.164 16:18:50 HC-HMI -3, [Errno 1] Startup - command line 
> parameters invalid: '29.1CBF0E00/sensed.BYTE' while reading the byte 
> 1452093530.667 16:18:50 HC-HMI -3, [Errno 1] Startup - command line 
> parameters invalid: '29.1CBF0E00/sensed.BYTE' while reading the byte 
> 1452093531.169 16:18:51 HC-HMI -3, [Errno 1] Startup - command line 
> parameters invalid: '29.1CBF0E00/sensed.BYTE' while reading the byte 
> 1452093531.171 16:18:51 HC-HMI gave up on reading the byte at:29.1CBF0E00
> 1452093532.371 16:18:52 HC-Monitor 29.1CBF0E00 is now present, setting OK 
> to True
> 
> I retry twice to read the byte, and the task sets the flag, that the module 
> has a problem, and proceed to read the other module,
> again the monitoring task is checking the module
> 
> So far, I could not observer that reading or writing IOs took longer, but 
> once in a blue moon I get this error:
> 
> 1452099227.565 17:53:47 HC-HMI [Errno 2] legacy -

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-07 Thread Jan Kandziora 
Am 08.01.2016 um 01:07 schrieb Stefano Miccoli:
> 
> I agree: since owserver is multi-threaded by design there is nothing
> wrong with multiple client tasks/threads accessing it concurrently.
> One should just avoid clogging the server wit an excessive number of
> requests.
> 
All is fine as long as you are not insisting on the order in which
requests are served. That is because the owserver protocol is based on
TCP, so the order of requests is only honoured per-socket. As soon there
are multiple sockets, messages stuck in them are handled as the
scheduler decides. And this isn't round-robin and not sorted by arriving
time either. It's a complicated scheme based on throughput.

So if you require to control the order of commands -as with
synchronizing /simultaneous/temperature triggers to readouts of the
chips-, you have to stuff them into the same socket on owserver side.

Kind regards

Jan

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

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-07 Thread Matthias Urlichs 
On 07.01.2016 10:11, Stefano Miccoli wrote:
> - write to /simultaneous/temperature
> - immediately read temperatures from the cache (and not from /uncached)

Well, not immediately. Wait a second before doing that.

-- 
-- Matthias Urlichs


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

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-07 Thread Martin Patzak (GMX) 



On 01/07/2016 10:11 AM, Stefano Miccoli wrote:

On 06 Jan 2016, at 12:32, Henrik Östman  wrote:


And that's it. Just one thread to not confuse the bus and the good thing is that I no 
longer experience the "found 0 devices"-problem I had before when running 
multiple thread and doing a bus scan. Probably the threads was lock too long in Owserver 
so somekind of timeout was reached as you suggested.

While writing my python owserver client I encountered a similar problem, see 
https://github.com/miccoli/pyownet/pull/1

A not well documented feature of owserver is that it sends keep-alive packets 
to the client when an operation takes longer than a given amount of time. The 
client has to discard these packets and keep waiting. (This is a common 
pitfall, see http://sourceforge.net/p/owfs/mailman/message/34211145/ )


I am using the pyownet library to communicate to a local owserver.
I have 25 temp-sensors and 2 io 2408 modules on one powered bus with an 
usb-link as master.


I do use simultaneous to read all 25 sensors every 30 seconds as well 
(see below)

From a seperate task I am reading the state of the 1-wire IOs every second.
Another task lets a LED flash, that is connected to one of the Outputs, 
also every second (as an indicator of the state of the system)


The system runs 24/7 and is mainly busy running the heating system in 
our house.
Additionally I do have separate tasks for running the furnace and the 
floor and radiator-circuits.


Using parallel tasks to communicate to owserver, was just a more natural 
and also an easier approach for me, and have owserver serialize the 
1-wire communication. (is that not advised???)


Henrik, what was your reason to rewrite your software to communicate 
only from one task to owserver?


In general everything is fine, but *sometimes*, reading a 
temperature-sensor takes a little longer (normally it takes between 0.1 
and 0.2s per sensor, so 25 sensors take about 1.5 to 2.5s). When it 
takes longer, reading a sensor can take as long as 4(!) seconds, however 
it usually is 0.5 to 0.7 seconds. I do log, when it takes longer, and 
this is how I know.


Here is one of the more interesting excerpts from my logs:

/1452153935.340 09:05:35 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.36seconds //
//1452153936.315 09:05:36 HC-Temp-Log Reading Temps took a little longer 
: 4.22 seconds //
//1452153965.491 09:06:05 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.42seconds //
//1452153966.702 09:06:06 HC-Temp-Log Reading Temps took a little longer 
: 4.64 seconds//
//1452154055.099 09:07:35 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.35 seconds//
//1452154055.985 09:07:35 HC-Temp-Log Reading Temps took a little longer 
: 3.86 seconds//
//1452154085.459 09:08:05 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.41 seconds//
//1452154086.616 09:08:06 HC-Temp-Log Reading Temps took a little longer 
: 4.49 seconds//
//1452154115.309 09:08:35 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.39 seconds//
//1452154116.242 09:08:36 HC-Temp-Log Reading Temps took a little longer 
: 4.12 seconds//
//1452154145.268 09:09:05 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.41 seconds//
//1452154146.162 09:09:06 HC-Temp-Log Reading Temps took a little longer 
: 4.10 seconds//
//1452154175.325 09:09:35 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.32 seconds//
//1452154176.295 09:09:36 HC-Temp-Log Reading Temps took a little longer 
: 4.19 seconds//

/
In this case it is the same sensor that takes longer to read in 
consequent reads for 7 times.
When a read takes longer, than it is quite often, that the same sensor 
takes longer to read soon again.

And it can be any sensor, in the beginning, in the end, anywhere.
Then it can be weeks until this sensor makes a problem again.

Could this be cause by asynchronous and parallel requests to owserver?

Stefano, would it be possible to have a max timeout while issuing a read 
command? How will I know that sometimes it won't take even longer?


*Occasionally* reading a temp-sensor fails completely with the error:
/
//1452093633.364 16:20:33 HC-Temp-Log error from owt.RD_Temp: -1, [Errno 
1] Startup - command line parameters invalid: '28.CF791502/temperature'

1452093633.610 16:20:33 HC-Monitor 28.CF791502 is not present
1452093636.839 16:20:36 HC-Monitor 28.CF791502 is now present, 
setting OK to True

/

In that case, it looks like the sensor is not connected to the bus!?!
The task that reads the temps sets a flag, that a particular sensor has 
a problem, and continues reading the other sensors.
Meanwhile a seperate monitoring task picks up the flag and checks for 
the sensor at a certain interval. As you can see the sensor is actually 
not present, only to be present at the next check-interval 3 seconds 
later. Where was the sensor in the

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-07 Thread Cornie Malan 
Referring to the following in multi-client environment:


"If I got it right, when owserver returns from the write to
/simultaneous/temperature, fresh temp values can be read from the cache. If
you read from /uncached, you trigger a fresh conversion.

- write to /simultaneous/temperature
- immediately read temperatures from the cache (and not from /uncached)

S.M. originally I was under the impression, that after writing '1' to
/simultaneous/temperature, I would have to read back the value until
owserver sets it to '0' which would indicate that the conversion is done."


The model could be improved with owserver incrementing the value in
/simultaneous/temperature.  This will mean that if any client needs a
conversion, writing a random number to /simultaneous/temperature and
tracking the increment will be possible.

If no specific tracking is required, writing 0 and polling for 1 will also
work.

c-:


On 8 January 2016 at 03:26, Jan Kandziora  wrote:

> Am 08.01.2016 um 01:07 schrieb Stefano Miccoli:
> >
> > I agree: since owserver is multi-threaded by design there is nothing
> > wrong with multiple client tasks/threads accessing it concurrently.
> > One should just avoid clogging the server wit an excessive number of
> > requests.
> >
> All is fine as long as you are not insisting on the order in which
> requests are served. That is because the owserver protocol is based on
> TCP, so the order of requests is only honoured per-socket. As soon there
> are multiple sockets, messages stuck in them are handled as the
> scheduler decides. And this isn't round-robin and not sorted by arriving
> time either. It's a complicated scheme based on throughput.
>
> So if you require to control the order of commands -as with
> synchronizing /simultaneous/temperature triggers to readouts of the
> chips-, you have to stuff them into the same socket on owserver side.
>
> 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] Getting simultaneous to work (and other)

2016-01-06 Thread Henrik Östman 
Thank you for so thoroughly answering my questions, its been gold worth 
to me who lack deeper understanding of the 1-wire devices and of OWFS!


After reading your answers in the mailthread I went and rewrote my 
program to use a single thread for Owserver and using a single 
connection to Owserver for that thread. Maybe some smarter bridges like 
DS2490 do support simultaneous scanning and reading a bus but it would 
be unwise of we to optimize my application just around how that single 
chip works.


The thread that communicates with owserver now execute the following 
mainloop over and over again:


- Collect all found 1-wire devices from a previous bus scan and separate 
them into three different lists, "temperaturedevices", "voltagedevices", 
"fastdevices" (the rest of the devices not being temp or voltage).
- Execute all queued command to be written to Owserver from a queue. 
When you want to change a pin or write something to a device to add a 
-entry to this queue and they are all executed on this step.
- If there are any devices found in "temperaturedevices"-list, write "1" 
to "/simultaneous/temperature".
- If there are any devices found in "voltagedevices"-list, write "1" to 
"/simultaneous/voltage".
- Iterate though all devices in "fastdevices"-list and do a 
"this.owserverConnection.read(path)" on each of them (this is a 
/uncached-path!). Hopefully these can be read safely while the 
temperature and voltage-sensors are working on their own, we thus do 
some parallel work.
- Check if there are any new queued commands to be executed. We do this 
several times between steps that possible could take a long to to 
execute just to get a responsive system for the endusers.
- Iterate though all devices in "temperaturedevices"-list and do a 
"this.owserverConnection.read(path)" on each of them(this is a 
/uncached-path!). Hopefully the conversions are done by now, otherwise 
Owserver will block the rest of the time left and return the readings 
when they are done.

- Check if there are any new queued commands to be executed.
- Iterate though all devices in "voltagedevices"-list and do a 
"this.owserverConnection.read(path)" on each of them(this is a 
/uncached-path!). Hopefully the conversions are done by now, otherwise 
Owserver will block the rest of the time left and return the readings 
when they are done.
- If 30 secs has elapsed, do a full bus scan against Owserver (we read 
from the CACHE). If 30 secs not has been reatched we just skip this step.


And that's it. Just one thread to not confuse the bus and the good thing 
is that I no longer experience the "found 0 devices"-problem I had 
before when running multiple thread and doing a bus scan. Probably the 
threads was lock too long in Owserver so somekind of timeout was reached 
as you suggested.


However I still having problem getting the simultaneous reading of 
temperature devices to work. I disconnected my whole 1-wire network from 
the Abiowire-card and solder on two DS18S20 on a short 10 cm cable, with 
5v power, and connected it to the card. Just to rule out long cables and 
faulty soldering from the equation. I run my above program and recorded 
the times between each of these steps:


2016-01-05 21:30:33,973 [owfsAdapter-mainloop-1410803762] DEBUG 
se.liquidbytes.jel.owfs.OwfsAdapter - Mainloop execution statistics: 
command 0ms, simultaneous 147ms, fastdevices 0ms, temperaturedevices 
1280ms, voltagedevices 0ms, busscan 0ms.


Many of the above steps reported 0 ms since there was no queued command, 
no other devices was present except temperaure-sensors, and no bus scan 
occured. Writing to /simultaneous/temperature took 147 ms, reading from 
the sensors took 1230 ms.
Some more samples showed a average reading from sensors of about 1300 
ms. If simultaneous had kicked in we should see something more close to 
700 ms, right? I tested to connect my cable to both DS2482-800 and the 
single DS2482-100 the card is equipped with, but got the same result. I 
have and old DS2480-card somewhere, I will see if I get the same result 
on that one. Here is a interesting thread that at least suggest that it 
should work on DS2482-800: 
https://www.mail-archive.com/owfs-developers@lists.sourceforge.net/msg05631.html


Regarding how static the 1-wire network is, I would say it is for the 
most of the time is very static. I guess that some users may hotplug 
their networks by adding or removing devices on-the-fly without powering 
the network down, and for that I want to poll the bus for any added or 
removed devices. If they only could be removed then reading /power would 
be a excellent way (thanks for the idea!).


The "POR"-bit sounds interesting, so it get set when the chip has been 
powercycled?  So during initialization I can set this to "0" and I could 
poll /alarm and it will be triggered if the chip has been powercycled 
(among other alarms)? Then I just set it back to "0" and initialize the 
DS2408 to correct state once

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-05 Thread Matthias Urlichs 
On 03.01.2016 20:08, Jan Kandziora wrote:
> Reading the sources again, it would be easiest to have another node
> "latesttemp" in the chip directory which just returns the interpreted
> values of scratchpad[0] and scratchpad[1].
> 
I'd like to have that.

> Or you can read the scratchpad node and do the arithmetic yourself.

Yes I could, but doing it that way would be somewhat ugly. :-/

-- 
-- Matthias Urlichs


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

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-03 Thread Jan Kandziora 
Am 03.01.2016 um 18:07 schrieb Matthias Urlichs:
> 
> What I would like to have is a way to read /temperature which simply
> fails when no value is available.
>
It is easy to change that behaviour. Should we have another node in
/settings controlling how reading temperature/voltage values work or do
you see an ingenious way to have owfs find this out automatically?

Kind regards

Jan




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

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-03 Thread Jan Kandziora 
Am 03.01.2016 um 19:28 schrieb Jan Kandziora:
> Am 03.01.2016 um 18:07 schrieb Matthias Urlichs:
>>
>> What I would like to have is a way to read /temperature which simply
>> fails when no value is available.
>>
> It is easy to change that behaviour. Should we have another node in
> /settings controlling how reading temperature/voltage values work or do
> you see an ingenious way to have owfs find this out automatically?
> 
Reading the sources again, it would be easiest to have another node
"latesttemp" in the chip directory which just returns the interpreted
values of scratchpad[0] and scratchpad[1].

Or you can read the scratchpad node and do the arithmetic yourself.

Kind regards

Jan

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

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-03 Thread Matthias Urlichs 
On 03.01.2016 05:32, Jan Kandziora wrote:
> a) have to synchronize writing to /simultaneous with reading each node

I have a separate task in my system which checks the datastore how often
any temperature sensor on the bus wants to be read(*), then simply
writes to /simultaneous/temperature, waits a second, reads all values,
and broadcasts them.

(*) or rather, the parameter lives in etcd, so I get notified when it
changes.

What I would like to have is a way to read /temperature which simply
fails when no value is available. I do not want to lock the bus for a
second! there will be sensors on it that respond to conditional search,
I want to read their new state *now*, not "whenever".

-- 
-- Matthias Urlichs


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

[Owfs-developers] Getting simultaneous to work (and other)

2016-01-02 Thread Henrik Östman 
Hi, I have a bunch of questions regarding performance on large scale 
1-wire networks. Hopefully some of you out there have experience with this.

I'm developing a home automatisation software for my personal use, but 
when it's mature enough it will be released as Open Source.
When I begun experimenting with Owfs with just one DS18S20 everything 
was working great. However when I kept adding more DS18S20 the network 
got more and more unresponsive and my single threaded web application 
finally would stop answering requests. I had to get back to the 
"drawingboard" and make some redesign on how everything was supposed to 
work.

To clarify my setup I can say that the application (web based) in built 
upon Java 8 using the jowfsclient 
(https://github.com/pakerfeldt/jowfsclient) to communicate with Owserver 
running on the same computer. I'm aiming on running all this on a 
Raspberry Pi B-model or later, and so far its been working great.

Like I wrote above the more devices I added the more time was stacking 
up until it was unbearable slow, a possible solution to get a more 
O(1)-like performance instead of O(n) when adding more devices was the 
"Skip ROM"-command. Pseudo-code of the part that was interfacing with 
owserver looked like this:

setup:
   owDevices = owfs.listDirectoryAll("/uncached")
while(true):
   for each (device in owDevices)
 owfs.read(device)
   sleep 4000// Read whole bus every 4 secs.

More than 3-4 DS18S20 and we could no longer keep the 4 sec. budget. :-)

Now the same application after "Skip ROM"-modification:

setup:
   owDevices = owfs.listDirectoryAll("/uncached")
while(true):
   if (any owDevices is temperature device)
 owfs.write("/simultaneous/temperature", "1")
   if (any owDevices is voltage device)
 owfs.write("/simultaneous/voltage", "1")
   sleep(1000)
   for each (device in owDevices)
 owfs.read(device)
   sleep 4000// Read whole bus every 4 secs.

Ok, to start a conversion on ALL temperature sensors on the bus at the 
same time we write a "1" to the global "/simultaneous/temperature", we 
do the same for voltage devices (like the A/D-converter DS2450).
But we only do this if there are any devices of these present on the 
bus. Next I have read in a maillist post that we should wait 1000ms to 
let the conversion take place. My first question is if this sleep(1000) 
is really needed? Does not Owserver itself block on a following read 
until conversion is finished?

Unfortunately I can't seem to get any positive effect from this, it 
takes as long as without the simultaneous-code. When I have tested there 
has just been DS18S20 and DS2408-devices on the bus, cables are just a 
couple of meters long, and all devices are powered (this is a 
requirement for simultaneous to work). I’m running the latest Owfs 3.1p0 
version. Any more suggestions from the audience?
Note that I do all my reading from "/uncached", is that possible even 
with simultaneous-code? Or do I have to read from the cached-directories?

This is from a logfile of my application, the DS18S20 takes about ~700ms 
per conversion:

Recorded new value '23.75' at time '2016-01-02T21:20:17.582' for device 
with id '7F0560010800' on Owserver at 192.168.10.110:4304 with id 
"1410803762".
Recorded new value '1,1,1,1,0,0,0,0' at time '2016-01-02T21:20:17.627' 
for device with id '4D4D1300' on Owserver at 192.168.10.110:4304 
with id "1410803762".
Recorded new value '22.6875' at time '2016-01-02T21:20:18.345' for 
device with id '52A9B5010800' on Owserver at 192.168.10.110:4304 with id 
"1410803762".
Recorded new value '24' at time '2016-01-02T21:20:19.062' for device 
with id 'AC1A60010800' on Owserver at 192.168.10.110:4304 with id 
"1410803762".
Recorded new value '20.8125' at time '2016-01-02T21:20:19.779' for 
device with id 'C9E69E010800' on Owserver at 192.168.10.110:4304 with id 
"1410803762".
Recorded new value '1,1,1,1,0,0,0,0' at time '2016-01-02T21:20:19.824' 
for device with id '3E4D1300' on Owserver at 192.168.10.110:4304 
with id "1410803762".
Recorded new value '22.75' at time '2016-01-02T21:20:20.541' for device 
with id '0C92B5010800' on Owserver at 192.168.10.110:4304 with id 
"1410803762".
Recorded new value '23.125' at time '2016-01-02T21:20:21.259' for device 
with id '158DB5010800' on Owserver at 192.168.10.110:4304 with id 
"1410803762".
Recorded new value '23.125' at time '2016-01-02T21:20:21.976' for device 
with id '969D98010800' on Owserver at 192.168.10.110:4304 with id 
"1410803762".
Recorded new value '21.625' at time '2016-01-02T21:20:22.693' for device 
with id 'B74C8A010800' on Owserver at 192.168.10.110:4304 with id 
"1410803762".
Reading all current device values took 6833ms.

I stopped my application and mounted the Owfs-filesystem, looking at the 
/simultaneous/temperature gave:

trycoon@dixie:/mnt/1wire/simultaneous$ cat temperature
0trycoon@dixie:/mnt/1wire/simultaneous$ cat temperature
0trycoon@dixie:/mnt/1wire/simultaneous$ cat temperature

Re: [Owfs-developers] Getting simultaneous to work (and other)

2016-01-02 Thread Jan Kandziora 
Am 03.01.2016 um 00:11 schrieb Henrik Östman:
> Note that I do
> all my reading from "/uncached", is that possible even with
> simultaneous-code? Or do I have to read from the cached-directories?
> 
When you read from /uncached, you either

a) have to synchronize writing to /simultaneous with reading each node

or

b) have to trigger simulatenous conversions at least twice as often as
you read from /uncached

That is because reading /uncached reads the value from the chip stored
within from the last simultaneous conversion, and then resets the chip
state inside OWFS to "no result pending", which means another subsequent
reading of /uncached would trigger a normal single conversion.

When you can do neither a) nor b), you have to read the cached value and
trigger /simultaneous at a least twice as often as the cache timeout for
temperature values (that latter is usually 15 seconds.)


> 0trycoon@dixie:/mnt/1wire/simultaneous$ cat temperature 
> 1trycoon@dixie:/mnt/1wire/simultaneous$ cat temperature 
> 0trycoon@dixie:/mnt/1wire/simultaneous$ cat temperature
> 
> Is it normal that the value are jumping back and forth between 0 and
> 1? 
>
Reading that node gives you an indication whether owfs thinks there is a
conversion running. The value is global for both temperature and
voltage. This is only based on OWFS' internal state, the slaves are not
checked.

No idea why it toggles. That code is a bit opaque. If you insist on
knowing, I go hunting for the reason.


> 
> Without my 1000ms delay a full bus reading took only 362ms. I got
> about the same result without the /simultaneous/temperature-code. So
> my question is, does fake Owfs-devices emulate the time
> characteristics of the real devices (conversiontime of 700ms for a
> DS18S20) and is the /simultaneous/temperature-effect correctly
> emulated?
>
No. Using the fake adapter replaces all the device-specific code for
slave objects on that adapter by simple random-value "read" functions.

Writing to /simultaneous/temperature (or voltage) on a fake adapter is a
no-op.


> 
> Another problem I'm struggling with is that listing devices returns 0
>  devices when concurrent requests to Owserver are in progress.
>
This should not happen. Owserver should block that connection until the
"Search ROM" command can be executed on the bus in question. Maybe you
have a hidden timeout in your client application?

The most likely case for reaching such a timeout is doing a lot of
non-simultaneous conversions, as they are clogging the bus for 800ms each.

Owserver is multithreaded by client itself, so the kernel is deciding
with message is processed first by selecting a thread. I seriously doubt
that's ordered by arriving time of single packets as TCP is not intended
to transport messages. The arriving time of packets just isn't of
interest for TCP. So, by using a multiple-socket client application, you
lose control about the order of message processing within owserver.

I recommend you to get rid of the concurrency within owserver by
serializing your requests within your client application and sending
them through one single socket. That way you can control the order of
commands all by yourself.


> To overcome my slow single threaded application I introduced some more
> threads, so now I basically has four of them:
> 
> - The presence-thread polls owfs.listDirectoryAll("/uncached") every
>  30th seconds and stores all found devices in a list, lets call it 
> owDevices. (It has its own dedicated persistent connection to
> Owserver)
>
Do you have an ever-changing setup? I don't think so.

Threading doesn't help you gain speed when you are doing a bus
enumeration, as this is an atomic operation on the host adapter.
Theoretically, one could have this interleaved with other bus traffic
but for the sake of doing things the simple way (and not breaking
anything with intelligent host adaptors like the DS2490) it is just a
single bulky operation which stops everything on the bus until all chips
are identified.

If you are reading the global /uncached directory, all buses are
occupied for up to a few seconds.


As enumerating the bus can be a very time-consuming operation, and as it
is the most brittle part of the whole protocol, I do it different in my
machines. They have a list of devices to expect on the bus (need it for
functional assignment anyway) and just check if all of these chips are
still there by reading a property from them. For temperature sensors,
you may use the "power" property for that check.

I trigger the check in the board-specific code that chip is on from a
timer thread, not in a bulk but interleaved with all the other
operations on the buses.


> 
> For those of you that strive for more resilient 1-wire networks, how
> do you detect device-resets/device power failure? I setup a DS2408 by
> a write "1" to "//strobe", if the device is then power
> cycled I'm back to square one without even knowing it.
>
Uh, the DS2408 has a dedicated "por" property, which