> On 07 Jan 2016, at 14:45, Martin Patzak (GMX) <martin.pat...@gmx.de> 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#L117> https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L310 <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 <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.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! Just for the list: pyownet sets errno to the owserver return code and gets the errmessage from /settings/return_codes/text.ALL. Errno 1 is raised when you try to read a non-existing path. I never experienced an Errno==2 Everything here happens owserver side, so I have no clue. > > 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! > You’re wellcome! S.
------------------------------------------------------------------------------
_______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
