BruControl: Brewery control & automation software

[Hannabrew]

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?

 

[oakbarn]

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

 

[CDCTx]

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?

 

[Hannabrew]

Yes, same resistor, same card, same firmware.

 

[CDCTx]

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.

 

[oakbarn]

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.

 

[oakbarn]

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).

 

[CDCTx]

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.

 

[Mervin Lee]

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.

 

[BrunDog]

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.

 

[BrunDog]

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.

 

[CDCTx]

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.

 

[BrunDog]

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.

 

[CDCTx]

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.

 

[CDCTx]

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.

 

[oakbarn]

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.

 

[BrunDog]

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.

 

[Hannabrew]

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.

 

[clearwaterbrewer]

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...

 

[clearwaterbrewer]

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

 

[BrunDog]

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…

 

[BrunDog]

Also when you say “being on a ups doesn’t help”, what do you mean?

 

[clearwaterbrewer]

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?

 

[BrunDog]

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?

 

[clearwaterbrewer]

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.

 

[BrunDog]

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.

 

[clearwaterbrewer]

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....

 

[BrunDog]

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.

 

[clearwaterbrewer]

being a fellow Floridian, you know the thing about the quarter on top of the ice in the freezer? Sometimes it is good to know that you lost power.

 

[clearwaterbrewer]

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.

 

[BrunDog]

Dunno... this works. Dispenser Control is a hysteresis.

Is your Sonoff_5 Dout 12 a hysteresis? I see your Sonoff_7 Dout 12 is.

 

[clearwaterbrewer]

Dunno... this works. Dispenser Control is a hysteresis.

Is your Sonoff_5 Dout 12 a hysteresis? I see your Sonoff_7 Dout 12 is.

DOH!... my naming convention got me. Thank you! I was graphing the wrong element...

 

[CDCTx]

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.View attachment 782207

I have my cooling and heating hysteresis elements on a graph. Both are manually set to 0 for Min and 1 for Max. Your values otherwise look like mine.

 

[CDCTx]

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.

(Edit for anyone new to BC and reading this: this isn't an issue related to the BC software or firmware; it's an issue due to my setup and the external hardware. BC is fantastic and reliable; I just tinker a lot and like to learn new things.)

I have made a workaround to this issue. Recognizing that I should find the cause and address it while also recognizing that I'm not an electrical engineer, I grabbed three ESP-01S modules on Amazon that also came with their own relays.

I coded the ESP-01S in Arduino IDE to connect to my sub-WiFi network (the router has OpenWRT and Node-RED, and it acts as a server to my own keg scales, on-tap webpage with websocket for real-time scale data, etc.; basically, anything not BC). From there, it will wait for a UDP JSON message from Node-RED. When told to reset, the ESP-01S will switch the relay from NC to NO then back to NC.

The ESP-01S is powered by its own 110V-to-5V stepdown, so hopefully, whatever issues the main ESP32 module faces with power spikes, this device doesn't also face them.

I have the EN pin of my ESP32 module leading to the COM pin of the ESP-01S relay and a ground connection leading to the NO. When the ESP-01S makes the switch, the ESP32 is then reset.

I'm now debating if I shoule have Node-RED send the reset message if my BC-coded alarm triggers (thus setting a global that Node-RED reads) or have Node-RED ping the ESP32 device (the BC firmware one) then trigger the reset if the ping fails. I assume if the device locks up, it shouldn't return a ping, but I'm waiting for another lockup so I can test that.

Hopefully, I'll find the main cause of the occasional lock ups and just fix that, but until then, this seems like a viable way to keep my fermentations on track.

 

[CDCTx]

@BrunDog On my controller that doesn't have my aforementioned workaround solution yet, I just had a continued connection drop in BC, so I decided to see if that interface can be pinged (indicating if it locked up and can't handle those requests). I am fully able to ping the "dropped" interface, so I don't think it is locked up.

Looking at BC communications for that interface, it tries to reconnect, does so, sends the normal TX message, then pauses. It then says "Error Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host." For some reason, I don't see a log file for that device (there are active log files for other devices), so I can't see what it shows, but I assume it would show this same thing (though, seeing what happened before this point would have been good).

So I'm thinking, at least in this case, it's not a lockup issue. Restarting it (unplugging and plugging back in) makes it resume normal ops. Any thoughts on what that error means?

 

[clearwaterbrewer]

Is there a quick way to view the 1-wire hardware address? I am making a 5-sensor daisy chain on my bench, and really would like them in order... if I could use small jumpers to connect to my interface and reset it and get the hardware address, I could note it or even print it on a label like I used to do with CBPi, then set them in order and wire them up...

 

[BrunDog]

@BrunDog On my controller that doesn't have my aforementioned workaround solution yet, I just had a continued connection drop in BC, so I decided to see if that interface can be pinged (indicating if it locked up and can't handle those requests). I am fully able to ping the "dropped" interface, so I don't think it is locked up.

Looking at BC communications for that interface, it tries to reconnect, does so, sends the normal TX message, then pauses. It then says "Error Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host." For some reason, I don't see a log file for that device (there are active log files for other devices), so I can't see what it shows, but I assume it would show this same thing (though, seeing what happened before this point would have been good).

So I'm thinking, at least in this case, it's not a lockup issue. Restarting it (unplugging and plugging back in) makes it resume normal ops. Any thoughts on what that error means?

Sounds like the problem is on the computer end... do you have any active firewalls? Are you sure you don't have an IP address conflict?

 

[CDCTx]

Sounds like the problem is on the computer end... do you have any active firewalls? Are you sure you don't have an IP address conflict?

I've turned off all firewalls on my PC, and all my WiFi devices have reserved/static IPs. I do have occasional connection drops between my BC devices and PC that I do think is on my PC's end, so maybe that contributes to the issue of my fermenter devices completely dropping.

I'll stick with my resetter device plan for now then. Having a timer that resets and starts when a device drops has been a huge help. Thanks for having a look!

 

[BrunDog]

Any chance you could run some tests on a different computer or network? Is it "consumer" grade WiFi?

 

[CDCTx]

This is my only comp. And the router is consumer grade but on the higher end. The temporary drops aren't bothersome, just weird that the two RobotDyn ESP32 relay boards occasionally fail to come back up.