dht.go:19: exported type SensorType should have comment or be unexported
dht.go:22: receiver name should be a reflection of its identity; don't use generic
           names such as "this" or "self"
dht.go:35: comment on exported const DHT11 should be of the form "DHT11 ..."
dht.go:37: comment on exported const DHT22 should be of the form "DHT22 ..."
dht.go:39: comment on exported const AM2302 should be of the form "AM2302 ..."
dht.go:43: comment on exported type Pulse should be of the form "Pulse ..."
           (with optional leading article)
dht.go:55: should drop = 0 from declaration of var boost; it is the zero value
dht.go:83: should drop = 0 from declaration of var value; it is the zero value
dht.go:99: should drop = 0 from declaration of var b; it is the zero value
dht.go:109: don't use ALL_CAPS in Go names; use CamelCase
dht.go:112: don't use ALL_CAPS in Go names; use CamelCase
dht.go:175: if block ends with a return statement, so drop this else and outdent
            its block
dht.go:212: comment on exported function ReadDHTxx should be of the form
            "ReadDHTxx ..."
dht.go:243: comment on exported function ReadDHTxxWithRetry should be of the form 
            "ReadDHTxxWithRetry ..."
dht.go:280: error strings should not be capitalized or end with punctuation or a newline

These seem to be easy fixes, mind if I just do them?

Hello!

I have been trying to use the first reading example in the code.

As said in the title I am using Ubuntu server 20.04 64bits. I have tested this on Ubuntu 20.10 also. Checked in all 64 and 32 bits editions.

The thermometer works on Raspbian just fine using this library but it doesn't on Ubuntu. This is the error:

[     dht] WARN  Error during call C.dial_DHTxx_and_read(): failed to open GPIO export for writing

The thermometer model is AOSONG AM2302

Do you know how this could be fixed?

Thanks a lot!

First time posting so hopefully properly. Am experimenting w/RPI3s + several Zero Ws. Using DS18B20s on pin 4 (GPIO4) so DHT22 is connected to pin 5. Code snippet is:
humSensor := dht.DHT22
dht22Temp, dht22Humidity, _, err := dht.ReadDHTxxWithRetry (humSensor, 5, false, 10)

Code runs fine in RPI3 but errors on Zero. have swapped Zeros, 22s, all connector wires betw RPIs & breadboards, tried several resistor values. Errors I see are:
Failed to open gpio direction for writing!
2017-08-13T04:36:51.860 [dht] WARN Error during call C.dial_DHTxx_and_read()
2017-08-13T04:36:54.080 [dht] WARN Can't decode pulse array received from DHTxx sensor, since incorrect length: 79
2017-08-13T04:36:56.293 [dht] WARN High edge value duration 100µs exceed expected maximum amount 97µs
2017-08-13T04:36:58.502 [dht] WARN Control sum 221 doesn't match 115 (130+235+1+5)
2017-08-13T04:37:00.719 [dht] WARN Control sum 220 doesn't match 141 (129+214+17+37)
2017-08-13T04:37:02.937 [dht] WARN Humidity value exceed 100%: 149.4
2017-08-13T04:37:05.154 [dht] WARN High edge value duration 107µs exceed expected maximum amount 97µs
2017-08-13T04:37:07.361 [dht] WARN Control sum 158 doesn't match 0 (3+247+1+5)

Have lotsa experience w/various languages, etc, etc. But do not understand what the problem w/the Zeros is. Both Zeros do the same thing, so I'd guess it's cockpit error or (perhaps?) difference in Zero using the lib. Thanks in advance for your help and kindness.

If set env to
GOOS=linux GOARCH=arm GOARM=5
ind try to compile
go build ./examples/example1/example1.go
got error:
build command-line-arguments: cannot find module for path github.com/d2r2/go-shell

Unable to build this in an alpine docker image.
Adding following "stdint.h" will fix it like redis/redis#336

#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <fcntl.h>
#include <sched.h>
#include <time.h>
#include <unistd.h>

Hi,

Tested on RPI 3B+, tried running on RPI-Zero and it fails with the following error:

Error during call C.dial_DHTxx_and_read(): failed to export pin 4

Any help much appreciated.

Hi. I tried to use the driver to detect the temperature in the indoor environment for days. However, it would always suddenly throw a fatal message after collecting the temperature data for ten or more hours. Is there anyway for ignoring this kind of outlier?

$ go version
go version go1.12.6 linux/arm

I've tried code from example1:

	sensorType := dht.AM2302
	pin := 22
	temperature, humidity, retried, err :=
		dht.ReadDHTxxWithRetry(sensorType, pin, false, 10)
	if err != nil {
		fmt.Println(err)
	}

	fmt.Println("Sensor = %v: Temperature = %v*C, Humidity = %v%% (retried %d times)",
		sensorType, temperature, humidity, retried)

compiled and run by:

GOARM=7 GOARCH=arm GOOS=linux go build -o main & ./main

got error:

Error during call C.dial_DHTxx_and_read(): failed to open pin 22 direction for writing

in the same time tried to use DHT from https://github.com/adafruit/Adafruit_Python_DHT (python lib) and it worked fine.

Also I've tried to connect to different pins, but got the same result -- works fine on python and doesn't work on golang lib :(.

Would it be possible to add support for the AM2301 (DHT21)? That would be much appreciated since it is one of the easiest available DHT sensors to me.

Datasheet is available here: http://www.haoyuelectronics.com/Attachment/AM2301/AM2301.pdf

Hi, I made small temperature service for my own use on beaglebone https://github.com/Gonzih/temperature-service. Originaly i wanted ot use your library but it did not work. I looked at Adafruit labrary https://github.com/adafruit/Adafruit_Python_DHT and main difference that I saw is /dev/gpiomem usage instead of /dev/mem on beaglebone. Do you think it is possible to adjust this labriary in a way that it will work on Beaglebone also? Their implementation should work on beaglebone black, but also works on my beaglebone white board.

Thanks!

in the line 184, 185 of dht.go. why don't add the decimal part to the value? Based on the datasheet of DHT11, it supports the decimal part.

Hi, thanks for the lib - works great!
here's a patch to get rid of compiler warnings - I see these when cross-compiling to arm with
CC=arm-linux-gnueabi-gcc CGO_ENABLED=1 GOOS=linux GOARCH=arm GOARM=6 go build <app.go>

----------------------------------- dht.go.h -----------------------------------
index 6cda1e0..fc05c70 100644
@@ -7,6 +7,7 @@
#include <fcntl.h>
#include <sched.h>
#include <time.h>
+#include <unistd.h>

// GPIO direction: receive either output data to specific GPIO pin.
#define IN 0
@@ -52,7 +53,9 @@ static int gpio_export(int port, Pin *pin) {
}
(*pin).pin = port;
bytes_written = snprintf(buffer, BUFFER_MAX, "%d", (*pin).pin);

• write(fd, buffer, bytes_written);

• if (-1 == write(fd, buffer, bytes_written)){

•    fprintf(stderr, "Failed to export pin!\n");
  

• }
  close(fd);

  #define DIRECTION_MAX 35
  @@ -92,7 +95,9 @@ static int gpio_unexport(Pin *pin) {
  }

  bytes_written = snprintf(buffer, BUFFER_MAX, "%d", (*pin).pin);

• write(fd, buffer, bytes_written);

• if (-1 == write(fd, buffer, bytes_written)){

•    fprintf(stderr, "Failed to unexport pin!\n");
  

• }
  close(fd);
  return 0;
  }

As @jnovack report, app termination produce long output, which can contains hundreds/thousands of lines:

2018/10/01 11:18:47 Signal received, cancel context
2018/10/01 11:18:47 Signal received, cancel context
2018/10/01 11:18:47 Signal received, cancel context
2018/10/01 11:18:47 Signal received, cancel context

As it found each call to ReadDHTxxWithRetry left goroutine live and running inside of shell.CloseContextOnKillSignal(cancel) waiting for termination event.

On my Raspberry Pi 3 (64bit kernel and userland) the pins are in the 4 character range (e.g. 2017 for GPIO23) according to kernel debug interface. But the library only uses the first two digits:

bytes_written = snprintf(buffer, BUFFER_MAX, "%d", pin->pin);

Writing manual a 2 digit number in the kernel interface with echo does not work (creates an error), but the "2017" does work.
Will fork the code and try to increase the buffer the next days when I have time again.

As documentation, I executed:
go get -u github.com/d2r2/go-dht

# github.com/d2r2/go-dht
In file included from ../../go/src/github.com/d2r2/go-dht/dht.go:3:
../../go/src/github.com/d2r2/go-dht/dht.go.h:304:15: warning: implicit declaration of function 'sched_setscheduler' is invalid in C99 [-Wimplicit-function-declaration]
# github.com/d2r2/go-dht
ld: library not found for -lrt
clang: error: linker command failed with exit code 1 (use -v to see invocation)

env GOOS=linux GOARCH=arm GOARM=5 go build godht.go.

command-line-arguments

./godht.go:24:15: undefined: dht.DHT11
./godht.go:31:1: undefined: dht.ReadDHTxxWithRetry

This is example1

I try to read out the data of my DHT11 sensor using the example. My Golang code looks like this:

package main

import (
	"fmt"
	"log"
	"os"

	"github.com/d2r2/go-dht"
)

func main() {
	temperature, humidity, err := dht.ReadDHTxx(dht.DHT11, 4, true)
	if err != nil {
		log.Fatal(err)
		os.Exit(1)
	}
	// Print temperature and humidity
	fmt.Printf("Temperature = %v*C, Humidity = %v%%\n", temperature, humidity)
}

I downloaded the lib via go get -u github.com/d2r2/go-dht.

Thereby compile the binary on my Arch Linux system. Therefore I give the ARM, OS and ARCH variables so that the binary is executable on the Pi. When compelling I get the following error:

markus@markus-pc:~/go/src/dht11-example$ GOARM=7 GOOS=linux GOARCH=arm go build
./main.go:17:32: undefined: dht.ReadDHTxx
./main.go:17:46: undefined: dht.DHT11

Does anyone have any idea what I'm doing wrong?

So I created a fork of this project in an attempt to achieve a completely "go-only" implementatiton (I know, sue me, but I have my reasons).

I got everything working, but noticed that the errors I had periodically received warning of invalid array lengths were now much more frequent. When I started digging through the code, I noticed that the function gpio_read_seq_until_timeout sleeps for times not quite on par with the DHT11 single-wire communication bus specification, though mostly compatible with it's DHT22 counterpart.

My question is this: do these functions actually support the DHT11 communication bus? Are the delays in place somehow calculated to work for both DHTxx models?