Parallel processing of multiple Sensors

[toine-at-est]

Hi Rob,

Thanks for keeping active on this DHTNew Library you are making some great improvements!

I recently applied the non-blocking approach to read a DHT Sensor on a device that had many other tasks as well. It works very well and is very useful in that project as the device also functions as a HTTP Server and I don't want to block request etc.

However that device only has 1 DHT Sensor. I have other devices that have 4 or 5 DHT Sensors and I would like to process the DHT readings as soon as possible to achieve a high frequency of readings.

I used to poll the DHT sequently waiting on each on to get stable, do the reading and then move on to the next one etc. It works OK but is a bit slower then I would like...

So I did an experiment with use an ESP D1_Mini board with 3 DHT22 sensors. Using the latest version of your lib: robtillaart/DHTNEW@^0.4.18

The code creates 3 Sensor objects and starts a new read on each using the non-blocking approach. Then in the main loop I poll each and read the temp when ready.

Its seems to work OK but I am a bit suspicious that all 3 always finish at the same time and I do get slightly different readings as expected because of the accuracy of the sensor (at least that seems to suggest that each sensor state is handled separately).

If I completely disconnect each sensor it also seems to work as expected I only when I reconnect it it finishes the polling for that sensor...

It is really that I don't trust them finishing always at the same time I worry about some static variabel in your lib that is not instance based if you know what I mean (I know I am using Java terminology but tat is the only way I can explain it)

So basically I am asking your opinion as the developer of this lib whether you think parallel sensor reading should be feasible or not. ANd if so maybe you can explain why they always finish at the exact same iteration unless fully disconnected...

Correction: In my latest test I reduced the poll delay to 10 ms and now 1 sensor was ready 1 iteration before the others 2 so maybe it is all OK... Still interested in your opinion though!

I Attached my test code and sample output...

Many thanks,

Toine

experiment.zip

[ToineSiebelink]

Apologies Rob, I used my work account above by mistake. PLease reply to this message from my private account instead

[RobTillaart]

Hi Toine, Had long busy weeks so I will try to pick it up tomorrow.

[ToineSiebelink]

No worries, no rush anyway

On Thu 30 Mar 2023, 17:56 Rob Tillaart, @.***> wrote:

Hi Toine, Had long busy weeks so I will try to pick it up tomorrow.

— Reply to this email directly, view it on GitHub https://github.com/RobTillaart/DHTNew/issues/92#issuecomment-1490627399, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBXXACWRVAO5GA2Y5LNNZ3W6W3LHANCNFSM6AAAAAAWNIYXU4 . You are receiving this because you commented.Message ID: @.***>

[RobTillaart]

@ToineSiebelink

I would like to process the DHT readings as soon as possible to achieve a high frequency of readings.

The DHT22 can be read once every 2 seconds (datasheet spec), in practice one can reduce this time 5-25% so a slightly higher frequency is possible. You can adjust the time per sensor with setReadDelay() (at your own risk).

I have other devices that have 4 or 5 DHT Sensors

Given the above interval and the fact that reading a DHT takes 5-6 milliseconds, one can very easily make a round robin schedule that samples them all every 2 seconds. Ready of sensor 1 triggers the read of sensor 2, etc. optionally one can spread the 5 sensors over 2000 millis so start next one every 400 millis. Advantage is that you can spread the load evenly. Drawback is that the measurements differ in time so accurate correlations between sensors might be a little more complex.

Its seems to work OK but I am a bit suspicious that all 3 always finish at the same time

They start at almost the same time, have the same wake up time, therefore the read()s are called at roughly the same time so, it does not surprise me at all.

What you can do is determine an optimal readDelay per sensor and use *setReadDelay() to set these in your setup. ( configure the parameter in the struct Sensor{}** per sensor)

Then it might be that one sensor get read every 1700, 2nd every 1800 and 3rd every 2000 milliseconds. (do not set time too critical, keep e.g. 100 ms margin)

Then you should see more differences, especially over time, that sensor 1 is read slightly more often than sensor 2 and 3 etc.

Does this help? Rob

[RobTillaart]

Another thought is that humidity does not change as fast as temperature, so processing it as often does give a (very very small) gain. Alternating the processing can also save some CPU cycles. But these tricks can only be done if they fit into the requirements of the project at hand.

[ToineSiebelink]

Hi Rob,

Thanks for you detailed reply and apologies for my delay in answering back. You answered all my question. I think what I get now is good enough as I explain I just had some doubts about the timing but you now explained that. KInd regards,

Toine

[RobTillaart]

If all questions are answered you may close the issue