BruControl: Brewery control & automation software

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

 

[clearwaterbrewer]

it took many hours, but dug up my old CBPi3 boards and wiring harnesses and used them to get the hardware addresses... and printed them on some wraps to put on the probe leads... BruControl NEEDS this functionality....

 

[BrunDog]

Do you have any normal ESP32 Dev boards you can test side by side?

 

[BrunDog]

it took many hours, but dug up my old CBPi3 boards and wiring harnesses and used them to get the hardware addresses... and printed them on some wraps to put on the probe leads... BruControl NEEDS this functionality.... View attachment 784164

We can add a control code to show you the addresses of the indexed sensors. Not sure that helps you right now but it’s easy enough.

 

[CDCTx]

Do you have any normal ESP32 Dev boards you can test side by side?

I have two normal ones that sit on top of my fermenters for Tilt readings. They have occasional drops but always reconnect. I haven't had one completely drop and not come back online. They don't control anything, just take Bluetooth readings.

My keezer uses a Lilygo ESP32 relay module and same. Comes back online if the connection drops for a second. It only monitors the temps and turns on the keezer.

The two problematic ones are the RobotDyn relay boards, which monitor temp and pressure and control a pump, heat wrap, and spunding solenoid each. That's why I thought the complete drop (and seeming lockup) was an electrical feedback issue, since it has these devices connected.

 

[clearwaterbrewer]

We can add a control code to show you the addresses of the indexed sensors. Not sure that helps you right now but it’s easy enough.

I think that would be a great addition. I suggest hardware address, offset, and a readable value of temp(uncalibrated is OK)...

 

[BrunDog]

I think that would be a great addition. I suggest hardware address, offset, and a readable value of temp(uncalibrated is OK)...

Just need to keep in mind we're dealing with a microcontroller which has limited memory. If we abandon the MEGA today (in favor of ESP32, M0/M4 based cards, etc.), this gets a lot easier as they have much more memory. But I have a feeling that would piss off some people!

 

[clearwaterbrewer]

point taken... and I have not made the recent jump to the latest FW/SW anyway.. I will put a couple ESP32 unishields in the equipment budget to be prepared.

Might be a good time to announce an upcoming 'final edition' firmware for our beloved 256k mega. It can join my BCS462 on the shelf... I assume that ESP8266 would also forced into retirement but ESP8285(1MB) used in the sonoff dual R2 would be OK?

 

[BrunDog]

Flash and RAM are two different memories and both need be managed. The 46 FW reduced RAM needs quite a bit, buying some time there.

 

[Chokpish]

I know this has probably been covered a few times, but I need to ask: I just received my Unishield, and I intend to power it with my Meanwell 24 VDC 4 A pwr supply. Plan is to bring 24 VDC on pin VS, adjust the DC-DC converter's voltage to 5.0 then move Unishield pwr switch from VR only to VR- 5V.

Per the Unishield product note, the max input current = 3A. Can I proceed with my 4A pwr supply without damaging anything?

 

[BrunDog]

Yes, 24 VDC to VS and GND. No need to adjust as we ship at 5V and the switch set to 5V.

Also your current is available supply. It can be more than the needed amount, but not less. You’re good!

 

[Chokpish]

Perfect!!

 

[passedpawn]

Just need to keep in mind we're dealing with a microcontroller which has limited memory. If we abandon the MEGA today (in favor of ESP32, M0/M4 based cards, etc.), this gets a lot easier as they have much more memory. But I have a feeling that would piss off some people!

Rip off the bandaid! Arm for the win. M4 can rip.

 

[TenaCJed]

I would say provide a recommended path forward along with a guide for making the change away from MEGA, then set a date \ version change that would not longer support MEGA. Obviously if they do not update to that version then the MEGA continues to work.

I am currently on MEGA, as long as there is a good notification and a little help guide on making the change I personally would not have an issue with it. I do not know if there would be any major issues or changes that would need to be made with items like the RTD Amplifier board you offer, running analog flow meters, or controlling multiple electronic ball valves. I am going to assume there would not be, lol.

 

[BrunDog]

Part of the concern of abandoning the MEGA is there is really only one drop-in upgrade: The Adafruit Grand Central M4. I'm not sure how long they will offer/support it. It's also nearly 4x the price. So it could be a transition opportunity, for those who need that form factor. BUT, longer term, I'd like to abandon that form factor because it is fairly inefficient. It's also kinda a PITA that the connection pins are female and on top of the board. This makes integration a bit tricky (hence the UniShield's underslung type design).

Anyway, random musings... the MEGA isn't EoL for a while!

Edit: Actually the Due is a replacement too. We have support for it but haven't tested it in a while - would just need to do that.

 

[DonWMason]

I'm finally getting around to upgrading to 46D firmware. I previously had the 45O firmware running with the 7/31 updated BruControl and had fixed all my analog port #'s. With the 45O firmware, everything was 100% reliable.

After upgrading the MEGA2560 to 46D, none of my digital outputs seem reliable. A random number of the 24 relays I have DO ports connected to power on at startup, even though the BruControl device shows the state as being off. I usually have to click on each one twice to get it to synchronize back to the off state. Sometimes adjusting one DO, causes another DO to kick on. As I was typing this post, a valve just decided to change state. Very weird.

Any ideas?

 

[BrunDog]

Did you check the updated Interface Wiring Maps? The numbering system changed a bit, and you’ll need to use the new interface definitions in the BruControl application.

 

[DonWMason]

Did you check the updated Interface Wiring Maps? The numbering system changed a bit, and you’ll need to use the new interface definitions in the BruControl application.

I updated the Wiring Map selection on the interface in BruControl to "Ethernet_FW_v46" - should that be "Default" since the Interface Wiring Map for v46 shows "Default" below?

I also adjusted all the Analog ports to the new numbering. I compared my Ethernet wiring map from Feb to the current v46 one and there are a few changes outside of the analog ports but nothing that affects my wiring.

 

[BrunDog]

Also did you download the latest BC application? It will be the same version but has the Interface Definition files which matches the Interface Wiring Map.

You will want to use "Ethernet_FW_v46". Now, when you switch to this map, your existing elements will get erased, so we need to fool it by editing your configuration file. You can do that by closing BC, making a backup copy of your configuration file, then opening the configuration file with a text editor, and changing your interface's declared wiring map from Default to Ethernet_FW_v46. This will be in the between tags Wiring map, for example: WiringMap>Ethernet_FW_v46</WiringMap>

If that's not making sense, please feel free to email us your configuration file (it's in your Documents/BruControl file, with the name matching your selected configuration name, with the .brucfg extension.

Should v46 not work for you, you can drop down to 45Q, which uses the new map but with the old firmware code.

 

[BrunDog]

Small FYI... updated the Interface Wiring Maps document... removed the 'R' designation for RTD's CS pins... every R is possible on D pins, so no real need to have both. Simplifying things I hope.

 

[BrunDog]

I updated the Wiring Map selection on the interface in BruControl to "Ethernet_FW_v46" - should that be "Default" since the Interface Wiring Map for v46 shows "Default" below?

I also adjusted all the Analog ports to the new numbering. I compared my Ethernet wiring map from Feb to the current v46 one and there are a few changes outside of the analog ports but nothing that affects my wiring.

Hi Don. Trying to duplicate this... are you still having the problem with firmware v46D?