• 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.
FYI for anyone connecting to the ESP32 via Serial (USB)... IO15 should be tied to ground (ideally through a resistor of ~47k). This suppresses a power-on reset message that the ESP's operating system issues (which causes BC <-> interface communications to enter a miscommunication loop).

Thanks @VinceBrews for pointing out the issue! While this work-around isn't ideal, it will resolve the problem for those who aren't connecting to the ESP32 via Wi-Fi.
 
Even with nothing connected, they have the state "ON", so the pin must be low. That seems backwards given the open circuit nature of those GPIOs.

I'm measuring it with a Fluke DMM, so that has an input impedance of 10M which shouldn't really effect the pin voltage assuming a pull up of 10s of K ohms.

OK, so it looks like there was indeed an error in the FW. Minor typo yielded the result of making the pullup get set and them immediately reset. Odd thing (but explicable) is this behavior did not exhibit on other micro-controllers. We'll get a new firmware uploaded (will be 45B). Apologies for the headache and thank you for pointing it out!

Edit: FW updated.
Edit again: Please do not use this for serial (USB) connections - use 45C once available.
 
Last edited:
When looking at the device log files, what does '!' designate? For instance, I have a slightly problematic ESP32 for fermentation that disconnects from time to time and tends to drop the 1-wire temp when it does so.

Here is a log sample from this morning:

09:00:31.539: Error: No device response
09:00:31.761: Disconnected
09:00:32.815: Connected
09:00:32.816: Tx: /2/27/32/12/34!220,15,3!200,10,0,1!25,5,200,4820,4870,300,0!26,5,200,3500,3410,30,0!39,8,500,40
09:00:32.825: Rx: /#/#/#/#/#!220,15,3!200,10,#,#!25,5,#,#,#,#,#!26,5,#,#,#,#,#!39,8,500,40
09:00:35.826: Tx: ?200?25?26?39
09:00:35.893: Rx: ?#?#?#?39=0
09:00:38.893: Tx: ?220?200?25?26?39
09:00:38.968: Rx: ?220=-1,-1?#?#?#?39=0
09:00:41.968: Tx: ?200?25?26?39
09:00:42.037: Rx: ?#?#?#?39=0
09:00:45.038: Tx: ?200?25?26?39
09:00:45.104: Rx: ?#?#?#?39=0

I'm running 1.1 and firmware 45 on this device. I was able to remotely recover by sending %3 and disable/enable the comms to the interface/device a few times. Looking at the logs, this didn't seem to do anything until a !200 was sent (not by me) then the 1-wire came back to life.

10:38:19.955: Tx: ?200?39
10:38:20.135: Rx: ?#?39=0
10:38:20.820: Tx: %3
10:38:20.917: Rx: %3
10:38:23.135: Tx: ?220?200?39
10:38:23.204: Rx: ?220=49,1038?#?39=0
10:38:26.205: Tx: ?200?39
10:38:26.274: Rx: ?#?39=0
10:38:29.274: Tx: ?200?39
10:38:29.351: Rx: ?#?39=0
10:38:32.351: Tx: ?220?200?39
10:38:32.426: Rx: ?220=49,1038?#?39=0
10:38:35.426: Tx: ?200?39
10:38:35.495: Rx: ?#?39=0
10:38:38.496: Tx: ?200?39
10:38:38.568: Rx: ?#?39=0
10:38:38.603: Tx: %3
10:38:38.679: Rx: %3
10:38:41.568: Tx: ?220?200?39
10:38:41.642: Rx: ?220=49,1038?#?39=0
10:38:44.642: Tx: ?200?39
10:38:44.708: Rx: ?#?39=0
10:38:47.709: Tx: ?200?39
10:38:47.985: Rx: ?#?39=0
10:38:50.985: Tx: /200?220?39
10:38:51.063: Rx: /#?220=49,1038?39=0
10:38:54.063: Tx: !200,10,0,1?39
10:38:54.150: Rx: !200,10,0,1?39=0
10:38:57.151: Tx: ?200?39
10:38:57.206: Rx: ?200=4977?39=0
 
When looking at the device log files, what does '!' designate? For instance, I have a slightly problematic ESP32 for fermentation that disconnects from time to time and tends to drop the 1-wire temp when it does so.
...
I'm running 1.1 and firmware 45 on this device. I was able to remotely recover by sending %3 and disable/enable the comms to the interface/device a few times. Looking at the logs, this didn't seem to do anything until a !200 was sent (not by me) then the 1-wire came back to life.

Ok, a few comments before we roll up our sleeves: Let's figure out why the ESP32 is dropping. If it loses Wi-Fi, the 1-wire should not drop. This leads me to believe a power-on reset or EMI is occurring. Any high voltage/power stuff nearby and cycling? %3 alone should reset the bus and have the interface re-discover the 1-wire devices. You would then only need to disable and re-enable the 1-wire elements, not the communications. Ideally, you would disable the devices, send %3, then re-enable the devices (and for the record, we are working on the ability for you to send this control code via a script).

Ok, regarding the question: ! tells the interface to set up a device type on a port, ? asks for a value on a port, and / deletes a port. # indicates an invalid parameter. So in your case, when BC connects, it deletes all the ports of disabled device elements, then establishes the ports of enabled devices. With '!200,10,0,1', BC tells the interface to set up a 1-wire on virtual port 200, but the interface responds with '!200,10,#,#' because there are no sensors found on the bus. The subsequent devices on ports 25 and 26 fail as well because they are dependent on the sensor on port 200, which is not established. Later, when you send '%3', the bus is reset and the sensors are found, but it is not until '!200,10,0,1' is later sent that the port starts reporting a proper temperature back, with '?200=4977'

That might be more under the hood than wanted, but since you asked, I wanted to explain it in completely. Hope it makes sense.
 
Thank you for the detailed response, it was exactly what I was looking for. I do have a problematic WiFi issue with dense neighborhood interference, so there isn't a lot I can do about it at the moment. However, your comment regarding EMI is interesting but I can't narrow down a specific root cause. The board is mere inches away from relays controlling 120v loads (refrigeration compressor/heater), but neither were being called for when the specific issue above occurred. Next time it occurs, which might be some time, I'll try disabling the device, send %3, then re-enable. I may have jumped the gun trying to reset comms even though it was clearly working because I still had readings coming in from the Tilt. Also, thank you for answering my next question about being able to perform re-initialization requests via a script... it's like you can read my mind!
 
Nearby relays and compressors can definitely cause a problem. Interestingly, they will do so when they open, not when they close. Relay coils, motors, compressors (inductive loads) store electromagnetic power charge in them. When the power is pulled from them, that energy has to go somewhere - usually that is back down the wires to the switch unless there is a local noise suppressor. So relays dump into their switching circuitry and motors dump back into their relay contacts (causing a cool arc!). Suppressors are fly-back diodes (reverse-biased diodes or transient voltage suppressive diodes) for DC powered inductive loads, and MOV's (metal oxide varistors) and R-C snubbers for AC powered inductive loads. Resistive loads like heaters will not exhibit this issue. There is some extensive discussion on this waaaay back in this thread.

So it might be worth looking at the log *before* the power failure to see if a relay/compressor was turned OFF. Problem is, it will likely not show up in the log because hysteresis devices will change state (on their own) and cause a reset before BC can see that the state did change. You will have to see if the temp approaches the turn-off point and interpolate if it switched off. If you run graphs, you might be able to see that it was about to switch off... for example, below. In this example, you can see the temp (blue) approaching the bottom when compressor turns off (orange) and use the time as a reference:

upload_2019-7-23_22-8-8.png
 
EMI is a pain to deal with, especially on sensitive components like temp probs.

I was getting device reboots, temp fluctuations, etc due to 24V devices being switched off. Not even in same circuit (well way back down the system they would join up,I suppose).

Using 5M shielded probes earthed to arduino worked around the problem for me.
 
EMI is a pain to deal with, especially on sensitive components like temp probs.

I was getting device reboots, temp fluctuations, etc due to 24V devices being switched off. Not even in same circuit (well way back down the system they would join up,I suppose).

Using 5M shielded probes earthed to arduino worked around the problem for me.
When you say 'earthed to Arduino' are you saying that your DC negative is isolated from the AC ground?
 
When you say 'earthed to Arduino' are you saying that your DC negative is isolated from the AC ground?

Simply put, 24V DC circuit is grounded to incoming 240V, and then 9V DC (arduino power) and 24V DC (automated ball valves and pump relay) grounds are tied together.

We were getting a lot of interference when using a long temp probe (anything over 2 metres). So my client purchased some shielded 5M temp probes, which I grounded the shield to arduino ground, and all worked as normal from then on.
 
Thanks for the ideas and I agree that I have some sort of EMI issue going on. I was able to correlate most of the disconnects to specific events, namely when the ESP32 roamed to a different AP on my mesh network and the fridge compressor was on. I am able to reliably recreate the disconnect event, and while the 1-wire doesn't drop every time, its enough to kill my cool/heat hysteresis devices which depend on it (BC doesn't seem to recreate the device after it deletes it, which seems kind of strange to me but may be SOP). Below is the log where I have the compressor running and force the AP roam (which I understand *is* a disconnect/reconnect), which some devices handle better than others. I tried the same experiment with an 8266 and had no issues with it.

09:21:22.997: Tx: ?200?25?26?39
09:21:23.070: Rx: ?200=5427?25=1?26=0?39=0
09:21:26.070: Tx: ?200?25?26?39
09:21:26.139: Rx: ?200=5427?25=1?26=0?39=0
09:21:29.139: Tx: ?220?200?25?26?39
09:21:37.141: Error: No device response
09:21:37.149: Disconnected
09:21:38.275: Connected
09:21:38.275: Tx: /2/27/32/200/25/26/12/34!220,15,3!39,8,500,40
09:21:38.284: Rx: /#/#/#/200/25/26/#/#!220,15,3!39,8,500,40
09:21:41.284: Tx: ?39
09:21:41.351: Rx: ?39=0
09:21:44.352: Tx: !200,10,0,1?39
09:21:44.434: Rx: !200,10,0,1?39=0
09:21:47.434: Tx: ?220?200?39
09:21:47.489: Rx: ?220=54,1029?200=5427?39=0
09:21:50.489: Tx: ?200?39
09:21:50.559: Rx: ?200=5427?39=0
09:21:53.560: Tx: ?200?39
09:21:53.627: Rx: ?200=5427?39=0
09:21:56.627: Tx: ?220?200?39
09:21:56.695: Rx: ?220=54,1029?200=5427?39=0

I've isolated this device to a specific AP so that it won't try and roam and I'm about 80% finished with a new enclosure so I'll transition to it and see if it helps with the EMI issues. Thanks for all the help.

Joe
 
When an interface loses communication with BC, the devices will not change. For example, Hysteresis will continue to run and 1-wire should not reset. BC will recreate enabled devices upon reconnection as a fail-safe.
 
Would an interface experiencing a power-on reset explain why my hysteresis devices stayed disabled in BC after the disconnect/reconnect? In the interest of full disclosure, I have a script that might be misbehaving and causing the hysteresis devices to stay disabled after they disconnect, but I'm still troubleshooting it and its hard to do with beer fermenting!
 
Would an interface experiencing a power-on reset explain why my hysteresis devices stayed disabled in BC after the disconnect/reconnect? In the interest of full disclosure, I have a script that might be misbehaving and causing the hysteresis devices to stay disabled after they disconnect, but I'm still troubleshooting it and its hard to do with beer fermenting!

Normally no, but if your hysteresis devices are dependent on 1-wire, and that bus is crashing as a result of a bumpy noise related reset, then they will fail until the 1-wire bus is reset and the 1-wire devices are established. Normally a power-on resets the 1-wire bus but if it was transient and/or noise related, it may not.
 
Here is a look at a prototype MEGA format UniShield. The final version will have a shorter stack height (we selected the wrong power connector for this one). Will support MEGA, Due, Grand Central (installed here) and will allow other shields like Wi-Fi to be added on top. Up to 48 high-powered outputs, 5-24V DC each (4 divisible banks) up to 2.5A per output. DIN rail mount.


IMG_6969.JPG
 
Normally no, but if your hysteresis devices are dependent on 1-wire, and that bus is crashing as a result of a bumpy noise related reset, then they will fail until the 1-wire bus is reset and the 1-wire devices are established. Normally a power-on resets the 1-wire bus but if it was transient and/or noise related, it may not.
Ok thanks, in this case the 1-wire did come back but my hysteresis devices dependant on it stayed disabled. This leads me back to my misbehaving script theory, so thanks for the confirmation.
 
Here is a look at a prototype MEGA format UniShield. The final version will have a shorter stack height (we selected the wrong power connector for this one). Will support MEGA, Due, Grand Central (installed here) and will allow other shields like Wi-Fi to be added on top. Up to 48 high-powered outputs, 5-24V DC each (4 divisible banks) up to 2.5A per output. DIN rail mount.


View attachment 637070

I like 24V! and reset button is placed well! thinking a buck converter to power the interface and some RTD headers would fit on that board ;-)
 
The base board (bottom) is stuffed so no room there. And that can be split into 4 different power supply voltages, so if you want to drive different devices at 5, 12, 24 V (or any other up to 24V), you will have the flexibility.

The top board does have some room on it and we considered a regulator to give users the ability to power with a single power supply. Next update maybe!
 
I am trying to connect a Mega (Robodyn) 2560 using Ethernet.

I used the setup.bat (v45) to configure the Mega for a MAC and IP Address. The Only question I had was DCHP which I set to "N" (I assumed because I was setting a Static IP.)

I added the Interface and used the following:
TCIP.png


I manually added the device to my Frontier FIOS Router and it got the MAC Address from the Mega but Ping Tests or BruControl Communications do not work.


Any ideas?
 
I am trying to connect a Mega (Robodyn) 2560 using Ethernet.

I used the setup.bat (v45) to configure the Mega for a MAC and IP Address. The Only question I had was DCHP which I set to "N" (I assumed because I was setting a Static IP.)

I added the Interface and used the following:View attachment 637347

I manually added the device to my Frontier FIOS Router and it got the MAC Address from the Mega but Ping Tests or BruControl Communications do not work.


Any ideas?

if you set it up to get an address from your fios router, that is called 'static dhcp' or 'DHCP reservation' set the interface to DHCP like this:
Code:
BruControl v43A.W Setup 10s (y)?
BruControl v43A.W Setup 9s (y)?
BruControl v43A.W Setup 8s (y)?y
Config net (y/n)? Y
DHCP (y/n)? Y
SSID? yourssid
Pswd? yourpassword
Save (y/n)? Y
End setup
Use saved
DHCP
SSID:yourssid
PASS:yourpassword
 
I am trying to connect a Mega (Robodyn) 2560 using Ethernet.

I used the setup.bat (v45) to configure the Mega for a MAC and IP Address. The Only question I had was DCHP which I set to "N" (I assumed because I was setting a Static IP.)

I manually added the device to my Frontier FIOS Router and it got the MAC Address from the Mega but Ping Tests or BruControl Communications do not work.


Any ideas?

A few things come to mind. 1) Are you sure the .160 address you assigned to the board was not in use? Disconnect the board and try and ping that address again to verify there is nothing else sitting there. 2) Did you set the static IP on the board or on your FIOS router? If you set it on the board (setting N to DHCP) and configured your IP/subnet AND set it on the router, that is fine. But if you only set it on the router, then you need to enable DHCP on the board. 3) Make sure the subnetting on the board matches your network size... likely a /24 or 255.255.255.0
 
Yeah, I think if it is exposed it needs to enclosed. And "yup, I feel ya" on the sticker shock on 50amp GFCI breakers. :)
I normally buy spa panels with the breakers and remove the breakers and install in main panel or keep spa panel near the control panel. for some reason the spa panels with gfci breaker are usually $50-75 and just the breaker alone is $100+
 
A few things come to mind. 1) Are you sure the .160 address you assigned to the board was not in use? Disconnect the board and try and ping that address again to verify there is nothing else sitting there. 2) Did you set the static IP on the board or on your FIOS router? If you set it on the board (setting N to DHCP) and configured your IP/subnet AND set it on the router, that is fine. But if you only set it on the router, then you need to enable DHCP on the board. 3) Make sure the subnetting on the board matches your network size... likely a /24 or 255.255.255.0
I went back and set a different MAC and set DHCP to "Y" and saved.

Termite is reporting back with the MAC and DHCP on Termite but it is not being picked up by the Router that I can see. I am not sure if the Arduino Mega is giving a handshake like this but it does not appear so. I would think that you would want a Static IP since in BruControl you have to put in IP (DHCP is not an Option).

I did Ping my Static IP Setup with the Board On and Off and I get no ping either way. I can see all devices that are connected to my Router and there is no other .160 I ran
IP config and my Subnet is the 255.255.255.0 one. My Gateway is 192.168.1.1 (How I get to the router anyway).

I would think that you would not use DHCP on the MEGA setup.
 
If you changed the MAC address on the device and enabled DHCP, did you also set your DHCP reservation on your router to that new MAC? You are correct about wanting to use a static address. Personally, I disable DHCP on the device and assign the IP info via termite.
 
If you changed the MAC address on the device and enabled DHCP, did you also set your DHCP reservation on your router to that new MAC? You are correct about wanting to use a static address. Personally, I disable DHCP on the device and assign the IP info via termite.

I cannot set a device on the Router except by IP Address. There is no way that I can see to set with the MAC. That seems automatic.

I think that setting the IP On Termite would be the preferred way with DHCP set to N. I also assume that the Port of 5000 is fine in the BruControl Interface setup. I have checked the cable and I can hook up this computer and it works fine so I "know" it is not Hardware from the Cable upwards. I am going to try a different Mega.
 
I have over 50 DHCP reservations in my router that have worked flawlessly for more than a decade, and have only recently had a problem with the W5500 connected Mega2650's when I changed out my 15 year old Cisco 3560 100mbit switch for a new, current, 2960L switch that is gigabit and fanless... I had it working for a while, but it errors enough that requires a power cycle to reconnect that I ran a cable all the way back directly to my router. Static assignment on the interface did not help... also, triple check your cable quality...
 
I'm not familiar with the Robodyn MEGA model, but I assume there should be indicator lights at the NIC port to verify connectivity at the device level. Do you see link and/or activity lights lit up near the port?
 
I have over 50 DHCP reservations in my router that have worked flawlessly for more than a decade, and have only recently had a problem with the W5500 connected Mega2650's when I changed out my 15 year old Cisco 3560 100mbit switch for a new, current, 2960L switch that is gigabit and fanless... I had it working for a while, but it errors enough that requires a power cycle to reconnect that I ran a cable all the way back directly to my router. Static assignment on the interface did not help... also, triple check your cable quality...
We had a nearly identical issue with some Allen-Bradley PLCs, where we found that Cisco's link speed autonegotiation wasn't playing nicely with AB's network cards. Forcing the port to 100/FDX (or 10/HDX for some models) fixed the issue in our case.
 
I cannot see any NIC lights but if not on, there could be there. I tried a different Robodyn and set to that same IP and then a Different one (.159). I looked at my router list and did not see any devices set to that IP. I pinged with Mega off the network and got no activity on that address. (Pinged Mega on the network and no connection) I am really at a loss as to why it fails to connect. I may just try to figure out how to do a serial only connect as that is easy. PITA as I have to move a computer to the USB cable when I want to Brew.
 
I normally buy spa panels with the breakers and remove the breakers and install in main panel or keep spa panel near the control panel. for some reason the spa panels with gfci breaker are usually $50-75 and just the breaker alone is $100+

Got lucky and found a new open box 50 amp gfci breaker on ebay for $50. Now if I could just find a ee with micro-processor experience to help me with this build. I am finding ee's but only with power experience. I guess this is going to be trial by fire for me, but it will be a fun project. I thank everyone on this thread for their help in advance! I do have experience with house wiring and have built quite a few computers from scratch over the years and done a bit of wiring and soldering.

edit: cheaper to enclose wire in conduit that use metal sheathing. All the rest of my wiring coming into the house is open in the ceiling of the basement.
 
I cannot see any NIC lights but if not on, there could be there. I tried a different Robodyn and set to that same IP and then a Different one (.159). I looked at my router list and did not see any devices set to that IP. I pinged with Mega off the network and got no activity on that address. (Pinged Mega on the network and no connection) I am really at a loss as to why it fails to connect. I may just try to figure out how to do a serial only connect as that is easy. PITA as I have to move a computer to the USB cable when I want to Brew.

if you have an old, dumb switch or a router with multiple switch ports, try plugging that in between the fios switch and the mega...
 
Here is my issue I have been running into, wireless 'SonOff Dual' interfaces using the ESP8285 are regularly disconnecting after running for a few days... If I power cycle the interface, it runs fine for a few days...

Remote full reset would be really nice...
 
Sorry... way behind on posts here. Working off the phone so will catch up on computer later. But: I would caution anyone from haphazardly changing MAC addresses. Once that gets registered across the other Ethernet interfaces (not BC interface in this context), it will create a problem when multiple MACs and IPs are mixed.
 
Sorry... way behind on posts here. Working off the phone so will catch up on computer later. But: I would caution anyone from haphazardly changing MAC addresses. Once that gets registered across the other Ethernet interfaces (not BC interface in this context), it will create a problem when multiple MACs and IPs are mixed.
My Router would not allow me to create a second Static with the same IP. I deleted the Static IPs before I did another on my router. I have yet to get one to connect. Right now I only have one Static IP for a Mega on the Router. I can always start fresh in the morning with a New MAC Address and new IP.
 
Back
Top