Mum’s quite sensitive to air quality: she struggles with smoke during bushfire season, and pollen or dust at other times of the year. Declining air quality isn’t always as visually obvious as smoke, so an early warning for changing conditions helps. We want to know to close the house up before the indoor air quality gets compromised. When the outdoor air quality improves, we want to know that it’s the right time to open the house up.

My parents live in a rural setting, so for this type of thing we really need to source our own local data, rather than just looking at a region-wide feed.

🎁 Today’s electronics project: an air quality monitor.

One for inside, and one for outside. USB-powered. Wi-Fi connected.

The Sensor

We’re interested in measuring particulate matter, like ash and pollen suspended in the air, as opposed to gas mix. The go-to sensor for this is a Nova PM SDS011. The sensor comes mounted on its own PCB, around 5cm square, with an integrated fan.

Every few minutes, the sensor fires up the fan on top, and sucks a sample of air from the intake tube you can see top-left, into the metallic box area.

Inside this box, it shoots a laser through the air, and then measures the scattering of the laser.

From this, it can determine the concentration of different sizes of suspended particles in the air.

They’re readily available on AliExpress for ~AU$25, and have good software support.

We had a prototype running for a good year or more, and it was working well, but we were overdue with boxing it up nicely.

The Case

First up, we needed a case. Gone are the days of the generic project box from Jaycar, but this is my first foray into 3D printing.

https://www.thingiverse.com/ > Search > SDS011 found lots of existing designs, for this exact scenario. Wunderbar.

I ended up picking this design, by @sumpfing. There’s a “tip the designer” option in Thingiverse, but unfortunately she doesn’t have this enabled, so all I can do is say “Dankeschön!” a few times.

It includes space for a DHT22 temperature/humidity sensor as well, in that square breakout back-right. It supports mounting for outdoor, and will happily sit on a shelf for indoor.

From Thingiverse, I was able to just download the design as a collection of STL files.

Rather handily, Windows 10 has native preview support for STL files. 💪 You can just double click the files and get an interactive preview without any additional software.

For extra bonus points, open the file in “Paint 3D” (also built-in to Windows 10), then hit Mixed Reality mode.

You can drop the model straight on to the workbench next to the real sensor. This was a really handy way to get a sense of scale, and how the pieces would ultimately go together.

At this point, I’m sold on the design, but I don’t own a 3D printer. I have no interest in owning, calibrating, or maintaining a printer. Zilch.

To the internet! Some quick Googling led me to Craftcloud, which provides a great marketplace experience.

You start off by uploading the STL files, and they generate a whole stack of quotes based on different materials, finishes, and operators from around the world.

So … will this case be brass, maraging steel, or titanium? 🤔

I took the wild choice, and opted for cheaper black plastic. Specifically, something called PETG. I have no idea if that was the best choice or not, but it sounded versatile enough. I also chose a local, Melbourne-based printer, offering a 6-8 day turnaround.

No doubt I can optimise this purchase path in future, but Craftcloud earnt their money here for ease of access for a first-timer. I spent $46 on the case, and then nearly half again to ship it three suburbs.

A few days later, we have a case! 🥳📬

The top section snaps on snugly.

The particulate sensor fits perfectly.

It’s black plastic.

Satisfied Tatham.

• 

• 

• 

• 

The sensor pops right into place, and anchors in easily with three screws. These are just random left over PC tower screws, probably from old hard drive mounts or something. I have a whole ziplock bag of them and they’re endlessly useful.

The intake tube is a bit short when the top of the case is popped on. I’m worried that it’ll suck air from inside the case, which would have it contaminated by its own exhaust.

This is easily fixed with a short section of heatshrink to the rescue, just slipped on (not actually heated).

• 

• 

• 

For the compute + Wi-Fi module, it’s a trusty M5Stack Atom Lite, for ~AU$10.

I’m obsessed with these devices. Obsessed.

I’ve written about why previously.

With the M5Stack, there’s no soldering required: just 4x Dupont jumpers for power + data (UART).

I put some double-sided tape under it to hold it in place. Fancy. Imagine if I’d picked brass for the case, then used double-sided tape inside.

• 

• 

• 

For power, I plug a cheap USB-C cable into the M5Stack.

In case it gets a yank, I put a cable tie around it and tuck the tail under the sensor.

It’s not anchored to anything, but you’d have to give it a serious yank to pull it through. It’s not going to fall out easily.

That’s all of the physical aspects done for now.

(The DHT22 temperature + humidity sensor will mount into that final space on the right, but it’s still in the mail.)

The top of the case just pops on with a little pressure.

This can now subtly sit on a shelf, or be mounted under an eave outside.

• 

• 

The Software

Time for some software.

Thanks to ESPHome, it’s only 58 lines to get it connected to my Wi-Fi and have each particulate concentration (<2.5µm, <10.0µm) reported every 5 mins. Bonkers, but true.

It takes me ~15mins to create and deploy this firmware.

If you’re not familiar with ESPHome, I’d encourage you to check out my previous post: ESPHome: Nothing-to-firmware in 30mins.

	# Used with ESPHome. See https://tatham.blog/2020/08/30/esphome-nothing-to-firmware-in-30-minutes/
	## Commom pieces of text we'll re-use later
	# (makes it easier to copy and paste all of this code for another value later,
	# because you only have to set the new name at the top of the file)
	substitutions:
	device_name: air_monitor_indoor
	friendly_name: Air Monitor Indoor
	area: Indoor
	## Board config
	esphome:
	name: ${device_name}
	platform: ESP32
	board: m5stack-core-esp32
	## Boilerplate, same for all of our devices
	wifi:
	ssid: !secret wifi_ssid
	password: !secret wifi_password
	ap:
	ssid: "Fallback ${friendly_name}"
	api:
	password: !secret esphome_secret
	ota:
	password: !secret esphome_secret
	## Hardware setup
	# Move the log output off the main UART so it doesn't conflict with the particle sensor
	logger:
	hardware_uart: UART1
	level: VERBOSE
	uart:
	rx_pin: GPIO25
	tx_pin: GPIO21
	baud_rate: 9600
	sensor:
	– platform: wifi_signal
	name: ${friendly_name} WiFi Signal Strength
	update_interval: 60s
	– platform: uptime
	name: ${friendly_name} Uptime
	– platform: sds011
	update_interval: 5min
	pm_2_5:
	name: "${area} Particulate Matter <2.5µm"
	pm_10_0:
	name: "${area} Particulate Matter <10.0µm"

view raw air_monitor_indoor.yaml hosted with ❤ by GitHub

The Result

We now have particulate matter concentration showing in @HomeAssistant. 🥳🎉

From here we need to:

1. Add the DHT22 temperature and humidity sensor when it arrives, to complete the build.
2. Build a second box for outside, so we can decide when to seal-up vs. air-out the house, based on indoor/outdoor differences.
3. Trigger a push notification when particulate-matter is increasing, to say ‘close up the windows now’.

---

PS. This project was originally shared on Twitter. Jump over there for the discussion.

😷 Mum's quite sensitive to air quality, and struggles with smoke during bushfire season. It's not always as obvious as smoke though, so an early warning for changing conditions helps. This is hyper-local data.

🎁 Today's electronics project: an air quality monitor. pic.twitter.com/u7OgXEzCCG

— Tatham Oddie (@TathamOddie) May 29, 2021

I live in an inner-city apartment. There’s a concrete slab, brick walls, and no ceiling cavity access. Oh, and we rent, so drilling into things is frowned upon. The home automation potential in a scenario like this consists of some coloured lights, and watering about four plants on a timer. It’s not exactly an inspiring IoT site. There’s also not much wrong with the humble light switch that works instantly, every time.

In complete contrast to this, my parents live on 100 acres / 40 hectares of land, a few hours out of the city. It’s quintessential rural Australia. They’re mostly off the grid: there’s a skerrick of Telstra 4G signal, and some power, except when there isn’t, which is surprisingly often. This is an absolute IoT playground, and we’ve given that a fair crack over the seven years as they’ve established themselves there.

Opportunity

On a property like this, water is critical. There are the basic living requirements, the opportunity of gardens, and the very real risk of bushfires. All up, we have ~300,000 litres of water tanks on the property, and then a small dam and two creeks. We use sensors to track tank volumes. We measure flow rates at key plumbing points (for both instantaneous oversight and tracking cumulative usage). We use power meters to detect when pressure pumps are running.

Energy management is also important. Whilst there is the option of grid connectivity, we try to run as off-grid as possible, or at least export-only. This requires some smarts around load management. For example, instead of just having a hot water system that aggressively chases a specific temperature, we want the hot water systems to head for a temperature range, but only use excess solar production to do it. If there’s a bit less sun for the day, it’s ok if the water it a few degrees cooler: don’t burn down the batteries or import power just to hit a specific temperature.

And then there’s a safety aspect. The property is on the top of an escarpment where storms can roll in fast from a few different directions. By running things like lightning sensors on the property, we can trigger our own localised alerts for approaching storms.

Challenges

The challenge is to convert all these possibilities into something real, that works, and doesn’t cost an absolute mint. Over the years, we found this incredibly hard to solve for. You’ll find a solution for measuring tank volume, but it comes with its own LoRA gateway, a cloud dependency, and a new app. You’ll find a cheap Z-Wave temperature sensor, but it’s only really good for a room, and doesn’t have a probe that you can put into the measurement point in a hot water system. You’ll find a flow meter, but it’s only an industrial solution that wants to talk RS485 serial. Who even does that anymore⁈ You’ll find a garage door opener that works for the extra-high roller doors on the shed, but it has its own 433MHz RF remote.

It’s easy to end up with a horrible mishmash of radio technologies, software platforms, and APIs, not to mention some scary pricing as you drift from the traditional world of home automation into the more dated world of industrial automation.

Goal

We want to be able to dream up crazy new ideas, pick and choose the right sensors, and then integrate them with relative ease and consistency. That means a balance between the ability to build new things ourselves, but not having to go and custom fabricate a circuit board and write new firmware just to add a new sensor.

Considerations

Sense

Most sensors give out some kind of analogue signal (like a pressure sensor where the output voltage varies from 0V to 5V depending on applied pressure), a pulse (like a flow meter that pulses once for every 500mL of water that flows through it), or a digital signal (like a temperate and humidity sensor with a 1-Wire output).

To handle all of these scenarios, we’ll need some GPIO pins (the most basic of digital connections), and something with an analogue-to-digital-converter onboard (so that we can measure that variable pressure scenario).

Affect

Most of the outputs that we’re dealing with are straight up binary: turn a pump on, open a valve, flash a light. This means that they can be again driven by some GPIO pins, paired with an appropriately sized relay.

For more complex outputs, like sound, we can defer back to more consumer-grade hardware, like just broadcasting an announcement on the Google Home speaker in the kitchen.

Plug and Play

As much as we’re building things ourselves, we don’t need to put too many barriers in front of ourselves. We’re after a module that we can connect sensors to easily, without too much soldering, and certainly not having to build up our own circuit boards / Veroboard. We want to be out of the lab and into the environment as fast as possible.

Secure

There’s a persistent joke about how the ‘S’ in IoT stands for security.

Security was absolutely a consideration for us though: both on-property, and when it comes to remote access. When you’re switching things like power, or controlling a precious resource like water, you want to be confident that you’re the only person in control.

Our preference has been to keep connectivity and control local to the property, via authenticated connections, and then apply a separate remote access approach further up the stack. This means the hardware needs to have enough power and smarts to handle secured local connections, and not be dependent on its own path to the internet.

Compute

Some sensors require both precise timing and persistence to count things like pulses and turn them into natural measures. For example, a flow meter might give you a signal pulse for very 500mL of water that flows through it. If you miss a pulse and stop counting for a bit, you’re missing water. Our preference has been to count pulses on the hardware attached to the sensor, and then report back the natural values (L/min, L/day) whenever the network and central compute is available. We want to keep sensor-specific concepts, like pulses, at the sensor, and just send meaningful information over the network.

As much as we want things to be connected, they can still be somewhat smart in their own right. If a hardware module has both a temperature sensor and a relay to turn a heating element on and off, it’s perfectly capable of being a thermostat on its own, regardless of what’s happening to the wider network or any centralised compute. It will be smarter when the central controls are online, because it can be aware of other datapoints like the solar charge status, but it doesn’t have to be totally bound to the availability of those other systems to operate its basic function. Achieving this balance requires us to be able to run basic logic directly on the module.

The world is not static. If we want to run logic on these devices, and keep them secure, they need to be able to receive firmware updates over-the-air. We don’t want to be clambering around under sheds with laptops to reprogram a thermostat.

Connect

Network standards are still the multi-billion-dollar question in IoT.

Early on, we deployed a number of Z-Wave and Zigbee based devices. These are two different mesh protocols, at the mid-point of their VHS vs. Betamax battle for dominance. They’re common in consumer automation solutions like smart switches, and good for extremely low power environments, like where you want to be able to throw a temperature sensor in the corner of a room with a coin-cell battery in it and then forget about it for a year. The sensor ecosystem is very consumer focussed (you’ll find a million temperate sensors, but no tank pressure sensors). The communication protocol is constrained: by design, it’s a very low bandwidth data network, operating up to 40kbps for Z-Wave, or a whopping 250kbps for Zigbee. Range is limited to keep within the power limits, so typically as low as ~15-20m. There’s no common way of building on-device logic, and if you do manage to, then it’s incredibly hard to apply firmware updates over-the-air for either of them.

Our exploration continued into LoRA and NB-IoT, but we’ve opted away from both for this property. They’d each be very compelling options if we wanted to cover the larger property, such as if it was more of a working farm with distributed infrastructure than predominantly bushland and gardens with clustered buildings.

Ultimately, we settled on Wi-Fi as our preferred connectivity on the property. We’re already got great coverage throughout the house, cottage, shed, and key outdoor locations via a UniFi deployment. Whilst this is heavily centred on the built infrastructure, and not the full 100 acres of property, that’s where most of the sense-and-act needs to occur anyway. Investing in the Wi-Fi coverage provides other benefits, like Wi-Fi calling for mobiles where we’re otherwise on the fringe of 4G coverage. The UniFi infrastructure is readily extensible, as Lars has proven on his property with the deployment of Llama Cam, and even extending the coverage to places without power. Finally, it gives us a pretty amazing management plane that’s a lot nicer to work with than trying to diagnose a Z-Wave/Zigbee mesh.

Power

We’re happy to depend on a power source for most devices: they’re usually located near other loads that are already powered, or it’s easy enough to get power to them, such as dropping in a 12V cable out to a water tank at the same time as trenching the plumbing in. If we really want to run on battery, it’ll be ok to have a larger 12v battery and a small solar panel or something: we don’t need to try and run off a coin-cell battery for years on end.

Cost

The approach needs to be reasonably affordable if it’s going to grow over time: tens of dollars to add a new thing, not hundreds.

Sensors themselves range from $1 for a temperature probe, to $20 for a lightning sensor, or $30 for a laser-based air particle sensor. Short of buying them in bulk, that’s about the best the prices are going to get: you’re already buying the smallest possible unit straight out of China.

Whilst there’s no room to optimise on sensor cost, it does give something to calibrate against for the target cost of the compute module. We wanted to target ~$5 per module. It felt like the right cost, relative to the sensors themselves.

Hardware Options

So many options! Let’s run through them against those considerations:

Raspberry Pi

By this point, most software developers are jumping in with “Raspberry Pi! You can even buy hats for them!”. That’s certainly a response I started from. It feels safe: it has ports that you’re used to, you can plug in screens, it runs a whole operating system, and it has an IO header exposed for those plug-and-play scenarios.

They’re also completely overpowered for what we need here. These things are small PC replacements: they’re full computers, not basic microcontrollers. Memory capacity starts in the gigabytes when we only need megabytes. They can run dual 4K display outputs when we only need to switch a couple of wires on and off. They need an SD card with a whole operating system on it just to boot. They suck up 3A of power, which is at the expensive end of USB power supplies. They’re also quite bulky compared to other options we’ll look at through this post.

A Pi, power supply, and SD card will quickly run to ~$50, which is 10x our cost target.

Raspberry Pi Zero W

This is as small as the Raspberry range goes, but it’s still a similar position as the main Raspberry Pi models: completely overpowered for this purpose, with a 1GHz processor, 512MB of RAM, and HDMI video output. Thankfully, it’s less power hungry, so we’re back into the range of any-USB-power-will-do. It’s also physically a lot smaller: look at the relative size of those micro USB ports.

It still needs a micro-SD card in addition to the base board, which takes the bill up to ~$15, still 3x our cost target. From a plug-and-play perspective, you’ll have to first spend time soldering on your own header strip, or pay a bit extra for one pre-soldered.

Arduino and Adafruit

As we carve away ports and computer power that we don’t need, our next stop is the Arduino or Adafruit Feather range of boards.

Each of these ecosystems has a range of different connectivity options: boards that come with Wi-Fi, Bluetooth, LTE, NB-IoT, LoRA, or none of the above.

If we focus on the Wi-Fi based boards, the “Adafruit HUZZAH with ESP8266” starts to look interesting.

These things are small, at 51mm × 23mm.

They have Wi-Fi on board, a USB port for power and programming, a stack of GPIO pins, and an analogue input. There’s no additional SD card required: there’s flash memory on the board itself. You can buy a version with pre-soldered headers, making that plug-and-play scenario easier.

The compute is right sized for basic sensors: an 80MHz processor with 4MB of flash memory attached.

The only thing on here that’s a little bit extraneous for our scenario is the Li-Po battery connection. (That’s the black connector at the top corner, next to the micro-USB.) The board can both run off a Li-Po battery, and recharge one, as there’s a charging circuit built into it as well. But, for our scenario where we said permanent power was ok, the charging circuit just adds more cost to the board.

Unfortunately, the boards are still up around $20, which is 4x our cost target. There’s also a lot of exposed electronics, so we’d need to factor a case into the price yet.

Discovering the ESP

What we’ve looked at so far in this post are different boards.

As I was researching around different boards, I kept running into phrases like “Arduino compatible”, and references to ATmega, ESP8266, or ESP32 chipsets.

It starts to get interesting when you split up the concept of a board, versus a chipset.

The chipset is the processor at the core of each of these boards: the smarts that makes it tick. There are a small number of very popular chipsets. There are then lots of different boards that package these chipsets up with other supporting systems and accessories to make them more accessible: USB serial drivers, voltage regulators, battery charge circuits, different breakout headers, and different physical form factors. It’s these extra systems that drive the cost up, and the brand recognition of the boards that drives the margin.

After some very nerdy reading 🤓, I got quite excited by the ESP range, specifically the ESP8266 and ESP32 chipsets. It turns out these are very popular with makers and manufacturers alike because they hit an interesting sweet spot of cost and capability. If you’ve got a Wi-Fi enabled smart plug in your house, there’s a decent chance that it has an ESP inside it.

These chips were never really designed as a general-purpose compute unit: the ESP8266 came first, and it was intended as a Wi-Fi modem, to be added on to some other device. It has enough compute to run a full TCP/IP stack, some leftover generic pins, and the ability to re-flash it with new firmware. There was originally only Chinese-language documentation, but the low price point and interesting feature set led the maker community off into investigating it further and translating the documentation. The manufacturer – Espressif Systems – saw the opportunity and jumped right in with the release of official SDKs and English-language documentation.

The ESP8266 was succeeded in 2016 by the ESP32 series, upgrading it to a 32-bit dual-core processor, more memory, Bluetooth support, and a stack more peripheral interfaces.

Both chipsets now have an excellent ecosystem of software around them. Of particular interest to me was the ESPHome project: it’s specifically targeted at generating firmware for ESP-based chipsets, to integrate with a wide range of sensors, and then link all of this back to Home Assistant, which is what we’re already using as the integration layer for everything on the property.

Now I could re-focus the search for boards to be based around these chipsets.

Two compelling solutions came to light:

ESP-01S

These modules are positively tiny, at just 25mm × 15mm.

They’re an ESP8266 chipset, with just 8 pins exposed: power, serial comms (mainly useful for programming them), and two GPIO ports. That’s not very much exposed, but it’s just enough to get the job done when you only need to detect one thing and switch another.

At only ~$1.50 each, they’re at an incredibly compelling price point. That’s a custom programmable microcontroller, with Wi-Fi connectivity, for under $2. 😲

One minor annoyance is that they need to be powered by 3.3V, so you can’t just attach 5V from an old USB charger. There are however two very prevalent base boards: a relay board, and a temperature/humidity board. Each of these supports the ESP-01S just plugging into them, and can be powered by 5-12V. You can pickup the ESP+relay, or ESP+temperature combo for ~$3.

• 

• 

One frill they’re missing in their no-frills approach is any kind of USB serial driver. That just means you’ll need a separate programmer module for the first-time flash. Once you’ve flashed them once, you should be able to do future updates over-the-air.

For a good getting-started project, check out Frenck’s $2 smart doorbell.

M5Stack Atom Lite

These modules are the absolute winner: they hit the perfect sweet spot of capability, ease-of-use, and cost. They’re more like a ready-to-go compute module than a dangling microprocessor in need of a breadboard.

They have an ESP32 processor at their core, nine exposed GPIO ports, a button, an LED, and an IR LED. They’re housed in a nice little package, so you don’t have exposed boards. They’re powered and programmed by USB-C. All for ~$5.

The pin configuration is documented right there on the case, making them incredibly easy to wire up quickly. The only piece that’s missing is to know which GPIOs support analog inputs, but you can cross-reference them back to the ESP32 pinout for all the per-pin specs.

Many sensors can be connected directly to the Atom Lite: plug in +3.3V or +5V, GND, and a signal wire to a GPIO pin. For quick construction, wires can be pushed directly into the exposed header sockets. For a more robust connection, you can add a Grove/PH2.0-4P connector to your sensor, and then plug it into the port at the bottom there, next to the USB-C.

The LED is actually a “Neopixel” which means that while it only uses up a single GPIO, it’s a digitally addressable tri-colour LED. We’ve used this to provide a multi-colour indicator right there on the device for quick diagnostics in-the-field.

Pre-built solutions: Shelly1, Sonoff, and more

The prevalence of ESP chipsets continues to pre-built solutions as well.

The Shelly1 is a 230v/16A-capable relay, designed to fit in to tiny spaces like behind an existing light switch panel. It can be wired in with an existing physical switch, so you still have the instant experience of a normal light switch, but now it can be Wi-Fi monitored and controlled as well. Here it is with an Internationally Standard Sized Oreo for scale:

At its core: an ESP8266. And they even expose the programming headers for you right there on the case:

They’re Australian certified, but you’ll still need a sparky to actually install them for you if they’re hooked up to your 240v circuits. For lower voltage circuits – like switching irrigation – you can wire them up yourself with a screwdriver and zero soldering.

It’s a similar story for most of the Sonoff smart switches, and a stack of other manufactured devices.

I’ve used some Sonoff devices with good results, but having discovered the Shelly range via Troy Hunt, I’m keen to get my hands on that form factor next.

Implementation

ESP-based modules now litter the property.

Here, an M5Stack Atom Lite ($6) is combined with a DS18B20 temperature probe (~$2, including 2m cable), a single resistor jammed across two pins, a leftover USB charge cable, and a little bit of electrical tape to hold it all together. For sub-$10, and no soldering, we have a Wi-Fi connected temperature sensor dipped into the hot water system, connected back to Home Assistant.

• 

• 

A similar setup connects to a flow meter in-line with a pressure pump. The flow meter draws power (3.3V and ground) straight off the M5Stack. For each litre of water that passes through, it’ll pulse 11 times. A resistor is jammed across the pulse return and ground to remove float noise. The flow sensor can cost anywhere from $5 to $500 depending on what pressure you want to be able to handle, for what type of fluid, and to what accuracy. Ours cost ~$20, so the whole setup was <$30. It’s not the nicest fanciest of engineering, but it was zero soldering, and it hasn’t missed a pulse yet.

ESP-01S modules with corresponding relays litter Dad’s desk by the bundle. Right now, he’s building out a relay control, with active feedback, for an otherwise dumb valve. It’s a complex valve that takes 15 seconds to move fully from one state to another, due to the pressure it can handle. This is a perfect scenario for local logic: we can use an ESP-01S to drive the valve for the right amount of time, and then validate the expected state against the feedback wire. A dumb valve becomes a smart valve for <$10.

• 

• 

At home in the city, I’ve used an ESP-01S module to retrofit LED Christmas lights with a new sparkle-effect and Wi-Fi driven timing controls, based off the shifting time of sunset each day:

Weekend project: smarter Christmas lights! pic.twitter.com/skM0JhfOHE

— Tatham Oddie (@TathamOddie) December 15, 2019

And to bring my very-90s gate intercom handset into the world of mobile push notifications, whilst hiding the electronics within the existing handset:

Today's a day off for me, so I can nerd out on something fun for the day.

The plan: Internet enable this very 90s intercom for our apartment's shared gate entry.

🧵 pic.twitter.com/ndPJsXxEkD

— Tatham Oddie (@TathamOddie) July 31, 2020

Getting Started

Your shopping list:

1. A few M5Stack Atom Lite
2. A bundle of Grove cables
3. A bundle of mixed resistors (for pull-up/pull-down on data channels)
4. Your choice of sensors
5. The cheapest, most-basic USB-C cables you can find

Program them with either the Arduino ecosystem, or ESPHome (my preferred approach). There are a stack of example ESP projects on Instructables.

UPDATE: I’ve published the next post in this series, which will take you from nothing-to-firmware in 30 minutes using ESPHome.

Have fun!