The end result will be that I can deploy the same code on a bunch of boards, and each will send their temperature & humidity data to a central queue. From there I can record the values and end up with a useful graphing solution in a hands-free fashion.

Hardware

The shields available on AliExpress vary somewhat, but mine connects the sensor to pin D4 (which is plainly visible when looking at the traces on the board). Because I'm using a shield the connection is small and neat, and the end result is just powered by a typical USB phone-charger:

Software

This project requires three pieces of software:

The actual software running on the board itself.

This reads the local environment and publishes the value on the MQ bus.

A simple piece of software to listen to the queue, and record the values to a local database.

A viewing-application which will read the values from the database and let you see a pretty graph.

All the code is bundled together in a git repository, you can access all the source by cloning the repo involved, and then looking at the project itself:

Operation

If you've previously configured WiFi details the device will connect automatically, and begin showing the date/time, along with the departure times.

If you've never configured the device it will instead notice that, and configure itself as an access-point. This means you can use your mobile phone, or other WiFi-connected device, to connect to this access-point and choose the local access-point it should become a member of.

At that point the device itself is working, but it will be only sending updates once a minute to the message-bus. Without something listening for those updates you've not got anything useful!

To make things useful you'll need to have a local machine which can also connect to the bus. That will just sit idle, waiting for updates to be received on the "temperature" topic. When such a message arrives it needs to be saved to a database so that you can query it for display, or similar, in the future.

You can see my solution here - which records incoming values to an SQLite database

Recent Changes

One of the main goals of this project was that I could burn the same code into a bunch of different ESP-devices, and they would each submit their data to the message-queue.

The first device was deployed for several weeks before I got round to setting up more of them, at that point I learned that when a client connects to the queue it must announce itself with a unique name.

So now when clients connect to the queue their name is suffixed with the MAC address of the on-board WiFi device.