Proposed removal of DHT11 sensor support

[gnydick]

@dc42 I'm curious if you could explain this? From a programming perspective, why does it matter how many models are supported for the sake of implementation efficiency.

Unless you mean the overall implementation of RRF which I would guess means you're getting to shrink the size of the code/image.

[dc42]

The issue is that the DHT11 sensor needs a 18ms delay during the reading process. This is longer than is acceptable for the Heat task, therefore the DHT sensor needs its own task. The DHT22 needs only 1ms delay, so it wouldn't need a separate task.

[garyd9]

@dc42

I wonder how many users (if any) use the DHT11 that don't read the forums. If any exist, there's really no way to know until the feature is already removed and those users pop on here to complain.

Perhaps a good solution would be to have the normal 3.3 build remove DHT11 support, but instead set a flag in the firmware if M305 tries to configure a DHT11. Then when a print job is started, IF that flag is set, send a "error, DHT11 no longer supported" message to the console (and paneldue, etc.)

That message might even include a shortened URL to something that explains that DHT11 support was removed, and give instructions for reverting to RRF 3.2.x.

Then keep that warning in there for at least a couple versions before taking it out.

(The reason for the flag, etc is because M305's are usually handled config.g, and most users never see any error messages generated from config.g)

Thinking about it - this might be a good time to add some kind of "trouble code" lookup system in RRF. So the firmware displays "trouble code XXX" (just a 16 bit integer without the overhead of strings, translations, etc), and there's some interface on duet3d.com that translates "XXX" to meaningful text, links to wiki pages, etc. That might save a significant number of forum posts for future breaking changes.

[pixelpieper]

Funnily enough I am just trying to configure a DHT11, but as it reads a temperature in the thousands °C I assume it is faulty... IMHO DHT11 can be dropped if alternatives are available. I would love to see support for the more accurate and nearly as cheaply available BOSCH BME280 instead.

Edit: Maybe even BME680 to allow the filter fan to run based of the VOC reading inside the chamber?

[pkos]

@pixelpieper You can go for DHT22. It's more accurate and has the same footprint - and it works with 3.2.2

[dc42]

BME280 could be supported vis the SPI daughter board connector, but the driver would need to be written. Does it offer any advantages over the DHT22?

BME680 could be supported likewise.

[jay_s_uk]

@dc42 this should give you an overview https://randomnerdtutorials.com/dht11-vs-dht22-vs-lm35-vs-ds18b20-vs-bme280-vs-bmp180/
The BME280 also has pressure.
It generally gives more stable readings compared to a DHT22

[dc42]

I don't have time to write a BME280/BME680 right now, but if anyone else wants to then I will provide advice. It should use SPI protocol and the primary sensor class should be derived from SpiTemperatureSensor.

[lbtqsb]

@jay_s_uk

Hi,
"long time no see", I know this a bit old, but just stumbeld upon this comparison "shoot-out" and it seems there are better alternatives to the DHT´s on the long run: https://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html

Question is now for me: What do I need to train to write the library for e.g. the sensirion e.g. here https://sensirion.com/de/produkte/katalog/SHT45/ or https://sensirion.com/de/produkte/katalog/SHT85/ (we have sensirion at work also) and the bosch (given the fact that the temperature-max is a bit low but humidity seems to be pretty on spot https://www.bosch-sensortec.com/products/environmental-sensors/humidity-sensors-bme280/)

Lucas

[dc42]

@lbtqsb I've added BMP280 BME280 support as an item for consideration in the RRF 3.5 development cycle.

[lbtqsb]

@dc42

that is really cool! Thank you! I hope my post was not too "threatening", or was it "too good", I rather not know We currently test at work printer with duet-mainboard (duet3mini) with heated chamber to around 70°C (goal is to reach around 95°C till end of the year (need to switch cables and or maybe motors for that) and you can already now see that the dht´s drift away from our other laboratory temperature probes, e.g. when our good calibrated voltcraft probe I installed right next to the dht inside says chamber has 70 dht tells me 65 and so forth, let´s see what even higher temperatures will show Can report back if that stays same with 3.4 or higher, but I think the posted website shows already that dht´s can vary quite a bit +- so the easiest would be to switch to something that has a lower error (also the bosch seems to give rather "hot" values back). On the very long run (3.5/3.6 or even higher) it would be great to be able to calibrate temperature-probes, first maybe by a simple +- value and maybe later with a LUT but I remember I had this discussion already in the forum some time ago...

[dc42]

@lbtqsb the SHT45 and SHT85 are I2C only, so only usable reliably with very short cable lengths. The BME280 also does SPI, which is better with longer cable lengths and will fit in with the existing SPI temperature sensor support, so I plan to support it.

Have you considered using a thermistor or PT100 or Pt100 sensor to monitor the chamber temperature? Or do you need to monitor humidity as well?

[lbtqsb]

@dc42

Thanks! Definetly I can cut the cable shorter! Will try that. Ah you are right we do not really need humidity, it was more a test to see how a heated chamber maybe could drive out relative humidity as well. Yeah so I guess on the long run it will be replaced by a "classic" temperature sensor. Albeit in the filament-chamber of course it will stay there to trigger for now an alarm to swap dry-bags and on the long run have an automated dehumidifier take care of that.
Thanks!

[dc42]

@lbtqsb btw I didn't find you post at all threatening. I had been looking at the BMP280 and BME280 already.