Home Measurement with Raspberry Pi, ESP8266 and DHT22

I have a Raspberry Pi A+ sitting in my kitchen window for over a year already, using it as webcam (first idea was some timelapse over a year with all seasons. Too much movement in the first time, so the whole-year overview takes a little longer.) Yesterday I remembered that I also have a few DHT22 temperature and humidity sensors flying around.

So I decided to hook one up to the RasPi and see what it would spit out. Just wired it up to GND, 3.3V and to GPIO17, modified a Python script which uses the AdaFruit DHT library which I found on the net, and it spits out what I need. Here is a guide from them for a starting point.

This data needs to be visualized somehow. I remembered using MRTG 15 years ago. Good news is that MRTG is still maintained and easily available. Setting it up and adding the sensor to /etc/mrtg.cfg:

### Global Config Options
WorkDir: /var/www/mrtg
Options[_]: growright, nobanner
EnableIPv6: no
WriteExpires: Yes

######################################################################
# System: CamPI DHT22
# Description: Temperature + Humidity in Kitchen Windows
######################################################################

Target[CamPi-dht]: `/usr/local/bin/dht22.py`
Title[CamPi-dht]: Temperature and Humidity in Kitchen Window
MaxBytes[CamPi-dht]: 1000
AbsMax[CamPi-dht]: 1000
WithPeak[CamPi-dht]: dwmy
Options[CamPi-dht]: gauge, growright, nopercent, pngdate
YTicsFactor[CamPi-dht]: 0.1
Factor[CamPi-dht]: 0.1
#kMG[CamPi-dht]: ,k
YLegend[CamPi-dht]: °C / %
ShortLegend[CamPi-dht]: °C/%
Legend1[CamPi-dht]: Temperature in °C
Legend2[CamPi-dht]: Relative Humidity in %
LegendI[CamPi-dht]: Temperature °C
LegendO[CamPi-dht]: Rel. Humidity %
PageTop[CamPi-dht]: <h1>Temperature and Humidity in Kitchen Window</h1>

To get the fractions of temperature and humidity, the YTicFactor and Factor options are important.

Start the index building, let mrtg run once, and you get the first empty graphs. It takes about 10 minutes so the grpahs get filled with valid data. Remember to put mrtg to the list of cronjobs so it runs every 5 minutes.

Today I found out about ESP8266 being able to directly read out a DHT22 and offer the data as web server. I needed to flash the latest NodeMCU firmware - a simple guide is available here. You should download the latest development build of NodeMCU and flash that. Just enter the path and the name of the downloaded file under "configuration" (by hitting the gear symbol you can browse the file system for that) of the esp8266-flash.exe tool, address 0x00000 is correct. Hint: Solder that CE_PD-pin on the ESP-01-boards directly to Vcc. For flashing, you need to connect GPIO0 to GND. In all cases, an eletrolytic capacitor of 1000µF between GND and Vcc helps keeping the board stable.
This firmware offers plenty of functions which you can use with LUA, a basic programming language. ESPlorer makes it extremely easy to write and test a program. My version of init.lua looks like this (adopt SSID and PW to your Wifi).

-- setup Wifi
wifi.setmode(wifi.STATION)
wifi.setphymode(wifi.PHYMODE_N)
wifi.sta.config("SSID", "PASSWORD")
wifi.sta.connect()

--start server
srv=net.createServer(net.TCP)
srv:listen(80,function(conn)
  conn:on("receive", function(client,request)

-- read DHT22 on GPIO2
    pin = 4
    status,temp,humi = dht.readxx(pin)
    h=10*humi
    t=10*temp
    if( status == dht.OK ) then
      buf = t.."\n"..h.."\n"
    end
-- reading DHT done, now spit it out
    client:send(buf)
    client:close()
    buf = nil
    t = nil
    h = nil
    status = nil
    temp = nil
    humi = nil
    pin = nil
    collectgarbage()
  end)
end)

The temperature and humidity are now accessable via webbrowser. On the Pi, create a bash script, for example /usr/local/bin/nodemcu1.sh (make it executable via "sudo chmod a+x /usr/local/bin/nodemcu1.sh"):

wget -q -O nodemcu1.txt http://nodemcu1/
cat nodemcu1.txt
echo 0
echo NodeMCU1 Living Room
rm nodemcu1.txt

Add an entry to your /etc/mrtg.cfg like this (take the rest from the example above and adopt the device name in the brackets):

######################################################################
# System: NodeMCU1 DHT22
# Description: Temperature + Humidity in Living Room
######################################################################

Target[NodeMCU1-dht]: `/usr/local/bin/nodemcu1.sh`
Title[NodeMCU1-dht]: Temperature and Humidity in Living Room

Run the mrtg indexmaker and after that mrtg again.

Now you have a mobile temperature and humidity sensor which you can put anywhere in your Wifi range.
You only need a 3.3V power supply - either via USB and step-down, or battery and step-up. There are rumors that with connecting to pin 1 of the mcu you can enable a deep sleep mode, but as the ESP8266 is working as web server it should be always-on. My USB-Meter shows that the current drawn is always jumping around between 0-200mA. This is not bad for a web server!

Update 21.01.2016: Two more DHT-22 arrived yesterday, now I have four sensors in different rooms. I like the overview over the climate at home :)

Polarity Protection with P-MOSFET

I still need to learn a lot in electronics. Just yesterday I accidentally connected the battery wrong to my LDO XC6206 - which it seriously disliked and afterwards spat out 0.56V instead of 3.3V. No problem, I have plenty of them in the box - but this may happen more often and I don't want to always solder in a new LDO.

So I looked for ways to protect the IC from wrong polarity of the battery. Since I power a ATmega328 based 7-segment-LED watch via a LiIon battery this way which needs around 2mA current, a usual diode is no alternative. The voltage drop of ~0.7V is not usable with LiIon (3.0-4.2V) on a 3.3V LDO. A Schottky diode would be way better with only 0.3V voltage drop, but still makes quite some capacity of the LiIon unusable.

Thus I decided to use the AO3415A P-channel MOSFET. It has to be connected with Drain to the battery, Source to the Vin of the LDO. Gate connects to Ground. Since the LiIon voltage is well within the specs of the AO3415 for Vgs(max), I can even work without a Zener diode/TL431 to limit the voltage; a resistor at the Gate seems not necessary as well. This is a unusual orientation for a P-FET, the first time I soldered it in without turning it on its back ;)

The results are better than I expected. The battery has 4.171-4.172V; on Source, I measure the same value down to the millivolt.

How does this protection work? When connected correctly, the body diode is conducting from Drain to Source. The Gate gets negative compared to the Source, the FET opens fully. The resistance drops down to Rds(on) for the current voltage. The load is so little with ~2mA that there is no significant voltage drop, it should be in the nano- or micro-volt area.

The capacitance behind the FET is quite small and should pose no risk that the FET wouldn't disconnect. If the battery is connected the wrong way, no current can flow as the body diode of the P-FET will block in that direction. The XC6206 won't be destroyed anymore. With such a cheap transistor the power supply is much more reliable.

Improved Data Logger for Charger Measurements

I had some spare time during my vacation so I finally built a more solid version of my shunt and voltage divider "breakout" board which I used to measure the performance of LiIon chargers with.
I soldered everything onto a small breadboard and adopted the programming a little ...

Improved Data Logger for Charger Measurements.

As you can see, the plenty of loose cables are gone. Everything is statically soldered together so that no distortions should be possible anymore.

During the first tests, some error spots are still left. The two DuPont cables that lead from the charger to the board don't make solid contact, need to solder my own ones. And when moving the plugs in the USB ports of the computer, the voltage and current delivered are changing a little as well.

The first test: The DuPont cables for connecting
 the charger need to be replaced.

But the main goal was to minimize other distortions and that worked great. I now use a 10 mOhm resistor which can stand 1W of heat dissipation and has a <= 1% error. The ADC (ADS1115) is connected via 10 kOhm resistors to its ends, ensuring very little bias. The voltage divider consists of two 100 kOhm resistors, where the connection to the ADC has again a resistor of 1 kOhm. The OpAmp for fetching the amplified differential voltage from the shunt is removed, I'm now using the built-in PGA of the ADC to get a good resolution. 1mA current over the shunt equals 10 µV, while the resolution of the ADC is ~7µV. I should probably add some oversampling as this signal has true noise and can improve this way.

Update 22:00h: Soldered wires with better contact to the board. This helped the resistance of the whole circuit to drop by 10% to now ~90 mOhm (including the battery with its inner resistance).
Also used a USB hub so only one connection is used on the computer. Turns out that the plugs show similar behaviour on the hub when the computer is moved - you can clearly still see every movement test.
The charger seems to get even less disturbed looking at the charging curve. >1A until 4.20V are reached and then the current drops slowly, while the voltage rises up to 4.25V for a short time. This is all within LiIon specs and looks quite nice.

SPI Flash programmer with Arduino Pro Mini

Last updated 01.01.2016
I recently ordered a small Wifi bridge/repeater dongle which I wanted to use to offload the WPA2/AES encryption from my satellite receiver and have it connected virtually by ethernet. This Vonets Mini300 can't cope with long WPA passwords though with special characters - a "+" sign gets stored as space, thus it won't connect to my WLAN. The firmware was quite outdated and the update servers have changed, so the internal update mechanism doesn't work. The black and red wires are for a serial console to access the operating system on the little box directly and to see if it is possible to fix via command line interface. Unfortunately, the system spits out the boot messages, but is locked against keystrokes.

I started to investigate alternatives: OpenWRT for the MT7620N processor should work. Or the manufacturer sends me the most recent firmware so I can flash it myself. But there we are: Like usual PCs BIOSes, Wifi routers use SPI flash rom for storing the firmware and data. You can buy special flashers and use the software the manufacturer offers for it. Or - you build your own!

It's actually quite easy. You can use an ATmega board, connect it with USB-to-serial-converter to your computer, and wire up the Flash IC directly to the ATmega SPI pins. My first attempts used exactly this setup, but with plenty of DuPont cables and thus possible spots for errors - and for noise on the lines which can (and did!) disturb proper operation.

For such a flash writer you need:
- An Arduino Pro Mini board (cheap and runs with 3.3V)
- A USB-to-serial converter like FT232RL, PL2303, CP2102, ... (I used a PL2303) with 3.3V output
- Very useful is a SOIC8/SOP8 clip for easy access to the Flash ROM IC.

Wire the USB-to-serial-converter to the Arduino Pro Mini. If you want auto-reset for easier flashing, you need to solder a wire from Pin 2 of the PL2303 to Reset or DTR on the Arduino - but through a 100nF ceramic capacitor. Look at the photo at the end to see my version of the hack.



Software:
- flashrom - https://www.flashrom.org/Flashrom
- frser-duino for the ATmega328 - https://github.com/urjaman/frser-duino

The frser-duino Makefile contains some entries which you should adopt. I found out the hard way that the bootloader of the Arduino only talks at 57600bps. You need to tell that to avrdude via -b option, and set this in the Makefile for frser-duino. Also you can set a second bitrate below that line. I set it to 230400 and it works great; contrary to the 115200bps which the unmodified version offers. You should set the proper interface for your USB-to-serial-converter, the default /dev/ttyS0 is for Linux systems; on my MacBook Air, it is /dev/tty.usbserial.

Then you start building and flashing the firmware with:

make clean all program

 This will build the firmware and upload it by issuing the correct avrdude command line:

avrdude -c arduino -p m328p -P /dev/tty.usbserial -b 57600  -U flash:w:frser-duino.hex

That's it! Wire up the SPI Flash ROM to the proper SPI Pins on the Arduino or solder a board with a DIP8 connector which is correctly connected and you're good to go.

This way I can just plug the programmer into the computer and directly use it with flashrom to read or write SPI flash roms.





Now with the optimized firmware with 230400bps support the reading and writing significantly improved in terms of speed.

koepi$ time flashrom --programmer serprog:dev=/dev/tty.usbserial:460800 -r 16MB_empty.bin  

flashrom v0.9.8-unknown on Darwin 15.2.0 (x86_64) 

flashrom is free software, get the source code at http://www.flashrom.org

Calibrating delay loop... OK. 

Warning: given baudrate 460800 rounded down to 230400. 

serprog: Programmer name is "frser-duino" 

serprog: requested mapping AT45CS1282 is incompatible: 0x1080000 bytes at 0x00000000fef80000. 

Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on serprog. 

Reading flash... done. 

real 12m42.328s; user 0m6.428s; sys 0m12.367s

I also tried the STM32F1xx based vserprog, but the USB connection wasn't returning the expected results. Flashrom couldn't initialize the programmer. The authors of the code state that minimal changes are necessary for setting the necessary pull-ups, but I didn't find the spots in the code where to add that - bummer! With 36MHz SPI frequency, direct USB support without extra dongle and, most important, DMA it is the best you can get performance-wise.

With this SPI flash programmer I can flash the newest firmware from the manufacturer - the bug is still there though. But it can access it's update server so there is still hope for a fix in the near future.

I also cut-and-copied the firmware image - the U-Boot Bootloader didn't allow any access to it's shell, so I use breed from HackPascal now. The first 192kByte are Bootloader (pad with zero bytes up to the 192kByte boundary), then there's config data in the next 128kByte (cut out from the original flash dump). After that at 327680 bytes the firmware itself is stored. MT7620N firmwares from OpenWRT don't work, unfortunately. I tried even to build a version myself, but with the same result. Using a bigger SPI flash rom works, but there is no use for it when only the original firmware for 4 MByte flash is running on the machine.

Update 01.01.2016: I had to reduce the speed to 115200kbps again for reliable operation. The programmer stopped mid-reading after some time with 230400kbps.

Erase/write done.Verifying flash... VERIFIED.serprog: Output drivers disabled
real 61m53.970suser 0m10.722s
sys 0m50.472s

Pimp the Bolun WR-601 wireless mic

More than 5 years ago I bought a cheap Bolun WR-601 wireless lavalier microphone for playing around with my camcorder and proper audio for example at presentations. I totally forgot about it till yesterday since I never had used it before. Short tests at home with an old netbook as recording device were promising. But then when needing it at a seminar - which was close to train rails and the mandatory radio distortions close to the power lines-, I couldn't use it as reception was limited to one or two meters. The sound captured by the Samsung HMX-H200 camera itself is still usable, but you have this usual thin, distant 'speaker in a huge room' sound.

So the receiver of the Bolun WR-601 needed a better antenna. Since it uses fm frequency, I removed the socket from a cheap, small TMC antenna for GPS navigators (these are dirt cheap on eBay and look like this.). It is more or less a wound up long wire antenna with good reception properties. I soldered one end of a small piece of silver wire to it, the other end to the antenna solder point which is used on the PCB. Fixed it with a small drop of hot glue and made the antenna hole in the other case side bigger. After closing it, it needs even more hot glue to be stable and more sturdy.

The first test showed outstanding success. I went more than 5m away into the kitchen, so the signal had to go through walls - and no distortion was added! This seems to be a must-do modification so this cheap lavalier mic works as intended. A short test capture shows success while walking through the house: Test MP3.