I was trying to get that gliphy thing working but ....
Last edited:
HOWTO - Make a BrewPi Fermentation Controller For Cheap
- Thread starter FuzzeWuzze
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
- Status
Bubbles Are Back!
It's all good
It's all good
I've tried to upgrade my BPI and used doUpdate.sh
The scripts was execute well but I did not reprogram the arduino at the end because I'm using the brewpi-arduino-uno-i2c-0.2.12.hex version.
But now I'm unable to get the script running (see screenshot)
I tried to reprogram the arduino with XLoader but it still doesn't work.
Also notice that it upgraded to version 0.5.4.0 not 0.5.4.1
Did I do something wrong?
Attachments
I just found out that my SD card is almost full so this will probably be the reason!! Motion was installed so I could check the bubbles through my webcam but I didn't notice that the capturing was stored in /var/lib/motion directory
Last edited:
0.5.4.1 is scripts only so it will only show in the logs right now. The version given in the web page is currently only the WWW version.
To be sure, I'd have to see the logs, but you need to clear some space either way.
If you want to know the airlock is bubbling, you have seen Brew Bubbles, right? It's going to be a lot easier on your card space.
Once you get your space issue taken care of, here's sort of a catch-all method of remediating random "script will not start" issues:
From the Raspberry Pi command line:
The output should look like:
Then do:
There should be no output here. If there is, let me know. Then:
This will reboot your Pi. When it reboots, refresh your web page and if the button in the top-right still says Script not running!, click the button (once) and it should start within 30 seconds.
This takes care of a lot of potential issues. If at the end of all this the script will not start, I need to see the logs. You can issue these commands and each will give you a link. Run these and send me those links:
You will get back a link from each that looks like this; share it here:
To be sure, I'd have to see the logs, but you need to clear some space either way.
If you want to know the airlock is bubbling, you have seen Brew Bubbles, right? It's going to be a lot easier on your card space.
Once you get your space issue taken care of, here's sort of a catch-all method of remediating random "script will not start" issues:
From the Raspberry Pi command line:
Code:
sudo /home/brewpi/utils/doPerms.sh
Code:
$ sudo /home/brewpi/utils/doPerms.sh
***Script doPerms.sh starting.***
Fixing file permissions for /var/www/html/chamber1.
Fixing file permissions for /home/brewpi/chamber1.
Allowing BrewPi python access to Bluetooth interfaces.
Checking user accounts.
***Script doPerms.sh complete.***
Code:
sudo systemctl restart brewpi
Code:
sudo reboot nowThis takes care of a lot of potential issues. If at the end of all this the script will not start, I need to see the logs. You can issue these commands and each will give you a link. Run these and send me those links:
Code:
cat /home/brewpi/logs/stdout.txt | nc termbin.com 9999
cat /home/brewpi/logs/stderr.txt | nc termbin.com 9999
journalctl -u chamber1.service -b --no-pager | nc termbin.com 9999
Code:
https://termbin.com/h38zLee Thanks again for the info I will check it tomorrow! Here in Belgium its time to go to sleep ;-) and the Brew Bubbles was already on my todo list.
fwiw, I have a bunch of RPi's doing surveillance duty and if you go into the /etc/motion/motion.conf you can turn off all recording of images and video. You'll still need to find the (likely default) storage location (it's in the conf file) to delete the accumulated images/videos...
Cheers!
Cheers!
Lee I've send the links in a private conversation.
Lee, many thanks for your help! You are SUPER!!!!
@day_trippr Thanks for the info. By default it is turned off so I probably set it on for testing and forgot to turn it back off.
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
Hey guys, I hate just joining a forum for support, but I am really stumped with getting BrewPi Remix running. Any help is greatly appreciated.
I built my BrewPi Remix setup a few months ago on a RPi3B, inside a fresh install of Rasbian, with an Arduino Uno Clone R3 (DIP, not QFP), and an Arduino compatible 4x250VAC relay board using the code:
...and everything worked flawlessly. I had two DS18B20 temperature probes running, and reading accurately (Inkbird ITC-308 as reference). I set my probes up on a OneWire bus via a section of breadboard, and used a 4.77kOhm relay (all I had on hand). I moved it to it's permanent installation, and I inadvertently reversed the polarity on the 5VDC and ground for the probes (causing them to heat up, and kill the Ardino's onboard CH340G USB-to-serial chip). My bad.
I replaced the Arduino with another identical clonedunio, and two new DS18B20s. Ever since, I cannot for the life of me defeat the 85 degree reading on the probes. I have done multiple uninstalls and reinstalls, completely wiped the uSD card and reinstalled Rasbian, even went through the masochist's guide and did a line-by-line install - it still does not work.
I did discover when trying to do the reinstallations that the script above was consistently failing at the point where it asked if you wanted to flash the Arduino - the script would not open a serial port etc, and instead just jump straight to the end advising of successful installation. The only way I could flash the Arduino was via the manual Masochist's method (code used to flash the Arduino below). Even then, I still get 85 degrees. Having done a lot of reading, I believe this is the default value for the "waiting" or "ready" state of the probes.
Given I've gone through so much to get to this point, I'm left wondering: is there an issue with the Arduino code? Has it recently been updated? I'll attach a photo of my setup as it stands, ridicule away.
Thanks, Tim
I built my BrewPi Remix setup a few months ago on a RPi3B, inside a fresh install of Rasbian, with an Arduino Uno Clone R3 (DIP, not QFP), and an Arduino compatible 4x250VAC relay board using the code:
Code:
curl -L install.brewpiremix.com | sudo bash...and everything worked flawlessly. I had two DS18B20 temperature probes running, and reading accurately (Inkbird ITC-308 as reference). I set my probes up on a OneWire bus via a section of breadboard, and used a 4.77kOhm relay (all I had on hand). I moved it to it's permanent installation, and I inadvertently reversed the polarity on the 5VDC and ground for the probes (causing them to heat up, and kill the Ardino's onboard CH340G USB-to-serial chip). My bad.
I replaced the Arduino with another identical clonedunio, and two new DS18B20s. Ever since, I cannot for the life of me defeat the 85 degree reading on the probes. I have done multiple uninstalls and reinstalls, completely wiped the uSD card and reinstalled Rasbian, even went through the masochist's guide and did a line-by-line install - it still does not work.
I did discover when trying to do the reinstallations that the script above was consistently failing at the point where it asked if you wanted to flash the Arduino - the script would not open a serial port etc, and instead just jump straight to the end advising of successful installation. The only way I could flash the Arduino was via the manual Masochist's method (code used to flash the Arduino below). Even then, I still get 85 degrees. Having done a lot of reading, I believe this is the default value for the "waiting" or "ready" state of the probes.
Code:
avrdude -F -e -pATmega328P -cArduino -b115200 -P/dev/ttyACM0 -U flash:w:"/usr/share/arduino/hardware/tools/avr/brewpi-arduino-uno-revc-0.2.12.hex" -C /usr/share/arduino/hardware/tools/avrdude.confGiven I've gone through so much to get to this point, I'm left wondering: is there an issue with the Arduino code? Has it recently been updated? I'll attach a photo of my setup as it stands, ridicule away.
Thanks, Tim
Attachments
I would check the 5V on the Uno clone. How are you powering it? Via its power socket or via USB?
When a ds18b20 comes out of reset it'll read 85°C/185°F - the reason some folks see spikes in their plots at that temperature is most often due to less than great power to the Uno and thus the sensors which will go through reset if the voltage sags enough...
Cheers!
When a ds18b20 comes out of reset it'll read 85°C/185°F - the reason some folks see spikes in their plots at that temperature is most often due to less than great power to the Uno and thus the sensors which will go through reset if the voltage sags enough...
Cheers!
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
Hi day_trippr, thanks for your suggestion.
I'm currently powering it via USB from the RPi0W, however I have tried powering it seperately via the DC in with a 12VDC power supply from a modem (I believe it's 1.5A). It hasn't made any difference varying the power supply during my tests. I've also tried powering the DS18B20s via the 3.3V pin, as well as 5V, to no avail. Running the multimeter over the pins confirms there is enough voltage getting through.
Ok, good work there. Though it leaves me at a loss.
When you go into Maintenance panel - Device Configuration to setup the devices you see both probes listed? And if you check the "Read values" and click Refresh you get the 85° thing consistently?
Cheers!
When you go into Maintenance panel - Device Configuration to setup the devices you see both probes listed? And if you check the "Read values" and click Refresh you get the 85° thing consistently?
Cheers!
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
Currently, no - I only see one probe, measuring 85 degrees. This also seems to be a bit random - sometimes I get 1 probe, sometimes 2. This seems to vary with each fresh installation, although not consistently. However many probes are, they always read 85.
Are these the same probes that you heated up previously? Do you have an opportunity to test with any others?
Also about joining a forum for support: there are not many other options, certainly not many for free software. The reason I ask for people to participate here for support is because as you see there are many more people than just me who can help. It’s not uncommon these days to require membership of a forum, at least in this forum you can talk about beer and not just about the software.
Also about joining a forum for support: there are not many other options, certainly not many for free software. The reason I ask for people to participate here for support is because as you see there are many more people than just me who can help. It’s not uncommon these days to require membership of a forum, at least in this forum you can talk about beer and not just about the software.
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
Hi LBussy, really glad to hear from you! I've actually read this entire thread, and you're featured prominently.
After the initial reverse polarity issue, I replaced both temp probes and the Ardunio at the same time. So there is essentially no implicated hardware. It was from here onwards I continually got the 85 degree issue.
I've checked everything so many times, even re-soldered the breadboard, and confirmed the connections with the continuity function of the DMM. The only thing that has changed (and many times) is the software, by means of several re-installs.
I've also tried the old temp probes, just in case, and they also read 85 degrees. So that says to me it's either a hardware issue I haven't addressed (perhaps my 4.76KOhm resistor?) or a software issue.
After the initial reverse polarity issue, I replaced both temp probes and the Ardunio at the same time. So there is essentially no implicated hardware. It was from here onwards I continually got the 85 degree issue.
I've checked everything so many times, even re-soldered the breadboard, and confirmed the connections with the continuity function of the DMM. The only thing that has changed (and many times) is the software, by means of several re-installs.
I've also tried the old temp probes, just in case, and they also read 85 degrees. So that says to me it's either a hardware issue I haven't addressed (perhaps my 4.76KOhm resistor?) or a software issue.
I will never say never, but software seems unlikely. There have not been any changes to that portion of the code since the original work, and it’s quite well baked. There are a lot of users out there without the problem.
That said, I have occasionally chased such a gremlin. To get to the basics, use the one wire connected directly to the Arduino and see if the problem goes away. It’s always possible that the breadboard you are using is bad in someway, the wires are not making a good connection, or some other strange issue.
Burning out a resistor seems a little far-fetched, but it’s worth changing a two cent piece.
That said, I have occasionally chased such a gremlin. To get to the basics, use the one wire connected directly to the Arduino and see if the problem goes away. It’s always possible that the breadboard you are using is bad in someway, the wires are not making a good connection, or some other strange issue.
Burning out a resistor seems a little far-fetched, but it’s worth changing a two cent piece.
Bigdaddyale
Well-Known Member
Has he checked for ds18b20 running in parasitic mode?
I've never had a PAR probe, would he be able to see any PAR probe via the Device configuration panel?
I suggest hooking the probes up to the RPi, using 3.3V with the same 4.7K pull-up resistor to 3.3V.
ie:
Sensor red wire(s) to +3.3V (GPIO header pin 1 or 17)
Sensor black wire(s) to GND (GPIO header pin 6,9,14,20 or 25)
Sensor yellow (or white) wire(s) to GPIO4 (GPIO header pin 7)
Add a 4.7K ohm 1/8w resistor across GPIO header pins 1 and 7 (ie: between red and yellow/white wires).
Then run this python script and see what is reported:
This code will not work with PAR probes afaik...
Cheers!
I suggest hooking the probes up to the RPi, using 3.3V with the same 4.7K pull-up resistor to 3.3V.
ie:
Sensor red wire(s) to +3.3V (GPIO header pin 1 or 17)
Sensor black wire(s) to GND (GPIO header pin 6,9,14,20 or 25)
Sensor yellow (or white) wire(s) to GPIO4 (GPIO header pin 7)
Add a 4.7K ohm 1/8w resistor across GPIO header pins 1 and 7 (ie: between red and yellow/white wires).
Then run this python script and see what is reported:
Code:
#!File: /usr/lib/cgi-bin/test_sensors.py
#!Version: 20mar2014
#!Discover and test any DS18B20 temperature sensors
#!Run from user space (/home/pi)
#!/usr/bin/env python
import os
import time
import glob
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
comp_pin=25
GPIO.setup(comp_pin, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
#-------------------------------------------------------------------------------------------------------
# global variables
speriod=(15*60)-1
comp_high=55
comp_low=45
#-------------------------------------------------------------------------------------------------------
# get temperature
# returns None on error, or the temperature as a float
def get_temp(devicefile,devicenumber):
try:
fileobj = open(devicefile,'r')
lines = fileobj.readlines()
fileobj.close()
except:
return None
# get the status from the end of line 1
status = lines[0][-4:-1]
equals_pos = lines[1].find('t=')
if equals_pos != -1:
tempstr = lines[1][equals_pos+2:]
print "Read Sensor",
print devicenumber
print "Raw Data = ",
print tempstr,
tempvalue_c=float(tempstr)/1000.0
print tempvalue_c, "Degrees C"
tempvalue_f = tempvalue_c * 9.0 / 5.0 + 32.0
print tempvalue_f, "Degrees F"
tempvalue = round(tempvalue_f,1)
print tempvalue, "Rounded"
return tempvalue
else:
print "There was an error."
return None
#-------------------------------------------------------------------------------------------------------
# main function
# This is where the program starts
def main():
# enable kernel modules
os.system('sudo modprobe w1-gpio')
os.system('sudo modprobe w1-therm')
print "Looking for W1_Slave Temperature Sensor Devices..."
# search for a device file that starts with 28
devicelist = glob.glob('/sys/bus/w1/devices/28*')
print " "
devicecount = len(devicelist)
print "Number of W1_Slave Devices found:",
print devicecount
print " "
for deviceindex in xrange(0,devicecount):
print "Sensor " +str(deviceindex)+ " ID: " +devicelist[deviceindex]
print " "
if devicelist=='':
return None
# while True:
# get the temperatures from the device files
for deviceindex in xrange(0,devicecount):
w1devicefile = devicelist[deviceindex] +'/w1_slave'
temperature = get_temp(w1devicefile,deviceindex)
if temperature != None:
print "Sensor " +str(deviceindex) +" Temperature = " +str(temperature) +" F"
print " "
else:
# Sometimes reads fail on the first attempt
# so we need to retry
temperature = get_temp(w1devicefile[deviceindex],deviceindex)
if temperature != None:
print "Sensor " +str(deviceindex) +" Temperature = " +str(temperature) +" F"
print " "
else:
print "Error Reading Sensor " +str(deviceindex)
# time.sleep(speriod)
if __name__=="__main__":
main()
comp_state = GPIO.input(comp_pin)
print comp_state
if comp_state == 1:
print "Compressor On"
comp = comp_high
else:
print "Compressor Off"
comp = comp_low
print comp
GPIO.cleanup()This code will not work with PAR probes afaik...
Cheers!
There's also a test out there for parasite mode.
It's in this thread somewhere...
It's in this thread somewhere...
#include <DallasTemperature.h>
#include <OneWire.h>
#define ONE_WIRE_BUS 02
OneWire oneWire(ONE_WIRE_BUS);
// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);
void setup() {
Serial.begin(9600);
sensors.begin();
}
void loop() {
Serial.print("Parasite power is: ");
if (sensors.isParasitePowerMode())
Serial.println("ON\n");
else
Serial.println("OFF\n");
Serial.print ("Detected ");
Serial.print(sensors.getDeviceCount(), DEC);
Serial.print(" devices\n");
byte deviceAddress[8];
for (int i = 0; i < sensors.getDeviceCount(); i++) {
sensors.getAddress(deviceAddress, i);
Serial.print("Device ");
Serial.print(i);
Serial.print(" is a ");
switch (deviceAddress[0]){
case DS18S20MODEL:
Serial.print("DS18S20\n");
break;
case DS18B20MODEL:
Serial.print("DS18B20\n");//hopefully this one
break;
case DS1822MODEL:
Serial.print("DS1822\n");
break;
case DS1825MODEL:
Serial.print("DS1825\n");
break;
default:
Serial.print("Unknown\n");
}
}
delay(1000);
sensors.requestTemperatures(); // Send the command to get temperatures
delay(750);
for (int i = 0; i < sensors.getDeviceCount(); i++) {
float temp = sensors.getTempCByIndex(i);
Serial.print ("Sensor ");
Serial.print (i);
Serial.print (" ");
Serial.print(temp);
Serial.print("\n");
}
Serial.print("\n");
}
The code above from DT was able to tell me what sensors I had, and if they were running in parasitic mode or not.
#include <OneWire.h>
#define ONE_WIRE_BUS 02
OneWire oneWire(ONE_WIRE_BUS);
// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);
void setup() {
Serial.begin(9600);
sensors.begin();
}
void loop() {
Serial.print("Parasite power is: ");
if (sensors.isParasitePowerMode())
Serial.println("ON\n");
else
Serial.println("OFF\n");
Serial.print ("Detected ");
Serial.print(sensors.getDeviceCount(), DEC);
Serial.print(" devices\n");
byte deviceAddress[8];
for (int i = 0; i < sensors.getDeviceCount(); i++) {
sensors.getAddress(deviceAddress, i);
Serial.print("Device ");
Serial.print(i);
Serial.print(" is a ");
switch (deviceAddress[0]){
case DS18S20MODEL:
Serial.print("DS18S20\n");
break;
case DS18B20MODEL:
Serial.print("DS18B20\n");//hopefully this one
break;
case DS1822MODEL:
Serial.print("DS1822\n");
break;
case DS1825MODEL:
Serial.print("DS1825\n");
break;
default:
Serial.print("Unknown\n");
}
}
delay(1000);
sensors.requestTemperatures(); // Send the command to get temperatures
delay(750);
for (int i = 0; i < sensors.getDeviceCount(); i++) {
float temp = sensors.getTempCByIndex(i);
Serial.print ("Sensor ");
Serial.print (i);
Serial.print (" ");
Serial.print(temp);
Serial.print("\n");
}
Serial.print("\n");
}
The code above from DT was able to tell me what sensors I had, and if they were running in parasitic mode or not.
Note that sketch is for the Arduino. And the ONE_WIRE_BUS value needs to be set to match the hardware configuration...
Cheers!
Cheers!
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
Awesome guys, thanks fornthe suggestions! I'll try these out later today.
I don't mean to disrespect the great work done to make this software what it is, I just am at a loss. Oh well, time to work it out.
Re: PAR; my sensors do not have any markings on them to indicate whether they are PAR or not, but they are from the same seller on eBay and advertised as not being PAR.
I don't mean to disrespect the great work done to make this software what it is, I just am at a loss. Oh well, time to work it out.
Re: PAR; my sensors do not have any markings on them to indicate whether they are PAR or not, but they are from the same seller on eBay and advertised as not being PAR.
I use a barrier or euro strip when I want to get down to basics and test. Sometimes you just have to do that to make sure you're sane.
Also, don't discount the old erase EEPROM fix. Sometimes it's like rebooting a Windows PC. No idea why it works but it sure fixes a lot.
Also, don't discount the old erase EEPROM fix. Sometimes it's like rebooting a Windows PC. No idea why it works but it sure fixes a lot.
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
I made the above connections to my RPi3B (no Arduino involved), pasted this code into a new file via Nano and saved it as a python script, executed it, and got the error:
>>> %Run test_sensors.py
Traceback (most recent call last):
File "/home/pi/test_sensors.py", line 43
print "Read Sensor",
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Read Sensor", end=" ")?
>>>
It has many other errors similar to the above, which are revealed after I fix it with the suggestion. I'm not sure if I've made a fundamental error somewhere - I'm not particularly well versed with coding.
Ugh. fwiw, this is what five probes on an RPi should report running that script (using 'python test_sensors.py' as shown):
I'll take another look through this theadlette tomorrow...Maybe something will pop up...
Cheers!
Code:
pi@raspi5:~ $ python test_sensors.py
Looking for W1_Slave Temperature Sensor Devices...
Number of W1_Slave Devices found: 5
Sensor 0 ID: /sys/bus/w1/devices/28-0118331d0eff
Sensor 1 ID: /sys/bus/w1/devices/28-0118333937ff
Sensor 2 ID: /sys/bus/w1/devices/28-01183319b4ff
Sensor 3 ID: /sys/bus/w1/devices/28-011833349cff
Sensor 4 ID: /sys/bus/w1/devices/28-0118331c11ff
Read Sensor 0
Raw Data = 21625
21.625 Degrees C
70.925 Degrees F
70.9 Rounded
Sensor 0 Temperature = 70.9 F
Read Sensor 1
Raw Data = 21562
21.562 Degrees C
70.8116 Degrees F
70.8 Rounded
Sensor 1 Temperature = 70.8 F
Read Sensor 2
Raw Data = 21562
21.562 Degrees C
70.8116 Degrees F
70.8 Rounded
Sensor 2 Temperature = 70.8 F
Read Sensor 3
Raw Data = 21687
21.687 Degrees C
71.0366 Degrees F
71.0 Rounded
Sensor 3 Temperature = 71.0 F
Read Sensor 4
Raw Data = 21625
21.625 Degrees C
70.925 Degrees F
70.9 Rounded
Sensor 4 Temperature = 70.9 F
pi@raspi5:~ $I'll take another look through this theadlette tomorrow...Maybe something will pop up...
Cheers!
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
Further to this, I've just had a look through my Arduino libraries on the compiler (v1.8.10, Win10), and found I did not have OneWire or DallasTemperature installed - I've now installed them, and compiled & uploaded LTBrewer's code example to my Arduino. Whilst running the serial monitor, I get "Parasite power is: OFF" and "Detected 0 devices". Cool!
I assume that if I connect up one or more DS18B20s via the usual wiring method to the Arduino, I should get some output (if the hardware is working).
Edit: I got something working! I currently have a 4.77kOhm resistor between the 3.3V and pin 2, and a total of 3x DS18B20s attached to my breadboard (two are soldered in because that was for my brew fridge, but a third is alligator clipped to some test wires). Aside from a slight continuity issue I've found, the output via te serial monitor is:
Thanks so much for your help everyone. It's interesting that it states they're in PAR mode?
I assume that if I connect up one or more DS18B20s via the usual wiring method to the Arduino, I should get some output (if the hardware is working).
Edit: I got something working! I currently have a 4.77kOhm resistor between the 3.3V and pin 2, and a total of 3x DS18B20s attached to my breadboard (two are soldered in because that was for my brew fridge, but a third is alligator clipped to some test wires). Aside from a slight continuity issue I've found, the output via te serial monitor is:
Thanks so much for your help everyone. It's interesting that it states they're in PAR mode?
Last edited:
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
Well, after many late nights tearing my hair out, you guys have helped me get it running again. I rebuilt my breadboard with a fresh piece, systematically weeded out the dead B20s (I have 6x, and 2x were dead/reading 85), reinstalled BrewPi Remix, and reflashed the Arduino. Funnily enough I still am not able to flash my Arduino via avrdude on command line or via the BPR load hex file option - I had to use HEXtoArduino and manually load it. Oh well, got there in the end!
Thankyou so much for your help everyone.
Thankyou so much for your help everyone.
Attachments
Glad you got this far!
What errors are you getting flashing with avrdude?
What errors are you getting flashing with avrdude?
Aliensrgr8
Member
LBussy,
Thank you for making this easy for a noob like me.
I just got a BrewPI Remix installation running in January. I am looking for a brief description on how to get the Tilt Sensor integrated into BrewPi Remix since the release of version 5.4.1. I opted to include the Tilt Integration during the installation of BrewPI on my Raspberry PI V3 B+. But it does not appear to be tracking and I don't see a way to configure it under the Device Configuration. I have tried looking for this information, but all the information appears to be prior to the newest release of Remix. I assume that I need to connect the PI to the Tilt, but I don't have a clue where to start.
Thank you for making this easy for a noob like me.
I just got a BrewPI Remix installation running in January. I am looking for a brief description on how to get the Tilt Sensor integrated into BrewPi Remix since the release of version 5.4.1. I opted to include the Tilt Integration during the installation of BrewPI on my Raspberry PI V3 B+. But it does not appear to be tracking and I don't see a way to configure it under the Device Configuration. I have tried looking for this information, but all the information appears to be prior to the newest release of Remix. I assume that I need to connect the PI to the Tilt, but I don't have a clue where to start.
5spdvl
Member
- Joined
- Jan 15, 2020
- Messages
- 23
- Reaction score
- 1
With the BPR GUI, when I attempt to upload the .hex file it just hangs. No output occurs in the bottom window. With avrdude over command line, it gives a stk500 and communication error. Sometimes it says it times out. I will get you a proper output a bit later. The only way I was able to get the .hex file on was with HEXtoArduino.
You're right - the documentation is lagging. Since I basically forked the project and the original docs were limited, I often find myself neglecting some because it's not "all."
Tilts are added by color. Even though there's not documentation for this specifically (yet) I did attempt to leave examples. Check your {brewpi app directory}/settings/config.cfg.example file and you will see (in part
Code:
# wwwPath = /var/www/html
# port = /dev/ttyACM0
# altport = /dev/ttyACM1
# boardType = arduino
# startupDelay = 1.0
# debug = true
# tiltColor = Purple
# logJson = True
# scriptPath = /home/brewpi/You'd have to be using a configuration file, in other words, there would have to be a "config.cfg" in that location. If there is not one, copy the example:
Code:
sudo cp config.cfg.example config.cfgAfter that, you would stop and start the script and it should start picking up. If it does not, the first step would be to share the logs so we can see what's happening.
The GUI has always been iffy. I'll get back to that one of these days. If avrdude is not working, certainly the script will not. Seeing the output would help.
thestraw0039
Active Member
Here is the output I get when I try to run the avrdude command.
Code:
pi@raspberrypi:~ $ sudo avrdude -F -e -p atmega328p -c arduino -b 115200 -P /dev/ttyACM0 -U flash:w:"brewpi-arduino-uno-revc-0.2.12.hex"
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file "brewpi-arduino-uno-revc-0.2.12.hex"
avrdude: can't determine file format for brewpi-arduino-uno-revc-0.2.12.hex, specify explicitly
avrdude: read from file 'brewpi-arduino-uno-revc-0.2.12.hex' failed
avrdude: safemode: Fuses OK (E:00, H:00, L:00)
avrdude done. Thank you.Do you get the same results when running updateFirmware.py?
You can try adding a ":i" after the filename to explicitly define it as an Intel Hex file:
Code:
sudo avrdude -F -e -p atmega328p -c arduino -b 115200 -P /dev/ttyACM0 -U flash:w:brewpi-arduino-uno-revc-0.2.12.hex:ithestraw0039
Active Member
I haven't tried running updateFirmware.py yet, doing that next, but here is the new output adding the :i
Edit: Running updateFirmware.py seems to have run without an issue.
Code:
pi@raspberrypi:~ $ sudo avrdude -F -e -p atmega328p -c arduino -b 115200 -P /dev/ttyACM0 -U flash:w:brewpi-arduino-uno-revc-0.2.12.hex:i
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x54
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x3a
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x7b
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x22
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x42
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x65
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x65
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x72
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x54
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x65
avrdude done. Thank you.Edit: Running updateFirmware.py seems to have run without an issue.
Last edited:
That suggests the BrewPi script was still running.
Excellent! That means when I fix the UI method, it will work.
- Status
