georgetownmakerhuborg / air-quality Goto Github PK

From the readme:

On a battery monitor when the lithium battery hits a certain threshold, enter deep sleep to prevent total depletion.

With the imminent use of battery-powered monitors, there will be a need to sleep the monitor before fully depleting the battery. It may also be a good idea to build in the capability of notifying on critical battery, so the user can go and replace/recharge the battery.

Describe the bug

The attached ESP device is not being detected on older variants of MacOS.

Putting together these files and templates will go far to enable consistent community expectations and quality work.

See this and the linked project for examples of the direction I'm thinking. I'm planning on working on this myself in the coming days.

If the device was able to pull it's own GPS data, many of our use cases would be greatly simplified and we could have increased confidence in that our data is actually from the location is claims to be from.

Of course, our hardware doesn't currently support GPS, but I find it a worthy inclusion in the future. I vote for adding this to the "hardware to-do" list.

With the inclusion of logging to disk with, perhaps occasional, uploads to the internet. We will want to have a well defined and easily extensible format for our data points. For example, we will want the format to always include certain base parameters such as the "serial" and timestamp, but be able to optionally include a variety of sensor parameters. Some sort JSON dictionary seems workable with these requirements and relatively easy? That's my first thought, I'd be interested in suggestions for those more knowledgeable.

It will be absolutely necessary to know, at least relatively, what time data was logged if we are going to be saving data to disk and uploading only whenever the network is available.

Let's base our current release to a known, stable uP release. 1.11. In the bin/build directory, place the file using the original name (esp32-20190529-v1.11.bin) and symlink it to 'up-firmware.bin' so that we don't have to constantly modify files that reference it (e.g. upload).

From the readme:

We still need to either combine the results of redundant sensors or report both

This is currently in progress and being worked on (#6), I'm creating this to document the issue and be able to accumulate all of our issue tracking in one location. I'm removing these as notes in the readme.

My opinion is that it is better to report the data from each sensor even if there is redundancy.

From the readme:

The BME280 draws power from the 3.3v even during ESP deep sleep. Can we invoke deep sleep on sensors too prior to shutting down the ESP?

This would greatly improve our power efficiency and enable the monitor to run for a longer duration on battery power. This may very well involve circuit changes, but the need to power down all sensors to reduce draw makes the change valuable.

How about using the REST API to provision a default dashboard for each new machine id (group) in the adafruit io cloud?

Describe the bug
BME280 implementation appears broken. How did we miss this?
lib/bme280/init.py is empty when it should provide the BME280 class.
line 16 in tph.py should read "from lib import bme280" not "from lib.bme280 import bme280".

To Reproduce
Steps to reproduce the behavior:

1. Configure wake.py to support only tph.py
2. upload the code.
3. get the error "Running Sensors...
   Traceback (most recent call last):
   File "main.py", line 25, in run
   File "wake.py", line 24, in main
   File "sensors/tph.py", line 16, in
   ImportError: no module named 'lib.bme280.bme280'

Describe the bug

subprocess.check_output returns bytes on Python 3, and a string on Python 2. Extracting the Chip ID was failing, as it could not parse the bytes.

To Reproduce

Run the upload.py script using Python 3.

python3 bin/upload.py --device /dev/tty.usbserial-1410

Expected behavior

Shouldn't throw an exception.

Desktop (please complete the following information):

• OS: macOS

In order to scale we are going to want to maintain a database of all devices and be able to generate serials as new ones are added to the GUAQ network. In addition to letting us count and advertise the number of active devices, this will let us more easily increase the security of our data collection down the line.

Perhaps there's a way to generate this with a hash function pulling hardware information from the chips and then checking to ensure it doesn't collide with an existing device?

Describe the bug
A clear and concise description of what the bug is.
Line 49 of wake.py is:
# aq.update(stub.measure())> # when you only want the MCU and no sensors.

Should be:
#aq.update(stub.measure()) # when you only want the MCU and no sensors.

Here's a 3D-printable enclosure for weather station electronics - seems like it would be useful for us.

https://www.thingiverse.com/thing:2282869

The Kathmandu GUAQ has shipped without network/Wifi credentials. We will need to upgrade this unit on site. An upgrade script that uses ampy to put files to a GUAQ that has the supported micropython version (for 905, this is 1.11) is needed. If we can avoid having to use esptool to flash uP, we will reduce the number of problems.

The onsite team will have to put the unit into 'upgrade' mode to prevent a wake/sleep cycle that prohibits ampy from working properly. The other alternative is to teach this team how to use the WebREPL interface to upload specific files (like config.py).

• Add some exception handling for when sensors are not attached.

I'm going to suggest that we have 2 bash scripts in the /bin directory:

1. upload - which calls esptool to erase and reflash the esp and then calls upgrade
2. upgrade - calls ampy and uploads all the guaq files. Upgrade takes /dev/tty... as an argument.

This will allow us to minimally disrupt our field sites by requiring that they install ampy only. Until we can get the WebREPL tested and documented better.

Pas

As currently stands, all PRs and changes are merged directly into master and we don't use semantic versioning to keep track of releases.

Before any significant work continues (besides hotfixes), I recommend that we transition to a system of merging PRs into a "development" branch and then merging "development" into master after some level of formalized testing.

Additionally, I feel that would be beneficial to tag our current "release" software as some beta tag (v0.2.1?) and implement semantic versioning to keep track of who/what units have what software version to better debug and manage our distribution.

This will enable us to increase the rate of development without risking releasing untested code. Of course hotfixes, for example, could be merged otherwise and development branches could be deployed onto monitors, but in general, this will help our stability and sustainability.

For scenarios where the networking is less than ideal, we should store sensor measurements on-board and then upload missing data when the network has come back online.