Read the statement by Michael Teeuw here.
MMM-DHT22
-
@Jonae Nicely done.
I’ve used MMM-CommandToNotifcation/MMM-ValuesByNotification for mine, with MMM-Temperature prior to that. Nice to have a specific to device module, though. :)
-
@ankonaskiff17 said in MMM-DHT22:
@Jonae Have you by chance done or looked at any sensors that use I2C?
No
-
-
Version info:
Version info:
v1.0.0 - Initial release
v1.0.1 - Added option to modify the color of the temperature and humidity icons
- Added option to modify the header size
v1.0.2 - Fix the error readings from sensor
- Added option to calibrate the sensor readings
- Added option to change units: C or F -
-
Thanks for your work - it looks good and has the offset feature I need! Like @BKeyport I formerly used MMM-LocalTemperature, but it won’t run on my new MagicMirror build.
For context, I currently do have MMM-DHT-Sensor running on this instance. It runs just fine, but I would prefer the look and feel of yours, as well as needing the offset feature. I have also tried changing from GPIO 4 to GPIO 21 - same results [MMM-DHT-Sensor works on either, MMM-DHT22 works on neither].
My issue with MMM-DHT22 is understanding whether one can get it to run on a Raspberry Pi 4? I have been unable to do so, and it appears to be issues with the Adafruit_Python_DHT libraries. My research appears to show your module relies on that Adafruit library, and the Adafruit library doesn’t support Raspberry Pi 4.
Am I missing something? If so, what? If not, is there a workaround?
-
@JohnGalt I had no trouble with the Adafruit libraries on Pi4. It should be working just fine - Take a look around https://forums.adafruit.com/ - there might be fixes or something available.
-
@BKeyport thanks for the response. It looks like my issue is actually with the Linux 12 / bookworm version of Raspbian I installed when rebuilding my MagicMirror, as opposed to the R-Pi 4 hardware.
In reading the Adafruit forums here: https://forums.adafruit.com/viewtopic.php?p=938344&hilit=Adafruit_Python_DHT#p938344 I find the official Adafruit response to someone with the same issues is that “DHT22 really sucks to use on linux” and … “you will be a lot happier just using the DHT20 and friends”, with a reference to an Adafruit web article at https://learn.adafruit.com/modern-replacements-for-dht11-dht22-sensors/overview.
In short, the advice is to just buy all new sensors for your Raspberry Pi installs. The OP pointed out that while he acknowledges the newer sensors may indeed be better, that " I spent a good amount of money buying and building, and for all of that to go away with an update really stinks! :( ".
I agree with him since I have probably five (5) DHT 11/22 sensors working on R-Pis, and while it looks like he found a way to upgrade all pip libraries and get it working again, it also appears to only be a matter of time until another update or upgrade of something breaks the system.
Again thanks for pointing me in the right direction.
-
@JohnGalt I’m betting LadyAda and co are working on a fix all the same. They’re big on keeping old hardware working.
-
@BKeyport - That has been my general impression of Adafruit, and for the sake of general continuity, I do hope that is the case. All that said, the situation with the sensor libraries has been a mess for years - with my personal favorite gripe being libraries being deprecated without clear messaging on the website hosting the old, together with new libraries with very similar names but different functionality. For the life of me I cannot understand why simply incrementing the version numbering wouldn’t have accomplished what was needed [accompanied of course, by clear messaging…].
Meanwhile I have ordered and received some DHT20 sensors, and will soon begin standing some of those up. This has entailed first building a development instance to work on, as I find the MagicMirror system to be fragile, and I want to minimize downtime on the production instance. As of yesterday I do have the dev instance running and am trying to iron out a couple of wrinkles, like tracking down why and how the default calendar module on the new dev instance doesn’t display recurring appointments the same as on the existing [production] instance. Seeing as I literally copied and pasted the configuration code from the old to the new, I would think it would perform the same.
Anyway - thanks again for the input and the guidance, as always.
