• Please visit and share your knowledge at our sister communities:
  • If you have not, please join our official Homebrewing Facebook Group!

    Homebrewing Facebook Group

BruControl: Brewery control & automation software

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Interestingly, I was able to get up to two of the probes working after reseating the connections however I didn't see anything really wrong with them to begin with and secondly it doesn't seem to ever work when I have all 4 plugged in so maybe it has more to do with how many are plugged in than reseating connections.

When I have 1 or 2 plugged in, it shows a reading but even then the reading keeps flipping between the normal reading and a -197F reading repeatedly. When anymore than 2 are plugged in, it shows no readings.

Any way to debug from the ESP32 level through brucontrol to see what the ESP is seeing?
 
One wire on the Unishield Grand Central:

I have the Dip Switch set for AREF to Pin 5.

I connect the Data to Pin 5, the GND to GND.

Do I use the 5 v Output on the Riser or the 3.3 v for VDD of the probe?
Bump
UNI GrandCentral (v45e+) Oakbarn Other Pins.png
 
Interestingly, I was able to get up to two of the probes working after reseating the connections however I didn't see anything really wrong with them to begin with and secondly it doesn't seem to ever work when I have all 4 plugged in so maybe it has more to do with how many are plugged in than reseating connections.

When I have 1 or 2 plugged in, it shows a reading but even then the reading keeps flipping between the normal reading and a -197F reading repeatedly. When anymore than 2 are plugged in, it shows no readings.

Any way to debug from the ESP32 level through brucontrol to see what the ESP is seeing?
The -197 tells me it's still a bad signal. Is the resistor the same one from before?

And you said you still have version of BC as before. Is that the same case for the ESP32? Same as before with same firmware?
 
Yes, same resistor, same card, same firmware.
My next thought after checking connections would be to replace the resistor if you have any spares on hand. Since you haven't updated BC or the firmware, their versions should be aligned (we are up to firmware v46 now, with an updated BC), so there shouldn't be an issue there.

After contacts and resistor, it may be worth testing on another ESP32, if you have another.
 
I answered my own question about using a DS18B20 (one wire probe) with a Grand Central.

Do you use the 3.3v out or the 5v out on the Unishield riser?

It does not matter. A DS18B20 VDD can be powered by either one on the riser or even an external Power supply in the range from 3.0 to 5.5 v. You must have a common ground between and power and the Unishield if you use an external Power Supply.

When I originally hooked up to the 3.3 volts, I could not get the probe to read at all.

After doing some googling on the web, I surmised that the VDD could be separate and AREF tied to PIN 5 had nothing to do with the VDD Power.

I also read the schematic on the Bru Control website and it lead one to believe that the AREF needed to be tried to the Power for the VDD. It does not. If using an external Power Supply, it must share a ground with the interface.

The AREF does need to be tied with the on board power with a resistor. I have no idea how that is done on the Unishield for a Grand Central but it does not matter. You set it with a Dip Switch.
 
My next thought after checking connections would be to replace the resistor if you have any spares on hand. Since you haven't updated BC or the firmware, their versions should be aligned (we are up to firmware v46 now, with an updated BC), so there shouldn't be an issue there.

After contacts and resistor, it may be worth testing on another ESP32, if you have another.
I tried to connect my first one with to a Grand Central. I had hooked up one and then disconnected it. I reconnected using a different physical probe and got no joy on the temperature. I deleted the Element and then recreated it. It now works correctly. You might try to delete and add them back one at a time. You can use the CRTL C to copy the name, Delete the Element (noting the Port).. Add the Port using the same Port. Name it the same (use CTRL V to paste).
 
Sound great. Thanks for focusing the improvement about the brewery's control system. Again glad to learn about brucontrol and its interesting highlights. I think automated systems can help to produce quality beer.
 
One wire on the Unishield Grand Central:

I have the Dip Switch set for AREF to Pin 5.

I connect the Data to Pin 5, the GND to GND.

Do I use the 5 v Output on the Riser or the 3.3 v for VDD of the probe?
Sorry... just getting to these new posts...

AREF is not set to pin 5... it's set to 3.3V on the GC, and this setting is for Analog Inputs. There is no association to 1-wire.

Depending on your network connection (WiFi uses pin 5 so you can't), I'd suggest Pin 6 and use the Pin 6 pullup resistor dip switch build in to the UniShield. Use 3.3V for the probe since the micro is 3.3V. You should never apply 5V to any pins as it will (likely) damage the chip.
 
Last edited:
I have had this happen for YEARS and have asked for a watchdog or something to reset it... it even happens when plugged into a UPS...
Should the interface lock up and lose communication, how will you reset it? BC knows when an interface is disconnected, but what can it do then? I suppose you could use another interface to pull and reapply power via a relay.

I also suppose we could reset the interface if it loses connection to BruControl for a period of time, but then these things could be resetting constantly since the computer is MUCH more likely to go down. We could probably add a setting for this if this is something that you really want.

I'll still go on record to say the interfaces essentially never crash - any lockups are most likely power / EMI related.
 
Should the interface lock up and lose communication, how will you reset it? BC knows when an interface is disconnected, but what can it do then? I suppose you could use another interface to pull and reapply power via a relay.

I also suppose we could reset the interface if it loses connection to BruControl for a period of time, but then these things could be resetting constantly since the computer is MUCH more likely to go down. We could probably add a setting for this if this is something that you really want.

I'll still go on record to say the interfaces essentially never crash - any lockups are most likely power / EMI related.
I believe my issue is power related, though I can't find what the actual issue is given the capacitors and such that are part of the 110v to 5v/3.3v stepdowns. And it seems tied to when the pump kicks on, but I wouldn't expect it to cause much of a power drop.. possibly a spike though.

I plan to have a separate ESP32 relay board that will act as a smart power strip. If an interface is disconnected for other a minute, a global will be set, and Node-RED can then read that global and act on it (I already get a Pushover notification, and my Google Home lets me know there's an issue). The ESP32 can then switch that relay on and off to reset the interface. I might also have the separate ESP32 ping the interfaces and detect a freeze that way.
 
Likely an EMI spike. Does it only happen when the pump kicks on, or when it kicks off? Usually inductive loads (like relays, solenoids, and motors) induce a back-voltage when power is removed and their stored inductive potential is looking for a place to go.
 
Likely an EMI spike. Does it only happen when the pump kicks on, or when it kicks off? Usually inductive loads (like relays, solenoids, and motors) induce a back-voltage when power is removed and their stored inductive potential is looking for a place to go.
Seemingly when it kicks on. I'm assuming this because the last drops I've had always occured at the peak of my upper temp offset. Doesn't seem to happen at other points along the temp graph. The point at which the pump would kick on is the only pattern.

Interestingly though, I haven't had it happen for almost a week now, even though my beers are currently cold crashed and the pump kicks on more frequently.
 
I'll add that I've left my heat wraps off since the room temp did a good job bring up the wort temp, so the only other electronic device is the 12v spunding valve solenoids, but I didn't see a correlation with it. I even had this happen when I reached final attenuation and there was no more CO2 being produced (i.e., no more solenoid triggering). Just odd.
 
Sorry... just getting to these new posts...

AREF is not set to pin 5... it's set to 3.3V on the GC, and this setting is for Analog Inputs. There is no association to 1-wire.

Depending on your network connection (WiFi uses pin 5 so you can't), I'd suggest Pin 6 and use the Pin 6 pullup resistor dip switch build in to the UniShield. Use 3.3V for the probe since the micro is 3.3V. You should never apply 5V to any pins as it will (likely) damage the chip.
You need to update the manual and schematics for the differences between the Grand Central, the ESP 32, and the Mega. You also need to update the product notes for the Unishield.
 
Happy to for what is missing!

With respect to AREF, it looks like the Product Note spells it out... let me know what's missing and we'll add it.

With respect to the which pin to use. you can use any of them from 0-15 for 1-wire. Since we included a built-in pull-up on pins 5 and 6, those are easier to wire. But since Pin 5 is not available when using a WiFi shield (per the Interface Wiring Map), then 6 is the better choice. If you want to use a different pin for 1-wire, you can but must supply your own pull-up. Also, there is a big note on page 5 which warns against providing any pin input voltage higher than the Vcc of the interface board. I know there is a lot to pull together here... there are so many combinations of interfaces and wirings, it can be tricky to figure it all out. But I'm happy to update documentation to make it clearer.
 
Oh! @Hannabrew try the above. I forgot that @oakbarn had an issue with devices a few weeks ago and this seemed to be the fix.

To follow up on this, it was as simple as a faulty power supply to the ESP32. I replaced the USB PS that I was using with a different one and now they all work great and no fluctuation in the readings.

Funny enough, it seems the distance the card was away from the nearest WAP had everything to do with how it behaved. When I was right next to a WAP it worked with the original PS but as soon as I moved it to where I wanted to use it it would start acting up...not powering any/some of the 1 wire probes and constant fluctuating of temps.

Glad it was a simple fix. Thanks for the assists.
 
Should the interface lock up and lose communication, how will you reset it? BC knows when an interface is disconnected, but what can it do then? I suppose you could use another interface to pull and reapply power via a relay.

I also suppose we could reset the interface if it loses connection to BruControl for a period of time, but then these things could be resetting constantly since the computer is MUCH more likely to go down. We could probably add a setting for this if this is something that you really want.

I'll still go on record to say the interfaces essentially never crash - any lockups are most likely power / EMI related.
Can there be a watchdog inside that if it does not hear from BC in 1/6/24 hours that it resets internally and sets a flag or something that can be in the log? I do not know if that is possible, but if being on a ups doesn't help it, I guess I could try a faraday cage, but that would kind of make the wifi useless...
 
Can I graph the output of a hysteresis element(0-1 or 0-255) along with the input? I would like to see a square wave showing when the element was on and off. The manual for v1.1 (1-1-2020) shows this on page 65, but I am not sure if "Fermenter Control: Value" is a hysteresis element. I have it set up but no line for the secondary value in my graph
 
Can there be a watchdog inside that if it does not hear from BC in 1/6/24 hours that it resets internally and sets a flag or something that can be in the log? I do not know if that is possible, but if being on a ups doesn't help it, I guess I could try a faraday cage, but that would kind of make the wifi useless...
Fer sure,
Can reset on a defineable time interval. But no way to log it on the interface side. Can set a flag, but maybe not a good idea as it would have to be done in EEPROM which should (technically) not be written to too many times.

Also keep in mind a reset wouldn’t happen if the microcontroller crashes, which it should never do assuming external influences are nominal.

Let’s try it and see what happens…
 
Also when you say “being on a ups doesn’t help”, what do you mean?
I have multiple ESP32's in a AC-USB adapter plugged into 2 different Cyberpower 375VA UPS units, one has a Cisco 2960L 24 port switch also plugged in and the other has a Pi Zero W also plugged in via a similar adapter... both experience hanging every few months, but not at the same time.
edit: for logging, something like a flag that the ESP sends out every time it is reset? or is this already there?
 
Those USB adapters are likely not industrial-level performers. Try using a legit switching power supply.

Regarding the flag… Sending out to where? If it’s disconnected from BruControl, how will it send anything?
 
When it does, in fact, reconnect to BruControl.

legit switching power supply not exactly a compatible form factor and kind of defeats the purpose of a a remote probe in a small waterproof box... I will try a small capacitor on the ESP, but not sure if the pins can have access to the right portion of the circuit when powered by USB cable.
 
Last edited:
Understood... but we can't expect a cheap adapter which was made to charge a phone to have 100% power reliability.

I know an N of 1 is not a good example, but my Feather M0 with good power supply and LiPo pack connected to control my fermenter and dispenser has been running for 5 years straight, and has never failed (other than when the LiPo swelled up and died). Good power is the #1 key to microcontroller reliability.
 
Understood... but we can't expect a cheap adapter which was made to charge a phone to have 100% power reliability.

I know an N of 1 is not a good example, but my Feather M0 with good power supply and LiPo pack connected to control my fermenter and dispenser has been running for 5 years straight, and has never failed (other than when the LiPo swelled up and died). Good power is the #1 key to microcontroller reliability.
I bought one of those feather things, and it died within a few months and they are expensive... I have yet to fry an ESP32, but I have fried 1 of 2 dozen SonOff Dual R2, I wish I had a way to do more I/O with the new Dual R3 and R3 lite... they are awesome.. Itead wanted $30k to do custom tho....
 
When it does, in fact, reconnect to BruControl.

I'm still struggling with the value. When it connects, what will that convey... "I was disconnected but now I'm connected, and while I was disconnected I reset myself"?

We'll definitely add the auto reset option... just not sure the juice is worth the squeeze on the reporting part.
 
Can I graph the output of a hysteresis element(0-1 or 0-255) along with the input? I would like to see a square wave showing when the element was on and off. The manual for v1.1 (1-1-2020) shows this on page 65, but I am not sure if "Fermenter Control: Value" is a hysteresis element. I have it set up but no line for the secondary value in my graph
bump... trying to display on a graph when a hysteresis element was on. Is it possible and I am doing something wrong? I have tried auto and manual, no graph trace for the hysteresis element output. I have this hooked up to a commercial TDD-4 kegerator, and I want to see when the interface is on but the kegerator internal thermostat is off.
1664468126123.png
 
Back
Top