Is this the 20x4 white-on-blue LCD display with the I2C backpack, like this?
Cheers!
This is the one that I bought off of amazon
I have a second one I could try. I should do that.
Last edited by a moderator:
Native ESP8266 BrewPi Firmware - WiFi BrewPi, no Arduino needed!
- Thread starter Thorrak
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
This is the one that I bought off of amazon
I have a second one I could try. I should do that.
No, you're not missing something. The RJ11 plugs are supposed to be used with flat telephone cable. The wires in that are quite thin and slide into the housing easily.
The pre-wired temperature sensors have a slightly meatier cable.
You have two choices. One is to shave a little of the insulation from each wire until it fits. The other is to use another connector.
If have used both approaches. Most recently I used a 3.5mm stereo plug on the sensor cable and made a pigtail adapter from a 3.5mm stereo socket to an RJ 11 plug.
Thanks. I will give it a shot and see how it work out. Will try and post pics.
Bigdaddyale
Well-Known Member
I never thought about installing it in a wall -that might be cool if you use Raspberry Pints.
Kinda - I plan on building an All in One brewing control panel stand that holds Brew Pi,CraftBeer Pi, my march pump and Therminator chiller.Still working on the design
Bigdaddyale
Well-Known Member
This seems like the classic LCD scrambling problem.
Last edited by a moderator:
Ah yes. Did a little googling with that info and it might be related to the mechanical relays. Going to switch to solid state relay. Thanks.
That's where I was leading him
It's hardly a revelation, but it confirms what I've been saying all along: these screens are susceptible to voltage noise, which has nothing to do with the various "shield" designs...
Cheers!
That's where I was leading him
It's hardly a revelation, but it confirms what I've been saying all along: these screens are susceptible to voltage noise, which has nothing to do with the various "shield" designs...
Cheers!
Hmm. Whats the best way to handle that, though? Capacitors on the +5/+3.3 lines?
So I feel like I'm 95% there.
I've connected both DS18B20 to a Cat5e cable. I decided that I needed to make myself some standard so I don't mess this up since I'm looking to use this same setup for my Strangebrew Elsinore panel. I used the pair of orange as 3.3v, the pair of blue as Data, and the pair of brown as Ground. Green pair is unused. I shoved the 4.7kOhm resistor in the push down RJ45 jack.
I've also got everything wired up right on the high side. I have three LED lights (Power - White, Heat - Red, Cool - Blue) with a toggle switch to shut the lights off completely if I want.
I ripped apart an old cell phone charger and took the circuitry out and it's in the enclosure to power the ESP8266.
My low side (5v & 3.3v) connections are correct as far as I can tell (Pin Vin = 5v and Pin 3.3v = 3.3v)...
BUT when I power everything on, the Sainsmart board crackles, both lights flash, and then shut down. The ESP8266 I believe shuts down as well when this happens, unless I press the reset button. I can push the reset button and it'll keep crackling (and this happens without the high side 120v power connected).
I disconnected the 5v lead from the Sainsmart board, restarted everything (RPi, ESP8266) and after a couple seconds connected the 5v lead, and it works. I go into BrewPi, tell the controller that pins D3 and D4 aren't inverted (testing their wiring) and the relay board switches them on without issue. I press the reset button on the ESP8266 and it crackles and shuts down...
So I feel confident in my wiring, but I'm a bit concerned with my Sainsmart board. I'm going to bring it down and test it out with the Arduino again, and if that doesn't work, I'm a bit worried about the ESP8266...
Hopefully this post (while a bit long) is both helpful for others planning a build, and gives enough info that someone more versed than I am can help me get across this finish line. Cheers!
I've connected both DS18B20 to a Cat5e cable. I decided that I needed to make myself some standard so I don't mess this up since I'm looking to use this same setup for my Strangebrew Elsinore panel. I used the pair of orange as 3.3v, the pair of blue as Data, and the pair of brown as Ground. Green pair is unused. I shoved the 4.7kOhm resistor in the push down RJ45 jack.
I've also got everything wired up right on the high side. I have three LED lights (Power - White, Heat - Red, Cool - Blue) with a toggle switch to shut the lights off completely if I want.
I ripped apart an old cell phone charger and took the circuitry out and it's in the enclosure to power the ESP8266.
My low side (5v & 3.3v) connections are correct as far as I can tell (Pin Vin = 5v and Pin 3.3v = 3.3v)...
BUT when I power everything on, the Sainsmart board crackles, both lights flash, and then shut down. The ESP8266 I believe shuts down as well when this happens, unless I press the reset button. I can push the reset button and it'll keep crackling (and this happens without the high side 120v power connected).
I disconnected the 5v lead from the Sainsmart board, restarted everything (RPi, ESP8266) and after a couple seconds connected the 5v lead, and it works. I go into BrewPi, tell the controller that pins D3 and D4 aren't inverted (testing their wiring) and the relay board switches them on without issue. I press the reset button on the ESP8266 and it crackles and shuts down...
So I feel confident in my wiring, but I'm a bit concerned with my Sainsmart board. I'm going to bring it down and test it out with the Arduino again, and if that doesn't work, I'm a bit worried about the ESP8266...
Hopefully this post (while a bit long) is both helpful for others planning a build, and gives enough info that someone more versed than I am can help me get across this finish line. Cheers!
What are you doing with the jumper that's on the board?
That was my suggestion, but nobody's tried it AFAIK.
Ah, you probably need to remove the jumper and connect 5V to the relay coil (JD-VCC) and 3.3V to the optoisolator (VCC).
Trying it right now, no popping when powered on, but the the relays won't activate. I tried reversing your suggesting with 5v on VCC and 3.3v on JD-VCC, and the heater relay seems to work fine, but the cooler relay doesn't seem to actually make the switch. The boards specs are for 5v all around...
I've also tried using a couple low-ohm resistors on the 5v lead to limit the voltage slightly but it doesn't seem to help either.
You must have 5V on JD-VCC. This powers the relay coil.
You don't want this to back-feed into the chip, because it runs at 3.3V, so remove the jumper. However, many people claim that the ESP8266 i/os are 5V tolerant.
The VCC line is a power supply for an optoisolator, but remember it's active low, i.e. the control pin must be low to turn on the relay.
You can test this by connecting 5V to JD-VCC and 3.3V to VCC (no jumper) and GND to GND. Leave the relay control pins disconnected from the ESP8266. Then ground the relay control pins to activate the relays.
If that doesn't work then probably you are on the edge of the voltage supply for the optoisolator. This is caused by the indicator LED in series with the optoisolator dropping too much voltage and not allowing the optoisolator to operate. You can fix this in two ways. One is to reduce the on-board resistor value. The second is to short out the indicator LED. Maybe you only need to do this for the cooler relay. Swap the control lines to see.
If the ESP8266 i/os are 5V tolerant then you can connect 5V to VCC and you will be well above the optoisolator conducting threshold. But, that's what you had and it didn't work.
I also wonder why you had it working after you plugged it in after waiting a short time.
You can find a schematic and discussion here if it helps:
https://arduino-info.wikispaces.com/RelayIsolation
You don't want this to back-feed into the chip, because it runs at 3.3V, so remove the jumper. However, many people claim that the ESP8266 i/os are 5V tolerant.
The VCC line is a power supply for an optoisolator, but remember it's active low, i.e. the control pin must be low to turn on the relay.
You can test this by connecting 5V to JD-VCC and 3.3V to VCC (no jumper) and GND to GND. Leave the relay control pins disconnected from the ESP8266. Then ground the relay control pins to activate the relays.
If that doesn't work then probably you are on the edge of the voltage supply for the optoisolator. This is caused by the indicator LED in series with the optoisolator dropping too much voltage and not allowing the optoisolator to operate. You can fix this in two ways. One is to reduce the on-board resistor value. The second is to short out the indicator LED. Maybe you only need to do this for the cooler relay. Swap the control lines to see.
If the ESP8266 i/os are 5V tolerant then you can connect 5V to VCC and you will be well above the optoisolator conducting threshold. But, that's what you had and it didn't work.
I also wonder why you had it working after you plugged it in after waiting a short time.
You can find a schematic and discussion here if it helps:
https://arduino-info.wikispaces.com/RelayIsolation
I did test it that way, running 5v to the JD-Vcc and 3.3v to Vcc. The LEDs on board light up, but dimly and the relays didn't trigger. I only reversed it because it was clear the only way to get the optoisolator to work was provide the 5v. With it reversed, I had the bright LEDs, but the relay coils clearly didn't have the voltage necessary to engage the contactor.
Yeah I'm aware that Low=On and High=Off with this relay board hence the "Inverted" tag in BrewPi. My thought as to why it worked is D3 and D4 are likely set low on a reset, and only go high when the firmware is initialized. Because of that, and the fact the relay is active with a low signal, both relays are likely activating momentarily and drawing too much current. By leaving the Vcc disconnected until after initialization, the D3 and D4 signal pins are high, and the current draw is minimized when connected. If this is the case, I'm a bit concerned that after a power outage, my compressor might receive a fraction of a second of power before going off, which I can't imagine is good.
I think today's test will be to bring the Arduino back, and see if it will power the relay board without issue. I think that will either rule out the ESP8266 or Relay.
Any other thoughts?
Yeah I'm aware that Low=On and High=Off with this relay board hence the "Inverted" tag in BrewPi. My thought as to why it worked is D3 and D4 are likely set low on a reset, and only go high when the firmware is initialized. Because of that, and the fact the relay is active with a low signal, both relays are likely activating momentarily and drawing too much current. By leaving the Vcc disconnected until after initialization, the D3 and D4 signal pins are high, and the current draw is minimized when connected. If this is the case, I'm a bit concerned that after a power outage, my compressor might receive a fraction of a second of power before going off, which I can't imagine is good.
I think today's test will be to bring the Arduino back, and see if it will power the relay board without issue. I think that will either rule out the ESP8266 or Relay.
Any other thoughts?
Shaving the insulation sounds ... what's the right word ... how would you describe sanding your man-bits with a random orbit sander? That word would apply here.
The stereo jack pigtail sounds like a good idea. How exactly are you wiring that? Which wire to where? Ground on the sleeve, data on the ring, Vcc on the tip? Which side gets which end of the plug?
This might be a good time to ask how folks are using the wiring in the phone cables too so that I might not have to do this again. I am assuming that folks would use:
- Red - Vcc
- Black - Ground
- Yellow - Data
I used stereo jacks (1/4" ones) for my PT100 thermocouples on my current setup. Doesn't really matter which way you wire it up, just make sure that you standardize it. Write it down, refer to it frequently, and you won't mess up. Your Ground/Data/Vcc -> Sleeve/Ring/Tip seems like a good way to wire it since you'll never apply 5v to the Data directly.
If I went with telephone wire, I'd probably do Red-Red, Yellow-Yellow, Black-Black, and ignore green. Easier to remember that way.
If I went with telephone wire, I'd probably do Red-Red, Yellow-Yellow, Black-Black, and ignore green. Easier to remember that way.
Shaving the insulation sounds ... what's the right word ... how would you describe sanding your man-bits with a random orbit sander? That word would apply here.
The stereo jack pigtail sounds like a good idea. How exactly are you wiring that? Which wire to where? Ground on the sleeve, data on the ring, Vcc on the tip? Which side gets which end of the plug?
This might be a good time to ask how folks are using the wiring in the phone cables too so that I might not have to do this again. I am assuming that folks would use:
Mostly I guess I'm interested in how @Thorrak is doing this part since he'll be doing the boards (so I don't have to re-do them all,) but I'm curious if anyone chose anything different.
- Red - Vcc
- Black - Ground
- Yellow - Data
@ame actually sent over some documents when I asked him the same question -- apparently there's a defacto standard that people have been using:
https://datasheets.maximintegrated.com/en/ds/DS9097U-DS9097U-S09.pdf
Basically, it's:
Door - Yellow (see note below)
Gnd - Green
Data - Red
3v3 - Black
Yes - this means that we are not running the sensors in parasite mode.
On the door sensor - Again, stole the idea from @ame - Given that this uses RJ-11, you can just hook up telephone jack splitters to wire up multiple sensors. If you save one jack & break out the wires, you can use it to wire up your door sensor and save yourself additional wires coming out of your fermenter.
Ha, thanks. Yes, I looked at all the standards available and picked one I liked.
For the 3.5mm plugs I liked this one:
https://openenergymonitor.org/emon/buildingblocks/DS18B20-temperature-sensing
For the 3.5mm plugs I liked this one:
https://openenergymonitor.org/emon/buildingblocks/DS18B20-temperature-sensing
I just thought, if I disconnect the signal wires, there's shouldn't be a path to ground for the voltage and it shouldn't try turning on both relays on restart. If I connect the jumper, attach Vcc and Gnd, and reset the board, and I still get the popping noise, I've probably got issues on the board.
Just another test to do later today.
Okay so I need to do some reflective listening on that one. This means that my sensor to phone cord connections will look like this?
Code:
Sensor <-> RJ-11
-----------------------
Red (Vcc) <-> Black
Black (Gnd) <-> Green
Yellow (Data) <-> Red... and then the door will be Yellow grounding to Green on the phone cable, right?
So an update, I'm starting to think there's something in the code in play with my relay troubles...
With power off, I did the following two scenarios, thinking that the initializing status of the ESP8266 pins D3 and D4 were starting Low before turning High:
and
This would (should) give me the two extreme case scenarios for the relay board, having both relay coils do nothing in scenario 1, and both engage in scenario 2. Well lo and behold, neither one of these situations shut the board down with the pop.
Thoughts? Is there a different initialization for other GPIO pins on the dev board? Could the firmware be modified to use D0 and D1 or is there something preventing this? And hey Thorrak, not looking to get you to start writing up a million different versions of the firmware, just trying to learn the board too!
With power off, I did the following two scenarios, thinking that the initializing status of the ESP8266 pins D3 and D4 were starting Low before turning High:
Code:
Relay Vcc -> Vin 5v
Relay In1 -> 3.3v
Relay In2 -> 3.3v
Relay Gnd -> Gnd
Code:
Relay Vcc -> Vin 5v
Relay In1 -> Gnd
Relay In2 -> Gnd
Relay Gnd -> GndThis would (should) give me the two extreme case scenarios for the relay board, having both relay coils do nothing in scenario 1, and both engage in scenario 2. Well lo and behold, neither one of these situations shut the board down with the pop.
Thoughts? Is there a different initialization for other GPIO pins on the dev board? Could the firmware be modified to use D0 and D1 or is there something preventing this? And hey Thorrak, not looking to get you to start writing up a million different versions of the firmware, just trying to learn the board too!
Ok so looking back at the Github page, I think I found some answers
And I know you wrote this WeMOS which has a different pinout than the NodeMCU Dev Board...Yeah I'm a bit at a loss at the moment
I did find this thread so I'm sending them a PM and I'm going to try and use a ULN2003 darlington array to try and isolate it a bit more...will report back....
Code:
D1 - I2C SCL
D2 - I2C SDA
D3 - Cool
D4 - Heat
D5 - Door
D6 - OneWire Data
D7 - Buzzer (currently unsupported)And I know you wrote this WeMOS which has a different pinout than the NodeMCU Dev Board...Yeah I'm a bit at a loss at the moment
I did find this thread so I'm sending them a PM and I'm going to try and use a ULN2003 darlington array to try and isolate it a bit more...will report back....
This'll be my last post til I see a reply so this thread doesn't just become a wall of text from me
Darlington array is a near-success. I can control both relays with the pins without it tripping, and the only difference I need to make is making the switches not inverted in BrewPi since the array makes the signal a path to ground on high, and is effectively floating on low. My new issue is if the chip is reset, both pins are high for about 1-2 seconds, then switch back low when the firmware initializes. I'm just a bit concerned for my fridge's compressor in this situation.
Darlington array is a near-success. I can control both relays with the pins without it tripping, and the only difference I need to make is making the switches not inverted in BrewPi since the array makes the signal a path to ground on high, and is effectively floating on low. My new issue is if the chip is reset, both pins are high for about 1-2 seconds, then switch back low when the firmware initializes. I'm just a bit concerned for my fridge's compressor in this situation.
Not sure what polarity you're using but whichever state is "Off", add weak pull-ups or pull-downs to the two control signals to keep them in the "Off" state while the controller is spinning up...
Cheers!
Cheers!
Hi day_trippr,
According to the diagram of NodeMcu,
https://raw.githubusercontent.com/nodemcu/nodemcu-devkit/master/Documents/NODEMCU_DEVKIT_SCH.png
GPIO0(D3) GPIO2(D4) are pulled-up by 12k, is that good enough?
If I've followed this sub-thread correctly, your IO are as follows:
D1 - I2C SCL
D2 - I2C SDA
D3 - Cool
D4 - Heat
D5 - Door
D6 - OneWire Data
D7 - Buzzer (currently unsupported)
From the page you linked, it turns out the state of GPIO0 and GPIO2 (D3 and D4, respectively) are significant during boot, and both must be pulled high (they show 12K but 10K's would be fine).
Your down-stream implementation of D3 and D4 must account for that, so if your loads will be enabled if D3 and D4 are high at power-up (as required) you might consider sticking inverters in the circuits and going back to "Low = On" in BrewPi...
Cheers!
D1 - I2C SCL
D2 - I2C SDA
D3 - Cool
D4 - Heat
D5 - Door
D6 - OneWire Data
D7 - Buzzer (currently unsupported)
From the page you linked, it turns out the state of GPIO0 and GPIO2 (D3 and D4, respectively) are significant during boot, and both must be pulled high (they show 12K but 10K's would be fine).
Your down-stream implementation of D3 and D4 must account for that, so if your loads will be enabled if D3 and D4 are high at power-up (as required) you might consider sticking inverters in the circuits and going back to "Low = On" in BrewPi...
Cheers!
I just tried a 3.3k resistor and a 100 ohm resistor as pullup from 3.3v and didn't help.
I'm trying to learn how this all works, so bear with me a bit...since the 2 channel relay is on when the pin is set LOW, at boot, the pin being set HIGH would not cause the relay to turn on?
"should not", yes, definitely. The Sainsmart opto-isolator circuit require a low input to actuate the relay. I have at least five of the Sainsmart 2-channel relay modules running here and they do not turn on during boot, as their respective inputs do not go low until programming (BrewPi firmware running on an Arduino) tells them to...
Cheers!
For what it's worth, this is the schematic I'm using at the moment:
Below is what mine looks like.
From the top down:
Yellow (4) - Door
Green (3) - Ground
Red (2) - Data
Black (1) - 3v3
The colors aren't important - what is important is the pin order.
Yeah that's what I've been following from your instructables page, and it works in every situation except during the boot up of the ESP8266 because D3 and D4 seem to be pulled low at boot (or are initially inputs to check for flashing conditions?) before the void setup() gets them set as outputs and High.
Weird - I thought I avoided all the pins that had secondary functions or strange boot states. Hmm.
I hate to switch pin configuration, but D7/D8 instead perhaps? Hmm...
Would it be an issue that D7/D8 are a UART TX/RX Pair?
Edit: doesn't appear like it would
Seems like we are saying the same thing.
I get what you are saying about the colors, but they do conform to the USOC standard. At least in the US a guy should be able to count on those colors being as I said.
Talking about pin numbers ... you have those numbered from 1-4 but the jacks themselves have up to six positions. Technically these are numbered 2-5. If we're going to be exact I guess we need to refer to these as RJ14C (four position) rather than RJ11C (two position).
Not trying to be pedantic, just pointing out that there are standards and there are standards. It might make sense to make those distinctions, at least when in the context of making the boards where a guy needs to follow what you'd laid out.
(hope I'm not sounding grumpy, just tired and not feeling eloquent)
I think that's why I initially avoided them, but I vaguely recall seeing something about separate pins being used for the USB bridge when looking at the differences between NodeMCU (which doesn't expose them) and other ESP8266 implementations (some of which do).
Similar threads
