Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Tuicemen]

This was more of a task then I initially though. Originally I had planned to just use the HG DHT22 Program to simply display values from a DHT sensor. However that program is outdated and needs some drivers updated. Since I had to find my own way to display the Temperature and Humidity values in HG I figured I might as well also include away to trigger things via that info and for a DHT11 as well.
Several here and else where have stated the DHT sensors are very unreliably accurate with the DHT22 being the most accurate of the two.
I can confirm the DHT22 is more reliably accurate then the DHT11.
I Also picked up an AM2302 temperature/humidity sensor as I wanted to have an enclosure for the DHT22 and these are essentially a DHT22 in a case. However in my tests while creating a HG Program found it to be a bit more accurate then even my DHT22.
The program works with any of the three sensors and uses the HG Sensor widget which displays Temperature and Humidity alternately every second. The Info is updated at each sensor pole interval and most modules in HG are triggerable .
I over thought the triggering requirements and options for this originally or it would have been ready much sooner.
Requirements:

• a sensor if you already have a DHT11 you can use it however I recommend a AM2302 temperature/humidity sensor for this.
• jumper wires to go from the sensor to the RaspiGPIO header.
• if you use an AM2302 sensor or you have no header pins from your GPIO pins you'll require a solder gun and solder
  
• Python3 you could use Python2 but you'd have to change a line in the Program code
• The Adafruit_DHT Pi library there is a newer library based off this but since this one worked I stuck with it for this project.
  

UpDate: Zip file is now attached rename extention before opening

[Tuicemen]

Here are some shots of the Sensor displaying the info and one of the options as they appear in most HG modules.

[soxfan1966]

Nice.  Is it possible to have multiple sensors ?

[Tuicemen]

Good Question! I never thought of utilizing more then one sensor at a time.
That way you could monitor different rooms. I believe I read the max wire run for a sensor or GPIO pin was 100 feet but could be wrong.
I do plan on creating a simple weather station  but using a different sensor for that which isn't supported by the Ada_Fruit_DHT driver or the HG sensor widget.

Currently the program only utilizes one sensor and one GPIO pin.
To add another sensor I suppose you could just clone the program then make sure you specified a different pin.
You most likely would need to make another Python script too so calls didn't clobber each other.
I may just play with this Idea as I have a few DHT sensors now.
 

[soxfan1966]

I was thinking more along the lines of wireless sensors - if the phython code works with the means implemented then something like the meross sensors?  Those were the ones I tried getting working in HomeGenie over the summer.

[bkenobi]

If you are interested in temperature and humidity in the form of a wireless sensor that can read data easily into HG, I would not consider the DHT line.  You are better off looking at something that is compatible with the rtl_433 project than IMO.  I personally would consider finding something like a cheap Acurite temp/humidity sensor and a SDR.

https://github.com/merbanan/rtl_433

I personally have an Acurite 5-in-1 weather station and a power meter reader installed right now, but I also have 3 Acurite tower temperature/humidity sensors that will be installed in a few locations soon.  These work very well, are basically weatherproof, and already have the power and communication issues solved for you.  All you have to do is install rtl_433 and configure MQTT to work with the sensor you opt for.

[40]  Acurite 592TXR Temp/Humidity, 5n1 Weather Station, 6045 Lightning, 3N1, Atlas


As for wire run length, it really depends on how you connect to the sensor, the wire you select, the sensor, etc, etc.  I have DHT sensors connected to an Arduino project that are around 25' away and connected via RJ11 (4-conductor phone wire).  They have worked basically flawlessly for close to 10 years.  I was going to replace the setup with BME-280 sensors connected in much the same way, but I found these sensors won't connect at anywhere near the same wire run.  FWIW, I would highly recommend throwing out your DHT sensors and use BME-280 in a heartbeat instead.  The DHT are basically garbage (speaking from experience) whereas the BME are absolutely solid.  If you need an enclosure consider a contact lens case or camera film container (if you can find one).

[Tuicemen]

I ran a Acurite 5in1 weather station here in the city for several years. However the humidity sensor failed after about the third year.
I ordered a new sensor which took over a year to get and was twice the price of my DHT sensors. when I went to replace the sensor the ribbon cable fell apart and I never did get it attached. The DHT sensors I have will never see the outdoors. If I even get 1 to 2 years life out of each DHT sensor then they will have lasted longer then the Acurite. Since you say you've been running flawless for over 10 years with a DHT Arduino project. I suspect my DHT sensors will out last me.

I have a BME-280 on order but it is looking like it got lost in the mail!
I do have several wireless sensors already which are in the list of supported devices for the rtl_433 project at my off grid place where I plan to create a weather station. Thanks for that link!
I have a Oregon Scientific Weather Sensor in operation there which has been operational for well over 15 years. I never thought of a wireless solution from that to my Pi. I'll have to look deeper into it and see what I'll require to gather the info onto my HG Zero W.

[bkenobi]

I'd definitely check out rtl_433 since you already have sensors that are compatible.  You will require a compatible SDR which can be fairly cheap or expensive depending on your needs.  The output will be much easier to work with than the junk the DHT outputs (for accuracy, quality, and reliability).  There is some learning required, but nothing someone with enough desire can't figure out.  I have played with the project in the past but decided to go a different route in the past.  I have recently decided to go back in this direction and it is now incorporated into my RPi + HG setup and it's working quite well.

The Acurite brand is not exactly the highest quality components you can find.  However the price point in combination with the good quality puts them at a bit of a sweet spot for many.  The sensors can be had for around $8-15 for temperature/humidity towers and they offer a large number of options.  The one down side that you must keep in mind is that Acurite only has a limited number of channels for their sensors.  So if you opt for the 592TX or 592TXR (very common module at the box stores), you will be limited to 3 units due to only having channels A, B, and C.  I don't know if it's possible to use more on the same channel as they do have a unique ID.  Either way, this is not a limitation due to other options being available.

If the Acurite wasn't good enough for your needs, there are many other options from other brands.  I have been fairly happy with my VN1TXC 5in1 station.  I haven't looked into repair as it has worked without issue for several years.  I see them all over the place so they must be reasonably good or else they'd have been taken down otherwise.

As for using the RPiZW, I can't say how that would work.  In my experience, the first generation hardware for the RPi was not particularly powerful.  I originally ran rtl_433 on my RPi1B and it worked fine.  However, I found it used a large amount of resources as did HG.  I would not consider using these on the same 1st gen RPi unless you are ok with missed signals by either the SDR or your HA as well as the relatively high chance of crashes.  When I revisited rtl_433 on my RPi3B, I found it worked much better even with HG running concurrently.

[Tuicemen]

I just tested the python script with two DHT11 sensors connected one on pin4 the other on pin 17 on my Pi 3b+
With a fresh install of HG I created a clone of the Indoor-DHT-Sensor and named it Indoor-DHT-Sensor2
I set their calls to 25  & 30 second intervals and placed them in a group.
They seem to be working fine but to be sure the HG Widget is displaying the value for the right sensor and avoid crashes I'd make a clone of the Python script and use only one sensor per script.
I currently don't have any more female to female jumper wires or I'd test a 3rd DHT11 with things 

[Tuicemen]

I was concerned that one was seeing the others temperature value until I noticed a small change.

[bkenobi]

You can easily test if the values are from different sensors.  Simply change the environment one of them is in.  You can do this by holding it in your closed hand (increase temperature), blowing on it (increases humidity), or blowing canned air on it (cools it down fast).  If your leads are long enough, you can put one of the sensors in a refrigerator too.  This is also a good way to calibrate the sensors.  If you have a known good temperature then record the output of your sensors in several environments.  It would be best if you cold go to both extremes (freezer up to covered by microwaved damp towel).

[Tuicemen]

You can easily test if the values are from different sensors.  Simply change the environment one of them is in.  You can do this by holding it in your closed hand (increase temperature), blowing on it (increases humidity), or blowing canned air on it (cools it down fast).  If your leads are long enough, you can put one of the sensors in a refrigerator too.  This is also a good way to calibrate the sensors.  If you have a known good temperature then record the output of your sensors in several environments.  It would be best if you cold go to both extremes (freezer up to covered by microwaved damp towel).

Yep did the humidity and Temperature thing then notice one GPIO Pin had become undone as you can see in the Humid shots there is a large update time variance.

[Tuicemen]

While working on code for my Ecobee Thermostat and helping soxfan1966 with code for a Nest Thermostat we noticed many similarities with the API and the info they supply.
This got me to thinking about looking at the outdated HG Nest Program widget (it comes with several) in particular the widget for the thermostat display. This widget works nice with the this Program too and I prefer it over the HG default Sensor widget.
I suspect once I've ran it with the Ecobee Thermostat API code I'll use it for the Ecobee as well and hopefully not need to create a custom widget or modify this.