BruControl: Brewery control & automation software

wps-hbt
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.
BrunDog said:
All,

FYI we have started to post some Universal schematics for brewery control panels. The first one, Universal 30A Dual Element with Thermistor Probes is up. We will follow with RTD and 1-wire probes, then 50A versions. Let us know if you want others!

Here is the link: http://brucontrol.com/build/schematics/
Click to expand...

I know most people using this software have a full electric system, but I am starting out with just RIMS. Would love to see an example of 120V RIMS. I have been looking over schematics for a while now, so I have a good idea of what to do, but would love to see a schematic that integrates Arduino MEGA as well. I will be running two DC pumps and a flowmeter to start out with.

I just got my license the other day and also ordered the RTD board from you as well!
 
TenaCJed said:
I know most people using this software have a full electric system, but I am starting out with just RIMS. Would love to see an example of 120V RIMS. I have been looking over schematics for a while now, so I have a good idea of what to do, but would love to see a schematic that integrates Arduino MEGA as well. I will be running two DC pumps and a flowmeter to start out with.

I just got my license the other day and also ordered the RTD board from you as well!
Click to expand...
120v is easier to wire up than 240v... but as far as what your asking its the same as 240vwhen it comes to the control wiring.
You just run the ground and signal wire from two of the alloted available indicated in the arduino mega wiring chart so an ssr to control it... then the 120v power wire goes through the ssr at the other (switching) end...all that wiring is commonly shared with any 120v device whether is pid, ssvr or just switch controlled

Again,
As far as wiring it up to the arduino or controlling it with brucontrol though its exactly the same as a 240v element, you just have a hot and neutral instead of two hot wires on the high current wiring side.
 
Last edited:
BrunDog said:
All,

FYI we have started to post some Universal schematics for brewery control panels. The first one, Universal 30A Dual Element with Thermistor Probes is up. We will follow with RTD and 1-wire probes, then 50A versions. Let us know if you want others!

Here is the link: http://brucontrol.com/build/schematics/
Click to expand...
I'm curious why you chose to use ssrs for the switching of the 120v pumps vs mechanical relays on the relay board in the diagrams? do the pumps turn on and off rapidly in an automated system? Or is there another reason?
 
augiedoggy said:
I'm curious why you chose to use ssrs for the switching of the 120v pumps vs mechanical relays on the relay board in the diagrams? do the pumps turn on and off rapidly in an automated system? Or is there another reason?
Click to expand...

The schematic shows both SSR’s and electromechanical relays switching 120V sources for pumps or other accessories. You are right, there is no particular reason to use SSRs for pumps. If you are already employing an electromechanical relay board, it probably makes sense to use some channels on it for the pumps.

Keep in mind that an SSR need not be a full hockey puck style - there are space efficient multi-channel SSR boards which switch small loads like 2A. These can often be better as the terminals on these boards accommodate 14 AWG wire better than the small terminals on the electromechanical relay boards. But again, personal preference.
 
Ok thats kinda what I figured, Ssrs often have some small voltage leakage as well right? Not that I believe this would necessarily cause any issues in this case.
 
Yeah they will leak voltage into a very high impedance load - enough to light an LED, but not enough to generate any measurable heat in a pump winding for example.

To be clear to the community, our goal for these “Universal” schematics is to demonstrate lots of options, then let the end designer remove or duplicate items specific to their design. For example, it shows one level switch, but if someone wanted two, they would just duplicate that part of the circuit (and wire to a unique pin of course).
 
Still not used to the new software and I keep getting my posts messed up.

Any plans on putting up schematics for some of the more complicated (for me) parts like proportional valves? Or is that stuff pretty specific to the valve?

I'm almost ready to start mapping out my build and I'll be mixing and matching some of the diagrams.
 
Last edited:
Ah, nevermind there it is at the bottom. Guess it pays to scroll to page two. I think I'll print it out, might be easier to trace it out than trying to sort it out on the phone.
 
Haha... yeah, that’s not a schematic you want to look at on a 4” screen! Plus the traces are likely incompletely optimized so it will take some effort to follow them.

We are trying to make these as comprehensive as possible, meaning they have too much detail - figuring it is easier to remove than add components. But if there is anything anyone needs added, we’ll try to accommodate it.
 
Quick easy question, what did you use or recommend to use to connect from panel to the end of the flow meter? BrunDog, I have the one that you have, the plastic one with the end being a 3 pin power plug.

I was thinking of using XLR like the RTD connections at panel. If you use XLR, did you just use a XLR cable or make your own with XLR ends?

I am also looking at keeping it at the 3 pin power plug with LED power cables, just need to find a panel connector for that as well.
 
You can use any 3 pin connector. I did use XLRs for all my I/O, but they aren’t the most space efficient. I put 16 XLRs in my panel not knowing what they would even be used for. Then later on when adding, I just solder in the wires. If I were to do it again, I would look for a smaller, higher density connector like Amp etc. but I would suggest to anyone building an automation control panel they drill holes and/or add connectors now so they have the I/O expansion for later. Nothing worse than needing to drill holes in an already completed enclosure!

Also yes, I just bought the panel mount and make connectors, then solder them up as needed.

Sorry, I don’t understand your last sentence re: LED power cables.
 
I was already leaning towards the XLR connection, and figured just making the cable was best course.

The LED power cables are just some extensions that have the same 3 pin connect that the flow meter has on it already. It would not be the most reliable connection to stay connected, and definitely no protection from a little water.

Thanks for the quick response!
 
augiedoggy said:
120v is easier to wire up than 240v... but as far as what your asking its the same as 240vwhen it comes to the control wiring.
You just run the ground and signal wire from two of the alloted available indicated in the arduino mega wiring chart so an ssr to control it... then the 120v power wire goes through the ssr at the other (switching) end...all that wiring is commonly shared with any 120v device whether is pid, ssvr or just switch controlled

Again,
As far as wiring it up to the arduino or controlling it with brucontrol though its exactly the same as a 240v element, you just have a hot and neutral instead of two hot wires on the high current wiring side.
Click to expand...


If you are going to use 120VAC, PLEASE run the hot wire through the SSR and not the neutral! Big safety flag!
 
BrunDog said:
I would look for a smaller, higher density connector like Amp etc.
Click to expand...

One option is Deutsch connectors. They are relatively easy to work with, have a high pin density, and have excellent environmental protection. They're used on boats, fleet vehicles, and construction equipment.
 
GParkins said:
If you are going to use 120VAC, PLEASE run the hot wire through the SSR and not the neutral! Big safety flag!
Click to expand...
I did not say to switch the nuetral that's why I said wiring the SSR up is the same with 120 or 240.
Btw some devices are ground switching like the old ricoh printers I used to work on... Here in the states it doesn't need code but it can be easier on electrical components from what I was told.
Anyway that's why you would have an actual relay in line with the SSR to ensure all the power was removed when off.
 
TenaCJed said:
Quick easy question, what did you use or recommend to use to connect from panel to the end of the flow meter? BrunDog, I have the one that you have, the plastic one with the end being a 3 pin power plug.

I was thinking of using XLR like the RTD connections at panel. If you use XLR, did you just use a XLR cable or make your own with XLR ends?

I am also looking at keeping it at the 3 pin power plug with LED power cables, just need to find a panel connector for that as well.
Click to expand...
I used XLR / aviation connectors for this as well.
 
augiedoggy said:
I did not say to switch the nuetral
Click to expand...

I wasn't suggesting that you would...far from it! My comment was more as a general safety tip geared toward the brave, but less savvy. Trying to learn electrical safety by reading some HBT threads might leave...gaps.
 
BruControl Users,

I want to inform you of a situation that a user pointed out to me today. He downloaded and unzipped BruControl from the website today, and his Windows Defender flagged the executable inside as having a Trojan virus, "Win32/Tiggre!plock". Here is more info: https://www.microsoft.com/en-us/wds...ia-description?Name=Trojan:Win32/Tiggre!plock

I downloaded the files off the website and received the same flag upon unzipping them. Windows Defender then deleted the file to protect my system. I then navigated to the folder where my current BruControl executable is running, and Windows Defender popped up again, flagging this file. It terminated the running instance of BruControl and deleted the executable. This file has been running for weeks… therefore I know this is not a hack of the files on the web.

I wanted to report this to the community as soon as I could. I am very confident BruControl does not have any virus in it. I believe the virus definition is to blame, as I see they were updated this morning. The executable it flagged has been running on my computer for weeks without any of the symptoms reported by the virus report. The registry files the virus supposedly create are not on my system. The browser extensions and automatic start files are also not on my system. The files on the website were uploaded by me, and were directly downloaded from a private, secure site from my partner.

That said, I have reported it to my partner who codes the executable and will report back as soon as he can provide any additional details. I suggest you run an scan using your anti-virus software to see if BC is flagged. If you are at all concerned, I suggest you do not run BruControl until we resolve this.
 
Last edited:
Hi BC Users,

I wanted to give an update of BruControl's virus scanner trigger issue. My development partner and I *think* that with the increase in users/people executing the application, the virus definition algorithms that define the applications to watch for has been triggered. The idea here is an application used by only a couple users won't be deemed bad but when that number of users increases, the concern level increases, hence the intervention is enforced. Because the application has encryption and a server call for the licensing, it can appear like it is sending data inappropriately to our license server.

As mentioned in our installation literature, the application is not currently digitally signed with a certificate, meaning we have not yet purchased the certificate from an authority guaranteeing the identify and of the publisher (us). We tried signing it with a "strong name" which is an interim solution, but this only improved the number of anti-virus scanners flagging the application (see before/after pics below), changing from 12 scanner triggers to 4 (determined via virustotal.com).

Therefore, our solution will be to sign the application with a certificate. This will take a bit of time but we will continue to report the status over the next few days. We appreciate your patience.

Independently, we published firmware 42Q yesterday. This includes some minor improvements for Wi-Fi users, fixes a problem with ESP8266 based devices, and improves debug mode. Stay tuned!

image001.png
image002.png
 
All, while we work on digital certification, we have begun to submit the executable to various anti-virus sites for proper evaluation. Here is the first... result from Windows Defender. As you can see they found no malware.
 

Attachments

  • IMG_0001.jpg
    IMG_0001.jpg
    257 KB · Views: 97
Latest update... Kapersky Labs has cleared the executable. Still waiting on McAfee!

Edit: Also, I just tested it with Windows Defender... it no longer gets flagged. As of this moment, Kapersky, McAfee, and ZoneAlarm flag according to virustotal.com. It will take a bit of time for the definitions to update, but we are confident this will be resolved shortly. We will also be digitally signing the application, which will also eliminate any issues.
 

Attachments

  • Kapersky Memo.pdf
    87.8 KB · Views: 87
Last edited:
All,

We uploaded BruControl version 1.0, build 28086. This version is not yet signed with a certificate, but is signed with a strong name, which improves the probability a virus scanner will not inappropriately flag is (see above reports from virustotal.com).

In addition, we uploaded v42Q of the firmware. This has some minor improvements, most specifically for debugging and Wi-Fi connections.

Finally, we uploaded the 50A version of the Universal Brewery Schematic. It is not much different than the 30A, but for those who have 50A service, it is actually simpler and easier to build.
 
I might be interested in this but in my mind it has several issues:

1: One Computer Licence. I run several different computers in my Brewery for different reasons. That would kill the deal for me as I "control"my processes from different locations with different computers.
2. Scripting fine and I could likely do it, but you need some standard script. In Fact, you need to make the interface more like Turbotax than Javascripting.
3. I once sold 100's of copies of software but in 2003 Windows made some of my internal programming obsolete. It would have required an entire re write and was not worth it. Windows is a kill for me for that reason.
4. HMI like bbralleys on the BCS would be nice.
5. I do not like building stuff like Boards and small Computers. I have a Pine 64 that has been sitting on my shelf for a year. I want a "solution", not something I have to make.
6. I try to keep my brewery isolated from the internet. I do not want a Nanny telling me I need to get a Licence if I have one.

BTW. since there are no more BCSs (no inventory), you are the one of the only games in town.
 
Hi @oakbarn,

Of course I am familiar with you due to your contributions on the BCS forum. I appreciated your guidance there when I was a BCS user, so value your opinion here.

It sounds like you have several deal breakers, so this may not be a fit for you. That said I will try to address them.

1. While individual I/O algorithms run on the micro controller interface, the automation (scripts) runs on the computer. Having multiple computers addressing the same interface will not work. Think of the host computer as an automation server. Now, if you want to address the server from different places, you can communicate with it via screen sharing applications like RDP, Chrome Desktop, etc. This allows you to use any client screen you like: PC, Mac, iPad, RPi, Android, etc. We have plans for a web interface, so you address the system via a web browser, but the server PC will need to remain.

2. I think you will find scripting very easy to use once you start. It is meant to be very powerful and flexible. I am not familiar with TurboTax but assume it is a wizard type system. All I can say is try it before you draw judgement. Remember we built this with BCS experience in mind - we felt the structured environment way to limited for true automation, so we built this with a combination of freedom and ease-of-use in mind.

3. I apologize but I don't understand what you are saying here. If Windows is a no-go for you, then unfortunately, this will not be a fit you you. We understand there are people who don't like or use Windows. We feel this is a more robust OS to build an automation server on, and have had very good success to date with it. We had original plans to compile on other OS, but ultimately determined this wouldn't be possible.

4. If you are referring to connectors, etc., yes this is planned in the future.

5. Fair enough. This is a common request. I just produced a complete interface solution for a user - MEGA controller with screw shield, Ethernet 2 shield, and a DIN rail mount. We will be offering this on the website soon. PM me if this is something you are interested in. I think you will find the I/O of the MEGA puts the BCS to shame.

6. We think it would be atypical these days for any computer to be isolated from the internet. That said, we believe our licensing system is unobtrusive. It checks for license renewal often but will not interrupt your system until a month of no internet. There are lots of benefits of course. Accessing your server from outside your home, email alerts, interface control through the internet, etc. offer some fairly powerful options.

I am interested in hearing your feedback. We are trying to make this platform very powerful yet user friendly. We might not get it perfect out of the box are intent on improving it based upon user feedback. We have had good feedback from our users so far, but welcome any insights from anyone.
 
Also, regarding #6 above, to the best of my knowledge and IIRC, on the BCS, all the screen elements are pulled from the Internet. The BCS does not have the memory to store the gauge controls etc. If you open the controller page without internet on network, I don’t think the page renders completely.
 
Having trouble getting the LCD to work. I connected a SunFounder 20x4 LCD with the I2C pack on it. Connected the SCL and SDA, power and ground. All I get on the display is the startup screen: Lines 1 and 3 with boxes and lines 2 and 4 blank. My interface is called BruControl and I don't get any errors in my script when I use the following:
new string displayInfo
displayInfo = "Hello World"
display "BruControl" 1 displayInfo

Just nothing sent to the display.

Setting displayInfo = "2" and sending
display "BruControl" 0 displayInfo

Does not clear the screen either.

I have upgraded to firmware 42Q

Must be something simple... Anyone have any ideas?
-Jay
 
Last edited:
BrunDog said:
Also, regarding #6 above, to the best of my knowledge and IIRC, on the BCS, all the screen elements are pulled from the Internet. The BCS does not have the memory to store the gauge controls etc. If you open the controller page without internet on network, I don’t think the page renders completely.
Click to expand...
This is completely untrue. The BCS does not require any internet connection at all. All screen elements are served up from the BCS.
 
JonW said:
This is completely untrue. The BCS does not require any internet connection at all. All screen elements are served up from the BCS.
Click to expand...

OK, my apologies and I stand corrected. I prefaced the statement with "to the best of my knowledge and IIRC", so I wasn't attempting to create alternative facts.
 
Last edited:
hinkensj said:
Having trouble getting the LCD to work. I connected a SunFounder 20x4 LCD with the I2C pack on it. Connected the SCL and SDA, power and ground. All I get on the display is the startup screen: Lines 1 and 3 with boxes and lines 2 and 4 blank. My interface is called BruControl and I don't get any errors in my script when I use the following:
new string displayInfo
displayInfo = "Hello World"
display "BruControl" 1 displayInfo

Just nothing sent to the display.

Setting displayInfo = "2" and sending
display "BruControl" 0 displayInfo

Does not clear the screen either.

I have upgraded to firmware 42Q

Must be something simple... Anyone have any ideas?
-Jay
Click to expand...

Hi Jay,

I just tested this with an off the shelf MEGA and backpack/LCD. I uploaded the firmware 42Q off the website to be sure (using the USB/Serial version). It is working normally. I suggest you double-check the wiring to make sure it is correct first:
Backpack <-> MEGA
GND <-> GND
5V <->5V
DAT <-> SDA (Pin 20)
CLK <-> SCL (Pin 21)

A few troubleshooting comments:
1. When you first boot up the MEGA with the LCD/BP attached, the LCD backlight should turn on, showing a lit screen but no characters.
2. If you transmit %4 in the Interface Communications screen (Settings... Interfaces... (select interface name)... Advanced...), it will re-initialize the LCD. So if you make a wiring change this *should* work without re-booting the MEGA.
3. When you first get an new LCD, the contrast may be such that you cannot read it. There is a little dial/potentiometer on the backpack that adjusts character contrast. Try looking for any characters at an angle... if you see some, adjust this pot. until the characters are more legible.
4. BruControl's communication engine has a little efficiency handling built-in which can interrupt expected LCD output results. When a message has already been sent from BC to the interface, it will not get sent again unless it has changed. Therefore re-sending the same text in your script will not actually be sent to the interface. Therefore, during troubleshooting, you should change the text before each transmit to make sure it gets sent. Here is a recommended script:

Code: 
new string displayInfo
new value count
[loop]
displayInfo = "Hello World "
displayInfo += count
display "TestMEGA" 1 displayInfo
count += 1
sleep 1000
goto loop

5. Let's get this working before sweating the screen clearing part of the script. That said, once you do, you will need to avoid the hiccup in #4 above. Here is the workaround (noted on current page 75 of the User Manual). Here, the first display code gets immediately overwritten by the second one prior to the end of the refresh interval, therefore the second message is transmitted to the interface.
Code: 
displayInfo = "1"
display "BruControl" 0 displayInfo
displayInfo = "2"
display "BruControl" 0 displayInfo

Please feel free to PM me or email us if these tips do not solve the problem.
 
Wow! For some reason Arduino's Wi-Fi 101 shield was retired a long time ago, despite the fact that the ATWINC1500 chip it was built on is a modern chip. Well, Adafruit has come to the rescue with the perfect shield for those looking to connect their MEGA's via Wi-Fi: https://www.adafruit.com/product/3654. This bad-boy has a uFL connector (they make an internal antenna also), so if you wanted to put it in a metal enclosure, you can do that and have an external antenna mounted to the enclosure on the outside. Sweet!

I have been having really good results with Wi-Fi and my impressions are changing whether this is an respectable network communication method for BruControl. Obviously Ethernet is best, but its certainly much less practical. I currently believe that if you have a quality Wi-Fi network, it should be strongly considered, depending on your application.
 
oakbarn said:
I might be interested in this but in my mind it has several issues:

1: One Computer Licence. I run several different computers in my Brewery for different reasons. That would kill the deal for me as I "control"my processes from different locations with different computers.
2. Scripting fine and I could likely do it, but you need some standard script. In Fact, you need to make the interface more like Turbotax than Javascripting.
3. I once sold 100's of copies of software but in 2003 Windows made some of my internal programming obsolete. It would have required an entire re write and was not worth it. Windows is a kill for me for that reason.
4. HMI like bbralleys on the BCS would be nice.
5. I do not like building stuff like Boards and small Computers. I have a Pine 64 that has been sitting on my shelf for a year. I want a "solution", not something I have to make.
6. I try to keep my brewery isolated from the internet. I do not want a Nanny telling me I need to get a Licence if I have one.

BTW. since there are no more BCSs (no inventory), you are the one of the only games in town.
Click to expand...


I am also a long time BCS person and I actually use it in a production craft distillery, but have PID and manual backup for the day it fails......

I really like the idea of Arduino over rPi, however I refuse to build a windows box for this, I could see a rPi used in conjunction with the Arduino, rPi being the server and Arduino doing the control, and maybe you issue an encrypted license we put on the microSD card of the rPi that is tied to a hardware address so you get reimbursed for your time... but I also have to say 100% absolutely no to Windows...

I do not mind wiring, soldering, a bit of programming, etc, but I do not want chips and resistors hanging all over and I do not have the time to design and send out for fab a custom circuit board. I don't like the idea stacking 4 rtd boards on another board and then stacking that on the arduino.. Kludgy...

I know you don't want to be a hardware company, but might I suggest one board (at least an approved PCB design) for folks that want RTDs with enough chips and connectors for 8 rtd's and the same shape as a common arduino board? I firmly believe this would pull over a big slice of customers... this could be put in the same footprint of most BCS installs Adding a pin header for a common 8/16 board relay board and maybe a RC low pass filter for the 4-20ma/0-10v valves would be icing..
 
fwiw, if there's a poll being accumulated, I'm fundamentally against software that has to phone home to mama for authorization or function.
There's nothing in Casa day_trippr that works that way.
I'm happy to buy a fairly priced license for a deserving effort and have - lots of times over the decades - but not if it needs the internet to work...

Cheers!
 
clearwaterbrewer said:
I am also a long time BCS person and I actually use it in a production craft distillery, but have PID and manual backup for the day it fails......

I really like the idea of Arduino over rPi, however I refuse to build a windows box for this, I could see a rPi used in conjunction with the Arduino, rPi being the server and Arduino doing the control, and maybe you issue an encrypted license we put on the microSD card of the rPi that is tied to a hardware address so you get reimbursed for your time... but I also have to say 100% absolutely no to Windows...

I do not mind wiring, soldering, a bit of programming, etc, but I do not want chips and resistors hanging all over and I do not have the time to design and send out for fab a custom circuit board. I don't like the idea stacking 4 rtd boards on another board and then stacking that on the arduino.. Kludgy...

I know you don't want to be a hardware company, but might I suggest one board (at least an approved PCB design) for folks that want RTDs with enough chips and connectors for 8 rtd's and the same shape as a common arduino board? I firmly believe this would pull over a big slice of customers... this could be put in the same footprint of most BCS installs Adding a pin header for a common 8/16 board relay board and maybe a RC low pass filter for the 4-20ma/0-10v valves would be icing..
Click to expand...

Our initial project scope included cross-platform compilation, but ultimately we realized two things: 1. We could not use the interface tools we wanted to, so the trade-off meant Windows as our target or an interface which didn't meet our goals (touchscreen, easy to navigate, appearance, etc.) 2. We do not believe the Raspberry Pi is a robust/reliable enough platform to build an automation controller upon. We are automating sequences which can ultimately power very high powered devices like heaters, etc. Delays, freezes, crashes, etc. and automation do not mix. It's one thing where your underlying controller is acting as a digital control panel - the user is likely nearby, so an aberrant event is perhaps managed quickly. But where the system has the capability, logic, and responsibility to run on its own, it needs to be rock solid. I am not claiming Windows is any type of guarantee, but we are confident its significantly better than RPi, most likely due to the file system hardware there based on a SD type storage card. I am certain this will spark debate, but please understand this is not the goal. We made engineering based decisions for the safety/security of our users, so for the foreseeable future, our system will be Windows based. We don't want to turn away customers, but if Windows is a deal breaker for you, I am afraid we are not your solution.

One of the benefits of open source interface microcontroller hardware is there are lots of available options at very low cost. Some are complete solutions off the shelf. Posted above are really nice industrial style PLCs that can be used without any soldering or customization. Alternatively is a unit like: http://www.digital-loggers.com/plc.html. There are a few others, but we felt users each have different needs, so it becomes a personal decision. That said, we continue to discuss hardware solutions/offerings. We may build a "universal controller" at some point in the near future, but this has lots of inherent risk as you can imagine. We are software people with fairly decent electrical knowledge, but not the time to take on this task. If there are any hardware designers who are interested in partnering, we are open to discussions!

Regarding the current options, I think we have mitigated kludgy installations with our thermistor and RTD boards - these have screw terminals and only require a few wires to be routed to the interface. There is no stacking needed for these.
 
Last edited:
day_trippr said:
fwiw, if there's a poll being accumulated, I'm fundamentally against software that has to phone home to mama for authorization or function.
There's nothing in Casa day_trippr that works that way.
I'm happy to buy a fairly priced license for a deserving effort and have - lots of times over the decades - but not if it needs the internet to work...

Cheers!
Click to expand...
not sure if a Cisco type license would work... you buy a license 'PAK', you go to a website and input the PAK and a unique hardware id and it spits out an encrypted license... once that is done, internet is not required... now, it looks like the only way to get a unique id is from the USB port, so may have to connect *something* to the USB (PC, rPi if that ever happens, or something else) that can verify the serial number matches the license... a method for de-installing the license should exist, and burning a board might require you sending the board in at a fee for partial credit towards a new one... or new software has a revocation list for the few sneaky people that fake burning a board... lots of stuff to think about...
 

Similar threads

h22lude
My BruControl UniFlex review
Replies
3
Views
2K
h22lude
h22lude
duncan.brown
Brewery Dashboard
Replies
18
Views
2K
suprchunk
suprchunk
braumke
Automate your electric brewery - 4 Testers needed for open source project
Replies
29
Views
5K
estricklin
estricklin
RonBurgundy10
BruControl Uniflex: Automation For All
2
Replies
51
Views
8K
BrunDog
BrunDog
muhteeus
muh's BruControl Build
Replies
25
Views
6K
sensei247
sensei247
BrewSwag 300

Latest posts

Back
Top