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 "/<device id>/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 indicates a
power-on condition. The chip even responds to conditional search as long
the POR bit isn't cleared.
In my machines, I have a loop which reads /alarm once in a second
-usually no slave responds to that- and then manages the alarm
conditions for all the slaves that do.
Kind regards
Jan
