[NewPing] Use Direct GPIO access to reduce jitter on ultrasonic sensors

[TD-er]

See: #4165

• Upgrading the NewPing library to one being 4 years newer ;)
• Re-apply the ESPEasy specific changes to know reason for failing a ping
• Re-apply the more accurate conversion to float cm (or inch)
• Use GPIO Direct access, the same as for Dallas sensors (See [Dallas] Fix Dallas 1Wire plugins on ESP32 #4164 )

Also added fix for timing critical issues for the P005 DHT sensors.
The P005 DHT plugin should now (finally) no longer be dependent on those awfully critical timings as reported by some users.
Those DHT sensors may have some drift in timings based on temperature (for a temperature sensor....)
Now the timings are all relative, so any drift among sensors should no longer matter.

Still to do:

• Check if several ping tasks can send out pings while other is still active
• Actually test on ESP32 (and ESP8266) to get some idea of the improvements using direct GPIO access
• Document plugin
• Get official permissing to fork the NewPing library because of changed license. Email has been sent.
• Test Ultrasonic sensor(s)
• Test DHTxx sensors
• Add AM2320 sensor to the DHTxx plugin (Multiple AM2320 --> CRC FAILED #2942)
• Check effect of reported bug in ESP32 micros(): ESP32 micros() bug pstolarz/OneWireNg#38

The new license of NewPing states:

// NewPing Library - v1.9.4 - 01/26/2022
//
// AUTHOR/LICENSE:
// Created by Tim Eckel - eckel.tim@gmail.com
// Copyright 2022 License: Forks and derivitive works are NOT permitted without
// permission. Permission is only granted to use as-is for private and
// commercial use. If you wish to contribute, make changes, or enhancements,
// please create a pull request. I get a lot of support issues from this
// library, most of which comes from old versions, buggy forks or sites without
// proper documentation, just trying to wrangle this project together.

This is a reasonable requests from the author, but merging this PR will be halted until official permission has been given or suggested changes to the library may have been merged via some pull request to the original library.

Edit:
Permission has been granted via email (within 2 hours :) )

Fixes: #4026
Fixes: #3494

[TD-er]

Would be really nice if someone could test these plugins.
Neither has been tested by me on real hardware.

The P005 DHT plugin should now (finally) no longer be dependent on those awfully critical timings as reported by some users.
Those DHT sensors may have some drift in timings based on temperature (for a temperature sensor....)
Now the timings are all relative, so any drift among sensors should no longer matter.

[ErikApption]

Would be really nice if someone could test these plugins. Neither has been tested by me on real hardware.

I have issues with couple sensors on my ESP32, I'm willing to give this a try however, I was not able to find a nightly build or simple instructions to build it. If you can point me to one of these, I'd like to test my SR04 and DHT11. Both are acting with recent espeasy and tasmota builds.

[TD-er]

Both should be in the "normal" build
So if you pick one of this GH Actions build you should have all the latest code in it.

[TD-er]

By the way, which other sensors are having issues on ESP32 lately?

[TD-er]

I did test the ultrasonic sensor myself both on ESP32 as well as ESP8266.
Both seem to work fine.

And for fun, here a screenshot of the signals on the trigger and echo pins:

The 2 signals on the top are digitally sampled.
The bottom 2 signals are the same pins, but measured analog.

You can clearly see the 8 pulses of 25 usec, sent by the sensor (on the analog signal) and the received pulse width on the echo pin. (25 usec pulse => 40 kHz)

[ErikApption]

I can confirm same here. Also this change made a huge difference on my DHT11 - it was receiving alot of invalid data before now it seems to be perfect again.

[TD-er]

Have you also tried the Dallas sensors?
Those also work very very well now. :)

[ErikApption]

Ok so it is not totally resolved... I tested two different SR04 sensors and same result.

I'm getting quite a bit of these errors. On older ESP8266, ESPEasy + SR04, I was getting proper measurements - aka 2+ meters but with this new version I'm only getting readings under 2m. Also it would be nice if we could get a null or -1 for errors instead of 0.

500536: EVENT: GarageDoor#Distance=0.00
501506: ULTRASONIC : TaskNr: 1 Distance: 0.00 cm Error: Echo too late, maximum distance exceeded
501535: EVENT: GarageDoor#Distance=0.00
502507: ULTRASONIC : TaskNr: 1 Distance: 0.00 cm Error: Echo too late, maximum distance exceeded

[TD-er]

Hmm will check the differences among library versions as I did not change anything related to the max. distance.
Over 38 msec it should -as far as I know- consider it a "no ping received" and below there is a limit set by the user which is then given to the library as an upper limit.

[TD-er]

I did a quick test here and it measured upto 3m55 when pointing it to the ceiling, which is about right. (it is a triangle shape so it is hard to point it exactly into the top corner)
Make sure you have the distance upper limit (Max Distance) set to allow over 200 cm.