At the moment, the script properly handles control constants. Nothing is done about control settings, however.

I'm not sure if this is something we really care much about or not. Once we get past the initial release it would be good to see if people actually want to view/touch control settings. If not, then the stubbed out code can be deleted.

Now that it appears django-Constance will handle the per-install settings in a sane way, we should probably create a "new installation" workflow that allows the user to set the per-install settings when the app is first accessed and creates a new superuser account for interacting with it. Separately, we then need screens to allow the user to edit his/her login credentials and the per-install settings saved in constance.

The way I envision it working is like this:

• Siteroot is replaced with a one-off cover page detailing the basic features if the constance settings aren't configured (need a one off flag in Constance for that)
• At the bottom of the page is a giant button that takes the user to a form to configure the app
• The form configures both the user and the app simultaneously
• Once the form is submitted successfully (and the user is created/settings are saved) the user is taken to a one off landing page with a direct link to the "add device" workflow (as well as instructions on where to find it later)

That said, I'm not married to this idea if there are others. This is just the best I could come up during my 7 am train ride to work.

To-Do:

• Prompt for user to create superuser account (Django admin, etc)
• Prompt for user to set constance variables

One of the basic functions BrewPi provides is temperature control. We need to be able to toggle this on and off, and set the basic modes:

• Enable setting "off" mode
• Enable setting beer constant mode
• Enable setting fridge constant mode
• Enable setting beer profile mode
• Update brewpi-script to support Django object model beer profiles

The Django version of "brewpi.py" can be used to mediate communication between brewpi-django and an unlimited number of installations of brewpi-firmware.

What we need is a script that monitors the "brewpi.py" processes to make sure a separate process is running for each configured (& active) controller in brewpi-django.

Due to the way fermentation profiles are implemented, we're preventing editing/deleting profiles while they're in use by a beer/controller. To enable changing a live profile, you need to create a copy of the profile, edit that copy, then assign it to the controller that was using the previous profile.

It would be good to have the following features:

• Ability to copy an existing profile into a new profile template
• Ability to replace an existing profile with a new profile (maintaining the point in the profile each beer had reached)

Right now, there's two configuration options that are being passed in related to brewpi-django:

tempLogType - Manages where the data points are saved to
Options:

• flatfile - Saves log points into individual, daily flatfiles as expected by brewpi-www
• django (formerly db) - Saves log points as handled by Django's BeerLogPoint model
• both - Saves log points into both individual daily flatfiles & via the model

dbConfig - Use Django-based configuration
Options:

• dbConfig present - Use brewpi-django specific code, models, etc.
• configFile present - Use brewpi-www specific code, models, etc.

Considering all the above together, there are really only three possible configurations:

• configFile & flatfile
• dbConfig & django
• dbConfig & both

That said, do we even really care about the third scenario (dbConfig & both)? Does that even really make sense as an option?

Right now, brewpi-script attempts to remain active if unable to connect to a tcpSerial device.

Although this makes some elements of brewpi-www/brewpi-django appear cleaner (we don't get timeouts/error messages everywhere) I think this leads to unexpected behavior when a user thinks his/her messages/commands are reaching the controller when really they aren't.

Given that both the official BrewPi installation and brewpi-django have (or will have) process monitors that periodically relaunch brewpi-script, I think it may make sense to just have brewpi-script die if it can't reach the controller.

The only remaining (actionable) TODO in brewpi-script relates to the fact that as currently implemented it attempts to use the same stdout.txt and stderr.txt file to hold all log messages - even if multiple controllers are running.

Now that brewpiName was implemented with the fix to #45 I'm thinking the best way to fix this is to add it to the log names. Alternatively, we could create an object in the database to hold log messages (though I don't know how useful this would actually be)

There's a ton of features that BrewPi-www implements with regards to DyGraphs & graphing. We need to figure out which of these are requirements for v1, which are things that would be nice to have in a later version, and which can be dispensed with:

1. "Snapping" to individual data series (may be a default feature?)
2. Annotation Support (Again - may be a default feature - need to test)
3. Toggle buttons for data series
4. "Refresh Chart" & "Help" buttons
5. Custom Axes (Custom axis labels for X & Y axes)
6. Custom "legend" box

To help explain what I'm referring to by each of the above, I've made this video on YouTube.

Normally, the script I use looks like the following (with a nginx/uwsgi based install):

#!/bin/bash
git pull
git reset --hard
git checkout origin/master
touch ~/etc/uwsgi/brewpi-django.ini

I'm hoping to avoid using nginx/uwsgi but regardless of where this ends up, we need a script that a user can run to automate updating.

Additional things that need to be added:

• migrating the database
• ??? other things?

Something I came across last night while reviewing the format of the "device add" template is the fact that we are setting the temperature format (Fahrenheit/Celsius) well in advance of BrewPi-script being launched (and therefore before we could actually update the controller to actually use the temp format specified).

I'm guessing there are a number of instances like this - we need to make sure that we either refactor out any instances where we allow a user to specify a temp format without actually updating the controller, or add code to automatically push updates to the controller when BrewPi script first connects if the temp format specified in the device definition differs from that on the controller itself.

At the moment, brewpi-script has two checks that it does that are incompatible with the way we currently use it:

• A "uniqueness" check that examines all running processes to ensure only one process is attached to a given device
• A "do not run" check that prevents launching an instance of brewpi-script if that instance of the script is disabled

Due to the way we're using circus, I think that we should be fine on the "uniqueness" front, but it would be good to verify that this makes sense and then modify brewpi.py to remove the process ID checks if this is the case. We should also modify the BrewPiDevice model to remove any fields we no longer need after doing so.

For the "Do Not Run" check, we now have a "status" field on the BrewPiDevice model that should replicate this functionality. We need to modify brewpi.py to use this new field and not look for the do not run file.

To-Dos:

• Validate that we no longer need the "uniqueness" check
• If above is validated, remove process ID checks from brewpi.py for instances using dbConfig
• If above is validated, remove process ID & other related fields from BrewPiDevice object
• Modify brewpi.py to use the new status field rather than the "do not run" file checks

I went ahead and copied updateCron to a new file updateCronCircus -- Now I need to go through and actually make it add a cron entry to launch circusd.

Open questions at the moment:

• What is the best command for launching circusd
• Do we want to delete any existing brewpi.py entries or just leave them alone
• Do we want to launch anything other than circusd (e.g. wifichecker?)

Just not to forget:

Feb 13 2017 15:29:39 Setting profile '1' as active profile
Traceback (most recent call last):
File "/home/stone/brewpi-django/brewpi-script/brewpi.py", line 699, in
profileSrcFile = util.addSlash(config['wwwPath']) + "data/profiles/" + value + ".csv"
KeyError: 'wwwPath'

(A nice thing was that circus started it again directly!)

For now, we aren't tagging releases so I'm satisfied with the Git checks only checking to see if there is a version mismatch. Once we start tagging releases, however, we should probably integrate checks for that (and only download tagged releases)

Right now, I'm using form submissions to handle temperature & backlight control. Ideally, this would instead be done via AJAX.

This is more a reminder for myself than anything --

One of the key benefits I had hoped to gain from having the BeerLogPoint model in a database was that the Django ORM would handle updates to the format. That is - if we wanted to add new fields (Tilt Hydrometer/Brewmometer support) or otherwise change things, we could do so easily. Now that we're using CSV files, that's harder to do.

In the extremely short term, I need to add a field to the Beer model called "version" which will allow us to track what version of the model the CSVs were built with. Then, later, if we change things we can just write a script to rewrite all beers to disk using the new format.

Normally, I use nginx/uwsgi for deploying django apps, but that seems like overkill here. There has to be an easier way!

Regardless - Need to figure out a solution for this.

I'd like to some kind of functionality to brewpi-django that displays a message to the user when an update is available on GitHub. Ideally, this would also allow the user to trigger an update directly from the website as well.

Given that I'm expecting there will be pretty frequent updates (see: bugfixes, things I forgot, etc.) when this is initially released, figuring this out before the initial release would probably be helpful.

Jan 15 2017 01:36:22 Connecting to BrewPi legacy2.local on port 23 Exception in thread zeroconf-Engine: Traceback (most recent call last): File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner self.run() File "/Users/jbeeler/virtualenvs/brewpi/lib/python2.7/site-packages/zeroconf.py", line 946, in run rr, wr, er = select.select(rs, [], [], self.timeout) error: (9, 'Bad file descriptor')

I'd rather not create an issue called "write documentation", as that's going to end up being such a task it needs to be broken up. 😨

The first bit that needs to be tackled are robust, automated install instructions using brewpi-django-script. This needs to cover at least:

• Basic setup of (or link to instructions for) Raspberry Pi
• Basic setup of Raspbian (including enabling ssh/wifi)
• Installing git/software required to clone the repo (ALTERNATIVELY - Use Pi-Hole "trust us and use curl piped to bash" method
• Cloning the repo
• Running/completing the install script

Once these steps are completed, the user should then be prompted to complete the in-application BrewPi-Django setup.

I did a really poor job of organizing things originally. The organization scheme should probably be something like:

• js/vendor/[vendor name]/abc.js - Externally developed libraries
• js/abc.js - Internally developed/project specific libraries
• css/vendor/[vendor name]/abc.css - Externally developed stylesheets
• css/vendor/abc.css - Internally developed/project specific stylesheets

...etc. for fonts and the like.

Once issue #6 is resolved, use the same graphing engine to make a graphical representation of the fermentation profile.

wwwPath removed in 02fb277

 Feb 06 2017 09:09:44   BrewPi version received was 0.2.4 which this script supports in 'legacy' branch      mode.
 Feb 06 2017 09:09:44   Bound to TCP socket on port 2222, interface localhost
 Traceback (most recent call last):
   File "brewpi-script/brewpi.py", line 521, in <module>
     startBeer(config['beerName'])
   File "brewpi-script/brewpi.py", line 370, in startBeer
     changeWwwSetting('beerName', beerName)
   File "brewpi-script/brewpi.py", line 298, in changeWwwSetting
     wwwSettingsFileName = util.addSlash(config['wwwPath']) + 'userSettings.json'
 KeyError: 'wwwPath'

There needs to be a better way to add controllers to the app. Currently, we need the user to know the WiFi host, port, Serial Port, etc. when many of these can be autodetected. It would be good to simplify this workflow to make it easier for users.

To-Do:

• Create family specification form
• Create flash form/instructions (with flashing coming in v2)
• Create mDNS autodetection script
• Create serial autodetection script
• Create BrewPiDevice creation script using autodetected mDNS parameters
• Create BrewPiDevice creation script using autodetected serial parameters
• Fix javascript & workflow on "advanced" page to match latest model version

One thing that always frustrated me about brewpi-www is the fact that the "Start BrewPi Script" button didn't provide any feedback as to what exactly was going on. If you're smashing it it's probably because something isn't running/working. It would be useful if there was a tool which could diagnose (or explain) exactly what was going on and provide guidance as to how to resolve any issues.

Uninstalling/removing devices (sensors/relays) works, but doesn't remove the proper device

I don't know how to do it yet, but at the moment the device dashboard (with the temperature graph) is incredibly ugly. Something needs to be done to make it less hideous.

The brewpi_spawner.py script is run under chaussette, I don't think that is needed at all, as it is just a simple process that needs supervision and do not act as a server.

It may yet be a bit premature, but the issues list keeps getting shorter and it feels like we're getting to the point where it makes sense to start thinking about the initial release of the code.

For the initial release (pre-Arduino support) I was thinking of keeping things relatively low-key -- basically posting a link within the ESP thread and not much else. The majority of the world can't use it yet, and I don't want people getting frustrated if it doesn't support their use case. A more official thread, with hype would be for v2 at the earliest (Arduino + Serial support).

One major drawback to the way that things are implemented at the moment is the fact that Nginx won't support running both BrewPi-www and BrewPi-Django at the same time. I think I could potentially bundle an Nginx config file that would run BrewPi-www on another port (based on the default install) - but obviously there would be a potential conflict with BrewPi-script. What are your thoughts on this? Do you think this is a must-have to get people to try BrewPi-django or is this a nice-to-have?

With regards to timing, I mostly count in weekends since that's when I personally have time to code. What do you think about targeting the weekend of March 18th (and releasing a week earlier if it's done sooner)?

Ugh. :(

This is a quick one, and is more of a reminder than anything.

There's a lot of device options that are defined in the firmware, but don't actually have any code supporting them. Examples include chamber fan, chamber light, etc.

Before release, I need to (all in the control constants model I believe):

• Comment out any unused device types
• Review and rename renaming device types to make it clear what they are
• Unrelated - refactor the control constants model to shift all communication with the controller to BrewPiDevice (there's two lines where ControlConstants is using sendmessage)

Although I personally prefer using CDNs when possible, I expect there are people who may deploy this app in an environment that doesn't have (decent) web access. It may make sense to download local copies of all the javascript libraries we use and include in the static folder.

Thoughts?

I added a view to find uninstalled ESP8266 BrewPi devices with the latest commit (f12c66b) - It would be nice to have this page allow for very fast device setup. What I'm envisioning is:

1. User clicks on a link to the mDNS scan page
2. User gets a list of uninstalled devices
3. User clicks an "install" button which then takes them to a pre-filled "Device Add" page
4. User saves the newly configured device

When I'm running circusd and having it control everything, I constantly seem to have two zombie chaussette processes running.

ferment+  9518  0.5  1.5  40584 14608 ?        Sl   17:07   0:10 /home/fermentrack/venv/bin/python2 /home/fermentrack/venv/bin/circusd --daemon /home/fermentrack/fermentrack/circus.ini
ferment+ 14959 16.5  2.5  46984 24624 ?        Ssl  17:40   0:01  \_ /home/fermentrack/venv/bin/python /home/fermentrack/fermentrack/fermentrack_django/brewpi_spawner.py
ferment+ 14960 13.8  1.6  38392 15720 ?        Ssl  17:40   0:00  \_ /home/fermentrack/venv/bin/python2 -c from circus import stats; stats.main() --endpoint tcp://127.0.0.1:5555 --pubsub tcp://127.0.0.1:5556 --statspoint tcp://127.0.0.1
ferment+ 14984 20.0  0.0      0     0 ?        Zs   17:40   0:00  \_ [chaussette] <defunct>
ferment+ 14985 19.6  0.0      0     0 ?        Zs   17:40   0:00  \_ [chaussette] <defunct>

It doesn't seem to impact functionality, but it's frustrating nonetheless.

The device constants form is currently functional, but has a number of things that need to be fixed/updated before release:

• Convert tempFormat to a drop down/select (C vs. F, not freetext)
• Add tooltips to each of the available settings
• Add error message support when invalid inputs are supplied

If no beer is active (or logging is paused/stopped) when turning on fridge constant, beer constant, or beer profile mode, we should add a messages.warning alert informing the user that temperature control is active but logging needs to be enabled separately on the dashboard.

When running brewpi.py with --dbcfg and when brewpi_spawn tries to start another one it exits with:

Feb 08 2017 18:36:42   Another instance of BrewPi is already running, which will \
conflict with this instance. This instance will exit

I can see lots of TODO's in the code :)

On the LCD list page, there is a "Set Temp" button which pops up a modal dialog that the user can use to set the temperature control mode for connected devices. This dialog is disabled by default if there was a connection issue in the script.

Instead of displaying an error message, it would be good to display a link to a "Debug Connection" page that would allow the user to diagnose what might have gone wrong. The key thing I'm worried about here is there being a "Do Not Run" flag set inappropriately (though admittedly - this flag shouldn't be used until firmware flashing is implemented)

• Create a "Debug Connection" page which will display connection diagnostics to the user
• (Ideally) Replace the "Set Temp" text with "Debug Connection" when the controller cannot be contacted

Welp, apparently my git integration doesn't work as well as I thought it did. I'm getting "upgrade" messages every time I visit siteroot, even when running the latest codebase.

Have an almost ready rewritten brewpi_spawner.py

• Configurable (cmd, prefix, model)
• Make it nicer and a class
• Implement logging

The way I'm currently implementing it, editing each line in a fermentation profile requires a separate form submit & reload of the edit page.

It would be nice to rewrite it to allow inline edits - even if it means we would potentially have to manually trigger a refresh of the graph.

There are a handful of features that are missing that need to be implemented. Here are the ones I can remember off the top of my head:

• "Reset EEPROM" button
• Control settings management (do we need this?)
• Help button (in upper right on the toolbar)
• Log in/Log out views (even though we don't have access control yet)
• Ability to load/view previous beers

Any others?

Including and distributing brewpi-django with included brewpi-script where brewpi-django is MIT and brewpi-script is GPL we should probably clearly state in the brewpi-script directory that it is licensed under the GPL.

Once a beer is completed, the data is saved - but can't be viewed. There needs to be a way to load this data & display it.

wifiChecker.sh checks to see if wlan0 is up and tries to fix things when it's not. But running a Pi with wire this will not work and generates some interesting log entries.

Proposal is to make this configurable, with settings/config.cfg

wifiCheckerEnable = true/false
wifiCheckerDevice = wlan0/wlanX

Currrently, it uses sqlite/dygraphs and is incredibly slow. Figure out a way to speed things up

Thanks to the efforts in #34 the in-app setup process is pretty darn straightforward. Still though, it would be good to have documentation for it just in case.

• Creating/understanding the user account
• Initial application (constance) configuration