search

vitotai / BrewManiacEsp8266

BrewManiac on ESP8266. Only ESP8266 needed.
158 stars 71 forks source link

MQTT For Node Red Integration #83

Open interstaller555 opened 3 years ago

interstaller555 commented 3 years ago

is MQTT integration available for brew maniac? would want to be integrated with node red.

vitotai commented 3 years ago

Not yet. I don't have use cases. that is, I don't know how users are going to use it.

interstaller555 commented 3 years ago

Is there a way I can reach out directly? I have some pretty compelling use cases.

Sent from my iPhone

On Feb 28, 2021, at 8:43 PM, vitotai notifications@github.com wrote:

 Not yet. I don't have use cases. that is, I don't know how users are going to use it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

vitotai commented 3 years ago

You can attach files, here.

interstaller555 commented 3 years ago

The reason I would like to see node red/mqtt integrations is as follow: this is a scenario for a 10bbl brewery (mine) as well as my pilot brewery (1bbl)

System requirements: Wemos D1 mini LCD 20x4 3 Input (max31865/DS-18b20/DHT22/Hall effect/Pressure) 3 Output (relay) Control Select - PWM, Hysteresis (On/off),PID Hysteresis - support DHT, Pressure, or HE Pump Local Control (4 push Button and or Rotary Encoder) -Rotary Encoder reduces IO requirements

Layout: 2 sections 1- Pilot brewery (applies to 100% home-brew setups) -=Current Setup=- 1bbl HLT (5.5kw) Single Element (Would like to upgrade to two at some point soon) 20G Mash Tun (SSBT InfuSSion) RIMS (3.4Kw) 24VDC Heating Pad (under Tank for “Long term souring”) 1BBL BK (6.5kw) Sinlge Element - soon to be two)

Proposed Integration (1 Wemos Per Kettle)

Node Red Integration Flows control all components independently but display a unified dash. Kettle Type (HT, MLT, BK, Fermenter, Brite) Control Select: ie. HLT-PID, RIMS - PID, BK- PWM, Fermenter - Hysteresis Pump Control Recipe integration (brew father, or other) Data logging Front end interface. **Wemos retains 20x4 as well as all other local control functions. Can be set to control remote or locally Modularity allows for growth without losing current hardware. Unique ID per wemos that is tied to each controller. - important in the cellar

Cellar Home-brew or professional setup

-Pressure, Temp, control (Cooling/Heating) Tilt integration - important for spunding or fermentation hang

Automated spunding and or crash/carb on input (tilt/ispindel or time set point)

Carbonation control - set #volumes and temp - crash to temp THEN open valve for carb stone.

Retain said carbonation based on head pressure etc.

I can go into the feather valves and how I would love to be able to integrate this into my steam fired system but that just seems like too far in the future.

For Nodered via MQTT - it seems like the legwork to incorporate MQTT and allow the control is relatively easy it would also allow users to customize their hardware to suit their exact needs. Furthermore. - the cost of a few demos D1’s and being able to switch them out is significantly lower than say - losing a batch of beer because the singular memos dies or burned up or - whatever...

As a professional brewer this is where I would love to see this type of integration - as a home brewer (of 18 years) this is the kind of hands on integration that makes most sense.

/s

On Feb 28, 2021, at 9:03 PM, vitotai notifications@github.com wrote:

You can attach files, here.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vitotai/BrewManiacEsp8266/issues/83#issuecomment-787584624, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARJM2LHJZBDAD7WBPQFREHTTBLYY5ANCNFSM4YLLZKCA.

vitotai commented 3 years ago

  1. What you described is very different from BrewManiacEx. Most of the jobs done on BrewManiacEx are for automation and user interface, including Web pages. What you need is a generic wireless controller that can connect devices/sensors. CraftbeerPi might be a better choice, though I haven't spent time studying it.

  2. I would suggest ESP32 instead of ESP8266(D1 mini). ESP32 has far more pins and runs faster. It doesn't cost too much more.

  3. I prefer Rotary Encoders over buttons because only one hole is needed on the project box. However, from hardware and software aspect, buttons are better. Yes, simply better. Rotary encoder needs 3 pins, RA/RB and Push, while 3 buttons can be used as exact function: UP/DOWN and Enter. Long pressed can even be implemented for buttons.Rotary encoder works best with interrupt while polling is fine with buttons.

  4. The fermentation control is implemented as BrewPiLess, my other project. All functions except carbonation valve you mentioned are supported. ESP32 is required to support TILT, though.

BrewManiacEx is designed for single vessel E-BIAB systems. I know some people had used it in 3-vessel systems (maybe) because it is more flexible than regular PIDs, but I wouldn't recommend it. If I am going to develop a 3-vessel system, I would design a generic controller like what you describe. Because I am using an E-BIAB system, so I keep working on current BrewManiacEx.

interstaller555 commented 3 years ago

Cbpi isn’t robust enough IMO and relies solely on a pi. The automation portions of brew maniac are what I’m after - the integration with node is specifically for front end control. I have esp32 as well as d1’s - the truth is there’s not a whole lot of io requirements.I think adding mqtt support to your current software setup would do exactly what I’m after and provide the expansion abilities.

Sent from my iPhone

On Mar 2, 2021, at 8:07 PM, vitotai notifications@github.com wrote:

 What you described is very different from BrewManiacEx. Most of the jobs done on BrewManiacEx are for automation and user interface, including Web pages. What you need is a generic wireless controller that can connect devices/sensors. CraftbeerPi might be a better choice, though I haven't spent time studying it.

I would suggest ESP32 instead of ESP8266(D1 mini). ESP32 has far more pins and runs faster. It doesn't cost too much more.

I prefer Rotary Encoders over buttons because only one hole is needed on the project box. However, from hardware and software aspect, buttons are better. Yes, simply better. Rotary encoder needs 3 pins, RA/RB and Push, while 3 buttons can be used as exact function: UP/DOWN and Enter. Long pressed can even be implemented for buttons.Rotary encoder works best with interrupt while polling is fine with buttons.

The fermentation control is implemented as BrewPiLess, my other project. All functions except carbonation valve you mentioned are supported. ESP32 is required to support TILT, though.

BrewManiacEx is designed for single vessel E-BIAB systems. I know some people had used it in 3-vessel systems (maybe) because it is more flexible than regular PIDs, but I wouldn't recommend it. If I am going to develop a 3-vessel system, I would design a generic controller like what you describe. Because I am using an E-BIAB system, so I keep working on current BrewManiacEx.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

vitotai commented 3 years ago

The problem I have is that I don't have exact use cases of MQTT. To be exact, what states/signals/messages are users interested in. Obviously PUMP and TEMP are two most important ones, but how about others, like states of automation, hop schedule? It would be simple if MQTT is only supported under manual mode.

interstaller555 commented 3 years ago

I think the whole point would be to have mqtt jjst for a “manual” mode so you can create your own automation flows in node red

Sent from my iPhone

On Mar 11, 2021, at 6:19 AM, vitotai @.***> wrote:

 The problem I have is that I don't have exact use cases of MQTT. To be exact, what states/signals/messages are users interested in. Obviously PUMP and TEMP are two most important ones, but how about others, like states of automation, hop schedule? It would be simple if MQTT is only supported under manual mode.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

interstaller555 commented 3 years ago

Basically being able to have an address ID for every io with mqtt would be (IMO) the easiest way to integrate.

Sent from my iPhone

On Mar 11, 2021, at 6:19 AM, vitotai @.***> wrote:

 The problem I have is that I don't have exact use cases of MQTT. To be exact, what states/signals/messages are users interested in. Obviously PUMP and TEMP are two most important ones, but how about others, like states of automation, hop schedule? It would be simple if MQTT is only supported under manual mode.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.