• Please visit and share your knowledge at our sister communities:
  • If you have not, please join our official Homebrewing Facebook Group!

    Homebrewing Facebook Group

Native ESP8266 BrewPi Firmware - WiFi BrewPi, no Arduino needed!

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Just updated my arduino based brewpi to Fermentrack. Install and config were simple and flawless, UI looks great! Really nice to have my Tilt integrated after several failed attempts using various branches of Brewpi. This is impressive piece of work!!!

Only issue I am seeing is the control constants are blank on the configuration page. Defaults or previous settings are not loaded. I entered the constants from Brewpi default settings, it seems to take but next time I go to change a constant they are all blank again. Should settings be loaded from the EEPROM or do they all need to entered each time you want to change one setting?
 
Underneath the control constants there is a reset eeprom button. Have you tried that?

Once you press it you should have the control constants defaults but you'll have to re-assign the chamber and beer probes etc.
 
Underneath the control constants there is a reset eeprom button. Have you tried that?

Once you press it you should have the control constants defaults but you'll have to re-assign the chamber and beer probes etc.

Yes, I tried that, but all of the fields remain blank even after the reset. To change one setting I have to place values in every field in order to submit the changes.
 
I'm using an ESP8266 setup and what I would try is erasing the flash on the ESP8266 and then try to flash it again, followed by a EEPROM reset. Could you try that on the Arduino?

I have experienced the same as you and a EEPROM reset solved it. However, a bad flash to the ESP8266 and the script would not even start.

Hope you can resolve it.
 
I'm using an ESP8266 setup and what I would try is erasing the flash on the ESP8266 and then try to flash it again, followed by a EEPROM reset. Could you try that on the Arduino?

I have experienced the same as you and a EEPROM reset solved it. However, a bad flash to the ESP8266 and the script would not even start.

Hope you can resolve it.

Thanks alexlark. I have tried that reflashing the arduino and resetting the EEPROM several times to no avail. Everything seems to be functioning otherwise. The only log file showing errors is Fermentrack (Web Application), with many errors that seem to trace back to 'query.py'. I'll see if I can make any sense of the source to track this down.
 
Thanks alexlark. I have tried that reflashing the arduino and resetting the EEPROM several times to no avail. Everything seems to be functioning otherwise. The only log file showing errors is Fermentrack (Web Application), with many errors that seem to trace back to 'query.py'. I'll see if I can make any sense of the source to track this down.

PM me the errors you are seeing, and I can take a look
 
Scratch this. I got it working.
At first I had the ESP8266 flashed from Windows. Looks like that was broken.
After reflash from Fermentrack, still same error. But an EEPROM reset, this time (before the reflash was to no avail), got the sensor working.

@Thorrak , thank you for this great work!
I got an error trying to remove a controller, looks like the method expects a gravity hook up also. I will post the log in another post.

I reflashed from Fermentrack and also tried moving the OneWire from 3.3V to 5V but no luck yet. In a couple weeks when all my parts come in I'll solder up my board and try a different Temp Probe.

Code:
Aug 01 2017 19:58:29   Connection type WiFi selected.  Trying TCP serial (WiFi)
 Aug 01 2017 19:58:29   Connecting to BrewPi esp2691404.local (via 192.168.0.18) on port 23
 Aug 01 2017 19:58:36   Successfully connected to controller.
 Aug 01 2017 19:58:36   Notification: Script started for beer ''
 Aug 01 2017 19:58:46   Checking software version on controller...
 Aug 01 2017 19:58:46   Found BrewPi v0.2.4, running commit 00000000, running on an ESP 8266 on port 192.168.0.18:23

 Aug 01 2017 19:58:46   BrewPi version received was 0.2.4 which this script supports in 'legacy' branch mode.
 Aug 01 2017 19:58:46   Bound to TCP socket on port 2070, interface localhost
 Aug 01 2017 19:58:47   Installed devices received: []
 Aug 01 2017 19:58:48   Available devices received: [{"a": "28FFC99863160381", "c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 2, "j": 0.0, "p": 12, "t": 0, "v": 26.188}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 16, "t": 0, "x": 1}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 14, "t": 0, "x": 1}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 13, "t": 0, "x": 1}]
 Aug 01 2017 19:58:48   Controller debug message: INFO MESSAGE 12: Received new setting: tempFormat = F
 Aug 01 2017 20:04:58   Received applyDevice request, updating to: {"a": "28FFC99863160381", "c": 1, "b": 1, "f": 9, "i": 0, "h": 2, "j": 0.0, "p": 12}
 Aug 01 2017 20:05:03   Device updated to: {"i":0,"t":0,"c":39,"b":0,"f":-120,"h":1,"d":33,"p":-86,"x":41}
 Aug 01 2017 20:05:03   Controller debug message: ERROR 8: Cannot assign device type 0 to hardware 2
 Aug 01 2017 20:05:03   Installed devices received: []
 Aug 01 2017 20:05:03   Controller debug message: ERROR 3: Device definition update specification is invalid
 Aug 01 2017 20:05:03   Available devices received: [{"a": "28FFC99863160381", "c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 2, "j": 0.0, "p": 12, "t": 0, "v": 79.586}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 16, "t": 0, "x": 1}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 14, "t": 0, "x": 1}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 13, "t": 0, "x": 1}]

Hello @Bum Fudge . Did you find a solution for this? Or was it bad hardware issue?
I got the exact same problem, but using a generic ESP-12f board.
 
Last edited:
Scratch this. I got it working.
At first I had the ESP8266 flashed from Windows. Looks like that was broken.
After reflash from Fermentrack, still same error. But an EEPROM reset, this time (before the reflash was to no avail), got the sensor working.

@Thorrak , thank you for this great work!
I got an error trying to remove a controller, looks like the method expects a gravity hook up also. I will post the log in another post.



Hello @Bum Fudge . Did you find a solution for this? Or was it bad hardware issue?
I got the exact same problem, but using a generic ESP-12f board.

Thanks!

I’ll try to take a look at that bug shortly. Should be an easy one to squash (though if you have a log available and wouldn’t mind PMing it to me, I would appreciate it!)

Bum Fudge and I actually swapped ESPs - I haven’t been able to find a fix (but I haven’t spent as much time looking as I would have liked). When I have some time I’ll try again and post back with the results.
 
I've put together my own PCB design. Similar to Thorrak's. It's currently untested. It has logic level converters for I2C, and also a couple NPN transistors to allow for 5v outputs. I omit the door switch, buzzer, etc. Let me know if you find any errors with it if you get to them before I do. :)

on PCBs.io here: https://pcbs.io/share/4QvpO

and github here: https://github.com/jangevaare/Homebrewing-PCBs
 
Last edited:
Nice! Let me know how it goes. I've got two running at the moment, and the only issue I've encountered is the issue with WiFi not always reconnecting if the network disappears. It's on the list - I just need to get some time to fix it.

Not to pester, but did want to let you know it appears I'm affected by this. My symptom isn't quite the same but I'm guessing the fix will solve that problem as well as mine. My issue appears to be my mesh wifi network (Google Wifi). I have two routers and the ESP8266 is sitting in between the two. My suspicion is that when the ESP8266 is supposed to switch from one router to another it fails to reconnect. Unfortunately with Google Wifi you don't necessarily get a lot in the way of logs, so I attempted to confirm by unplugging one router for several hours (much longer than the ESP8266 ever managed to stay connected). With one router disconnected it's staying connected like it's meant to. I think that's the best I can do, but if there's anything else I can do to help resolve the issue, or if I'm way off base and this fix won't help me, then please let me know.
 
Not to pester, but did want to let you know it appears I'm affected by this. My symptom isn't quite the same but I'm guessing the fix will solve that problem as well as mine. My issue appears to be my mesh wifi network (Google Wifi). I have two routers and the ESP8266 is sitting in between the two. My suspicion is that when the ESP8266 is supposed to switch from one router to another it fails to reconnect. Unfortunately with Google Wifi you don't necessarily get a lot in the way of logs, so I attempted to confirm by unplugging one router for several hours (much longer than the ESP8266 ever managed to stay connected). With one router disconnected it's staying connected like it's meant to. I think that's the best I can do, but if there's anything else I can do to help resolve the issue, or if I'm way off base and this fix won't help me, then please let me know.

I've been experiencing similar. I figured it was just an issue with esp8266 tiny antenna and the fact I use a steel enclosure for my controller. I ordered a cheap antenna from aliexpress (hasn't arrived yet) that I figured would fix.
 
I'm baffled and in terrible need of help. I've built two boxes, both with esp8266 wemos d1 mini's for the controllers. I am getting very frequent errors of the temp probes disconnecting. Like multiple times per minute. I've tried new probes and new d1 mini's. I've tried wiping the SD card, reinstalling Rasbian and Fermentrack. I've checked the wiring with a multimiter. I've tried one probe at a time, but it doesn't help. The most baffling part is that I can get things hooked up and running without disconnects on my kitchen table, but when I bring it out to the garage and power it up, I start getting the probe disconnects. Doesn't matter whether I have a load on it or not.

For example, in the kitchen, I can run for an hour or more without a dropout. I can hook up a load to the cooling relay and it runs no problem. When I take it out to the garage and plug it in, Fermentrack finds the controller and reconnects it quickly, but I start getting the probe disconnections.

I'm at a loss as to what else to try for troubleshooting. Any ideas?

EDIT: So I've duplicated the errors in my kitchen and on different branch circuits in the garage. I've taken my probes off of the mini XLR jacks they were on, spliced the wires directly together to a dupont connector, and gone straight to the wemos D1 and I still get multiple connects and disconnects. I'm at a total loss...
 
Last edited:
I have a mesh router system and there's an access point in the garage. I checked the router and the boxes correctly switch between the access points when I take them out of the kitchen and to the garage. I edited my prior post as I took one of the boxes into the kitchen, cut all the probes and spliced the leads directly together to bypass the XLR connectors I was using to eliminate wiring errors. I still get the disconnects.
 
What voltage are you using for the probe VCC? 5V works best.
What size pull-up resistor to 3.3V are you using on the data line? Typical value is 4.7K but you can go numerically lower...

Cheers!
 
I'm on 3.3v because the PCB that Thorrak designed for the esp has the pull-up tied to the 3.3v, not the 5v. I'm getting exactly 3.3v across the 3.3v and gnd pins, and I'm getting 4.62k resistance across the same pins. I'm at a total loss for other troubleshooting steps.
 
The pull-up needs to be to 3.3V to be compatible with the ESP, but you can run the probe VCC on 5V without issue if you can find a way to hook it up...

Cheers!
 
Last edited:
Pictures of the box in case that triggers something for someone.
IMAG0226.jpg
IMAG0225.jpg
IMAG0224.jpg
IMAG0223.jpg
 
Yes, network connectivity is solid. I get multiple probes that disconnect and connect every few seconds in the error logs.
 
I'm using the version with the through hole components, with the RJ11 Jack. I assumed it was supposed to be a 4.7k resistor because that's what the probes call for. Would a 10k resistor fix this problem?
 
I'm using the version with the through hole components, with the RJ11 Jack. I assumed it was supposed to be a 4.7k resistor because that's what the probes call for. Would a 10k resistor fix this problem?
All of the circuits I have seen that use ds18b20 temperature sensors call for 4.7k. I just thought it was unusual that the SMD board uses a 10k. I don't think that's your problem. I would start by disconnecting the relays and feed separate 5v power to the PCB from a wall wart. There might be some type of power drop when the relays kick in. Set the tempt. in the program, so the relays never fire and see what happens.I don't know enough about this stuff to make an educated guess.Break everything out to a breadboard and see if you can get it to work without the PCB
 
Just curious-What version of thorraks board do you have? I know on the SMD version it uses a 10k for the pull up resistor.

If you're having issues, lower is better in this case. I only used 10k because that's what I had in my test build and knew it worked for me. 4.7k should work fine, but you could possibly go even lower if you're having issues.

@CadiBrewer - How long is the RJ-11 cable you have running to the sensor board/sensors?
 
If you're having issues, lower is better in this case. I only used 10k because that's what I had in my test build and knew it worked for me. 4.7k should work fine, but you could possibly go even lower if you're having issues.

@CadiBrewer - How long is the RJ-11 cable you have running to the sensor board/sensors?
I'm not using an RJ11 cable. I bought sensors with the 200cm long cables. I soldered mini XLR jacks on the ends. Inside of my box, I daisy chained the XLR jacks to each other, and then soldered DuPont connectors on the last XLR jack. The DuPont connectors go straight to the Wemos Mini pins.

Last night, to eliminate wiring issues with the XLR jacks, I cut them off and spliced and tinned all of the leads together with DuPont connectors. You can see that version in the pictures I posted. It didn't eliminate the problem.
 
All of the circuits I have seen that use ds18b20 temperature sensors call for 4.7k. I just thought it was unusual that the SMD board uses a 10k. I don't think that's your problem. I would start by disconnecting the relays and feed separate 5v power to the PCB from a wall wart. There might be some type of power drop when the relays kick in. Set the tempt. in the program, so the relays never fire and see what happens.I don't know enough about this stuff to make an educated guess.Break everything out to a breadboard and see if you can get it to work without the PCB
I appreciate the help. The sensors drop off even when the controller is in off mode and the relays aren't firing. I'll try separate power to the board with a wall wart.
 
I'm not using an RJ11 cable. I bought sensors with the 200cm long cables. I soldered mini XLR jacks on the ends. Inside of my box, I daisy chained the XLR jacks to each other, and then soldered DuPont connectors on the last XLR jack. The DuPont connectors go straight to the Wemos Mini pins.

Last night, to eliminate wiring issues with the XLR jacks, I cut them off and spliced and tinned all of the leads together with DuPont connectors. You can see that version in the pictures I posted. It didn't eliminate the problem.

Ultimately this sounds like a hardware issue.

Are you running your probes through a door/door gasket of a fermentation chamber by chance? I have seen these cheap probes have issues like you describe under light crimping. I've also seen this come up for those use CAT5/6 cable for their probes, as the solid core wire doesn't take tight bends and movement well.
 
I appreciate the help. The sensors drop off even when the controller is in off mode and the relays aren't firing. I'll try separate power to the board with a wall wart.

Are these all from the same batch of sensors? Hmm.

I didn’t see one in your photo, but do you have an LCD hooked up? If so, try flashing the “WiFi reset” image. It also has some sensor checks built in that it will run & display on the LCD if memory serves.
 
Ultimately this sounds like a hardware issue.

Are you running your probes through a door/door gasket of a fermentation chamber by chance? I have seen these cheap probes have issues like you describe under light crimping. I've also seen this come up for those use CAT5/6 cable for their probes, as the solid core wire doesn't take tight bends and movement well.

I thought this might be the case. For example, when I had the box working in my kitchen, I'd take it outside and run it on top of the keezer with no problem, with the probes laying on top. After it would run for a while, I'd open the keezer lid and put a sensor inside to cool down so I could figure out which sensor was chamber and which was beer. The dropouts would start. I thought I might be crazy because I figured that the wires were insulated and couldn't touch inside. Another point of data, when I took off the XLR jacks and spliced everything together, I knotted the ends of the sensor cables so they wouldn't pull through my enclosure. When I fired the box up, I had more frequent drop outs than when the cables were run through the XLR jacks.

But I've taken the knots out of the cables and fired things back up. I'm still getting dropouts, on the order of every minute or two instead of every 15 seconds or so. There are no kinks in the cables, but do you think that once kinked, they may be kaput? On another box, I've never knotted the cable and only put the cables under the keezer lid. The cables are no longer under the keezer lid and are run through a hole in my keezer collar with no kinks. I'm getting drops on that one, too.

These cables are from the same seller, bought two or three weeks apart after I started having trouble the first time. They are from the same seller as my original brewpi box, which worked great for two years or more. But maybe I just have a bad batch of cables? Find a new seller and order more?
 
But I've taken the knots out of the cables and fired things back up. I'm still getting dropouts, on the order of every minute or two instead of every 15 seconds or so. There are no kinks in the cables, but do you think that once kinked, they may be kaput? On another box, I've never knotted the cable and only put the cables under the keezer lid. The cables are no longer under the keezer lid and are run through a hole in my keezer collar with no kinks. I'm getting drops on that one, too.

Ya if a conductor has been broken or damaged due to bending - which seems likely, knotting is pretty extreme - bending back may provide temporary connection, but can not undo the damage... leading to the intermittent issues you describe. Changes in temperature can affect flexibility of cable as well, which may be enough to explain why the issue seems to be environment specific.
 
Ya if a conductor has been broken or damaged due to bending - which seems likely, knotting is pretty extreme - bending back may provide temporary connection, but can not undo the damage... leading to the intermittent issues you describe. Changes in temperature can affect flexibility of cable as well, which may be enough to explain why the issue seems to be environment specific.

Thanks. I'll try cutting the cable past where it was knotted and see what happens while I wait for a new batch of cables to arrive...
 

Latest posts

Back
Top