Proposed removal of DHT11 sensor support
I am considering removing support for DHT11 sensors from RRF 3.3 or 3.4 because code that supports DHT21 and DHT22 sensors but not DHT11 would permit a more efficient implementation.
Do any users have DHT11 sensors in their Duet+RRF systems?
fractalengineer last edited by
I'm not so you can dump it lol
clegg78 last edited by
DHT22 are easily available and far more accurate I've found. I used both but standardized on 22's for chamber temps and filament drybox humidity monitoring.
gnydick last edited by
@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.
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 last edited by
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 last edited by 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 last edited by
@pixelpieper You can go for DHT22. It's more accurate and has the same footprint - and it works with 3.2.2
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 last edited by
@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
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.