This project is a clean-reworking of Brewerslab which is looking to provide an datamodel and associated implementation for a small brewery. There has been a lot of stop/start on rewriting the existing code - most of the problem stems from reactoring in between brewing beer is unlikely to happen- so a gradual migration is required.
There is still a strong desire to distribute, physical ports on a Raspberry Pi (I have two or three of these) can be extended with things like I2C, but that adds fragility for someone with my lack of soldering skills. Some obvious toolsets are too memory hungry or not available for ARM architecture (Tail-f ConfD, Elasticsearch, Kibana etc). Anything that uses Java is ruled out (Kafka was in with something to play with).
By retaining the multicast transmission of JSON encoded data it will be possible to migrate functions one by one - and within a brewday it would be possible to switch from old to new. The old code imports code with the pitm designation (pi temperature monitor), the new code will be designated with blng (brewers lab next generation)
The data for the brewery will use a strong data model (YANG), and this is still the desire.
Docker on a Raspberry Pi appears to be quite favourable at this stage - however it doesn't magically solve architecture differences. There are caveats with Multicast on the MAC because it uses a VM (going our own way with VirtualBox is an efective workaround).
- 1/ Move the recording of results to InfluxDB and Grafana
- 2/ Move the manual flag setting to a basic CLI based approach using Netopeer2/Sysrepod
- 3/ Re-implement functions
- a/ iSpindel
- b/ Temperature Sender
- c/ Relay Control
- d SSR Contrl
- TODO: we need to convert probeId mappings into Netconf datastore - not read from config file.
- we need to move target temperatures into Netconf datastore - not broadcast from governor
- Raspberry PI Basic Setup
git clone https://github.com/allena29/brewerslab(to be deprecated but still required)git clone https://github.com/allena29/brewerslabng
- Raspberry Pi
- DS18B20 - 1 Wire Temperature Probes
- Optional: iSpindel Hydrometer Tilt
TODO: old module must be used.
For temperature monitoring we use DS18B20 probes see here, one importnt lesson is that the resistor is very important in ensuring stable clocking of the signal.
The newer Raspberry PI's need 1wire support explicitly enabling in raspi-config from the Interfacing Options menu. If a PI isn't required for temperature monitoring it is best to disable the module as there can be CPU spikes whilst the kernel tries to discover non-existant probes.
When operating correctly looking in /sys/bus/w1/devices should shown a number of directories with a random but unique idenitifer (e.g. 28-0417c4aa05ff), each contains a file named w1_slave
0f 01 4b 46 7f ff 0c 10 0f : crc=0f YES
0f 01 4b 46 7f ff 0c 10 0f t=16937
In this case the temperature is 16.937, this can be found by taking t=16937, the resolution of the probes is limited based on the Analogue-Digital Conversion. A value of 85000 is an invalid reading and points to disruption on the 1-Wire bus - physical wiring should be checked.
Each time a temperature reading is taken it is published via a JSON string publised on the Multicast group 239.232.168.250 port 5087. This result is padded to 1200 bytes, however in future the configuration data will be moved out to a NETCONF data store. The publishing of the temperatures themselves will remain (i.e. currentResult and _operation keys)
{
"_operation": "temperatureResults1",
"currentResult": {
"28-0417c4aa05ff': {
"timestamp": 1537224875.011157,
"valid": True,
"temperature": 16.937
}
},
"_brewlog": "08.09.2018",
"_recipe": "Citra18",
"_mode": "ferm",
"currentStatus": 0,
"hlt": "28-0417c4b010ff",
"mashA": "28-0417c4acedff",
"mashB": "28-0417c4acedff",
"ferm": "28-0417c4aa05ff",
"_checksum": " ",
"tempTargetBoil": [-1, -1, -1],
"tempTargetHlt": [-1, -1, -1],
"tempTargetFerm": [16.7, 17.3, 17.0],
"tempTargetSparge": [-1, -1, -1],
"tempTargetMash": [-1, -1, -1],
}
}An iSpindel can be used to provide an approximate the progress of fermentation, this is unlikely to be entirely accurate but provides a useful guide for the progress. The iSpindel can be configured to submit results to a service like Ubidots, or a Generic TCP server where we have a simpe JSON structure.
Note: the iSpindle does not talk HTTP
{
"name": "iSpindel000",
"ID": 14039613,
"token": "A1E-fEI",
"angle": 43.95625,
"temperature": 17.1875,
"battery": 4.223149,
"gravity": 3.919538,
"interval": 600
}Calibration provides a formula to map the tilt value into Plato.
FORMULA_1 = 0.008626076
FORMULA_2 = 0.439419453
FORMULA_3 = 4.677151587
FORMULA_1 * angle **2 - FORMULA_2 * angle + FORMULA_3
Once we have the data it will be submitted via HTTP to the Influx Database used by Grafana and the grapical dashboard.
Temperature Publishing (publishTemperatureToInflux.py)
To provide a graphical dashboard the Influx Database is used to store the data, a multicast receiver will collect the results and publish them into the database. Grafana is then used to draw pretty graphs.
The best way to see how this project and code behaves is by running the approval testing, this will run through a set of tests. This will create a datastore will be created in a temporary directory and removed after the test is compelted.
The test harness follows Behaviour Driven Development approach which ensures asserts conditions in response to certain actions.
TODO... populate it.
The username is beerng and the password is beerng.
docker run --name grafana -i -d -p 3000:3000 -p 8086:8086 allena29/brewerslabng:grafana
For the dashboards to receive any stats the following processes need to run, they need to be able to successfully receive multicast and be able to make HTTP calls to the Influx DB port 8086.
screen -dmS broadcastGravity python broadcastISpindelGravity.py
screen -dmS publishGravity python publishGravityToInflux.py
screen -dmS publishTemperature python publishTemperaturesToInflux.py
The NETCONF datastore runs sysrepo and netopeer2 within a docker instance, the tag netopeer or netopeer-arm can be used from allena29/brewerslabng respository.
./launch-netconf
- validate module revisions when connecting CLI.