Native Python BrewPi controller

[ame]

I believe it was because the home directory was not empty. I went back to the BrewPI instructions to create the fuscus user using /dev/nul as the skeleton home directory:

sudo useradd -m -k /dev/null -G www-data,dialout brewpi

Not sure whether it needed to be a member of the groups www-data,dialout brewpi but I figured it would not hurt. Anyway, when I did that I was able to pull the repository. Now I am having the following issue/errors:

Using config file 'fuscus.ini'
Using calibration file 'calibrate.ini'
Network port: 25518 (not implemented)
No rotary encoder specified.
No LCD module specified.
Hot relay on pin 16 (inverted)
Cold relay on pin 18 (inverted)
Fridge sensor : 28-0015230d74ee
Beer sensor   : 28-00152d139cee
Ambient sensor: None
No door switch.
lcd object 6 x 20 created
Exception in thread Thread-4:
Traceback (most recent call last):
  File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
    self.run()
  File "/home/fuscus/fuscus/DS18B20.py", line 119, in run
    self.temperature = temperature + self.calibrationOffset
TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'

Traceback (most recent call last):
  File "/home/fuscus/fuscus/fuscus.py", line 37, in <module>
    import ui
  File "/home/fuscus/fuscus/ui.py", line 23, in <module>
    import displayLCD as display
  File "/home/fuscus/fuscus/displayLCD.py", line 25, in <module>
    from constants import *
  File "/home/fuscus/fuscus/constants.py", line 200, in <module>
    tempControl.fridgeSensor.calibrationOffset = calibrate['offset'].getfloat(ID_fridge,0.0)
NameError: name 'calibrate' is not defined

I suspect it's because the calibration code is there now and I don't have calibration.ini set up? I am not sure of the syntax of calibration.ini but I'll wing it and see what happens.

ETA: There is a calibrate.sample.ini that I copied in and edited. Still getting a couple of errors:

Using config file 'fuscus.ini'
Using calibration file 'calibrate.ini'
Network port: 25518 (not implemented)
No rotary encoder specified.
No LCD module specified.
Hot relay on pin 16 (inverted)
Cold relay on pin 18 (inverted)
Fridge sensor : 28-0015230d74ee
Beer sensor   : 28-00152d139cee
Ambient sensor: None
No door switch.
lcd object 6 x 20 created
Exception in thread Thread-4:
Traceback (most recent call last):
  File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
    self.run()
  File "/home/fuscus/fuscus/DS18B20.py", line 119, in run
    self.temperature = temperature + self.calibrationOffset
TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'

Traceback (most recent call last):
  File "/home/fuscus/fuscus/fuscus.py", line 37, in <module>
    import ui
  File "/home/fuscus/fuscus/ui.py", line 23, in <module>
    import displayLCD as display
  File "/home/fuscus/fuscus/displayLCD.py", line 25, in <module>
    from constants import *
  File "/home/fuscus/fuscus/constants.py", line 200, in <module>
    tempControl.fridgeSensor.calibrationOffset = calibrate['offset'].getfloat(ID_fridge,0.0)
NameError: name 'calibrate' is not defined

This is a bug. Sorry. If there is no calibration value for a particular sensor it's supposed to default to zero. Looks like I didn't catch that properly. Sorry.

 

[LBussy]

Well, I don't get a /dev/fuscus I assume because of that error with 'calibrate' not being defined. I did copy/create the INI file but I still get the error I show above. The sensors are there and registering correctly however.

Should I put something other than 0.0 in as calibration values?

 

[ame]

Right. /dev/fuscus appears when the code is running. Since it didn't start properly the port was not created.

The calibration code has a bug. I haven't looked for it yet, so I can't suggest a workaround at the moment. Sorry.

 

[Thorrak]

Well, I don't get a /dev/fuscus I assume because of that error with 'calibrate' not being defined. I did copy/create the INI file but I still get the error I show above. The sensors are there and registering correctly however.

Should I put something other than 0.0 in as calibration values?

Give it another day or so - there appears to have been a bug introduced in the mash-up between the calibration method I was working on and the improved version that ame implemented.

Once fully implemented, calibration will default to 0.0. If you want to calibrate, read the note in the "notes.md" file.

The calibration code has a bug. I haven't looked for it yet, so I can't suggest a workaround at the moment. Sorry.

I took a look just now, and this should be fixed by the last pull request I sent through.

 

[LBussy]

Okay I can wait.

I just want to be clear - I get the error in the second clip even if I have a calibration.ini with an entry for each probe.

Like I said I can wait, I just want everyone to be on the same sheet of music.

 

[ame]

The calibration problem should be fixed in the version I uploaded last night, if you'd like to try it.

Thank you for reporting the problem you had before, and sorry it happened.

 

[LBussy]

Verified. Did a fresh 'git pull origin master' and now I have a functioning python BrewPi... at least with temp control disabled. I'll do some more monkeying around and see what else I can break.

 

[ame]

Verified. Did a fresh 'git pull origin master' and now I have a functioning python BrewPi... at least with temp control disabled. I'll do some more monkeying around and see what else I can break.

Great! Thanks for trying the code. You might not break anything. It might be pre-broken by me.

Please report back if you find something, or if you found the installation notes missed something.

 

[LBussy]

When I go to view devices it just sits there and spins. Not sure if that's a BrewPi thing or a fuscus thing. It acts like it doesn't understand the sensors I have (they are different than the ones hooked to my Arduino) and won't configure them.

I suspect there's a config I need to manually edit somewhere, still poking at it.

 

[ame]

Yup. Devices are configured in fuscus.ini

My software will ignore the request for the current configuration and so the maintenance tab will wait forever.

 

[ame]

You can also run testTempSensors.py to check that your sensors are accessible.

 

[ame]

For the purposes of scientific accuracy I have to report a failure. About two days ago I logged in to the Pi that was controlling the fermenter. I wanted to copy the data off it and prepare to upgrade. I managed to do a couple of things, but then certain commands stopped responding. Generally this means SD card corruption, so I issued a reboot, which did not respond.

The data logging stopped. The web server stopped. But the temperature control software kept running (probably because it was in RAM and didn't need to read or write the SD card). So I left it going.

This was a mistake. This morning I saw that it had crashed last night with the fan running, which cooled the beer. I don't expect it cooled a lot, maybe a few degrees, but I didn't have time to do anything before I had to leave the house.

Fortunately, this brew is about done, so I'm not too worried. In general I understand the risks of running this software and I am happy that I can deal with the consequences. However, I am reporting it so that others can decide if it's worth it.

I have had fun working on the software, and it has been useful, but I still don't know if it's a good idea or not. Time will tell, so I'll keep going.

Incidentally, SD corruption is often due to the power supply (with the Pi, it's always the power supply). I might need to upgrade my $4 to something better. Maybe a $5 power supply.

 

[Thorrak]

Incidentally, SD corruption is often due to the power supply (with the Pi, it's always the power supply). I might need to upgrade my $4 to something better. Maybe a $5 power supply.

Oof. I was planning on attempting a $4.14 power supply with my Pi Zero this weekend in a desperate attempt to shrink the total footprint of a build. If anyone wants to set the over/under on how long it takes to either catch fire or stop working, I'll note the bets!

 

[ame]

I expect your $4.14 power supply to be 3.5% better than my $4 power supply. But if I buy a $5 power supply it is sure to be 25% better!!

Actually, if you are using a Pi Zero then you have a lot more headroom because the base level power consumption is less than a Pi 2. I think the culprit is the WiFi adapter. They seem to use a lot of current, and get quite warm.

Anyway, this one lasted through two brews (almost) so, that's $2 per brew. Have we reached the stage where the controlling hardware becomes a consumable item, like sterilising solution or bottle caps?

 

[ame]

It seems to be impossible to recover the earlier SD card that failed, nor is it possible to re-image it. Similarly, the SD card that failed yesterday is also quite dead. Luckily they are cheap, but only if I want to wait a few days to get a new one. The local mart has them for about 4x the price. I am stealing one from another project to get me going again (with the same power supply), and I'll order a $4.50 power supply which is from a reputable supplier. That'll be 12.5% better than what I have now.

It's always the power supply.

 

[ame]

Ok. Back in business.

I am using the latest (May 27) version of Jessie Lite. I noticed that raspi-config has a much easier option to turn on 1-wire support.

There is one recent change I am not happy about, and it concerns the state of the controller when the temperature control is off. I think there is a bug in the original Arduino code (or rather, an unintended, but benign, mode of operation). My original code fixed that, but recent changes, which are closer to the Arduino code, changed it back. I think I'll do the right thing, and not what the Arduino code does.

I think all the other changes are okay. And my beer is fine. It got stuck on cooling mode and probably dropped to about 15 degrees Celsius, but then during the day it crept up to about 18 degrees (23 litres of beer in an insulated box takes a while to change). The airlock was active when I came home. I have set it to 20 degrees again, and I'll take an SG reading at the weekend. I was hoping to bottle it this weekend, but if it's still going down I'll have to wait.

 

[ame]

I fixed the display issue. I definitely think it should display "Temp. control OFF" when the mode is "off". Displaying idling time make no sense, and someone else has pointed out in another thread that it counts up to 18 hours (I think) then stops.

I tidied the calibration code a bit. It now reports the offset at startup so you can see if there is an offset, and what it is.

 

[joebob296]

Well for the life of me I cannot update my version of fuscus. I've tried all the aforementioned git commands but to no avail. I think I might just have to start from scratch....well it says I'm updated when I run Sudo git checkout origin/master but my fuscus file did not change and I can not find the calibration either.

I run all of the git commands from the user fuscus right?

 

[ame]

Sorry to hear it's not going well. There's no need to use sudo with the git commands. And nowhere in my instructions does it say to run "git checkout origin/master".

By all means start again. It would clear up any lingering old files or misconfiguration.

You could delete the fuscus directory from the fuscus user and then start again from note 12. Or you could re-image Raspbian onto the SD card and start from the very beginning again.

Note that the May 27 version of Jessie Lite has an easier way to turn on 1-wire support, so step 4 is not needed. You'll see it in raspi-config.

 

[joebob296]

Sorry to hear it's not going well. There's no need to use sudo with the git commands.

If I don't use Sudo it says permission denied

And nowhere in my instructions does it say to run "git checkout origin/master".

I was following Thorrak commands. I also tried yours but I couldn't get it to work. I'm sure I'm doing something wrong I've never used github.

You could delete the fuscus directory from the fuscus user and then start again from note 12.

I will probably do this.

 

[joebob296]

Ok, so I got the latest version of Github downloaded and installed. It is working and logging temperature, Fahrenheit was on by default. However, I am getting an error in the LCD screen in the top left. It says: Could not receive version from controller, please reprogram your controller. I did not have this error with the first version of the code. How can I correct this error?

Edit: I restarted the web server and it went away. All is well.

 

[ame]

Glad to hear it. Are you using the calibration function?

I noticed that my LCD contrast was wrong yesterday. The screen was darker than it was originally, which is odd, because it's set by software. I took this to mean that my power supply was fading, which I already knew due to the SD card corruption.

I expect my problem is due to using the tiny plug-in phone chargers. The one I have is rated at 2.1A, but clearly it is unsustainable. So I bought one of these (approximately $7):
http://comsmart.co.kr/cmart/shop/item.php?it_id=10759

It is physically bigger and more robust, and more suited to continuous operation. I chopped off the cable at about 20cm and soldered on a micro USB plug. One of these:
http://www.dx.com/p/diy-90-degree-angle-micro-usb-male-plug-adapters-black-10-pcs-363228

That was a bit tricky as the plugs are tiny, but it's done. Another cause of voltage drop is thin wires in the USB cable. That's definitely a non-issue with the new power supply. I had previously used one of these:
http://www.dx.com/p/cy-u2-204-u2-20...-usb-up-down-90-angled-cable-30cm-2pcs-409509

It allows the cable to exit the Pi upwards, which fits more neatly into the box. The cable doesn't look too anaemic, but I don't know what's inside, and now it's irrelevant. The new cable exits sideways, away from the HDMI socket.

I shut everything down, swapped the PSU, and rebooted. Now my LCD contrast is back as it was. I'll keep an eye out for that changing, and for filesystem corruption.

It might be better to hard-wire a power supply inside the enclosure, like this one:
http://www.dx.com/p/5v-2a-regulated-switching-power-supply-110-220v-414428

However, I like the fact that there is no exposed mains wiring inside my enclosure, so it's safe to open it while the system is running.

 

[joebob296]

Not using the calibration function yet. I will be measuring my sensors against my calibrated thermometer tomorrow.

I am using this power supply

http://www.amazon.com/gp/product/B019RNKHJE/?tag=skimlinks_replacement-20

And am using this for my main switch

http://www.amazon.com/gp/product/B00ME5YAPK/?tag=skimlinks_replacement-20

 

[Thorrak]

So I've had my test build on a Raspberry Pi 3 running for a few weeks now, but haven't yet had a chance to get a full build (including LCD, encoder, etc.) built just yet. The last part just came in today, so looking forward to getting this wired up and running!

 

[ame]

Exciting times ahead!

If you are using the Nokia display then watch out for the contrast adjustment parameter. It's buried in the code, but it probably ought to be in the .ini file.

If the contrast is not right then the screen will be blank and it looks like it's not working.

It ought to be possible to add support for any LCD module, such as the original 4x20 character display. It's just Python!

 

[joebob296]

This is more of a personal request. I only use 2 sensors, freezer and beer. Is there an easy way that I can stop room from rotating on to the lcd screen? I doubt I have the skills to do it myself, but if someone would point me in the right direction if appreciate it.

Also, it turns out that I did not need to calibrate my sensors, but I made an adjustment to test it. It has been working for almost a week now with no interruptions.

 

[ame]

This is more of a personal request. I only use 2 sensors, freezer and beer. Is there an easy way that I can stop room from rotating on to the lcd screen? I doubt I have the skills to do it myself, but if someone would point me in the right direction if appreciate it.

Also, it turns out that I did not need to calibrate my sensors, but I made an adjustment to test it. It has been working for almost a week now with no interruptions.

Hi there,

Really pleased to hear you have everything working. I guess you are using the Nokia LCD? Or maybe you are referring to the web page copy of the LCD contents. It doesn't matter.

Your request to not show the "Room" information if there is no ambient sensor present is not unreasonable. I just took a look at the code, and it's around line 182 in displayLCD.py. It looks like that is precisely what the code is supposed to do, but for some reason it's not working. I'll take a look at it. Thanks for mentioning it.

 

[ame]

...and there is a reminder on line 45 to tell me to fix things so that the display doesn't alternate if the ambient sensor is not present.

Thanks, past self, for leaving me a note. Sorry I didn't read it.

Anyway, it's not bug. It's an unimplemented feature.

 

[joebob296]

Thank you for the explanation, it's not a big deal, I can use it as is.

I have a question that's not directly related to brew Pi but more along the lines of Rpi. Using brew Pi we have 2 users, the default user and fuscus. I remotely log into my Rpi. I know I can ssh into fuscus, but how can I load the GUI of fuscus? Essentially I would like to be able to switch users from a remote location. However, whenever I hit log out I lose wifi.

 

[ame]

Not sure I understand what you want to do.

There are now three accounts on your Pi. 'pi', 'brewpi' and 'fuscus'.

If you are logging in locally you will type the username and password of the account and get a GUI screen. You can't do this remotely unless you have set up VNC or something like that.

Logging in to a text terminal via SSH is generally what you want.

Google around for VNC and see if that is what you are looking for.

 

[joebob296]

Not sure I understand what you want to do.

There are now three accounts on your Pi. 'pi', 'brewpi' and 'fuscus'.

If you are logging in locally you will type the username and password of the account and get a GUI screen. You can't do this remotely unless you have set up VNC or something like that.

Logging in to a text terminal via SSH is generally what you want.

Google around for VNC and see if that is what you are looking for.

In short I want to be able to completely switch users from a remote location.

I have VNC set up already and can access what ever user is logged in at the time, however whenever I log out from a remote location (to switch users in RPi) it disconnects from the Internet which in turn disconnects my remote connection. For example, normally I'm logged in as brewpi and can access it remotely through VNC already, but when I want to log into Pi user or fuscus to edit my fuscus.ini or calibrate files, or any files that fuscus ownes I would like to login as that user with a complete GUI of said user; I know I can do this by ssh into Pi or fuscus user but then I only have access to the terminal which works, but in some cases it would be easier to have access to the GUI of the user.

While it's possible to edit any files with ssh into X user, I am looking for a way to switch users as if I were at the desktop just logging out of X user and logging into Y user. Hopefully this makes more sense.

 

[ame]

Well it's completely beyond the scope of what we're doing here, but my Google-fu led me to this:
https://www.ibm.com/developerworks/library/os-multiuserloginsvnc/

A cursory glance makes it look like it might cover your use case, but then again, it might not.

 

[joebob296]

Well it's completely beyond the scope of what we're doing here, but my Google-fu led me to this:
https://www.ibm.com/developerworks/library/os-multiuserloginsvnc/

A cursory glance makes it look like it might cover your use case, but then again, it might not.

Yea, that's why I said it more an RPi issue. Thanks for the link I will read it and see what I can do.

 

[ame]

This is more of a personal request. I only use 2 sensors, freezer and beer. Is there an easy way that I can stop room from rotating on to the lcd screen? I doubt I have the skills to do it myself, but if someone would point me in the right direction if appreciate it.

Also, it turns out that I did not need to calibrate my sensors, but I made an adjustment to test it. It has been working for almost a week now with no interruptions.

Ok. The code was supposed to do that, but there was a bug. Sorry. I fixed it, so you're welcome to try the new code.

In case anyone else is interested, the alternating between room and fridge is set to 4 seconds. In the Arduino code it's 8 seconds. However, on the web mimic display it's longer because it doesn't update immediately.

 

[joebob296]

Thanks I will update to the new code soon. Hopefully I will have more luck then last time.

 

[ame]

Time for a new beer. I bottled the Muntons Smugglers Ale at the weekend. Actually, that was a week late. I took it out of the chamber last weekend and sat it on the bench ready for bottling, but the airlock was still bubbling, and the SG was still dropping. So I waited a while longer until it seemed to have stabilised.

All of my temperature sensors have RJ11 plugs on them, so it's simple enough to use a telephone cable extender to connect the beer sensor back into the chamber. That way I could monitor the temperature of the beer while it was out of the chamber. Ambient temperature was quite high at about 24 °C, so I hope it doesn't spoil the taste. I decided it would be okay as the bulk of fermentation is done early on, when the temperature is controlled.

So, now it's on to another Muntons kit. This time "Woodforde's Headcracker", brewed with Gervin GV12 Ale Yeast. The range for this yeast is about 14 °C to 21 °C, so I will set it to 17 °C for the fermentation period and put it to 21 °C for the diacetyl rest when it nears the target gravity.

OG was 1.064 and the target is less than 1.020.

As I wrote before, the Pi destroyed its second SD card, which I blame (again) on the PSU. It now has a new, meatier PSU and a new SD card. Its uptime is 9 days (while the Smugglers was finishing off), and I just selected "Start a new brew" from the web interface.

Cheers!

 

[Mikmonken]

Reply, if the yeast had fermented out that majority of the sugar the high temperature would probably not make too much of a difference. I suspect the use of an arduino is probably starting to justify itself a little as even if the RPI dies the arduino board keeps running.

 

[ame]

Reply, if the yeast had fermented out that majority of the sugar the high temperature would probably not make too much of a difference. I suspect the use of an arduino is probably starting to justify itself a little as even if the RPI dies the arduino board keeps running.

I expect you're right about the taste. In a couple of days I'll drink the dregs (which I bottled anyway) and get an idea of the flavour. The rest I'll leave for a few weeks.

Regarding the choice of using the Arduino or not, it's up to you. I am happy with my code and how it is behaving. If any problems crop up I will deal with them, but I realise that others might be reluctant to try the software while it is still new.

 

[LBussy]

If I were to NEED to depend on the software on a Pi, I would want to have an external process monitoring the health of the controller and restart it if necessary.

I mean, early on in the thread, ame conceded to the strengths of using the Arduino. It's what those things are for. Still I always wondered "what if" and so did ame apparently because here it is.

I have a very well-regulated desk these days with the Python version controlling one set of lamps and the Arduino version controlling another. I am building out a fermentation chamber and I believe when it's time the Arduino will be tapped for the duty, simply because I can run multiple "minions" via BT and one central Pi to control them all. That does not mean that this is not a worthwhile effort. Hacking for the sake of hacking is always worthwhile!

 

[ame]

The uptime for the Pi last time before the PSU flaked out was 41 days. My Pi media centre is usually up for months. There were reliability problems with early Pis, but that is no longer an issue.

I have tried to make the code "multi-chamber" compatible. You can specify an .ini file at startup which contains a different set of GPIOs for the relays and a different set of addresses for the temperature sensors. So, you can do multi-chamber by running several instances of the software on the same Pi.

However, with the Pi Zero being so cheap you could run everything on one of those (web server, data logger, controller) and just have one Pi Zero for each chamber. All on wifi, no BT required. No central controller required.