CraftBeerPi - Raspberry Pi Software

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
The RPi is powered via its microUSB header as normal, and that jumper at the southeast corner of the PiFace can be set to draw 5V from the RPi via the 26 pin header...

Cheers!
 
The RasPi will pass 5V to the PiFace using pins 2 & 4 of the Pi's GPIO header. All you need to do to bring 5V to the Output terminal on the PiFace is to shunt the jumper at JP3 (lower right corner) on the PiFace, connect the PiFace to the RasPi and power the RasPi through its MicroUSB connector - always the last connection you make. This will also provide the 5V needed to energize the coil(s) for the relay(s) on the PiFace. Power down the RasPi before connecting or disconnecting the PiFace or anything tied to it.
 
Gotcha! Thanks for the detailed explanation! It was super helpful!
Will I have to edit the code to interface with the piface, or will I be able to just copy the code as is?
 
Presuming we are discussing CBP, no need to modify or add code for the PiFace. For 1-wire support when using a PiFace, however, you will need to get to one of the 3.3V pins (1 or 17) for power, pin 7 for GPIO4 data (or use a script to choose another GPIO for 1-wire), and one of the many ground pins (6, 9, 14, 20, 25, 30, 34 or 39) of the GPIO header. You could do this by directly soldering leads to those three solder pads on the PiFace or build your own breakout board using a passthrough stackable header (extra tall pins) between the RasPi and the PiFace. This middle board would need traces connected to only three of the pins as described above and could carry those out to an interface, such as a 3.5mm stereo jack. Either way you would tie the 1-wire data line to the 3.3V power line with a 4.7k Ohm (4k7) pull-up resister.
 
Is it possible to set a start time so I could have my water at just the right temp when I get in from work?

Not a start time per se, but you can get it to delay when it ramps up the temp.

Set up "Wait" step- No kettle for how ever long before you want the kettle to come on, and then make the next step the HLT temp that you need. Set the first step for automatic. When the 6 hours (or whatever) is up, the kettle kicks on.
 
Right, if you don't have a pi face, you need two relays or ssrs to control pumps. Also...


Boards shipped via dhl this afternoon. Some weird Hangup with those guys.
 
Not a start time per se, but you can get it to delay when it ramps up the temp.

Set up "Wait" step- No kettle for how ever long before you want the kettle to come on, and then make the next step the HLT temp that you need. Set the first step for automatic. When the 6 hours (or whatever) is up, the kettle kicks on.

Ah yeah that makes sense, thanks
 
Here is my controller and wiring diagram. No shields at all, SSRs for the heaters and a relay board for the pumps.

I can email anyone a PDF or visio of the diagram if they want more detail.

As stated earlier, I do have one weird issue where the outlets are on until the software starts which I work around by leaving the 220V and 110V that power the heaters and pumps unplugged until software is started up.

Edit: Also of note, from the picture to the diagram, I added a separate power supply to run the SSRs and run it through the relay board. The SSRs weren't tripping directly of the GPIOs and I was worried about the level of electrical separation. The diagram is correct, the picture is outdated by one revision.

UMPN Detail.jpg


UMPN Wiring.JPG
 
Last edited:
As stated earlier, I do have one weird issue where the outlets are on until the software starts which I work around by leaving the 220V and 110V that power the heaters and pumps unplugged until software is started up.

Edit: Also of note, from the picture to the diagram, I added a separate power supply to run the SSRs and run it through the relay board. The SSRs weren't tripping directly of the GPIOs and I was worried about the level of electrical separation. The diagram is correct, the picture is outdated by one revision.

It looks like you wired the outlet relays to be normally closed (NC). Any particular reason you did that? It is probably the cause of your power up issue. Have you tried moving the wires for the outlets to the normally open (NO) terminals?

Why are you triggering the SSRs with relays? Doesn't that defeat the purpose of the SSR? Why not try a NPN transitor on your breadboard, similar to what terragady and SHvB use? Most likely the reason the SSR wouldn't fire directly from the Pi is that you probably exceeded the current limits of the GPIO.
 
It looks like you wired the outlet relays to be normally closed (NC). Any particular reason you did that? It is probably the cause of your power up issue. Have you tried moving the wires for the outlets to the normally open (NO) terminals?

Why are you triggering the SSRs with relays? Doesn't that defeat the purpose of the SSR? Why not try a NPN transitor on your breadboard, similar to what terragady and SHvB use? Most likely the reason the SSR wouldn't fire directly from the Pi is that you probably exceeded the current limits of the GPIO.

I can wire the relays so that the load is powered in either the off or on state (NO or NC), but since the default for the RPi is off and the default of CBPi is on, my pumps and heaters are on as soon as I power the RPi until CBPi starts.

I have tried the solution earlier in the thread to reverse the operation of the relays, but that does not seem to have any effect. I have also tried changing the "hardware control type" from 1 to 0 and back. I'm not sure what this is designed to do, but it does not seem to affect the way the relays work.

I am triggering the SSRs with relays for 2 reasons. One is that as you stated, I must be over the current limit of the Pi, so I am using a separate power supply for the SSRs. The other is that it has been noted a lot earlier in this thread that running the SSRs off of the Pi directly didn't provide sufficient electrical separation and could fry the Pi. It does not defeat the purpose of the SSR at all as the purpose of the SSR is to switch the 220v (which has too much current for the relay board). The relay board is just providing switching to the power supply for the SSRs.
 
What happens if you disconnect the Pi from the Sainsmart and provide 5V power to only the relay board? Are your outlets on or off then when wired to NC? What about NO in that same scenario?
 
It does not defeat the purpose of the SSR at all as the purpose of the SSR is to switch the 220v (which has too much current for the relay board). The relay board is just providing switching to the power supply for the SSRs.

I thought the purpose of using a solid state relay (SSR) instead of a standard one was so that you eliminated mechanical contacts from the relay. This increases the speed of the relay and extends its life. This can be important when using PWM to vary the heat output of a resistive load, as most PIDs do and the PID mode of CBP does. Also just pointing out for the benefit of others who may be trying to follow along that there are simpler and cheaper ways to protect the Pi from the SSR, such as using a transistor with a resistor between the two.

Are you having the same issue with SSR going hot when you first power up, like you are having with the outlets? I suspect not because it looks like you wired those to the NO terminal of the relays. I'm tempted to purchase one of those boards to see if I can replicate and then help resolve your issue. Have enough other hobby projects where it could come in handy.
 
I have no problems with the Sainsmart modules controlled by the Pi.

I remove the JD-VCC to VCC jumper. Connect JD-VCC to 5V and VCC to 3.3V. then hook up IN1 and IN2 to GPIO pins and GND to GND.

My relays do not come on at boot time.

My software (not CraftBeerPi) turns the relays on by setting the GPIO low. Turns them off by setting GPIO high.
 
@ame:

Simple solution, good to know. Should work for CBP too as long as it doesn't force GPIO to active high within its own code, something to test later this weekend. Thanks!
 
I thought the purpose of using a solid state relay (SSR) instead of a standard one was so that you eliminated mechanical contacts from the relay. This increases the speed of the relay and extends its life. This can be important when using PWM to vary the heat output of a resistive load, as most PIDs do and the PID mode of CBP does. Also just pointing out for the benefit of others who may be trying to follow along that there are simpler and cheaper ways to protect the Pi from the SSR, such as using a transistor with a resistor between the two.

Are you having the same issue with SSR going hot when you first power up, like you are having with the outlets? I suspect not because it looks like you wired those to the NO terminal of the relays. I'm tempted to purchase one of those boards to see if I can replicate and then help resolve your issue. Have enough other hobby projects where it could come in handy.

That might be one reason for using SSRs, but my reasoning is purely that the relay board cannot handle the current that I have on the 220 side to run the heaters.

Since the SSRs are driven by the relay board, I have the same issues with them coming on until the CBPi software starts.

The major issue is that when the Pi starts, the relays are in one state. When CBPi starts, it reverses the state of all of the relays.

I will test some of the solutions below this weekend.
 
I have no problems with the Sainsmart modules controlled by the Pi.

I remove the JD-VCC to VCC jumper. Connect JD-VCC to 5V and VCC to 3.3V. then hook up IN1 and IN2 to GPIO pins and GND to GND.

My relays do not come on at boot time.

My software (not CraftBeerPi) turns the relays on by setting the GPIO low. Turns them off by setting GPIO high.

I will give this a shot this weekend.

Update: I tested this solution and it had no appreciable effect other than one of the SSRs (wired to IN5) no longer correctly switches with the relay is tripped.
 
Last edited:
To be clear about the behavior I am seeing:

Pi power-up:
  • All relays on the board are in "off" state
  • All loads powered since I have the relays wired to NC to give correct operation using the dashboard

CBPI software startup:
  • All relays immediately switched to "on" state
  • No loads powered

Software operation:
  • Buttons in the dashboard operate the devices correctly
  • Each button sets a relay to "off" and powers the load
  • Loads correctly powered by dashboard buttons

CBPi shutdown:
  • All relays on the board are switched to "off" state
  • All loads powered
 
To be clear about the behavior I am seeing:

Pi power-up:
  • All relays on the board are in "off" state
  • All loads powered since I have the relays wired to NC to give correct operation using the dashboard

CBPI software startup:
  • All relays immediately switched to "on" state
  • No loads powered

Software operation:
  • Buttons in the dashboard operate the devices correctly
  • Each button sets a relay to "off" and powers the load
  • Loads correctly powered by dashboard buttons

CBPi shutdown:
  • All relays on the board are switched to "off" state
  • All loads powered

Ok. Well it sounds like CBPi should be configured to use inverted logic to drive the outputs, and your loads wired to NO. That's how my BrewPi clone is configured, and in my software the output logic can be set to normal or inverted, to match the hardware that is used.
 
Ok, I looked at the CBPi source code, and it looks like the output logic is not configurable, i.e. when the software wants to turn a GPIO on it sets the pin high, and off is low. There needs to be an option to specify that "on" is 0 for some devices. The alternative is to use a transistor to invert the output, but that's more complex.
 
@Ph03n1X1:

Try switching your relays to GPIOs 9 thru 26 on the Pi and see if the relays start in their 'on' state. GPIOs 2 thru 8 default to a high pull up at power-on reset of the Pi. When the GPIOs are activated as outputs by software, they drop low until commanded high. This could explain the 'off' state on power up (Pi high connected to Sainsmart input high = relay off) and then 'on' when the software starts (Pi low connected to Sainsmart input high = relay on). Simply inverting the GPIO active level through Wiring Pi won't change the default power-on state. You should also connect Vcc on the relay board to 3V3 on the Pi and JD-Vcc to 5V on the Pi as Ame does or you risk damaging the GPIO on your Pi.
 
[...]You should also connect Vcc on the relay board to 3V3 on the Pi and JD-Vcc to 5V on the Pi as Ame does or you risk damaging the GPIO on your Pi.

While it's a good idea to run the optocouplers on the relay module at the same voltage as the RPi for the sake of coherency, they can only sink current and can't harm the RPi if one ran the entire relay module on 5V...

Cheers!
 
@Ph03n1X1:

Try switching your relays to GPIOs 9 thru 26 on the Pi and see if the relays start in their 'on' state. GPIOs 2 thru 8 default to a high pull up at power-on reset of the Pi. When the GPIOs are activated as outputs by software, they drop low until commanded high. This could explain the 'off' state on power up (Pi high connected to Sainsmart input high = relay off) and then 'on' when the software starts (Pi low connected to Sainsmart input high = relay on). Simply inverting the GPIO active level through Wiring Pi won't change the default power-on state. You should also connect Vcc on the relay board to 3V3 on the Pi and JD-Vcc to 5V on the Pi as Ame does or you risk damaging the GPIO on your Pi.

I'll try to give this a shot tonight. Thanks!
 
@SHvanBommel

Are there any boards left to purchase? Or is there a link to buy a board? I just stumbled across this thread and want to start a build.
 
Welp, looks like I was too late... Anyone else planning on printing some more boards?
 
Back
Top