@sbowler YAY! Got it working! It was (potentially) the dumbest thing … I had to FORCE RELOAD (Ctl-F5
) the brewpi page in Chrome browser. Thanks for your comments, I don’t think I ever would have found that. So simple yet so evasive.
Thanks @Ron_K, but I run on the legacy platform already, but I did an update today anyway and it looks like this. (after that, I also got the same message)
*** Updating BrewPi web interface repository ***
You are on branch legacy
Available branches on the remote ‘origin’ for /var/www/html:
[0] beta
[1] develop
[2] feature/chart-export
[3] feature/notifications
[4] legacy
[5] master
[6] Skip updating this repository
Enter the number of the branch you wish to update [legacy]:4
The latest commit in /var/www/html is 398f1b50c71904f69e836b26299dd178d9d4515a on Mon, 11 Jan 2016 14:16:11
The latest commit on origin/legacy is 398f1b50c71904f69e836b26299dd178d9d4515a on Mon, 11 Jan 2016 14:16:11
Your local version of /var/www/html is up to date!
No changes were made, skipping runAfterUpdate.sh.
If you encounter problems, you can start it manually with:
sudo /home/brewpi/utils/runAfterUpdate.sh
The update script can automatically check your controller firmware version and program it with the latest release on GitHub, would you like to do this now? [Y/n]:y
_ Stopping any running instances of BrewPi to check/update controller…_
_ _
Checking current firmware version…
_ Jan 24 2017 17:08:50 Opening serial port_
_ Found BrewPi v0.2.10 build unknown, running on an Arduino Uno with a revC shield on port /dev/ttyACM0_
_ Current firmware version on controller: 0.2.10_
_ _
Checking GitHub for available release…
Available releases:
[0] 0.2.10
[1] 0.2.9
[2] 0.2.8
[3] Cancel firmware update
Should I clone his (supercow) repository, or just as descripe in his Readme, copy the files in all folder.
Hi @frizzo,
It looks like it’s possible, but without a different data logging mechanism, that will just make the page load times slower. @Raptor has done this using a database. I could implement something similar but I’d prefer to wait for the overall BrewPi UI changes which will use a database to store logging data instead of a flat file.
You can get the battery level by the gatttool
command (installed from bluez-tools
package):
The following command will give you the battery level in hex.
sudo gatttool -b <brewometer address> --char-read -a 0x0048 | cut -d ' ' -f 3
@Ron_K @frizzo @sbowler Here is my getTiltBatteryStatus script for getting the Tilt battery level every 12 hours:
Note however that each time gatttool is used, this causes a ble subsystem issue and you will have to change the brewpi script so that it restarts the tilt integration properly. I had to make quite a few changes for this. Unfortunately due to starting a new job and doign a lot of travelling means I don’t currently have time to refactor all my code away from the other stuff I am doing in order to build a github release for this.
#BrewpiTilt - getTiltBatteryStatus - gets the current battery status
import subprocess
import shlex
import re
import sqlite3
#needs the following cron file entry in: /etc/cron.d/tiltBatteryStatus to run every 12 hours.
#0 */12 * * * root python /home/brewpi/BrewpiTilt/getTiltBatteryStatus.py >/dev/null 2>&1
#
sqlite_file = '/home/brewpi/BrewpiTilt/BrewpiTilt.db'
hwaddr = '88:C2:55:AC:2F:42'
def call_gatttool():
hexcmd = '0x48'
cmd = 'gatttool -b %s --char-read -a %s' % (hwaddr,hexcmd)
res = subprocess.check_output(shlex.split(cmd))
if not res.startswith('Characteristic value/descriptor:'):
return None
res = re.match('Characteristic value/descriptor: (.*)', res).groups()[0]
byte_values = res # .split()
return int(byte_values, 16) #convert to int value for battery percent
def log_to_DB(battery_level):
try:
#set up the db connection
conn = sqlite3.connect(sqlite_file)
cur = conn.cursor()
#update the battery level in the brewdevice table
sqlstr = 'UPDATE brewdevice set BatteryLevel = ?,BatteryLastChecked = CURRENT_TIMESTAMP WHERE Address = ?'
params = (battery_level,hwaddr)
cur.execute(sqlstr, params)
#close the connection
conn.commit()
#print "Number of rows updated: %d" % cur.rowcount
conn.close()
except Exception, e:
print("ERROR: BrewpiTilt - getTiltBatteryStatus - log_to_DB function - error is - " + e.message)
return;
result = call_gatttool()
print result
if not result == None :
log_to_DB(result)
Thank you for sharing. I’m sure someone on this thread will be able to find a solution for the ble subsytem issue.
What I suggest you do first is check the logs in brewpi just to make sure your running on legacy correctly. because the message you pasted from the previous log indicated you were not. Once you know that brewpi is running correctly then I would clone the repo from supercow. check again before making the permission changes that they say to do in the readme. When I made the permission changes as directed in the readme I broke my brewpi. I had to use Elcos fix permissions script to get it working again. Work this in phases and check after each change that it works or not. ITs easy to do too much at one time then when it doesn’t work you really don’t know where to look.
Thanks again @Ron_K.
I’m pretty sure I’m running legacy, the flash firmware on Genuino are 0.2.10, and says that is in legacy branch when run the updatescript.
Anyway, I took another SD card, installed a fresh Debian, install Brewpi recording to the docs, automatic script, flash the Genuino card automatic and copy that files like readme says in supercow repository. Run the FixPermision script…
I did get the same exit error, it says I’m not on legacy.
So I did a test, I comment the IF…Exit… chapter in the brewpi.py script, and woila… it then the script start, and I got the logging… strange?
So, I remove this from Brewpi.py , and then the script run and Brewometer logg… to me it seems that the script are made for not Arduino?
if hwVersion.family == ‘Arduino’:
_ exit("\n ERROR: the newest version of BrewPi is not compatible with Arduino. \n" +_
_ “You can use our legacy branch with your Arduino, in which we only include the backwards compatible changes. \n” +_
“To change to the legacy branch, run: sudo ~/brewpi-tools/updater.py --ask , and choose the legacy branch.”)
Where can I see, if I not running the Legacy ? Does give any meaning ?
Hi guys,
I haven’t seen it addressed since the middle of last year, so I don’t think anything has changed.
But I’m going to ask anyway - can the temp returned from the Tilt be used to control fermenters? Seems it would require integration with the Arduino code that has been ‘frozen’.
Thanks,
Paul
I would love to know how to change the logging intervals of the tilt. It seems to slow up displaying the graph after a week of logging.
Cheers stew
I agree with @rbpalmer, chnage the BrewPi logging to a lower frequency. I have set mine to every 2 minutes, but have only been logging for two days, so I will have to wait a bit to see if it has a positive impact.
Stefan
Woo Hoo, it is working. Now to get my GRAVITY.blue and TEMPERATURE.blue set up correctly (GRAVITY was adjusted just before noon yesterday, accounts for the jump). Interesting to see the temporary drop last night, I suspect it is the results of the 1098 yeast getting very active and Co2 or krausen affecting the Tilt.
Thanks again @sbowler for your changes to Elco’s software
Stefan
Simon, I really have to thank you for your changes to Elco’s software. I ferment in corny kegs, so cannot watch my wort swirling as the yeast bugs do their thing. However, watching the Tilt SG drop is almost as good, look at the drop of 20 points in less than 24 hours, That WY1098 is going gangbusters!
Thanks again
Stefan
Glad it’s working well for you. My changes are really s scratch on the surface of all the BrewPi work that Elco’s done. It’s an awesome bit of kit.
@prmurphy63026 - It’s still not possible to control the fermentation temp using the Tilt’s thermometer as input.
@Raptor - I’ve got a change coming that will automatically restart the Tilt connection without needing to restart the script. I hit a hurdle when I went to test and found that my BrewPi SD card had corrupted itself over Christmas. Almost there now though.
Thanks @sbowler - I don’t actually restart the script as such - I changed your code to move the exception block to catch the issue earlier and thus stopping the whole lot crashing. I also restart the scanning if it is not running from both the brewpi and your tilt class.
Simon,
I have had a corrupted SD card a couple of times too. Here is what I have done and things have been pretty stable.
- Added a surge protector/UPS. Just a cheap one as the RPi does not use much juice but hopefully enough to carry it through the occasional power interruptions that we have, now and then.
- Avoid restarting RPi by disconnectiong power and reconnectiong. Whenever possible I use Putty and then do sudo shutdown (with or without -r). I read in some other fori (fora? forums?) that RPis do not like the disconnect of power without shutdown. Obviously it works mostly, but I am concerned about the few times that it does mess up your card
Stefan
Did you verify that brewpi was working before adopting the changes for this modification? I can’t explain why you are getting the error message indicating that your not on legacy. I think you need to make sure brewpi is working first then try the modification. If it still throws the error with no modification then I’d ask Elko for help.
Hello Ron,
I am having the same problem as nanotap. Everything was working fine up until I copied over the scripts from the https://github.com/supercow/brewpi-brewometer repository. I have a feeling that it is the scripts downloaded from there that breaks it.
Reinstalling Brewpi and then reselecting the legacy branch starts everything working again. Checking the brewpi.py file from Supercow’s git repository shows:
logMessage("Checking software version on controller… ")
hwVersion = brewpiVersion.getVersionFromSerial(ser)
if hwVersion is None:
logMessage("Warning: Cannot receive version number from controller. " +
"Your controller is either not programmed or running a very old version of BrewPi. " +
“Please upload a new version of BrewPi to your controller.”)
# script will continue so you can at least program the controller
lcdText = [‘Could not receive’, ‘version from controller’, ‘Please (re)program’, ‘your controller’]
else:
logMessage(“Found " + hwVersion.toExtendedString() +
" on port " + ser.name + “\n”)
if LooseVersion( hwVersion.toString() ) < LooseVersion(compatibleHwVersion):
logMessage(“Warning: minimum BrewPi version compatible with this script is " +
compatibleHwVersion +
” but version number received is " + hwVersion.toString())
if int(hwVersion.log) != int(expandLogMessage.getVersion()):
logMessage(“Warning: version number of local copy of logMessages.h " +
“does not match log version number received from controller.” +
“controller version = " + str(hwVersion.log) +
”, local copy version = " + str(expandLogMessage.getVersion()))
if hwVersion.family == ‘Arduino’:
exit(”\n ERROR: the newest version of BrewPi is not compatible with Arduino. \n” +
“You can use our legacy branch with your Arduino, in which we only include the backwards compatible changes. \n” +
“To change to the legacy branch, run: sudo ~/brewpi-tools/updater.py --ask , and choose the legacy branch.”)
So it seems that the version of the script in the repository is what is causing the problem.
Regards,
Jerry
@jerryp, @Ron_K. I can confirm that my version of the scripts from “supercow” is working, after I comment out the following in brewpi.py:
if hwVersion.family == ‘Arduino’:
exit("\n ERROR: the newest version of BrewPi is not compatible with Arduino. \n" +
“You can use our legacy branch with your Arduino, in which we only include the backwards compatible changes. \n” |+
“To change to the legacy branch, run: sudo ~/brewpi-tools/updater.py --ask , and choose the legacy branch.”)
I did a new fresh install of Brewpi, install the legacy version, test it and up and running as before.
I copied then all the files from “supercow” and run Elcos “fixpermission” script to make sure everything is right. I do still have some logentry says I’, not running the right version, but it works.
Tested then the Breometer with water to calibrate it, so some sugerwater (SG 1.048) and calibrate, and let it go for a week.
Now I have my brew batch #002-2017 in fermenter, and the Brewometer work as a charm. (see pic)
The only issue is what someone else says, the refresh of page are slower than without brewometer integration, even if I set the logentry to be every 5 min.
So, if someone can clear this out why the “Arduino” check fails on a Arduino (Genuino board in Norway), I’ll be glad:)
//Cheers
That is great to know @nanotapp. I will give that a go once my current brew finishes. I have the Tilt Hydrometer logging to Google Docs, so at least that is working. Do not want to risk messing anything up during this run…