BruControl: Brewery control & automation software

Brewer's Friend 728
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.
OK, before I start to dig in and mess stuff up. Is there a trick to the Adafruit ESP32 Feather board to get it to connect back to BruControl? I flashed firmware 44J to it, configured the WiFi, choose the Tilt color and all was well. It connected to the WiFi (-53 dBm) and BC found it no problem. It showed a few connection drops in BC for a period of a couple hours. Then it dropped off the WiFi and went offline in BC. So I power cycled and reset the ESP32. This got it back on the WiFi but BC won't find it anymore. I can ping it no problem. So I flashed a couple test sketches for a web server, WiFi scanner, etc. and those all worked as expected with no issues. Flashed it back to BC 44J and I can see it on the WiFi and ping it but BC won't connect to it. I deleted it as a controller in BC and added it back but it is still disconnected. Exactly what about the BC -> Adafruit ESP32 Feather w/BC 44J ESP32 firmware relationship is not copesetic?

Any ideas how to remedy this? I am going to test reliability a bit with an example sketch to see if the board itself sans BC V44J stays on the WiFi more robustly and see if the BC firmware is somehow unique in its handling of the WiFi connection but I am not sure where to start looking. Any thoughts/past experiences?
 
Last edited:
FYI, for those evaluating the Release Candidate, we just posted v1.0.1.11. This fixed a few issues and added some functionality. One frequent concern was the number of decimals in variables (Inspectors and Globals). You can now set the precision in a script by referencing the variable's 'precision' property. Default is 3. For example:

Code: 
new value x
x = 123.4567
x precision = 2
 
VacationLand said:
OK, before I start to dig in and mess stuff up. Is there a trick to the Adafruit ESP32 Feather board to get it to connect back to BruControl? I flashed firmware 44J to it, configured the WiFi, choose the Tilt color and all was well. It connected to the WiFi (-53 dBm) and BC found it no problem. It showed a few connection drops in BC for a period of a couple hours. Then it went dropped off the WiFi and went offline in BC. So I power cycled and reset the ESP32. This got it back on the WiFi but BC won't find it anymore. I can ping it no problem. So I flashed a couple test sketches for a web server, WiFi scanner, etc. and those all worked as expected with no issues. Flashed it back to BC 44J and I can see it on the WiFi and ping it but BC won't connect to it. I deleted it as a controller in BC and added it back but it is still disconnected. Exactly what about the BC -> Adafruit ESP32 Feather w/BC 44J ESP32 firmware relationship is not copesetic?

Any ideas how to remedy this? I am going to test reliability a bit with an example sketch to see if the board itself sans BC V44J stays on the WiFi more robustly and see if the BC firmware is somehow unique in its handling of the WiFi connection but I am not sure where to start looking. Any thoughts/past experiences?
Click to expand...

Need to test again to see if any issues on our end.
 
VacationLand said:
OK, before I start to dig in and mess stuff up. Is there a trick to the Adafruit ESP32 Feather board to get it to connect back to BruControl? I flashed firmware 44J to it, configured the WiFi, choose the Tilt color and all was well. It connected to the WiFi (-53 dBm) and BC found it no problem. It showed a few connection drops in BC for a period of a couple hours. Then it dropped off the WiFi and went offline in BC. So I power cycled and reset the ESP32. This got it back on the WiFi but BC won't find it anymore. I can ping it no problem. So I flashed a couple test sketches for a web server, WiFi scanner, etc. and those all worked as expected with no issues. Flashed it back to BC 44J and I can see it on the WiFi and ping it but BC won't connect to it. I deleted it as a controller in BC and added it back but it is still disconnected. Exactly what about the BC -> Adafruit ESP32 Feather w/BC 44J ESP32 firmware relationship is not copesetic?

Any ideas how to remedy this? I am going to test reliability a bit with an example sketch to see if the board itself sans BC V44J stays on the WiFi more robustly and see if the BC firmware is somehow unique in its handling of the WiFi connection but I am not sure where to start looking. Any thoughts/past experiences?
Click to expand...

I have a dev board ESP32 arriving today, so I'll also check it out. In my experience, WiFi issues are largely related to the quality/number of radios in the access point and interference on the channel(s) you are operating on, not so much on the client side (barring firmware issues, as you noted). I put a Unifi system in a few years ago after having issues with consumer grade WiFi gear when my client count started getting high, problems solved.
 
VacationLand said:
OK, before I start to dig in and mess stuff up. Is there a trick to the Adafruit ESP32 Feather board to get it to connect back to BruControl? I flashed firmware 44J to it, configured the WiFi, choose the Tilt color and all was well. It connected to the WiFi (-53 dBm) and BC found it no problem. It showed a few connection drops in BC for a period of a couple hours. Then it dropped off the WiFi and went offline in BC. So I power cycled and reset the ESP32. This got it back on the WiFi but BC won't find it anymore. I can ping it no problem. So I flashed a couple test sketches for a web server, WiFi scanner, etc. and those all worked as expected with no issues. Flashed it back to BC 44J and I can see it on the WiFi and ping it but BC won't connect to it. I deleted it as a controller in BC and added it back but it is still disconnected. Exactly what about the BC -> Adafruit ESP32 Feather w/BC 44J ESP32 firmware relationship is not copesetic?

Any ideas how to remedy this? I am going to test reliability a bit with an example sketch to see if the board itself sans BC V44J stays on the WiFi more robustly and see if the BC firmware is somehow unique in its handling of the WiFi connection but I am not sure where to start looking. Any thoughts/past experiences?
Click to expand...

Tried running a test with the same micro... no problems yet. BC connection working and pinging simultaneously.

I would suggest running debug level 1 over serial and see what it reports, if anything when BC disconnects but you can still ping it.
 
RiverCityBrewer said:
I have a dev board ESP32 arriving today, so I'll also check it out. In my experience, WiFi issues are largely related to the quality/number of radios in the access point and interference on the channel(s) you are operating on, not so much on the client side (barring firmware issues, as you noted). I put a Unifi system in a few years ago after having issues with consumer grade WiFi gear when my client count started getting high, problems solved.
Click to expand...

Likewise experience on UniFi. I cannot believe HOW BAD my "comsumer grade" WiFi was despite buying decent brand routers... now it just works. I have a USG-3P and an AP-AC Pro for my house and they are bulletproof.
 
I upgraded from UNifi, to a true mesh setup.
IMG_2923.JPG


Anyways I am having a dropping issue, and it’s strange as well. Brun and I have been trying to suss it out.
 
BrunDog said:
Dunno... everything is in the BruControl folder... nowhere else.

Also, little trick... you can actually connect your terminal (termite) then send the control code from the communications dialog of the interface. Just send %1 - no &14 or semicolon. The debug data will come out of the serial pipe.
Click to expand...

I just used that little trick today, I like it!

I am getting a little further in remembering/understanding my system in regards to PID... For starters, my system is of the 'Bulk PV' category, that is when the valve opens or closes a certain amount, flow in the entire system is affected right away, (vs say Boil Kettle Temp, which takes a while to homogenize and is considered 'Particle PV').
My system is also is 'non-integrating', that is, moving the output in open-loop does not cause a lasting change a heating circuit would(the temp goes up if you turn the element on for a minute and then off and it takes a long time for it to come back to the intial temperature), you move my valve and then put it back, and the output changes, but then will come back to the same level in a little bit... from Recognizing Integrating (Non-Self Regulating) Process Behavior:
The heat exchanger process that has been studied on this site is self regulating. If the exchanger cooling rate and disturbance flow rate are held constant at fixed values, the exit temperature will steady at a constant value. If we increase the cooling rate, wait a bit, and then return it to its original value, the exchanger exit temperature will respond during the experiment and then return to its original steady state.
Click to expand...

what I might need is feed-forward, or add the previous control output to the new control output... as in "we want the steering wheel to move a little to the side in our self-driving car, not slam to the right or left..."


Maybe I can get this with better integral control... How is integral actually calculated in BruControl?
What is 'TInt' and how is it calculated? Is it just ('Max Integral %' * 255)?

Some things I have learned:
Integral (Ki) minimum working value is 0.005, below that, it does not change the TInt or Int value. (I would like lower to work, and to see it in the display with an extra digit if possible)
If you set the Ki to .004 or lower(including 0) and the TInt and Int values that were last present stay in the system, they do NOT go to zero unless you either disable/enable the PID or change the MaxIntegral. This can totally override and P contribution and frustrate you...

I should have a test up and running today and hope 0.005 works, it is causing the output to change by 1 unit or less every cycle, which is promising...
 
Die_Beerery said:
I upgraded from UNifi, to a true mesh setup.
View attachment 616555

Anyways I am having a dropping issue, and it’s strange as well. Brun and I have been trying to suss it out.
Click to expand...

I actually have a UniFi network at the house as well. Right now the client load and channel distribution is clean and stable. If you believe the WiFi experience values, all is well . If the wireless network is the problem, it is only related to the ESP32 wifi implementation and the network. I can add that after running an alternative sketch all night on the ESP32 , upgrading to the new BruControl RC, it starting seeing the ESP32 again once I flashed it back to 44j. Right now it is still up and running. Not sure what changed to make BC connect to it again.
 
VacationLand said:
I actually have a UniFi network at the house as well. Right now the client load and channel distribution is clean and stable. If you believe the WiFi experience values, all is well . If the wireless network is the problem, it is only related to the ESP32 wifi implementation and the network. I can add that after running an alternative sketch all night on the ESP32 , upgrading to the new BruControl RC, it starting seeing the ESP32 again once I flashed it back to 44j. Right now it is still up and running. Not sure what changed to make BC connect to it again.
Click to expand...

My ESP32 just arrived, so I'm standing it up now with 44J and v1.0.1.11. Glad you have a solid wireless foundation in place, so you can reasonably remove that part from the equation.
 
VacationLand said:
I actually have a UniFi network at the house as well. Right now the client load and channel distribution is clean and stable. If you believe the WiFi experience values, all is well . If the wireless network is the problem, it is only related to the ESP32 wifi implementation and the network. I can add that after running an alternative sketch all night on the ESP32 , upgrading to the new BruControl RC, it starting seeing the ESP32 again once I flashed it back to 44j. Right now it is still up and running. Not sure what changed to make BC connect to it again.
Click to expand...

Well my issue started with a feather MO( months ago)but it looks like (looking at the graphs of the elements) my esp33 is doing the same( just fired this one up about 5 days ago). Both on 44j. It’s also mind blowing to me since both of them are within 10ft of the AP rssi of -35 (perfect), the other curveball is that I have 2 8266 in the same room as these and they are rock solid and never drop.


The strange behavior these exhibit are loss of comms ( BC and pings) at random intervals, and then they come back on their own. In debug the micros show connected, and in the WiFi software they never drop either ( or drop signal strength).
 
Last edited:
While the ESP32 hasn't kicked out on me yet, I do see odd network related things from it compared to the 8266. Main issue is response times... 8266 typical avg was about 3ms and so far the ESP32 is about 160ms to the same AP. Going to try and get some packet captures to see if it is something network related.
 
RiverCityBrewer said:
While the ESP32 hasn't kicked out on me yet, I do see odd network related things from it compared to the 8266. Main issue is response times... 8266 typical avg was about 3ms and so far the ESP32 is about 160ms to the same AP. Going to try and get some packet captures to see if it is something network related.
Click to expand...

I have that same board and yup my ping is atrocious with only it.
 
I think I see the cause of the issue with the ESP32 chips. I was reminded of an issue when the Raspberry pi 3 boards came out and was having a problem with WiFi performance degrading when bluetooth was turned on. The issue there was that the WiFi and Bluetooth services shared the same 2.4ghz radio and antenna on the chip. I looked up the specs for the ESP32 and the radio spec is the same. It should be possible to optimize the timings for each WiFi and Bluetooth RX/TX cycle in the firmware (if it isn't already). @VacationLand, that would explain why when you put a WiFi sketch on the board it performed well, Bluetooth was likely not enabled. You could test this if you want, and I imagine the result will be the same as we are seeing now with both services enabled. I set the interface polling to 5 seconds, and I am seeing far fewer WiFi re-transmissions and it hasn't dropped.
 
clearwaterbrewer said:
I just used that little trick today, I like it!

I am getting a little further in remembering/understanding my system in regards to PID... For starters, my system is of the 'Bulk PV' category, that is when the valve opens or closes a certain amount, flow in the entire system is affected right away, (vs say Boil Kettle Temp, which takes a while to homogenize and is considered 'Particle PV').
My system is also is 'non-integrating', that is, moving the output in open-loop does not cause a lasting change a heating circuit would(the temp goes up if you turn the element on for a minute and then off and it takes a long time for it to come back to the intial temperature), you move my valve and then put it back, and the output changes, but then will come back to the same level in a little bit... from Recognizing Integrating (Non-Self Regulating) Process Behavior:

what I might need is feed-forward, or add the previous control output to the new control output... as in "we want the steering wheel to move a little to the side in our self-driving car, not slam to the right or left..."


Maybe I can get this with better integral control... How is integral actually calculated in BruControl?
What is 'TInt' and how is it calculated? Is it just ('Max Integral %' * 255)?

Some things I have learned:
Integral (Ki) minimum working value is 0.005, below that, it does not change the TInt or Int value. (I would like lower to work, and to see it in the display with an extra digit if possible)
If you set the Ki to .004 or lower(including 0) and the TInt and Int values that were last present stay in the system, they do NOT go to zero unless you either disable/enable the PID or change the MaxIntegral. This can totally override and P contribution and frustrate you...

I should have a test up and running today and hope 0.005 works, it is causing the output to change by 1 unit or less every cycle, which is promising...
Click to expand...

Integral is calculated just like every other integrator. The error is added with each cycle. The TInt is "True Int" and you will see it is a multiple of Int (just used for internal calculations).

You need a reasonable I (not the small one you think you do) and a reasonable P. Also a reasonable D to reduce the impact of input peaks. I would also extend your output window as you don't need it to respond that quickly. I'll also say that perhaps PID control is not your best route - a simple approach logic might suit the application better to keep things slow.
 
RiverCityBrewer said:
I think I see the cause of the issue with the ESP32 chips. I was reminded of an issue when the Raspberry pi 3 boards came out and was having a problem with WiFi performance degrading when bluetooth was turned on. The issue there was that the WiFi and Bluetooth services shared the same 2.4ghz radio and antenna on the chip. I looked up the specs for the ESP32 and the radio spec is the same. It should be possible to optimize the timings for each WiFi and Bluetooth RX/TX cycle in the firmware (if it isn't already). @VacationLand, that would explain why when you put a WiFi sketch on the board it performed well, Bluetooth was likely not enabled. You could test this if you want, and I imagine the result will be the same as we are seeing now with both services enabled. I set the interface polling to 5 seconds, and I am seeing far fewer WiFi re-transmissions and it hasn't dropped.
Click to expand...

Best of our understanding on ESP32 is the radios can be used simultaneously and we haven't seen the error in testing.

That said - it's time for a confession. Looking over the firmware code, it looks like we (temporarily but notsomuch) removed a safety that might be popping up here. BC sends a "heartbeat" signal to the interface when there are no device communications taking place. If the interface believes it is connected to BC but does not hear a heartbeat signal, it *should* force a disconnect, which would allow for a re-connect. This is at the software level, not the network level. The "CL" number in the debug level 1 report indicates the connection level. If it is more than 0, the heartbeat will be checked.

So, we'll publish an updated FW with this safety re-enabled. Stay tuned.
 
BrunDog said:
Integral is calculated just like every other integrator. The error is added with each cycle. The TInt is "True Int" and you will see it is a multiple of Int (just used for internal calculations).

You need a reasonable I (not the small one you think you do) and a reasonable P. Also a reasonable D to reduce the impact of input peaks. I would also extend your output window as you don't need it to respond that quickly. I'll also say that perhaps PID control is not your best route - a simple approach logic might suit the application better to keep things slow.
Click to expand...

PID is the best way to do this, absolutely 100%, positively.. it is not ever, ever, ever going to happen with hysteresis or logic.. the process needs the accuracy to within a tenth of a degree, and I had that with discrete PIDs, I am trying to see what id different with the implementation of PID in BruControl and discrete PID's, the hanging TInt and Int values were what likely threw me off, the debugging assistance you provided helped me find that and I am pretty close with those values.

You state that "Integral is calculated just like every other integrator. " Can I ask for a more understandable answer?

Yes, the 0.005 Ki is small, but how low it takes to have the output just move by 1 unit per cycle, I would like the ability to move Ki by .001, which I do not think is unreasonable, if I understand correctly, the very common Auber PID uses integral time and default is 1000, and if I=P/Ti, P is 1, and i is 1000, then it looks like I is .001... and if in BruControl, TInt is maxintegral(100)*output resolution(255) 25500 is the maximum TInt, and 255 is the max Int contribution(which makes sense), then .005 *255 - 1.275, which is about the increase in output I want (1.0 would be better, but not going to complain about that)
 
Die_Beerery said:
ESP32.
Click to expand...

yes, what interface wiring map and are there programming instructions? I am getting:
Code: 
- Review User Manual and 'Interface Wiring Map' for this interface to select appropriate firmware code.
- Firmware name is BruControl.version.interface_type.options.

1 - BruControl.44J.ESP32.W.ino.bin
- Which firmware to upload (select by number above):1
Press any key to continue . . .
esptool.py v2.6-beta1
Serial port COM13
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
 
clearwaterbrewer said:
yes, what interface wiring map and are there programming instructions? I am getting:
Code: 
- Review User Manual and 'Interface Wiring Map' for this interface to select appropriate firmware code.
- Firmware name is BruControl.version.interface_type.options.

1 - BruControl.44J.ESP32.W.ino.bin
- Which firmware to upload (select by number above):1
Press any key to continue . . .
esptool.py v2.6-beta1
Serial port COM13
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
Click to expand...
Press and hold IO0 or Flash button on the ESP32 then try to flash again.
 
It was going to be my first guess, I'm not sure how much crossover there is from the 8266 (what you are viewing there) and the 32. Looking at the IO map xml file in brucontrol there is a lot more IO available on the 32, mostly analog inputs. Unfortunately that xml file doesn't designate which pin is the one-wire.
 
RiverCityBrewer said:
It was going to be my first guess, I'm not sure how much crossover there is from the 8266 (what you are viewing there) and the 32. Looking at the IO map xml file in brucontrol there is a lot more IO available on the 32, mostly analog inputs. Unfortunately that xml file doesn't designate which pin is the one-wire.
Click to expand...

I am using 5 for my 1w.
 
Maybe I'm seeing a pattern here or maybe I am not but I'm seeing some BC connection oddities on network connected interfaces. I performed some network maintenance today and updated my router, switches and UAP firmwares (Ubiquiti gear). I have been testing the ESP32 WiFi stability so I have been monitoring my BC installation via RDP which also includes my ethernet (wired) MEGA 2560. All was well and stable for weeks on the MEGA 2560 interface and days for the ESP32 prior to the network firmware upgrades. I left BC up and running with the interfaces enabled on the most recent RC while I performed the firmware updates. Once the network firmware updates were completed and all the network devices came back online, BC would no longer connect to either interface (MEGA 2560 wired or ESP32 on WiFi). I can ping both devices and they show as actively connected and sending/receiving data so I closed BC and rebooted the Windows computer running BC but nothing changed. Disabling/enabling the interface in BC didn't have any effect either.

Another oddity is that network connected interfaces don't always "survive" the provisioning process of network devices (consider it like resetting or rebooting a consumer router). Somehow it kills the connections of the interfaces to BC even though network connectivity survives with no problems. The same computer running BC can ping the interfaces and no other devices connected to the network show any deleterious effects. If I physically reset the interface, BC recognizes the device in seconds.

So is there a routine in the BC RC itself or on the interface that once it can't find a device/connect to BC, it isn't allowing a reconnect to occur either easily or right away? How can one force BC to go and reconnect to the interfaces when the BC computer can ping the interface but BC itself says it can't reach it. I can power cycle stuff but it doesn't seem like that should be required. It just all feels a layer above simple TCP/IP connectivity and up more in the device/BC connection routines but I am just hypothesizing.
 
VacationLand said:
Maybe I'm seeing a pattern here or maybe I am not but I'm seeing some BC connection oddities on network connected interfaces. I performed some network maintenance today and updated my router, switches and UAP firmwares (Ubiquiti gear). I have been testing the ESP32 WiFi stability so I have been monitoring my BC installation via RDP which also includes my ethernet (wired) MEGA 2560. All was well and stable for weeks on the MEGA 2560 interface and days for the ESP32 prior to the network firmware upgrades. I left BC up and running with the interfaces enabled on the most recent RC while I performed the firmware updates. Once the network firmware updates were completed and all the network devices came back online, BC would no longer connect to either interface (MEGA 2560 wired or ESP32 on WiFi). I can ping both devices and they show as actively connected and sending/receiving data so I closed BC and rebooted the Windows computer running BC but nothing changed. Disabling/enabling the interface in BC didn't have any effect either.

Another oddity is that network connected interfaces don't always "survive" the provisioning process of network devices (consider it like resetting or rebooting a consumer router). Somehow it kills the connections of the interfaces to BC even though network connectivity survives with no problems. The same computer running BC can ping the interfaces and no other devices connected to the network show any deleterious effects. If I physically reset the interface, BC recognizes the device in seconds.

So is there a routine in the BC RC itself or on the interface that once it can't find a device/connect to BC, it isn't allowing a reconnect to occur either easily or right away? How can one force BC to go and reconnect to the interfaces when the BC computer can ping the interface but BC itself says it can't reach it. I can power cycle stuff but it doesn't seem like that should be required. It just all feels a layer above simple TCP/IP connectivity and up more in the device/BC connection routines but I am just hypothesizing.
Click to expand...

Hi @VacationLand. Please see my last post. My theory is that during the disconnection, the TCP pipe loses its persistency but the interface doesn’t realize it. So it thinks it’s connected to BC but isn’t. When BC tries to reconnect, that pipe is blocked because the interface is tied to the previous connection. This can be identified using serial debug level 1 reporting, to see if the interface reports CL (connection level) more than 0. The only way to resolve this is to reset the interface - far from ideal.

Per the last post, we realized we disabled a heartbeat system that forces the interface to close the connection once it stops receiving regular messages from BC. Somewhere, we disabled that (probably during testing) and have published the last few firmwares without it. We’ve re-enabled it and will publish this new FW today if possible. Sorry for the headache on this!
 
BrunDog said:
Hi @VacationLand. Please see my last post. My theory is that during the disconnection, the TCP pipe loses its persistency but the interface doesn’t realize it. So it thinks it’s connected to BC but isn’t. When BC tries to reconnect, that pipe is blocked because the interface is tied to the previous connection. This can be identified using serial debug level 1 reporting, to see if the interface reports CL (connection level) more than 0. The only way to resolve this is to reset the interface - far from ideal.

Per the last post, we realized we disabled a heartbeat system that forces the interface to close the connection once it stops receiving regular messages from BC. Somewhere, we disabled that (probably during testing) and have published the last few firmwares without it. We’ve re-enabled it and will publish this new FW today if possible. Sorry for the headache on this!
Click to expand...

Yeah, it's no problem, I just wanted to give some data that might be useful to collectively get a bigger picture. I expected that it might be the same type problem but it felt slanted towards the ESP32 and wireless due to the previous comments by myself and others. So I thought I would add more data to the collective understanding with the things I was seeing on the wired devices as well. I had not yet broke into the debug output to check CL. At this point, unless I want to actively try and break the connection again, I probably won't get to do that debugging :). I will just wait for the updated firmware. It's not that I do a lot of network updates and so the problem would be infrequent but today just so happens to be the day I pushed some firmware updates.
 
Last edited:
Hi all... please note we uploaded FW v44K. This includes the heartbeat functions to hopefully reduce disconnection issues noted above.

It is updated for MEGA and Feather M0 and ESP32... ESP8266 needs some more work yet.
 
Last edited:
Hi. Quick question... anybody care if we end support for the Yun shield? It seems these have been retired and we do not have anyone using it AFAIK. The Yun performance has been "meh" in our experience - likely due to the Linux interface interrupting the microprocessor. Comments appreciated.
 
BrunDog said:
Hi. Quick question... anybody care if we end support for the Yun shield? It seems these have been retired and we do not have anyone using it AFAIK. The Yun performance has been "meh" in our experience - likely due to the Linux interface interrupting the microprocessor. Comments appreciated.
Click to expand...

I don't have any so it doesn't bother me if you retire them :). At some point, you can't continue to support everything as resources could be better spent elsewhere.
 
Last edited:
Lol. I agree with the comment about resources/attention. Our goal has been to be micro agnostic to give our users the flexibility to use what they like for their application. But, as you’d expect, each have their idiosyncrasies, which requires some attention. So it will be better if we are good at a smaller number than be ok at them all.

One of the challenges is single source. We’d like users to have an option where to buy their hardware - and while Adafruit is a quality source with great products and service (in our experience) and likely not going anywhere, there is something to be said for buying the MEGA of your choosing practically anywhere. Adafruit’s stuff is open source so nothing is stopping an international manufacturer from replicating their stuff.

Going forward, assuming no dissenters, we’ll support:
-MEGA2560 (but I’ll warn this one will become tricky as we push the memory limits).
-Anything SAMD21/51 (M0 and M4)
-ESP32 and ESP8266/85 based
-Arduino Due (I don’t know of anyone using this one. Will likely get phased out eventually in favor of the M4 based Grand Central).

I think this will cover our different needs for a while across connectivity, I/O, and cost.
 
Last edited:
I have a general question around the things to consider when switching from a 5V board (MEGA 2560) to a 3.3V board (Adafruit Grand Central M4 Express). Is my following reasoning correct?

It looks like the TF-3, RP-3, and AA boards would all work with 3.3V Vcc, my relay boards would be powered by 5V and the input logic of 3.3V should work (2.5v - 24v required for high level realy action). Is that correct?

My simple flow totalizers say they have a 5-24v working voltage and in another spot it states 3.5v-24v. Do you think this would work in a 3.3v environment?
https://smile.amazon.com/gp/product/B00VKATCRQ/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

Are there other common sensors that would be problematic that I have missed?

I am just looking ahead so I move forward with any future integrations as future proof as possible.
 
Last edited:
Good thinking. 3.3V will pose a bit of an issue for some integrations. You are correct on the relays etc. We can also use active low (ground switched or NPN) circuits.

For 5V inputs to a 3.3V micro, a simple voltage divider makes it easy enough.
 

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
SSBrew 300

Latest posts

Back
Top