Particulate measurements near bushfires

Back in the 2019 Tasmanian bushfires we were lucky enough to be the other side of the Huon River from the fireground,  however we had a LOT of smoke (compare the photo below to the street view image)

We were also lucky enough to take part in a Huon Valley trial to compare HEPA filter systems which used a pair of CSIRO Smoke Observation Gadgets (further details on these units in Sensors 2021, 21(21), 7206; https://doi.org/10.3390/s21217206) to log the air quality (pm2.5 and pm10 measurements) inside and out. 

It's now 2025, and while we've been very lucky compared to the US and mainland Australia, we now have a bushfire nearby (~6km from our house) that contains the following advice:

Residents should be aware that smoke and ash may be visible in the Channel area over the coming weeks, and anyone who is at higher risk from smoke should enact their personal health plans.

So, it's time to DIY some new smoke sensors! (I would just rely on the excellent BLANkET network already in place in Tasmania, but there aren't any downwind of the current fire)

Hardware

I already have a pair of PMS7003 sensors unused in a 'future projects' box, so we'll use them. They are supported by esphome, so using an esp32/esp8266 with them seems a simple choice

Mine (located in Kettering) will use a wired esp32 (because POE makes that simple), and I'll see if I can get one mounted at the Channel Men's Shed in Margate which will need to use wifi

I don't have a nice shiny 3d printed enclosure, so it'l use something like an old yoghurt tub to weatherproof them.

Build

.. To Be Continued at the weekend :-)

The Physical Web. Yeah, thats a good idea.

In the last week I've discovered the Physical Web from google, and I'm sold on the idea. Apart from the "what's around here" geeky stuff, it's a great idea for sensible 'distant' digital signage. For example, $dayjob is at the Pawsey Supercomputing Centre, but we don't plaster our URL over the visitor area - what if guests could be gently prompted to the right URL by beacon?

Again tonight (while watching WASO play the Indiana Jones score) I noticed a set of three A3 posters explaining to users of another part of the conference centre how to connect to wifi and download <exhibit> app. This isn't even Scott Jensen's complaint of a 'dos prompt on the browser' - it's more a dig out the index card from the library, then go to the dos prompt...

All around the water tank, waiting for the rain...

Having the luxury of mains water means that I don't really care in fanatical detail about the state of the dam water levels for Perth (except that "it's lower than it should really be"). However with our new place being entirely dependant on rainwater collection off the roof into storage tanks, I'd like to know the levels of the various tanks (and therefore the volume remaining).

So, what's available - simplest is knocking on the side of the tank and guessing from the sound how full. Not terribly reliable or hi-tech, but is cheap. Dipstick also cheap, but requires removing filter cover. Next up are external gauges - Our tank supplier stocks the Yaktek Levetator, but that's not really any good when I'm not on site. Hence, it's time to investigate the electronic options:

This thread on whirlpool mentions the Electrosense Aquagauge, but at $265 each plus telemetry thats not cheap. The Jaycar ultrasonic one may be OK, but as it doesn't have a serial / usb  output from the display, I'd need to hack up something to parse the RF (as others have done). So datasheet hunting time:

The MaxBotix series looks like it's pretty much ideal - 1mm resolution, 5m max range, weather resistant. Annoyingly I can't see it cheaper than the ~100 USD on the manufacturer site (sparkfun et al. only have the MB7360 not the MB7369), but at least there's a local supplier.  A slightly different model (MB7060) is being used by the flood network.

Next up is trying to work out how to connect them - My options are:

• Wired - Etherten or possibly something as simple as serial-ethernet adaptor
• Wireless - wemos / ESP8266 for wifi (power hungry?)
• Wireless - rfm type TX/RX setup to basestation
• lora - nice but possibly expensive as I'd need a gateway.

I suspect this particular blog entry will get updated as things progress..

Traffic Light status IoT device

Following on from an all-too-regular "Is the lasercutter working?" mail thread at our local hackerspace, I've decided to come up with a nice simple IoT 'traffic light' device.


Plan is to use KISS principles and have 3 big pushbuttons (Red, Amber, Green) that light up (and stay lit) so that the next person knows if machine needs maintenance/ misbehaving slightly / all good.

Using something like an ESP8266 module (hello Wemos D1), this could trivially publish the status to a broker, and then be acted on elsewhere - updating status on website etc

Next up, finding a local supplier of parts to start a prototype at the next Arduino-U night.

Publishing DHT22 data via MQTT with an ESP8266

Some time ago I picked up a couple of ESP-01 modules with the intention of using them as wireless temperature/humidity sensors coupled with a DHT22.

Initial investigations took place at the Perth Artifactory "Arduino-U" evenings - I managed to put on a nodemcu lua firmware and found a few (varying) dht22 libraries. however I couldn't ever manage to get it to consistently publish the information to my message broker - it'd do one or two and then lock up. I dug it out again recently and decided to have another go - especially as Pete Scargill seemed to be having success with them (running native C).

So trying to 'revert' to a newer espressif release turned out to be non-trivial - installing the relevant toolchain needs multiple bits. I gave up and noticed that there was a newer (0.9.6-dev_20150704) nodemcu release, so I gave that a try.

First discovery - There's native support for the dht sensors in the firmware, so to get the current values all you need is a

print(dht.read(4)) 

So, I trivially modified the example mqtt.client from the docs and uploaded it with luatool. I'd already set my wifi parameters by hand, so it was connecting to the network at power on automatically. Once I was happy that my 'pub.lua' was publishing OK, I added a trivial init.lua (also available on the gist)

Some points to note from that gist:

• IP address of broker is hard coded. The nodemcu example uses a non standard port - be aware if you copy n paste
• Although I have a last will, there's no status setting on successful connect. needs fixing.
• I'd rather have temp / humidity as two separate topics, but I merged them into one json string to avoid having to worry about mqtt publishing concurrently (used to be fragile on the esp8266)
• I publish every 5s (tmr.alarm) - 2s is the min recommended for the dht22

so I now see a pretty

sensors/ESP-10264640/json { "temp": 16.8, "humidity": 53.4 }

every 5 s ("mosquitto_sub -h broker -t '#' -v" makes for great sanity checking), which is great but not terribly pretty. Thankfully I have a websocket enabled mosquitto broker running, so I'd already dabbled at some html display. so I took jpmens' dial example and altered it to one of the other gauge styles. and lo...

DHT22 + Arduino

I recently purchased a DHT22 (Also known as RHT03 on Sparkfun) from Proto-Pic temp and humidity sensor with the aim of using it as an outdoor sensor in the garden. Although there are several DHT22 libraries on github I couldn't get the nethoncho one (or the patched forks) to return anything other than checksum error.

However the combined dht11/22 one I found linked on arduino.cc seems to work just fine. Need to test with -ve temps next but an overnight plot on the bench seems reasonable

Despite many forums saying that it needs 5v I've managed to get it working OK with the 3.3v pin on my nanode, next step is to test on a jeenode and send the output via RF. Oh, and then get a solar panel to run the thing...

Cool Stuff

Things you find on the internet...

The Swiss Federal Office for the Environment (FOEN) Hydrology dept monitors the water temp at its gauging stations (http://www.hydrodaten.admin.ch/en/) including the one downstream from Lac Leman. Soneone else is feeding these into pachube as a data feed (https://pachube.com/feeds/43397) which means it's trivial to generate an on demand plot of last weeks water temp: