On 01/07/2016 10:11 AM, Stefano Miccoli wrote:
On 06 Jan 2016, at 12:32, Henrik Östman <tryc...@gmail.com> 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.AF531F060000 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.AF531F060000 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.AF531F060000 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.AF531F060000 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.AF531F060000 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.AF531F060000 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.AF531F060000 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.CF7915020000/temperature'
1452093633.610 16:20:33 HC-Monitor 28.CF7915020000 is not present
1452093636.839 16:20:36 HC-Monitor 28.CF7915020000 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.1CBF0E000000/sensed.BYTE' while reading the byte
1452093530.667 16:18:50 HC-HMI -3, [Errno 1] Startup - command line
parameters invalid: '29.1CBF0E000000/sensed.BYTE' while reading the byte
1452093531.169 16:18:51 HC-HMI -3, [Errno 1] Startup - command line
parameters invalid: '29.1CBF0E000000/sensed.BYTE' while reading the byte
1452093531.171 16:18:51 HC-HMI gave up on reading the byte
at:29.1CBF0E000000
1452093532.371 16:18:52 HC-Monitor 29.1CBF0E000000 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 - No such entity:
'29.1CBF0E000000/sensed.BYTE' while reading 29.1CBF0E000000/sensed.BYTE!
/
That means, that it did not create an Errno 1 but went throught fine,
just to fail at Errno 2!
Otherwise it is stable, and since it is winter right now, I cant risk
horsing up the system for a longer time period.
I did change to the pyownet library a while ago and it is quite
comfortable and smooth to use,
Thank You Stephano!
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.
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. However that does not work, so I had to also wait a period of 2
seconds (just to be sure) until reading back the values.
Is that the proper way to do it?
Cheers,
Martin
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
