Support DHT11/22

[tiagoboldt]

Please consider adding a GPIO driver for DHT22/11 temperature and humidity sensors.

[deadprogram]

This requires a pulseIn style of API to be able to function, in similar fashion to what https://github.com/hybridgroup/gobot/issues/246 would need.

[deadprogram]

Also same as #152

[pakohan]

I'd also be interested in that. I'm a little concerned about the fact that we're dealing with a digital signal where we'd need to differentiate a 28µs signal from a 50µs signal (from what I can see in the data-sheet. My concern is that the Go garbage collector and/or scheduler will make it impossible to read the correct value of the GPIO pin.

I was searching for another driver that solves this problem already but the only drivers reading values from a pin are button drivers that poll in a relatively long interval to get the value of the input.

Since I'd be interested in writing the driver, here's my background: I'm a experienced Go backend software developer (writing REST APIs for our company) but I'm not very deep into the Go runtime and garbage collector. Additionally, some years ago when studying I had to write a C-Linux driver for the RPi, but just for reading a button value and toggling a LED. After that, I've done nothing anymore with embedded systems, and I never worked with Gobot before.

From this tutorial I found some python that includes a C driver for the sensor. It seems like it is running in user space and so we might be able to write a driver using CGo. The relevant parts of the driver can be found here. I think the fact that it sets the kernels scheduler priority so the reading process doesn't get interrupted speaks for itself.

Nevertheless, it's a nice challenge. What could be the best solution? Maybe we can implement some tiny low-level reading logic in C and make it available via a generic driver that outputs []byte via the io.Reader interface? Asking @deadprogram, what is already there? What is missing? Since you know Gobot, how would you do it?

I'm really interested about the solution we'll come up with ;-)

[pakohan]

Hey guys, I've hacked sth. together :-)

@tiagoboldt That could be interesting for you: https://github.com/pakohan/dht

@deadprogram I'd like to see this in the Gobot repo, but I think before supporting the other two platforms of the upstream driver the quality isn't good enough. Also, do you really want to have CGo in the Gobot repo, I think this will affect the compilation time of the whole library :-(

If you have any ideas or a solution that would be great. I still hope it's possible to write it entirely in Go, but the weather is too nice to develop and debug all of this until it works ;-)

[stevemcquaid]

I think the correct approach here is emulate pyfirmata and use a modified Firmata sketch. The network latency is never going to be fast or stable enough to get any sort of accuracy for these timing-based sensors. The time differential really needs to be done on the hardware itself. Since network latency can add +-10 full milliseconds even under the best conditions. (Plus it would stink to have measurements change as a function of distance from wifi router.)

I will make a PR to get these changed into firmata itself. Would someone be willing to implement that firmata PulseIn/PulseOut method in gobot? https://github.com/jgautier/arduino-1/commit/eb48b875db50b467b59f6cd0e0b741efbf1e6a97