I agree that using the “persistent” network object for the present use case
could speed up things, see
<https://pyownet.readthedocs.io/en/latest/protocol.html#persistent-vs-non-persistent-proxy-objects
<https://pyownet.readthedocs.io/en/latest/protocol.html#persistent-vs-non-persistent-proxy-objects>>
However the correct call to obtain a persistent object is
owp = pyownet.protocol.proxy(persistent=True)
Stefano
PS
In the example code provided there is no need to close the connection, but the
typical usage pattern is
with owp:
# loop reading sensors, persistent connection is open
# do some work, persistent connection is closed
which ensures that the persistent connection is closed upon exit of the `with`
block and does not remain open when the program is not querying owserver.
E.g.
def main():
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"]
owp = pyownet.protocol.proxy(persistent=True)
while True:
start = time.time()
with owp:
# persistent socket is open!
owp.write("/simultaneous/temperature", b"1")
time.sleep(1)
print("start of sensor_read.py")
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)
# out of with block persistent socket is closed
sleep(30) # do some other work, and then start again
> On 6 Aug 2020, at 13:31, Martin Patzak <martin.pat...@gmx.de> wrote:
>
> I read the CRC16 attribute from /statistics
>
> CRC16_error = op.read('/statistics/errors/CRC16_errors')
>
> where op is the persistent(!) pyownet object, created like this:
>
> from pyownet import protocol
>
> op = protocol.proxy(server,port=port)
>
> On 06.08.20 11: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
>> <mailto:Owfs-developers@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> <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
