Define a Minimum Viable Product and Ship it
Monday, September 5th, 2016The last few weeks have seen me fighting a communication problem between the Oak and the STM8S. As a result the development has slowed down a little to the point that the project was becoming frustrating. It was about two weeks ago that I was listening to a podcast and the presenter made a very pertinent comment. Some software start-ups fail because they fail to define the minimum viable product. This gives them nothing to aim for and most importantly no firm idea of what they have to deliver.
This felt very relevant as the weather station was stalling. With this in mind I decided to break the project up into a number of revisions.
Revision One – Basic Sensing
Although this revision is titled Basic Sensing, we will aim to get as many of the sensors working with the Oak, and only the Oak, as possible.
The Oak has an ESP8266 (ESP12) at it heart and this leaves a restricted number of IO pins available to communicate with the outside world. With this in mind it should still be possible to work with the following sensors:
- Wind speed and direction
- Pluviometer
- BME280 (air temperature, humidity and temperature)
- DS18B20 (ground temperature
- TSL2561 (luminosity)
An additional pin is also required to allow the Real Time Clock (RTC) module to generate and interrupt to let the Oak know it is time to take a reading.
One of the aims of the final system is to be able to run using solar power and batteries, however, for the initial version of the system this is not necessary. The main controller board can be placed inside to run on mains power with the rain and wind sensors outside. Some of the sensors would be inside so this would not give a good view of the weather but will allow testing of the software.
Clock Module Change
I came across a variant of the DS3234 RTC on one of my usual suppliers web page. The DS3231 module is similar to the DS3234 with four differences:
- Price – I can buy four of the DS3231 modules for the same price as one DS3234
- Interface – the DS3231 uses I2C rather than SPI
- No on chip memory for the DS3231
- Additional EEPROM on board
All of the main features that make the DS3234 desirable are also present in the DS3231. The major piece of work is the necessity to overhaul the DS3234 library created previously.
Schematic
The main changes to the hardware design involve moving the connections to the various sensors from the STM8S to the Oak. This has been made possible by the change in the clock module from the DS3234 (SPI) to the DS3231 (I2C). This freed up the four pins that had been dedicated to the SPI interface.
The updated schematic is as follows:
Weather Station Rev1 Schematic
Translating this to hardware on a protoboard:
Weather Station Rev1 Protoboard
There are a couple of items on the hardware implementation that are not on the schematic:
- Additional connectors / jumpers
- Connector for OpenLog board
These items may or may not make it onto the final board and have been added to aid debugging.
Software
The software for this project has been placed on Github and is broadly speaking the same as previous versions in terms of design. The following are the most significant changes:
- STM8S code has been left in the project for the moment but this is not used in this initial working version.
- Interrupts for the pluviometer and the wind speed are now in the Oak code
- Logging to Phant has been implemented (public stream can be found
- DS3234 code has been abstracted and used to make a DS323x generic timer class and a DS3231 specific class
There are still some modifications required:
- Remove or convert to MQTT rather than Phant
- Look at exception handling
- Deal with network connection issues
- Clear the rainfall today counter when moving from one day to the next
One of the previous versions of this application used Adafruit’s MQTT library to connect to Adafruit.IO. Recent changes to the site and to the library means that any attempt to connect the Oak to Adafruit results in an exception being thrown. A task for later is to correct this problem if possible.
An Internet connection may not always be possible so it would be desirable to collect data while offline and then upload this later. This may be facilitated by the EEPROM on the DS3231 breakout board.
The software is currently throwing an exception every 10-30 readings. This results in the Oak resetting itself so it does recover although there is a small gap in the data gathering. The source code has been reviewed an there are no obvious memory leaks or null references. This problem is being deferred as there is a workable solution in that the Oak does reset itself. Not satisfactory in the long term but liveable for now.
Conclusion
The definition of a minimum product has allowed the project to proceed to the point where something can be deployed and tested. There are still a number of items to be completed before the original aims can be realised including the resolution of some issues in the minimum product.
One thing I have learned along the way, don’t try and use pin 10 as an interrupt pin on the Oak as this is not implemented.
The next steps, complete the initial code and deploy the external sensors.
