BruControl: Brewery control & automation software

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I am getting some communication issues. When it is just running hysteresis elements, it has been fine. Once I started running a script to control devices, it started disconnecting a few times a minute. I enabled debug level 1 and it is getting checksum errors. Debug level 1 also increases the frequency of the disconnects and if I enable debug level 1 without the script running, it starts disconnecting when it didn't before. It seems like the increased communication traffic is an issue. Let me know what info you need to help me debug it, or if you have any ideas for me to try. I am using a mega connected via USB. I have 5 onewire temp sensors that are working fine without the script enabled. I am running BC 1.1 with firmware v45 (I think O, but can't remember).
 
First, you can’t run debug mode while connected to the application via serial - they both use the same communication pipeline. You likely know this but wanted to make sure. This will cause all kinds of trouble.

That said, there are some odd timing anomalies that we honestly have not been able to solve when using many 1-wire sensors on a MEGA with USB. I thought the number was more like 7-10 1-wires, but perhaps it happens with 5.
My suggestion, as non-ideal as it may be… switch to a network connection shield like Ethernet, use less 1-wire sensors, or switch to an ESP32 which doesn’t seem to exhibit the same problem.

If you email us, I can also try to get you a 230kbaud firmware version which *might* resolve it for you.
 
First, you can’t run debug mode while connected to the application via serial - they both use the same communication pipeline. You likely know this but wanted to make sure. This will cause all kinds of trouble.

That said, there are some odd timing anomalies that we honestly have not been able to solve when using many 1-wire sensors on a MEGA with USB. I thought the number was more like 7-10 1-wires, but perhaps it happens with 5.
My suggestion, as non-ideal as it may be… switch to a network connection shield like Ethernet, use less 1-wire sensors, or switch to an ESP32 which doesn’t seem to exhibit the same problem.

If you email us, I can also try to get you a 230kbaud firmware version which *might* resolve it for you.
Thanks. I have not seen any issues with the 1-wire sensors unless they are causing the disconnects. It works fine when I manually turn on devices. The temperature sensors work fine and there are no disconnects. When I run a script that is controlling multiple devices, the interface starts to disconnect and reconnect a few times a minute. I noticed when monitoring the communication that it sends updated states on devices on every refresh even if there is no change. Is it bad form to keep updating a device even if it does not change? Here is an example

If NeedsHeating
If "Ferm1Heater" == on
"Ferm1HeaterLight" State = on
endif
endif

So in each loop it is sending a command to turn on the panel light even if it is already on. Alternatively, I could test if the light is on and do nothing if it is.
 
Not sure if it is related to my communication issues, but I am having issues with my LCD display. I saw the note in the manual about not sending duplicate commands, but I am not sure I understand it completely. Here is my script:

[Start]
new string data
new string line1
line1 = "F1 F2 Glyc"
display "MEGA" 1 line1

[loop]
data = "Ferm1 Temperature" DisplayText
data += " "
data += "Ferm2 Temperature" DisplayText
data += " "
data += "Glyc Temperature" DisplayText
display "MEGA" 2 data
sleep 5000
goto "loop"

It worked the first time, but now I don't get the first line even if I restart the script, restart BC, restart the interface or panel. I tried moving line1 to the loop and even changing line one so I print only "F1" and then the full line, but no luck.
 

Attachments

  • 20211020_131618.jpg
    20211020_131618.jpg
    1.4 MB · Views: 13
Thanks. I have not seen any issues with the 1-wire sensors unless they are causing the disconnects. It works fine when I manually turn on devices. The temperature sensors work fine and there are no disconnects. When I run a script that is controlling multiple devices, the interface starts to disconnect and reconnect a few times a minute. I noticed when monitoring the communication that it sends updated states on devices on every refresh even if there is no change. Is it bad form to keep updating a device even if it does not change? Here is an example

If NeedsHeating
If "Ferm1Heater" == on
"Ferm1HeaterLight" State = on
endif
endif

So in each loop it is sending a command to turn on the panel light even if it is already on. Alternatively, I could test if the light is on and do nothing if it is.

Yes, you should edit the script to make sure it doesn't repeatedly send the same command. You can add a conditional... replacing

"Ferm1HeaterLight" State = on

with

if "Ferm1HeaterLight" State == off
"Ferm1HeaterLight" State = on
endif

This is noted in the manual. Also, we recommend you add some time delays in your loop so it doesn't re-evaluate within milliseconds each loop.
 
Either an ESP32 (WiFi) or an Ethernet shield for your MEGA. The latter depends on your current screw shield - it needs to allow the shield to stack on top of the MEGA.
I am having a hard time getting my head around an automation solution that requires a windows computer and network to be up 24/7. It is clearly working for a lot of users, so what strategies are used to ensure it is robust? I think I saw in previous posts that local control of devices like hysteresis and PID are implemented on the interface, so these can continue to operate if connection is lost. Auxiliary devices like pumps and valves that need to operate in unison with these devices will not operate without connection, correct? This will definitely make me rethink my idea of using hysteresis control of lights so I can delay turn on of chiller and pump. This could result in my chiller not turning off until BC and/or the network is back up.

On a side note, I have been using onewire temp sensors exclusively for quite a few projects over the last 10 years without issue. What types of failures are you seeing with them? I have 5 set up on my system and so far I have not seen any issues (again with the caveat that they are not the source of my interface disconnects) with temperature spikes or dropouts of individual sensors. That said, I have not hooked up any AC motors to my system yet, so no major noise outside of the control panel components.
 
Yes, it's a fair question. As you pointed out, you don't technically need to have a computer running unless scripts are being executed. Hysteresis devices alone will run independent of the computer.

With respect to the computer, many people have PC's which are on all the time at home. Some have mini-PC's or old laptops, either of which are very power conservative,. In terms of robustness... that is a philosophical question. Depends on how many zeros you want! My experience is that with a Win10 PC that has a UPS backup (or laptop battery), is set to power on after power restoration, is set to start BC upon boot, and is modified to prevent automatic restarts as part of windows update... that's pretty reliable. For the interface, I'd recommend a LiPo battery backup for anything refrigeration. In my experience, I have a dispenser/fermenter that has been running without a single crash for over 5 years. It is a Feather M0 with a LiPo battery connected. Mind you, the battery needed replacement about a year ago, but I saw that coming.

1-wire sensors are fine. I'm not saying they will fail. I'm saying there is an odd timing anomoly that prevents the MEGA from successfully handing serial communications while also handling 1-wire communications. This only rears its head when there are "many" 1-wire sensors connectred. There is a conflict... I suspect its an interrupt overload, but I'm not certain. The serial buffer on the MEGA is also really small, so the problem could lie there. This problem does not exisit when it is connected via network means (Wi-Fi or Ethernet), which of course requires a shield and appropriate network connections.
 
1-wire sensors are fine. I'm not saying they will fail. I'm saying there is an odd timing anomoly that prevents the MEGA from successfully handing serial communications while also handling 1-wire communications. This only rears its head when there are "many" 1-wire sensors connectred. There is a conflict... I suspect its an interrupt overload, but I'm not certain. The serial buffer on the MEGA is also really small, so the problem could lie there. This problem does not exisit when it is connected via network means (Wi-Fi or Ethernet), which of course requires a shield and appropriate network connections.
What is the fail mode? So far, I am just seeing interface disconnects and it reconnects in a few seconds, so fundamentally it is annoying, but I don't think it will cause any issues. I am not seeing individual sensors dropping or any temperature spikes. Also, after I put conditionals on all of my state changes (to ensure that it does not continue to resend the same instruction), it has stopped dropping out. I still like the idea of a direct connection to the laptop. The equipment will be in the garage and there is no ethernet wiring and I am not sure how reliable the Wifi will be. Is it possible to set up a local network via ethernet connecting the laptop and interface?
 
I have tried a few things from Google searches, but am still not able to prevent windows from rebooting on its own. I have everything setup to auto login, start brucontrol, node red and a few other things. However, I just got back from vacation and saw that it rebooted and got stuck on login with the stupid "windows configuration wizard". It wanted me to confirm that I don't want edge as my default browser before it would finish logging in. As a result my irrigation timers didn't run for several days while I was gone...
 
I run Windows Server 2019 as a virtual machine, which fortunately gives you the control to not auto-patch and auto-reboot. I get my licenses as part of my MSDN subscription, but I see keys can be had from various retailers for <$100. Short of running Win10/11 Enterprise, I'm not sure home/pro editions will give you the patch/reboot control (Pro *might*, but I don't have any direct experience with that version).
 
Yeah, my "server" runs Pro... IIRC Home doesn't have the Group Policy Editor.

I will just say that it is absolutely whacky the MS does almost everything possible to make sure your computer reboots when you least want it to!
 
Yeah that would certainly limit Home edition's usefulness. Good to know Pro has the GPO add-in, I was thinking about that as I was typing my response, but I didn't know for sure.
 
Have you considered something like a USB widget for the liecence? I would perfer to never have my BruControl computer connected to the internet. It would never update and reboot unless I was doing it.
 
I'm running windows 10 Pro. I haven't came across the group policy editor way of disabling reboots. Thanks for the link. Hopefully that works.

I did them all… didn’t bother to figure out which one actually works!

Serendipity being what it is… after we had this chat yesterday, I woke to find my server rebooted. Turns out ups battery has given up the ghost. Software can’t fix misbehaving hardware it turns out!
 
Have you considered something like a USB widget for the liecence? I would perfer to never have my BruControl computer connected to the internet. It would never update and reboot unless I was doing it.

We went round and round on the implementation. We appreciated that many people would prefer not to have a network connection, but in this time, most need network for other updates, installations, time keeping, and other internet dependent services. The challenge of course is once something is implemented, it’s not easy to change it else other users might lose their access.

We did add the evaluation option for new users so they can test it, not incur any costs, and get up and running immediately. Challenge of a USB system is that we would need ship those out, and people would have to wait a few days to get up and running… probably not a great model.

The good news is that other when our host’s server took a crap a couple of months ago, we haven’t had any complaints or significant issues with it working. I honestly live in fear of a situation where someone can’t brew because their system won’t work for some reason - that’s not cool and we want to do what we can to avoid that experience!
 
We went round and round on the implementation. We appreciated that many people would prefer not to have a network connection, but in this time, most need network for other updates, installations, time keeping, and other internet dependent services. The challenge of course is once something is implemented, it’s not easy to change it else other users might lose their access.

We did add the evaluation option for new users so they can test it, not incur any costs, and get up and running immediately. Challenge of a USB system is that we would need ship those out, and people would have to wait a few days to get up and running… probably not a great model.

The good news is that other when our host’s server took a crap a couple of months ago, we haven’t had any complaints or significant issues with it working. I honestly live in fear of a situation where someone can’t brew because their system won’t work for some reason - that’s not cool and we want to do what we can to avoid that experience!
What about as an option where you could have a dongle OR internet and allow you to contol which one in Settings? i.e. up and running immediately and then sever the requirement for the internet or not. Could revert to internet only if you wanted.

I would be willing to pay for a dongle and shipping as I do perfer that the BruControl computer (mine is a dedicated small PC with a SSD that loads BruControl very fast is only connected to the internet when I want it to be.

Fermentation is the issue. Updates and restarts can be a nightmare. On my BCS, we had bistable relays that kept track of the Diacetyl Rest that would help recover from a power loss. With BruControl, Globals can accomplish this as well as saving the ferment time with a little math as long as you capture your start date and time (which is easy to script).
 
I hear you and appreciate the suggestion. Everything is a trade-off and we try to get a balance.

I'm not sure how a dongle would prevent updates and restarts though. Maybe you are saying the computer disconnected from the WAN would prevent it from getting updates? Perhaps, but power loss is always lurking too.

We may not get to nth degree of reliability, but I do believe (based on my experience) once you successfully prevent Win10 restarts, power the computer with a UPS, power your interface with a backup battery... you are into a very narrow sliver of failure modes.
 
Along those lines, I am trying to do same date math and it fails. I went back to previouis posts about date math:

I tried the following:
new datetime trigger
trigger = "09-15-2021 10:00:00 PM"
print trigger
// prints 09-15-2021 10:00:00 PM (trigger value)
new time change
// Add andHour
change = 1:00:00
new datetime future
future = trigger + change
// prints 09-15-2021 11:00:00 PM (future value)
print future
// Add a Day
change = 1:00:00:00
future = trigger + change
// prints 09-16-2021 10:00:00 PM (future value)
print future
//Try Date Math with now also tried with 10-24-2021 09:34:00 AM (what now returned)
new datetime vDTStartFermentaion
new datetime vDTChange
new datetime vTElaspedFermention
vDTChange = now
print vDTChange
vTElaspedFermention = vDTChange - vDTStartFermentaion
//[ERROR Line 23: Cannot convert 'DateTime' type to 'Time' type]
print vTElaspedFermention
stop "scrTimeMath"

I am trying something like a datediff function with DateTime data types to get the elasped time of a fermentaion from a Start Date time and now. This is to be able to know the time since a fermentaion started if there is a glitch (reboot or power outage) that would stop my fermentaion elasped timer Element.
 
Last edited:
I'm running windows 10 Pro. I haven't came across the group policy editor way of disabling reboots. Thanks for the link. Hopefully that works.
It appears that Win home can stopped from doing reboots also. I did not check it out but Pro and Home have ways to accomplish the task at hand. I do mine in Win11 Pro by means of the registry. Please look at https://www.techtics.com/disable-automatic-restart.
 
underlying link is still bad...

Just discovered that the same link that @BrunDog provided in post




I got this to load:

https://www.itechtics.com/disable-automatic-restart/
you may have to search "itechtics.com" and load manually

The link kept trying to load
"techtics.com" regardless of the typed link info

When I inspected the link it was

<a href="https://www.techtics.com/disable-automatic-restart" target="_blank" class="link link--external" data-proxy-href="/proxy.php?link=https%3A%2F%2Fwww.techtics.com%2Fdisable-automatic-restart&amp;hash=09726b17500d17f52c64fcb45b326cd4" rel="nofollow noopener">3 Ways To Disable Windows 10 Automatic Restart (Especially After Update Installation)</a>
 
Last edited:
Are there any guides or tips on Windows settings to make sure you do not have inadvertent disconnects of the computer? I pulled out an old laptop for this purpose and while I was setting up the workspace it randomly rebooted to install an update. I would like to prevent this or other disruptions that could ruin my fermentation from happening automatically.


I have a minipc set up to run brucontrol. IF you set the wifi connection to metered connection and this allows you to refuse windows updates over metered connection. every month or two you can turn this off for an hour and install updates and start again.
 
Yes, it's a fair question. As you pointed out, you don't technically need to have a computer running unless scripts are being executed. Hysteresis devices alone will run independent of the computer.

Thinking of off-line hysteresis, could you have a bit more capable, then it might fit more people's needs? I am happy running pc all the time, even though windows update on new machine got me a couple days ago and let ferment temp go to the moon...
  • option 1 - work put into it so that you could set up a couple IO as buttons for up-down target temp (not too helpful as you cannot see the setting)
  • option 2 - the above, but expand to LCD to show temp setpoint and buttons for up-down
  • option 3 - integrate with a 3rd party controller, something like an inkbird
 
Audrino Lost Connection but still powered on.

Is there a list of what Elements are affected and how?

For example, it seems that
Hysterisis continues to perform at its last settings (Target, On Offset, On Delay )?
Is the Predictive mode an internal Audrino thing or something in BruControl?

What about digital outs? If state was true then state still true?

Obviously nothing in BruControl is updated and all Application elements may be affected. It would be nice to know how any Device Elements are affected.
 
I do not think there is any DateDiff function available for DateTime data types. I am requesting this function be added in the future.


something like

new time ferment_time
// datetime1 is a global datetime element
ferment_time = datediff datetime1 value - now

returns a time in days hours mm ss
 
My SSRs seem to not be getting continuity on the live side when switched. They have solid 4.8V from the Arduino when switched on from BruControl. Any suggestions?
 
My SSRs seem to not be getting continuity on the live side when switched. They have solid 4.8V from the Arduino when switched on from BruControl. Any suggestions?
https://control.com/technical-articles/troubleshooting-solid-state-relays/
I think a better test of an SSR to put a real load on it. I have a test setup where I plug a box fan into. I have a extention cord with the insulation cut away in a section of the cord. The Black wire is broken and placed on the SSR load terminals. I can safely plug in the cord to an outlet, (mine is switched) and power the fan through the SSR.

Of course, you need to be careful working with live electricity but you can even have your SSR mounted in thier box.
 
Audrino Lost Connection but still powered on.

Is there a list of what Elements are affected and how?

For example, it seems that
Hysterisis continues to perform at its last settings (Target, On Offset, On Delay )?
Is the Predictive mode an internal Audrino thing or something in BruControl?

What about digital outs? If state was true then state still true?

Obviously nothing in BruControl is updated and all Application elements may be affected. It would be nice to know how any Device Elements are affected.

Sorry I don't understand this. If the connection is lost, the interface holds its state. Digital outputs, Hysteresis, PID, and Deadbands continue as before. Once reconnection happens, the expected state in BruControl is re-established in the interface (since it doesn't know if the power was lost too).
 
My SSRs seem to not be getting continuity on the live side when switched. They have solid 4.8V from the Arduino when switched on from BruControl. Any suggestions?

You will not get continuity through an SSR like you do through an electromechanical relay. As @oakbarn mentioned, it needs to be connected to a source and load.
 
Sorry I don't understand this. If the connection is lost, the interface holds its state. Digital outputs, Hysteresis, PID, and Deadbands continue as before. Once reconnection happens, the expected state in BruControl is re-established in the interface (since it doesn't know if the power was lost too).
That is what I was looking for.

I was thinking of Fermentation and Hysteresis if I lost my connection while I was out of town. I go on long walk abouts and plan for Lipo on the Fermentaion interface.


Can something like a Glycol Pump be a Hysteresis element? Something like I want to ferment at 62 F,

Set the Target at 62F. and the On Offset at 1 degree?

Our Chiller would be its own Hysteresis element set at 35F.
 
Back
Top