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.
My opinion, and take it as that, is that you are overcomplicating this. If you want two elements, then run two elements in parallel. Your circuit will need to support the current loads, so you will need to design that correctly - if you have 50A supply, then you can use a single 50A contactor to feed a single 50A SSR to drive two parallel elements. In this way, you control the heat input via BruControl with whatever control type you want: hysteresis, PID, or via a roll-your-own in script. If you want discrete control of these elements, then build them with 2x (30A contactor feeding 30A SSRs to drive an element). I don't see any logical reason to do it this way... but its your rig so do what you like. If you did run these two discrete elements through 2 parallel PIDs, as long as they use the same temp input, they will mirror each other because they will calculate the same results with each cycle. Setting them up with different probes or parameters would make little sense as each would be erroneously affected by the other, or more likely one would become dominant and hinder the other.

I'm not sure how the QuadZilla, your script lines, or dual throw play a role here, so maybe I'm still missing what you are looking to do.
 
Ok I was looking for someone that uses the Quadzilla and what logic they used to control it. It looks like the Quadzilla is 4 individual Elements that may be controlled individually or in unison. I do understand how to wire a contactor (that what I used before). It is some insight to "logic" of controlling more than a single element at the same time that I am looking for from the community.

Since I want tight control, I would prefer to use a PID type control versus Hysteresis when you have an Electromechanical contactor.

I know that I could use two separate 30 amp proportional controllers with the same temperature input to do it. I was just wondering if there is a better solution. I was not sure if using two separate PIDs would cause issues as to how well the temperature is maintained as I did not have that in my old Brewery (One Element per Vessel).

In the winter, one Element was not powerful enough to maintain my desired temperature.

There are certainly many ways to skin that Cat, so I was trying to see if anyone else had done this with two Elements in the same Vessel.
 
While we're on elements, I have a 20gal Stout boil kettle. I'm looking to convert it to electric (MT and HLT already are). My question is should I go with one or two 5500W elements in the boil kettle. I usually boil about 14-15 gallons to net 11 into my brite tank.

Thanks
 
I had a 75 gallon HLT with a 5500w 240v Element. I regularly kept it at 185 without issue. It was a different HLT that I was having issues with being able to maintain as I was using it to keep the Mash at Temp via a modified HERMS using a Chillzilla.

I lost that one in my fire and saw that Stout has an 80 gallon with two Elements and a sensor port. That is the real reason for my question about two Elements. You can never have too much hot water. I want IT!
 
I have the same kettle, 5500w is more than enough. In fact, when it comes time to replace that element, in going to swap it for a 4500w.

Edit: should also mention that I'm using a condenser.

Thanks, I'll be open lid since I brew in the garage but cutting one hole will be enough for me so your info is good news. This way I will use the element out of my RIMs so I won't even have to buy another element right away.
 
I took a chance on a cheap ESP32 'LOLIN32' board with onboard LiPo battery port and it seems to work well, will put it through it's paces in the next few weeks... I liked the Adafruit feather, but they are up to nearly $30 now... I got 3 for $12 from aliexpress and will be seeing if it, a battery, and 8 RTDs on 2 RP-3 boards in a cantex box works as i hope. US $3.31 19% OFF|ESP32 ESP 32 ESP 32S ESP32S For WeMos Mini D1 Wifi Bluetooth Wireless Board Module Based ESP WROOM 32 Dual Core Mode CPU|Integrated Circuits| - AliExpress
 
I just have upgraded to beta 1.1.9 (beta 1.2).
For me it wasn't straightforward, as I couldn't make installation of SQL 2019 LocalDB running. It wouldn't start service at the end of the installation called VSS. My workaround was to install full version of SQL express together with LocalDB feature, then uninstall SQL instace leaving LocalDB running. This isn't brucontrol installation issue per se, but it made me crazy for 1 day. :)

After that I had one exception with whole setup. which I _never_ had before:
In the first test I had sudden unexplained disconnects form arduno mega in the middle of the test and after ca. 15 mins from starting the arduno board (client brucontrl was running all the time) . Worst thing is since RIMS heater was in dumb duty cycle mode it heated water uncontrollably.

In one moment, I have noticed disconnects from the UI : all elements would go on-off all the time and it didn't recover by itself. I was able to ping WiFi interface from my windows brucontrol station (3ms- 45ms RTT) and also checked access point, signal strength for brucontrol was 95% (access point is 2 m away from Arduino), so my first assumption that it wasn't a network problem. If I test now with network, and stop AP ,or restart it, Arduno will get connected when WiFi becomes available. Also I can confirm that nothing was on the network in terms of bandwidth (it's anyway 802.11ax alowing up to 9-10Gbs).

Recovery was only possible by resetting Arduno. I never touched client -brucontrol client or anything else.

Here are the logs:
17:41:10.258: Device 'MEGA' @ 192.168.168.41 = Connected
17:44:53.992: Alarm 'Brew Alarm' activated
17:44:55.643: Alarm 'Brew Alarm' deactivated
17:44:55.726: Alarm 'Brew Alarm' activated
17:45:07.726: Alarm 'Brew Alarm' deactivated
17:58:41.538: Device 'MEGA' @ 192.168.168.41 = Disconnected
17:58:42.569: Device 'MEGA' @ 192.168.168.41 = Connected
17:58:45.570: Device 'MEGA' @ 192.168.168.41 = Disconnected
17:58:46.601: Device 'MEGA' @ 192.168.168.41 = Connected
17:58:49.601: Device 'MEGA' @ 192.168.168.41 = Disconnected
17:58:50.632: Device 'MEGA' @ 192.168.168.41 = Connected
17:58:53.663: Device 'MEGA' @ 192.168.168.41 = Disconnected
17:58:54.695: Device 'MEGA' @ 192.168.168.41 = Connected
17:58:57.695: Device 'MEGA' @ 192.168.168.41 = Disconnected
17:58:58.726: Device 'MEGA' @ 192.168.168.41 = Connected
......

18:00:38.179: Device 'MEGA' @ 192.168.168.41 = Disconnected
18:00:42.241: Device 'MEGA' @ 192.168.168.41 = Connected
18:00:43.991: Alarm 'Brew Alarm' activated
18:00:46.096: Alarm 'Brew Alarm' deactivated

Since then, after several 2h tests I didn't notice this behavior again. My network state of the art (it's part of my job :)), it is highly unlikely that there was the issue. Although you can blame it easily on wifi.

When I have duty cycle enabled, i just heat the water so if I had malt inside, i could have overheat it easily. Otherwise, if this happens while PID is running, disconnect should kind of fine as system continues to execute what has be lastly communicated.

Anyone knows if it is it possible to raise Alarm (email maybe?) on interface disconnect or start rotating light if same thing happens ?

thanks and cheers
 
How fast are you polling the Arduino (assuming 1s) and what is your timeout setting (assuming 3s)? What firmware are you running on the MEGA?

My understanding is that functions like PID are maintained at the interface level, so a random disconnect should leave the interface maintaining whatever temperature it was last set to. I'm sure you know this, but it doesn't have to be your network causing the issue. Since the 2.4ghz spectrum is crowded and has lots of overlap, your "channel" might be too crowded, causing dropped packets. Most Arduino gear doesn't use 5ghz spectrum, so unfortunately overall bandwidth doesn't really apply here. If you have done a spectrum analysis or are rural, you can probably disregard. Based on your network comment above, I would assume you have network logging capability. Check out your AP logs and see if your controller noted the interface disconnecting or anything else odd going on at the time.

If you can reliably determine that your issue is not network related, you are left with power and EMI (honestly these are the likely culprits). How are you powering the MEGA? For EMI, I would start by hooking up a serial connection to the MEGA and monitoring the output. See if the MEGA is rebooting or otherwise crashing, and since it could be a specific device causing the issue, make sure to cycle through all of your attached devices. Assuming you were running a script to heat up water, shut everything down and try it again with cold water to see if the problem is repeatable. These things can be a pain to track down, but it is achievable.

Finally, you can set an alarm based on interface connectivity. Try "Device Name" Connected == true/false in your alarm script.

Cheers and good luck.
 
Not an expert by any means, but over the years I have had to reboot my WiFi many times during those years, and did not have BruControl. In fact, I have a vacation home with nothing but my computer connected that I had to reboot recently. I do not trust WiFi because of that.
 
How fast are you polling the Arduino (assuming 1s) and what is your timeout setting (assuming 3s)? What firmware are you running on the MEGA?

My understanding is that functions like PID are maintained at the interface level, so a random disconnect should leave the interface maintaining whatever temperature it was last set to. I'm sure you know this, but it doesn't have to be your network causing the issue. Since the 2.4ghz spectrum is crowded and has lots of overlap, your "channel" might be too crowded, causing dropped packets. Most Arduino gear doesn't use 5ghz spectrum, so unfortunately overall bandwidth doesn't really apply here. If you have done a spectrum analysis or are rural, you can probably disregard. Based on your network comment above, I would assume you have network logging capability. Check out your AP logs and see if your controller noted the interface disconnecting or anything else odd going on at the time.

If you can reliably determine that your issue is not network related, you are left with power and EMI (honestly these are the likely culprits). How are you powering the MEGA? For EMI, I would start by hooking up a serial connection to the MEGA and monitoring the output. See if the MEGA is rebooting or otherwise crashing, and since it could be a specific device causing the issue, make sure to cycle through all of your attached devices. Assuming you were running a script to heat up water, shut everything down and try it again with cold water to see if the problem is repeatable. These things can be a pain to track down, but it is achievable.

Finally, you can set an alarm based on interface connectivity. Try "Device Name" Connected == true/false in your alarm script.

Cheers and good luck.


If you have PID running and lose connectivity, the temp control should be maintained as the PID algorithm is running on the interface.


@RiverCityBrewer

1600964683169.png


I couldn't repro the issue. My gear is running all the time without problems. Mega is not rebooting at all, never did. Good point about devices, but it's not that. I ran full cycle 2x after that and haven't found any issues. And thanks a zillion for the tip about alarm-
My firmware is "BruControl.45K.MEGA.W.hex". Is that the newest?

1600965340848.png


About WiFi - I am living in rural area so in total I have maybe 3 WiFi visible on different channels. Nothing tells me this was network problem.
No disconnects from AP and I was able to reach interface during the "incident".
Dropped packets: it's a TCP connection, and any of those should be re-transmitted by the protocol. Unless we are talking about high bandwidth streams where protocol itself cannot protect from such events if the packtes are dropped by the malfunctioning interface itself, because card had gone crazy. But this didnt happen as I could telnet to port 5000 (tcp connection) and could ping (ICMP) to arduino IP, without packet loss.

@oakbarn
I am betting my right hand in quality of WiFi and low latency. Devices I have are good quality and were not rebooted past several months.
With restarting MEGA all worked ever since. But cable is surely better :-D

@Brunog
If I'd run PID - your statement is correct, but I was running duty cycle and that has no limitation. It was on 100% duty cycle to preheat the water.
Except I could write a script and shutdown all if temp goes like ca. 5 deg C above. Then I'd be safe unless I lose connection and Script couldn't be executed ?Or is there other SW based protection I could implement that works even if MEGA gets disconnected ?

PSU: Well, maybe. I'll follow on that. It's completely new.
60w 5v, PSU is isolated form heater, fully. (another phase).
Nothing points to that. But I have equipment to log any abnormalities if needed on PSU.

EMI - My MEGA is in closed in metal isolated container and away from the rest of the box devices,. It's 40 cm away from any high voltage source.
Nothing points to EMI at this moment.

I wouldn't blow this topic out of proportion, it happened once, lets see how it goes. Thank you again all of you for answers and guidance.
 
This brings up a question. I know that if you lose connection for any reason rather than quitting and disabling, all output are left in the state they were in.

a pump (digital out) is left on if it was on.

So for other things:

Duty cycle will be at “on” or “ off” depending on where it was in the cycle?

PID will continue to maintain temp?

Hysteresis?
Deadband? And so on
 
This brings up a question. I know that if you lose connection for any reason rather than quitting and disabling, all output are left in the state they were in.

a pump (digital out) is left on if it was on.

So for other things:

Duty cycle will be at “on” or “ off” depending on where it was in the cycle?

PID will continue to maintain temp?

Hysteresis?
Deadband? And so on

Everything stays steady state upon disconnection. Digital outputs stay same as you mentioned. PIDs, Duty Cycles, Hysteresis, Deadbands all continue to function same.
 
Great! Pictures... or it didn't happen!
made only one, just at the beginning. Kids were not giving me a break .... 🙃 .
This time was more about system settings and parameters. I used RIMS first time in life and it was beautiful :-D.
Everything on the picture is kind of new to me. Now I've got enough data to adjust beersmith and brucontrol

Thanks again @BrunDog for making this possible.

As you can see I am a balcony, 100L brucontrol, brewer :). More pictures to follow next days after next session. I do have enough grains for 2 more batches.

This time was Belgian Dubbel on the menu:
IMG_20200924_162301.jpg
 
Just received the WINC1500 and looks like I need to solder the pins. Can I match the W5100 breakout for use with the screwshield provided by BruControl?
 
A general question about RIMS. In my previous Brewery I had a 9 gal "Radiator" that I used to cycle heated water in the outer tube of a Chillzilla. The 9 Gal "Radiator" had a 2000 w 115 vac element under PID control. I had the Chillzilla insulated with Foil Bubble foam. It worked great for the most part except on a very cold brew day. My Brewery was and will be in an unheated barn. I suppose I could do a 30 AMP 5500 W 240VAC Element, but I thought of running a RIMS in the Hot water bath line. Since the amount of water to be heated is much smaller compared to the 5 or so gallons I had in the "Radiator", do you think a RIMS 2000 W 115 vac Element would be sufficient to continuously heat my hot water bath. Something like an On Demand Hot Water Heater. I would still have my "Radiator" as the accumulator and the Hot Water Bath could be preheated to near the target prior to mashing so it would be more maintaining a Temp. Maintaining the Temp was quite easy when there was no WORT flow in the inner Tube of the Chillzilla regardless of how cold it was. I also used this hot water, heated to 185, to sanitize the Cold side of the of the Brew Day brewery (Plate Chiller and hoses to the fermentor) during the Boil.

I really like the way the Wort turned out and the way I was able to maintain my Mash. I never did Step Mashes but had thought of this type of a RIMs to do one.

One of the reasons I would prefer a 20 amp circuit is that I will likely be limited to 150 amp service in my new Brewery. I will already be using two 30 amp circuits for my Huge HLT.

I am talking to Electricians and may just op to have a separate Meter set ($$$$$), in which case I would have 400 amps.
 
... I used RIMS first time in life and it was beautiful :-D.

Yeah
Just received the WINC1500 and looks like I need to solder the pins. Can I match the W5100 breakout for use with the screwshield provided by BruControl?

You are switching away from Ethernet?

Not sure your question. You will replace one shield for another, load the Wi-Fi firmware, and go from there. Note some of the pins are not usable with the Wi-Fi shield. See the interface wiring map.
 
2nd time with brucontrol was also perfect. I like perfect and easy brew days ;-). This time also small batch in order to test my equipment.

Some more pictures as promised. Another day, another lesson learned. Adopted scirpts a bits but nothing major.
I use automation for strike water and for mashing, boiling and sparging to be added (for me not critical).

Here you go, sorry if I am spamming.

Recipe:
1601136528950.png


my VFD (of Ali, but really good) :
ACtC-3eOURgJcvofaNXQln4OmTlMDVxEBYgR-EHr7mPHDocH57PAv0igbKXUylwFYb3jBcUoHb0MzqNv15UgcwP9GdywboWMJiGItgP9YZesLVtzYuDBGWenTkF_iWyy9qj-uAlDtV4DPs_kqtBxWrxOgoH4ug=w1918-h1439-no
ACtC-3cCMXWo49NFi5KevWPTexMhby0z0Dxjj-DemeEYHtkFvDalCFwxO8wgC7272_CYCxJSv0XEI60QjfgziEihgYjTOdFGsqscW1LAvpWtSbuTZQ-AQZt0vwpTS7hcTkP4I1CBUZdDmddgy5YJ_Sm1qicOVg=w1439-h1918-no
ACtC-3ey73F0m4JoBQgHwYdPhQA68clBOzBgOv3ZjoLJvvLuPZjqTEg-gryP93KPOxUvWBY4duwNF6P57o3cSz-TJdH9FxqJ1KiSfzGCQMZi9qX56fa6wWPdcjY_mp3V4tZc6N7Cf9Qv_WXOUNOvyOfNLM56hA=w1918-h1439-no


double checking if Mash sensor is ok:
ACtC-3dII6QfGpWbRoVLmB1ycyy4vGAZgJ1ACFVTzrAzZSS0Sr47vRDK_8SzCJ6U4kGl07UmH67KEBMc1n7TQdP30cptgr9SDQ661HMuln7wotGMB1jrnv4j8FXWHKPhSjbraokjo0bTO0q31X4KzLA58tt-5g=w1439-h1918-no


During mashing: keeping 64C (RTD sensors are not connected) :

ACtC-3fvakUqUtf1xc4WLTCtVLQ4SBMZUhLtM1MyypdbPSHiW-ERfASUoCTEPGr7EqEByPhIC43iJoz5Ke89ejRWGo-grfVtMxVo-RbAtjPqFC1sLzorsnp6qfM_QUr8OJy9B4wNAlbU8FtYVAPqixKKFF97Og=w1918-h1080-no


Mashout:
ACtC-3d2xTzAuIhj4fdJov6ndBxs_9Q5tEdGtj-xRJrDeVvpnDBjYMZtvMDHTAnkFdGIvo0xP2u3SaQgCSswqfsNEbt3ZwQHWHJYVlHrVcS3Rug9Ija1qrMmhoK6nsWDXOlX5h45d6KwSaqilSQdG5PLSoF1_A=w1918-h1080-no


Result from today's session: Christmas beer :) :
ACtC-3dwpSsL7ZBrT9VNt1mpMOGnV9KhG2a43KGB2TRUGNLq9SZXAEhEPzYOSTWub-z6tz9gpIUv6i-BRZ7zH5zF69tFBHsW0peQnqDepQv5f-xD0rWL6ws_5Ui2TkYJdVjqaAxKdOsFQyboeksn6h7uGQOkzQ=w1918-h1439-no



Final transfer (Green cup, iSpindel) :
9nJKhkRk6BNlkrnzMj5yaWLqw21M9kyyRNOfOBng0AnhxQuD68mao8A-pZZZkX8Wqy-CPD-RyQ5-7TbSDSpJabxnqbTXohzsTdL-DfpFQecjBKZ1QX5yLJTemmlWzs8wqWNY8TZh719npc-oYFyqc_fCYbwpqhYIBnQ78xK2n9NcIYmqnIniI_1HvKqZ6RY2resXwfhXvMrox29NPkfxWY0V4uMq4j8ygPkQGkym3ZH9dsBJmnnhWir3eALdgPZnGaM9VNul9ZZznPEUzb4Lk9-pXPDdAOymMQXVk8RSjfgwaR6Za7ZrdwH1udusS9gvAr_JvXs1NfWUx8LHTk_GJWuhPJhvZ5M3yXmnj3vCUng6OmFABqIKsEX0rSKAywYfnZxpIwSzDdEpSCmgjq-eMImYEcwFJqU-a2qBZW1Swdub3lmq4KE6HDaihGi2rAEqTKihwgIWaVD3skqcfGyDg_AGAeChhnXkf-VRTZde97ScS25eofz-J-byKh62UU9bOrVvjpDDVS5kmk6WcFi-V2BQ97obVHzWbcItT2mA-unjrLMCEXTIz1LyAJfpdwxL3GvZvJZd3R5LQaFIDTdYT01DmTzS4iXU4CPNngOjzlJSIlF4dsRlyoTM1E5ZLfstnaMFjBOj7HkzbHzNu4HufWR5ODb1QWJfFUlwnPIUflQ56cb0I4deGbP5nawCsg=w1439-h1918-no


Result :) ;
ACtC-3cHZbdxpt4h4LrS0Vy-W7tBhHJ3alxhf6XqAt0v80TslTtdfIFn16XE4vnRuz0LmCQxN7Od9XHRxlk3gzjPIJDGhhZz4uEypwdbBbMhmvvoJ_M9d1p3zkUhnMZ-70EJ80vmYq9V1PJB48EjP5ltyL49Pw=w1918-h1439-no




And fermentation from yesterday looks promising (Sensor iSpindel, Server: Fermentrack):
Would be really good if I could catch-record fermentation with brucontrol only, yes?
I know there is a "complicated" way but for that additional license is needed @Brunog - anyone else needs iSpindel as native support ?

ACtC-3cjmOCmNgiOM_YKX-_gnoGMOSUA2eUb5oy58co0fLffv1KmuHnnXZ1GiUnSoQrYkXGluknZUz-9at-SDIOFdw3rjVB48_Yu-groPExVtDGXJdiGdxZyGPM2K5wZM2HSeTU_nYQE6ME9754npkclndfs6w=w1706-h1498-no




Happy weekend everyone !
 
Last edited:
Finally, you can set an alarm based on interface connectivity. Try "Device Name" Connected == true/false in your alarm script.
Cheers and good luck.

Hi, this tip worked for device elements. That's great, I improved some of the critical scripts already. I should have looked documentation :) .Thx.
However "Connected" is not a valid operator for the interface. (as you probably already know)
1601147080686.png

Hmm....I could test several elements for connection but would that be really the way?
Some elements failing wouldn't be solid proof that Interface is disconnected.I could have plugged out manually (accidentally) any of them :)

Do you know if there any properties for "interface" ?

Cheers
 
Hi, this tip worked for device elements. That's great, I improved some of the critical scripts already. I should have looked documentation :) .Thx.
However "Connected" is not a valid operator for the interface. (as you probably already know)
View attachment 700096
Hmm....I could test several elements for connection but would that be really the way?
Some elements failing wouldn't be solid proof that Interface is disconnected.I could have plugged out manually (accidentally) any of them :)

Do you know if there any properties for "interface" ?

Cheers

No, as odd as it sounds, you cannot test for the interface connection. But, testing for just one device element should be adequate to know if your communications are working. We did this because the interface can appear connected, but what really matters is data from devices changing hands.
 
Regarding iSpindel... there are probably a couple of routes, but the one I would prefer would be to cut our firmware for it. It would basically be BruControl FW running on that module, reading the sensors and passing them on as a native hydrometer device. This could happen very quickly. Downside is if you wanted your iSpindel to work with other devices like it does now, you would need to re-flash it.

Because I'm kinda lazy today, can someone point me to the current best repository for iSpindel code?
 
Does a stop {SomeScript} remove any variables declared in SomeScript from memory or do you need a clear command (or delete command individual variables) to remove from the memory?
 
A general question about RIMS. In my previous Brewery I had a 9 gal "Radiator" that I used to cycle heated water in the outer tube of a Chillzilla. The 9 Gal "Radiator" had a 2000 w 115 vac element under PID control. I had the Chillzilla insulated with Foil Bubble foam. It worked great for the most part except on a very cold brew day. My Brewery was and will be in an unheated barn. I suppose I could do a 30 AMP 5500 W 240VAC Element, but I thought of running a RIMS in the Hot water bath line. Since the amount of water to be heated is much smaller compared to the 5 or so gallons I had in the "Radiator", do you think a RIMS 2000 W 115 vac Element would be sufficient to continuously heat my hot water bath. Something like an On Demand Hot Water Heater. I would still have my "Radiator" as the accumulator and the Hot Water Bath could be preheated to near the target prior to mashing so it would be more maintaining a Temp. Maintaining the Temp was quite easy when there was no WORT flow in the inner Tube of the Chillzilla regardless of how cold it was. I also used this hot water, heated to 185, to sanitize the Cold side of the of the Brew Day brewery (Plate Chiller and hoses to the fermentor) during the Boil.

I'm sorry man... I seem to struggle understanding your approach sometimes. I can't visualize this. Do you have any pictures or diagrams?

My strong personal belief is if you want to use RIMS, do it and heat the wort directly with it - that is its purpose. Heating water with an element to heat your mash doesn't make a ton of sense to me personally, and it not RIMS, it's a version of HERMS.
 
I'm sorry man... I seem to struggle understanding your approach sometimes. I can't visualize this. Do you have any pictures or diagrams?

My strong personal belief is if you want to use RIMS, do it and heat the wort directly with it - that is its purpose. Heating water with an element to heat your mash doesn't make a ton of sense to me personally, and it not RIMS, it's a version of HERMS.
I always called it a modified HERMS. I had a stout 30 gal direct fired HERMS but could not control it. I came up with the idea of the Chillzilla and the control available with Electric. It worked very well.

I know lots of people use Electric Elements with their Wort. We do not. I think it more of a personal choice.

Of course, when we started Brewing we had a 10 gal Blickmann and a Turkey Fryer. We chilled by placing the Kettle in a horse trough filled with ice and water. We made an igloo mash tun and never looked back from All Grain. We bought a BCS 486 and added vessels and some electric, but stayed with propane for the Boil. We had discussed going to a RIMS to maintain the Mash but were discouraged from doing so because of "burnt wort" This was years ago and I know that there are uld elements like your Quadzilla that would likely never burn wort, but we are planning to return to what we had as we were very comfortable with the process.

We ended up with 8 Hot side vessels, three of which had Electric Elements. One of the SS Mash Tuns had a bottom heater but it had little effect as they vessel maintained temp without the heater.

we had:
75 Gal HLT with one 5500 240 vac Element
35 Gal MLT
9 Gal Brew Kettle with 2000w 115 vac Element (This was out Hot Water Bath for the Chillzilla HERMS
30 Gal Stout HERMS Coiled HLT ( used as a Direct Fired Second Brew Kettle without the Coil).
45 Gal Direct Fired Brew Kettle
20 Gal HLT with Electric (Not implemented but was going to be used to heat special strike water (like distilled water for some
lagers)
10 Gal SS MLT (bottom heater)
20 Gal SS MLT

We are thinking of replacing the 9 Gal Radiator with a 15 Gal Electric Brew Kettle. We would use that vessel for the Hot Water Bath and also to heat specialized Strike. That is the one we are thinking of using a single Element (or your Quadzilla just in case we break down and go to the dark side of RIMS versus HERMS) in a RIMS tube as the heat source.

We will only replace the 20 Gal SS MLT. We only used all 3 MLTs one time. It was a mistake getting the 10 gal instead of the 20 gal one first. (Bigger is Better!)
Here is a graphic:

sampe 2.png
 
Yes, it should. I don't recall if we tested it, but I don't know of a reason why it will not. I can test it if you need.

I have neither devices personally so at this point it’s mostly academic. If it’s not too much trouble to test I would be curious in the results.
 
Regarding iSpindel... there are probably a couple of routes, but the one I would prefer would be to cut our firmware for it. It would basically be BruControl FW running on that module, reading the sensors and passing them on as a native hydrometer device. This could happen very quickly. Downside is if you wanted your iSpindel to work with other devices like it does now, you would need to re-flash it.

Because I'm kinda lazy today, can someone point me to the current best repository for iSpindel code?

That would be great ! Totally fine with me.
If you can make it, I can get rid of my raspi server.

Basically, fw on iSpindel is sending angle, temperature and battery state.
It has configuration for WiFi and server address then token (if needed), protocol and frequency of samples. (typically 300-900 sec)
Than server side would use polynomial equation to calculate gravity from the tilt angle and show it on the graph.

I find everything here:
https://github.com/universam1/iSpindelhttps://github.com/universam1/iSpindel/releases
would that help ? How can I support you?
 

Attachments

  • 1601200701042.png
    1601200701042.png
    230.4 KB · Views: 12
Once you stop a script, the variables declared in it go buh-bye. Use globals if you want perpetuity.
Perhaps I was not clear what I was asking.

Really an esoteric question, rather than a practical one.

I know that there is a memory stack in the computer where the variables are stored. You have two Script commands dealing with the release of a variable:
delete "NameOfVariable"
clear

While I knew that the variables are no longer available once a Script is stopped (and that variables are only available within the same Script even when declared), I was wondering is you should proceed the stop "MyScript" with a clear command or does the stop also clear the memory stack.

The reason I was asking the question is I was seeing "how" to use the clear command. I was assuming it had something to do with the memory stack. I first started some programming in the 1980s and clearing your memory stack was a real issue in the day. Since BruControl might run for months without a reboot, I was wondering if the memory stack should be cleared?
 
That would be great ! Totally fine with me.
If you can make it, I can get rid of my raspi server.

Basically, fw on iSpindel is sending angle, temperature and battery state.
It has configuration for WiFi and server address then token (if needed), protocol and frequency of samples. (typically 300-900 sec)
Than server side would use polynomial equation to calculate gravity from the tilt angle and show it on the graph.

I find everything here:
https://github.com/universam1/iSpindelhttps://github.com/universam1/iSpindel/releases
would that help ? How can I support you?
For what it is worth, I've developed a couple of strategies to get iSpindel to work with Brucontrol and I really don't think reflashing their firmware is the easiest way to accomplish this. iSpindel already broadcasts in html every 15 minutes or so (you can make this more frequent but it is discouraged) its information as recognizable json objects. So the easiest route I have found is to set the iSpendel to POST a generic HTML to node red with an identifier at the end of the HTML POST such as http://127.0.0.1/ispindel001 (if you are running node red on your Brucontrol machine). Node red sees the tag at the end and grabs the information, then a simple function in node red puts the information into a form readable by Brucontrol such as:
name = msg.payload.name
id = msg.payload.ID
angle = msg.payload.angle
temperature = msg.payload.temperature
temp_units = msg.payload.temp_units
battery = msg.payload.battery
gravity = msg.payload.gravity
interval = msg.payload.interval
RSSI = msg.payload.RSSI
Update = msg.myrawdate


msg.payload = [

{"Name" : "Name " + name, "Value" : name},
{"Name" : "SG " + name, "Value" : gravity},
{"Name" : "Interval " + name, "Value" : interval},
{"Name" : "Temp " + name, "Value" : temperature},
{"Name" : "Voltage " + name, "Value" : battery},
{"Name" : "RSSI " + name, "Value" : RSSI},
{"Name" : "Updated " + name, "Value" : (new Date(msg.myrawdate)).toLocaleString()}

]
return msg;

What you decide to send to Brucontrol is then in a format that allows you to PUT the information to Brucontrol Data Exchange through a noded-red http request node:

http://127.0.0.1:8000/globals
Of course, you still have to create correctly named global elements for each json pair you are bringing in (which is kind of a pain, see my post above about the ability to use in-line quotes in a script) but at least it comes in dependably and you have not broken the ability for iSpindel to broadcast to other 3rd-party software such as Brewfather.

For me, looking around at other platforms, if Brucontrol were to embrace Node Red as a means to get things in and out of the fundamental platform (I believethere is a much earlier post that suggests making Brucontrol a nod-red node) it would open up a whole world of interface possibilities that from my perspective would make it absolutely first-in-class and go far to help market the ready-made solutions that Brucontrol is now bringing online. For example, if part of the value proposition for Uniflex was that you could automatically import your recipes and parameters from Brewfather and/or Brewsmith (which I and others on this forum are able to do using node red) I think it would be a significant advantage in selling Uniflex as something that builds and expands what you are already using out of the box. Of course this would require some standardization in element names, but it would also mean that scripts (and parts of scripts) could be more easily exchanged and understood. While the example of marketing may not match the primary goal of Brucontrol, I think everyone could agree that expanding the community and making the interface more user friendly could be.

Just my two cents, but I can see a lot of value in spending development time in opening up Brucontrol to much larger (and extremely helpful) development communities to accomplish things that might take much longer to develop as proprietary. Interested to see other opinions on this as someone who is in the middle of the Brucontrol learning curve.
 
These variables use very little memory. That said, you don’t need to worry about freeing up that space. I think it is good practice to u load variables you no longer need, but if there is a memory hole, that is our problem and we would fix it.
 
For what it is worth, I've developed a couple of strategies to get iSpindel to work with Brucontrol and I really don't think reflashing their firmware is the easiest way to accomplish this. iSpindel already broadcasts in html every 15 minutes or so (you can make this more frequent but it is discouraged) its information as recognizable json objects. So the easiest route I have found is to set the iSpendel to POST a generic HTML to node red with an identifier at the end of the HTML POST such as http://127.0.0.1/ispindel001 (if you are running node red on your Brucontrol machine). Node red sees the tag at the end and grabs the information, then a simple function in node red puts the information into a form readable by Brucontrol such as:


What you decide to send to Brucontrol is then in a format that allows you to PUT the information to Brucontrol Data Exchange through a noded-red http request node:

http://127.0.0.1:8000/globals
Of course, you still have to create correctly named global elements for each json pair you are bringing in (which is kind of a pain, see my post above about the ability to use in-line quotes in a script) but at least it comes in dependably and you have not broken the ability for iSpindel to broadcast to other 3rd-party software such as Brewfather.

For me, looking around at other platforms, if Brucontrol were to embrace Node Red as a means to get things in and out of the fundamental platform (I believethere is a much earlier post that suggests making Brucontrol a nod-red node) it would open up a whole world of interface possibilities that from my perspective would make it absolutely first-in-class and go far to help market the ready-made solutions that Brucontrol is now bringing online. For example, if part of the value proposition for Uniflex was that you could automatically import your recipes and parameters from Brewfather and/or Brewsmith (which I and others on this forum are able to do using node red) I think it would be a significant advantage in selling Uniflex as something that builds and expands what you are already using out of the box. Of course this would require some standardization in element names, but it would also mean that scripts (and parts of scripts) could be more easily exchanged and understood. While the example of marketing may not match the primary goal of Brucontrol, I think everyone could agree that expanding the community and making the interface more user friendly could be.

Just my two cents, but I can see a lot of value in spending development time in opening up Brucontrol to much larger (and extremely helpful) development communities to accomplish things that might take much longer to develop as proprietary. Interested to see other opinions on this as someone who is in the middle of the Brucontrol learning curve.
I have not implemented Node Red yet but was looking at it some time ago. I did some things with the BCS API where I created a separate HTML that displayed the Mash Temp and TIMER from data. I am hoping to do the same with Node Red and BruControl. Not sure if making BruControl a "nod-red node" would help, but from my limited understanding, I second that idea. One of my issues with BruControl is that it is Single Screen. I liked having a separate screen I could read from a distance when doing the Mash. I know I could create a Workspace in BruControl, but I would lose my "control" screen when I displayed that workspace. I had 3 Large Screen TVs above my Brewery and used all three with the BCS.
 
Back
Top