corvia/thermonitor

A hardware + web application to continuously monitor our farm and cafe thermometers and dispatch notifications.

thermonitor's Issues

Clean up duplicate code between API and signals/models

create methods for SensorSerializer and SensorDataSerializer in sensors/serializers.py duplicates some code from signals and data models.

Fix is enroute... I'll write some tests to confirm things are still working as-is after removing the create() methods.

Build out initial main apps: notifications and sensors

This (mostly) means data models but admin.py should also be built out a bit (and the admin app enabled!)

Implement the UI using React

I forgot to create this issue earlier. This is already partially completed by commits e9c72be and 836b9f3.

Convert visual mockups into usable front-end assets

• CSS should be stored as LESS and compiled to CSS.
• 3rd party resources should come in through bower (added to provision.sh), and with it, a bower.json manifest.
• Images should be pulled in and stored under thermonitor/static/img
• Skeleton HTML files placed under templates/

Expose read-only historical notification data in API

Setup SSL/HTTPS-everywhere on sqrts.com

We're looking at mounting our thermonitor API under something like: https://sqrts.com/thermonitor/api/1/

Install DRF and spec against API Design

Export Sensor Data Modal

Ideas:

• Export to CSV? XLS?
• Select multiple sensors in a Zone? (multiple sheets in one XLS)
• Fancy PDF with data, graphs, sparklines, status changes? (probably more than is needed...)

Define initial data models

Austin and Dan will do this in the conference room glassboard

Switch from sqlite3 to Postgresql

Django is setup to use sqlite3 out of the box. This needs to be changed to Postgresql when we go to production.

provision.sh should also be taken into consideration and constants defined should make their way into our provision script to be repeatable.

Modify Router Script to Push Data to API

Need IP/hostname of hoophouse router.

• Automatically detect sensors on network?
• Push data to Thermonitor API
• (Don't touch?) Justin's water pump code.

Document front end development and build processes

We're using React and ahead-of-time transformation for the front end components, which means a few extra steps are required for the development and build processes. These all need to be documented.

Down Sensor Reporting

Detect if a sensor hasn't checked in for awhile.

How long should that be? (60 minutes?) Might as well make it configurable, add it to the Sensor model.

Create a cron script to poll for down sensors and send a notification to the alert group.

Convert visual mockups into usable cd /etc/apache2/sites-enabled

Document SensorData POST with GUID

In the interest of being as lazy as possible, I made this work:

You can POST SensorData to the API using a GUID:

• If no Sensor exists with that GUID, create a new Sensor and associate the submitted SensorData and Zone Key with that new Sensor.
• If a Sensor already exists with that GUID, associate the submitted SensorData with that Sensor.

d = {
    'guid': "ABCDEFGHIJKLMNOPQRSTUV",
    'value': 43.0,
    'key': 'FDEA9C52EBCA4F6D9B873FFF059F0392',
}
new_data_first_request = requests.post("http://localhost:9000/api/v1/data/", data=json.dumps(d), headers={'Content-type': 'application/json'})

d = {
    'guid': "ABCDEFGHIJKLMNOPQRSTUV",
    'value': 99.0,
    'key': 'FDEA9C52EBCA4F6D9B873FFF059F0392',
}
new_data_second_request =  requests.post("http://localhost:9000/api/v1/data/", data=json.dumps(d), headers={'Content-type': 'application/json'})

# First request response 
# (Sensor with that GUID doesn't exist, create it, then associate SensorData to the newly created Sensor)
{u'state_changed': False, u'value': u'43.0',
u'datetime': u'2015-11-11T04:41:56.327317Z', 
u'state': False, u'sensor': u'http://localhost:9000/api/v1/sensors/281/', u'id': 774}

# Second request response
# (Sensor exists with that GUID, associate SensorData to that Sensor)
{u'state_changed': False, u'value': u'99.0', 
u'datetime': u'2015-11-11T04:41:56.33435Z', 
u'state': False, u'sensor': u'http://localhost:9000/api/v1/sensors/281/', u'id': 775}

Not sure how documentation will all come together for the API, but figured I'd dump this here for now.

Ensure DateTime Fields are using UTC

I think some of our datetime model fields are not configured for using UTC. Verify that we're using this consistently everywhere.

It looks like Austin did a good job of using datetime.nowutc() in the DRF API. I, however, did not while cooking up the models.

Test API and Notifications

Notifications branch still has some bugs and needs to be tested.

• Verify state in both Sensor and SensorData is set correctly
• SensorAlert doesn't seem to be setting the alert_class correctly
• Test down Sensor detection and alerting
• Document cronjob setup for down sensor detection

Sketch out API design

Production Deployment Checklist

https://docs.djangoproject.com/en/1.8/howto/deployment/checklist/